企业级大数据架构选型与设计（全）

1.1 如何构建大数据平台？

1.1.1 数据库与ER建模

1.1.1.1 数据库（DataBase）

数据库是按照数据结构来组织、存储和管理数据的仓库，是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。

数据库是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合，可视为电子化的文件柜，存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作，数据组织主要是面向事务处理任务。

1.1.1.2 数据库三范式

关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性和保证数据的一致性，这些规范就可以称为范式NF(Normal Form)，大多数情况下，关系型数据库的设计符合三范式即可。

第一范式(1NF):原子性，字段不可分

即表的列的具有原子性,不可再分解，即列的信息，不能分解。数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。如果实体中的某个属性有多个值时，必须拆分为不同的属性 。通俗理解即一个字段只存储一项信息。

举例如下,有如下订单表，购买商品一列，可以拆分为商品和数量两列。

 

第二范式(2NF)：唯一性，一个表只能说明一个事物，有主键，非主键字段依赖主键

第二范式是在第一范式的基础上建立起来的，第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分，为实现区分通常需要我们设计一个主键来实现。当存在多个主键的时候，不能存在这样的属性，它只依赖于其中一个主键，这就是不符合第二范式。通俗理解是任意一个字段都只依赖表中的同一个字段。举例如下：

学生信息表中的成绩依赖于学号和课程两个主键，但是课程学分只是依赖课程的。可以拆分成右侧的两张表。

 

第三范式(3NF)：非主键字段不能相互依赖，不存在传递依赖

满足第三范式必须先满足第二范式,第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主键字段(某张表的某字段信息，如果能够被推导出来，就不应该单独的设计一个字段来存放)。

如果某一属性依赖于其他非主键属性，而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。第三范式中要求任何非主属性不依赖于其它非主属性，即不存在传递依赖。很多时候，我们为了满足第三范式往往会把一张表分成多张表。

举例如下：

第一张表中“院校地址”是依赖于“院校”的，“院校”依赖于主键“学号”，存在传递依赖，不符合第三范式，那么需要拆解成对应的学生表和院校表两张表。

注意： 三大范式只是一般设计数据库的基本理念，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，提高读性能，就必须降低范式标准，降低范式就是增加字段，减少了查询时的关联，提高查询效率，适当保留冗余数据。这就是反范式，反范式化一定要适度，并且在原本已满足三范式的基础上再做调整的。

1.1.1.3 ER实体关系模型

ER实体关系模型（Entity-Relationship）是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式,这种建模方式基于三范式。在信息系统中，将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述。

实体（Entity）：实体是一个数据对象，指应用中可以区别的客观存在的事物。例如：商品、用户、学生、课程等。它具有自己的属性，一类有意义的实体构成实体集。在ER实体关系模型中实体使用方框表示。

属性：对实体的描述、修饰就是属性，即：实体的某一特性称为属性。例如：商品的重量、颜色、尺寸。用户的性别、身高、爱好等。在ER实体关系模型中属性使用椭圆来表示。

关系（Relationship）：表示一个或多个实体之间的关联关系。实体不是孤立的，实体之间是有联系的，这就是关系。例如：用户是实体，商品是实体，用户选购商品这个过程就会产生“选购商品数量”，“金额”这些属性，这就是关系。再如：学生是实体，课程是实体，学生选择课程这个过程就产生了“课程数量”、“分数”这些属性，这就是关系。在ER实体关系模型中关系使用菱形框表示，并用线段将其与相关的实体链接起来。

ER实体关系模型又叫E-R关系图，实体与实体之间的关系存在一对一的关系、一对多的关系、多对多的关系。

一对一关系：例如：“学生”是实体，“身份证”是实体，一个学生只能有一个身份证，一个身份证也只能对应一个学生。

一对多关系：一对多关系反过来也就成了多对一的关系。例如：“学生”是实体，“账号”是实体，一个学生有多个账号，反过来就是多个账号对应一个学生。

多对多关系：例如：“学生”是实体，“课程”是实体，一个学生可以学习多个课程，一个课程可以被多个学生学习，整体来看，学生学习课程就成了多对多的关系。

 

1.1.1.4 ER实体关系模型案例

假设在电商购物系统中，对商品、用户设计ER实体关系模型图来表示商品信息、用户购买商品之间的业务联系，完成数据库逻辑模型设计。

设计ER实体关系模型图，步骤如下：

1. 抽象出实体
2. 找出实体之间的关系
3. 找出实体的属性
4. 画出E-R关系图

以上是ER实体关系图，为了方便，我们一般可以将ER实体关系图转换成如下数据库表格式,IDEF1X格式:

1.1.2 数据仓库构建与分层

1.1.2.1 为什么构建数据仓库

在日益激烈的商业竞争中，企业迫切需要更加准确的战略决策信息。在以往的关系型数据库系统中，企业拥有海量的数据，这些数据对于企业的运作是非常有用的，但是对于商业战略决策和目标制定的作用甚微，不是战略决策要使用的信息。

关系型数据库很难将这些数据转换成企业真正需要的决策信息，原因如下：

1. 一个企业中可能有很多管理系统平台，企业数据分散在多种互不兼容的系统中。例如：一个银行中的系统分为：核心系统，信贷系统，企业贷款系统，客户关系系统，助学贷款系统，理财系统、反洗钱系统等，这些系统数据有可能存储在不同类型的关系型数据库中。
2. 关系型数据库中存储的数据一般是最基本的、日常事务处理的、面向业务操作的数据，数据一般可以更新状态，删除数据条目等。不能直接反应趋势的变化。例如：用户登录网站购买商品，在关系型数据库中最终存储的数据是某个用户下了一个订单，订单状态为付款待发货。一般用户在网站浏览了什么商品，搜索了什么样的关键字，这些数据不会存储在关系型数据库中，往往这些数据更具价值。
3. 对于战略决策来说，决策者必须从不同的商业角度观察数据，比如说产品、地区、客户群等不同方面观察数据，关系型数据库中数据不适合从不同的角度进行分析，只是面向基本的业务操作。

所以我们需要对企业中各类数据进行汇集，清洗，管理，找出战略决策信息，这就需要建立数据仓库。

 

1.1.2.2 什么是数据仓库

数据仓库，Data Warehouse，可简写为DW或DWH。数据仓库是面向主题的、集成的（非简单的数据堆积）、相对稳定的、反应历史变化的数据集合，数仓中的数据是有组织有结构的存储数据集合，用于对管理决策过程的支持。

面向主题 ：主题是指使用数据仓库进行决策时所关心的重点方面，每个主题都对应一个相应的分析领域，一个主题通常与多个信息系统相关。

例如：在银行数据中心平台中，用户可以定义为一个主题，用户相关的数据可以来自信贷系统、银行资金业务系统、风险评估系统等，以用户为主题就是将以上各个系统的数据通过用户切入点，将各种信息关联起来。如下图所示：

数据集成 ：数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息，这个过程中会有ETL操作，以保证数据的一致性、完整性、有效性、精确性。

例如某公司中有人力资源系统、生产系统、财务系统、仓储系统等，现需要将各个系统的数据统一采集到数据仓库中进行分析。在人力系统中，张三的性别为“男”，可能在财务系统中张三的性别为“M”，在人力资源系统中张三的职称为“生产部员工”，在生产系统中张三的职称为“技术经理”，那么当我们将数据抽取到数据仓库中时，需要经过数据清洗将数据进行统一、精确、一致性存储。

相对稳定： 数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，基本没有修改和删除操作，通常只需要定期的加载、刷新。

例如：某用户在一天中多次登录某系统，关系型数据库中只是记录当前用户最终在系统上的状态是“在线”还是“离线”，只需要记录一条数据进行状态更新即可。但是在数据仓库中，当用户多次登录系统时，会产生多条记录，不会存在更新状态操作，每次用户登录系统和下线系统都会在数据仓库中记录一条信息，这样方便后期分析用户行为。

反映历史变化： 数据仓库中的数据通常包含历史信息，系统地记录企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

例如：电商网站中，用户从浏览各个商品，到将商品加入购物车，直到付款完成，最终的结果在关系型数据库中只需要记录用户的订单信息。往往用户在网站中的浏览商品的信息行为更具有价值，数据仓库中就可以全程记录某个用户登录系统之后浏览商品的浏览行为，加入购物车的行为，及付款行为。以上这些数据都会被记录在数据仓库中，这样就为企业分析用户行为数据提供了数据基础。

 

 

 

 

1.1.2.3 数据仓库发展历史

1. 萌芽阶段**(1978~1988年)****。**

数据仓库概念最早可追溯到20世纪70年代，MIT(麻省理工)的研究员致力于研究一种优化的技术架构，该架构试图将业务处理系统和分析系统分开，即将业务处理和分析处理分为不同层次，针对各自的特点采取不同的架构设计原则，MIT的研究员认为这两种信息处理的方式具有显著差别，以至于必须采取完全不同的架构和设计方法。但受限于当时的信息处理能力，这个研究仅仅停留在理论层面。

2. 探索阶段。

20世纪80年代中后期，DEC公司（美国数字设备公司）结合MIT的研究结论，建立了TA2（Technical Architecture2）规范，该规范定义了分析系统的四个组成部分：数据获取、数据访问、目录和用户服务。其中的数据获取和数据访问目前大家都很清楚，而目录服务是用于帮助用户在网络中找到他们想要的信息，类似于业务元数据管理；用户服务用以支持对数据的直接交互，包含了其他服务的所有人机交互界面，这是系统架构的一次重大转变，第一次明确提出分析系统架构并将其运用于实践。

3. 雏形阶段**(1988年)**

1988年，为解决全企业集成问题，IBM公司第一次提出了信息仓库（InformationWarehouse）的概念:“一个结构化的环境，能支持最终用户管理其全部的业务，并支持信息技术部门保证数据质量”，并称之为VITAL规范（VirtuallyIntegrated Technical Architecture Lifecycle）。并定义了85种信息仓库的组件，包括数据抽取、转换、有效性验证、加载、Cube开发和图形化查询工具等。至此，数据仓库的基本原理、技术架构以及分析系统的主要原则都已确定，数据仓库初具雏形。

4. 确立阶段**（1991年）**

1991年，比尔·恩门（Bill Inmon）出版了他的第一本关于数据仓库的书《Building the Data Warehouse》，标志着数据仓库概念的确立。该书定义了数据仓库非常具体的原则，包括：

Ø 数据仓库是面向主题的（Subject-Oriented）、

Ø 集成的（Integrated）、

Ø 包含历史的（Time-variant）、

Ø 不可更新的（Nonvolatile）、

Ø 面向决策支持的（Decision Support）

Ø 面向全企业的（Enterprise Scope）

Ø 最明细的数据存储（Atomic Detail）

Ø 数据快照式的数据获取（Snap Shot Capture）

这些原则到现在仍然是指导数据仓库建设的最基本原则。凭借着这本书，Bill Inmon被称为“数据仓库之父”。

Bill Inmon主张自上而下的建设企业级数据仓库EDW （Enterprise Data Warehouse），认为数据仓库是一个整体的商业智能系统的一部分, 一家企业只有一个数据仓库，数据集市（数据集市中存储为特定用户需求而预先计算好的数据，从而满足用户对性能的需求）的信息来源出自数据仓库，在数据仓库中，信息存储符合第三范式，大致结构如下：

由于企业级数据仓库的设计、实施很困难，使得最早吃数据仓库螃蟹的公司遭到大面积的失败，除了常见的业务需求定义不清、项目执行不力之外，很重要的原因是因为其数据模型设计，在企业级数据仓库中，Inmon推荐采用3范式进行数据建模，但是不排除其他的方法，但是Inmon的追随者固守OLTP系统的3范式设计，从而无法支持决策支持（DSS -Decision Suport System ）系统的性能和数据易访问性的要求。

1994年前后，实施数据仓库的公司大都以失败告终，这时，拉尔夫·金博尔（Ralph Kimball）出现了，他的第一本书《The DataWarehouse Toolkit》掀起了数据集市的狂潮，这本书提供了如何为分析进行数据模型优化详细指导意见。

 

Ralph Kimball主张自下而上的建立数据仓库，极力推崇建立数据集市，认为数据仓库是企业内所有数据集市的集合，信息总是被存储在多维模型当中，为传统的关系型数据模型和多维OLAP之间建立了很好的桥梁，其思路如下：

 

5. 争吵与混乱（1996-1997年）

Bill Inmon(比尔·恩门)的《Building the Data Warehouse》主张建立数据仓库时采用自上而下 方式，以第3范式进行数据仓库模型设计，而Ralph Kimball(拉尔夫·金博尔)在《The DataWarehouse Toolkit》则是主张自下而上的方式，力推数据集市建设。企业级数据仓库还是部门级数据集市？关系型还是多维？Bill Inmon 和Ralph Kimball一开始就争论不休，其各自的追随者也唇舌相向，形成相对立的两派：Inmon派和Kimball派。

在初期，数据集市的快速实施和较高的成功率让Kimball派占了上风，由于数据集市仅仅是数据仓库的某一部分，实施难度大大降低，并且能够满足公司内部部分业务部门的迫切需求，在初期获得了较大成功。但是很快，他们也发现自己陷入了某种困境：随着数据集市的不断增多，这种架构的缺陷也逐步显现，公司内部独立建设的数据集市由于遵循不同的标准和建设原则，以致多个数据集市的数据混乱和不一致。解决问题的方法只能是回归到数据仓库最初的基本建设原则上来。

6. 合并（1998－2001年）

两种思路和观点在实际的操作中都很难成功的完成项目交付，1998年，Bill Inmon提出了新的BI架构CIF(Corporation information factory),把Kimball的数据集市也包容进来。CIF的核心是将数仓架构划分为不同的层次以满足不同场景的需求，比如常见的ODS、DW、DM等，每层根据实际场景采用不同的建设方案，现在CIF已经成为建设数据仓库的框架指南，但自上而下还是自下而上的进行数据仓库建设，并未统一。

以上就是到目前为止，整体数仓建设来源的过程。

1.1.2.4 数据仓库维度建模

维度建模主要源自数据集市，主要面向分析场景。

维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。它与实体-关系（ER）建模有很大的区别，实体-关系建模是面向应用，遵循第三范式，以消除数据冗余为目标的设计技术。维度建模是面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计技术。

Ralph Kimball(拉尔夫·金博尔)推崇数据集市的集合为数据仓库，同时也提出了对数据集市的维度建模，将数据仓库中的表划分为事实表、维度表两种类型。

l 事实表(面向主题的业务宽表)

发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。例如，一个按照地区、产品、月份划分的销售量和销售额的事实表如下：

1. 在以上事实表的示例中，“地区ID”、“产品ID”、“月份ID”为键值列，“销售量”、“销售额”为度量列，所谓度量列就是列的数据可度量，度量列一般为可统计的数值列。事实表中每个列通常要么是键值列，要么是度量列。
2. 事实表中一般会使用一个代号或者整数来代表维度成员，而不使用描述性的名称，例如：ID代号。上表中的“地区ID”、“产品ID”、“月份ID”就是维度列，就是观察数据的角度。使用代号或整数来代表维度成员的原因是事实表往往包含很多数据行，使用代号或整数这种键值方式可以有效减少事实表的大小。
3. 在事实表中使用代号或者整数键值时，维度成员的名称需要放在另一种表中，也就是维度表。通常事实表中的每个维度都对应一个维度表。
4. 在数据仓库中，事实表的前缀为“fact”

l 维度表（范式设计）

维度表包含了维度的每个成员的特定名称。维度成员的名称称为“属性”(Attribute)，假设“产品ID”维度表中有3种产品，例如：

1. 如上图，“产品名称”是产品维度表中的一个属性，维度表中可以包含很多属性列。
2. 产品维度表中的“产品ID”与事实表中的“产品ID”相匹配，称为“键属性”，在当前产品维度表中一个“产品ID”只有一个“产品名称”，显示时使用“产品名称”来代替，所以“产品名称”也被认为是“键属性”的一部分。

在数据仓库中，维度表中的键属性必须为维度的每个成员包含一个对应的唯一值，用关 系型数据库术语描述就是，键属性是主键列，也就是说维度表中一般为单一主键。

3. 每个维度表中的键值属性都与事实表中对应的维度相匹配，在维度表中“产品ID”类似关系型数据库中的主键，在事实表中“产品ID”类似关系型数据库中的外键，维度表和事实表就是按照键值属性“产品ID”进行关联的。在维度表中出现一次的每个键值都会在事实表中出现多次。例如上图中，产品ID 中 1111在事实表中对应多行。
4. 在数据仓库中，维度表的前缀为"dim"
   

   

    

总结 ：

在数据仓库中事实表就是我们需要关注的内容，维度表就是我们从哪些角度观察这些内容。例如，某地区商品的销量，是从地区这个角度观察商品销量的。事实表就是销量表，维度表就是地区表。

在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。

星型模型：

当所有的维度表都由连接键连接到事实表时，结构图如星星一样，这种分析模型就是星型模型。如下图，星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在下图中，时间维中存在A年1季度1月，A年1季度2月两条记录，那么A年1季度被存储了2次，存在冗余。

 

雪花模型：

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其结构图就像雪花连接在一起，这种分析模型就是雪花模型。如下图，雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的“层次”区域，这些被分解的表都连接到主维度表而不是事实表。如下图中，将地域维表又分解为国家，省份，城市等维表。它的优点是：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能，雪花型结构去除了数据冗余。

 

星型模型与雪花模型对比：

星型模型和雪花模型主要区别就是对维度表的拆分，对于雪花模型，维度表的设计更加规范，一般符合三范式设计;而星型模型，一般采用降维的操作，维度表设计不符合三范式设计，反规范化，利用冗余牺牲空间来避免模型过于复杂，提高易用性和分析效率。

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。

雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，数仓构建实际运用中星型模型使用更多，也更有效率。

此外，在数据仓库中星座模型也使用比较多，当多个事实表共用多张维度表时，就构成了星座模型。

1.1.2.5 维度建模案例

淘宝电商平台，经常需要对用户订单进行分析，以用户订单为例，使用维度建模的方式来设计模型。

以上涉及到的事实表有：订单明细表。

订单明细表中的维度有用户维度，区域维度，时间维度，商品维度，商户维度。度量有商品件数，商品金额。

用户维度表：用户ID,用户姓名，用户性别,用户年龄，用户职业，用户区域。

区域维度表：区域ID,区域名称。

时间维度表：时间ID,年份，季度，月份，天。

商品维度表：商品ID,商品名称，商品单价，商品类别，商品产地。

商户维度表：商户ID,商户名称，开店年限。

建模设计如下：

1.1.2.6 数据仓库分层设计

在大数据分析中，我们希望我们分析的数据在整个分析流程中有秩序的流转，数据的整个流程能够清晰明确的被我们掌握使用。

 

三种架构在各数据层的技术选型表（ds） 

数据分层	🏔️ 离线架构 (T+1 批处理)	⚡️ 实时架构 (秒级/毫秒级)	🔄 混合架构 (分钟级，流批一体)
ODS层 (原始数据)	Apache Iceberg (或 Apache Hudi)	Apache Paimon (配合 Flink CDC)	Apache Paimon (统一存储底座)
DWD层 (明细数据)	Apache Iceberg (Spark 批处理清洗)	Apache Paimon (Flink 流式加工)	Apache Paimon (Flink 流批一体加工)
DWM层 (中间层)	Apache Iceberg (Spark SQL 聚合)	Apache Paimon (Flink 实时聚合)	Apache Paimon (Flink 分钟级滚动聚合)
DWS层 (汇总层)	Apache Iceberg (存储预计算结果)	Apache Paimon (或直接输出至 OLAP)	Apache Paimon (轻度汇总存储)
DM层 / ADS层 (数据集市/应用)	Doris 或 StarRocks 或 ClickHouse (批量导入查询)	StarRocks 或 Doris (实时外表查询或内表导入)	StarRocks 或 Doris (外表直读 Paimon 或物化视图加速)

上图中的数据流转我们更希望得到A图中的数据流转过程。所以我们希望有一套行之有效的数据组织和管理方法来让我们的数据更有序，这就需要在数据处理中进行数据分层的原因。基于大数据的数据仓库建设要求快速响应需求，同时需求灵活多变，对实时性有不同的要求，除了面向DSS、BI等应用外，还要响应用户画像、个性化推荐、机器学习、数据分析等各种复杂的应用场景，实际上在大数据开发中，涉及到数仓设计都会进行分层设计。

数据分层好处如下：

ü 清晰的数据结构：每层数据都有各自的作用域和职责，在使用表的时候更方便定位和理解。

ü 减少重复开发：规范数据分层，开发一层公用的中间层数据，减少重复计算流转数据。

ü 统一数据出口：通过数据分层，提供统一的数据出口，保证对外输出数据口径一致。

ü 简化问题：通过数据分层，将复杂的业务简单化，将复杂的业务拆解为多层数据，每层数据负责解决特定的问题。

l ODS(Operational Data Store)层 - 操作数据层

ODS层，操作数据层，也叫贴源层，本层直接存放从业务系统抽取过来的数据，这些数据从结构上和数据上与业务系统保持一致，降低了数据抽取的复杂性，本层数据大多是按照源头业务系统的分类方式而分类的。一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可。

l DW（Data Warehouse）层 - 数据仓库层

数据仓库层是我们在做数据仓库时要核心设计的一层，本层将从 ODS 层中获得的数据按照主题建立各种数据模型，每一个主题对应一个宏观的分析领域，数据仓库层排除对决策无用的数据，提供特定主题的简明视图。DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data Warehouse Middle）层和DWS（Data Warehouse Service）层。

n 数据明细层：DWD（Data Warehouse Detail）

该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证，在ODS的基础上对数据进行加工处理，提供更干净的数据。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，当一个维度没有数据仓库需要的任何数据时，就可以退化维度，将维度退化至事实表中，减少事实表和维表的关联。例如：订单id,这种量级很大的维度，没必要用一张维度表来进行存储，而我们一般在进行数据分析时订单id又非常重要，所以我们将订单id冗余在事实表中，这种维度就是退化维度。

n 数据中间层：DWM（Data Warehouse Middle）

该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工处理数据。简单来说，就是对通用的维度进行聚合操作，算出相应的统计指标，方便复用。

n 数据服务层：DWS（Data Warehouse Service）

该层数据表会相对比较少，大多都是宽表(一张表会涵盖比较多的业务内容，表中的字段较多)。按照主题划分，如订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

在实际业务处理中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS也没有问题。

l DM(Data Mart)层 - 数据集市层

数据集市层，也可以称为数据应用层，基于DW上的基础数据，整合汇总成分析某一个主题域的报表数据。主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

1.1.2.7 数据仓库案例分析

现在以购物网站电商日志为例，来说明数据仓库分层的使用，这里我们只是关注用户产生的日志这一部分数据。

某购物网站用户可以在pc端、ipad、手机app端、微信小程序登录购物网站进行购物，用户购物会产生一些订单、浏览商品、地域登录登出等日志数据。为方便后期分析用户日志数据和订单数据更好的辅助决策，设计数据仓库分层如下：

1.1.2.8 数据库与数据仓库区别

数据库： 传统关系型数据库的主要应用是OLTP(On-Line Transaction Processing)，主要是基本的、日常的事务处理，例如银行交易。主要用于业务类系统，主要供基层人员使用，进行一线业务操作。

数据仓库 ： 数仓系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。OLAP数据分析的目标是探索并挖掘数据价值，作为企业高层进行决策的参考。

功能	数据库	数据仓库
数据范围	当前状态数据	存储历史、完整、反应历史变化数据
数据变化	支持频繁的增删改查操作	可增加、查询，无更新、删除操作
应用场景	面向业务交易流程	面向分析、支持侧重决策分析
处理数据量	频繁、小批次、高并发、低延迟	非频繁、大批量、高吞吐、有延迟
设计理论	遵循数据库三范式、避免冗余	违范式、适当冗余
建模方式	ER实体关系建模（范式建模）	范式建模+维度建模

1.1.3 大数据架构演变（数仓架构演变）

1.1.3.1 传统离线大数据架构

21世纪初随着互联网时代的到来，数据量暴增，大数据时代到来。Hadoop生态群及衍生技术慢慢走向“舞台”，Hadoop是以HDFS为核心存储，以MapReduce（简称MR）为基本计算模型的批量数据处理基础设施，围绕HDFS和MR，产生了一系列的组件，不断完善整个大数据平台的数据处理能力，例如面向KV操作的HBase、面向SQL分析的Hive、面向工作流的PIG等。以Hadoop为核心的数据存储及数据处理技术逐渐成为数据处理中的“中流砥柱”，部分技术栈如下图所示：

 

这个时期，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术在大数据场景中被广泛使用。大数据中的数据仓库构建就是基于经典数仓架构而来，使用大数据中的工具来替代经典数仓中的传统工具，架构建设上没有根本区别。在离线大数据架构中离线数仓结构如下:

 

随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。

以上离线大数据架构不能够处理实时性业务，早期，很过公司都是基于Storm来处理处理实时性比较强的业务场景，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求。而对于用户而言，其实他们并不关心底层的计算模型是什么，用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果，于是Lambda架构被提出。

1.1.3.2 Lambda架构

在Lambda架构中，为了计算一些实时指标，就在原来的离线数仓基础之上增加了一个实时计算的链路，并对数据源做流式改造：把消息发送到消息队列中（大数据中常用Kafka），实时计算去消费消息队列中的数据，完成实时指标计算，推送到下游的数据服务中去，由数据服务层完成离线与实时结果的合并。

Lambda架构中数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark Streaming），去计算实时的一些指标，保证数据实时性；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见，保证数据有效、准确性。

根据实时业务统计的复杂程度Lambda架构也分为以下两种情况。

l 离线数据+实时处理链路(传统实时开发)

根据实时链路中实时指标计算的复杂程度，开始实时业务不复杂，都是“烟囱（cong）式”开发设计，不需要构建实时数仓，我们可以选择不分层，这种场景下Lambda架构中是由离线数仓和实时业务处理部分组成，这部分实时还达不到叫做实时数仓阶段，只能叫做实时处理链路，其结构如下：

 

注意：“烟囱式”开发：在一个有一定规模的企业中，通常都会存在各种各样的应用系统，它们分别由企业的各个不同部门、在各种不同历史时期、为满足各种不同业务目的而开发。由于数据格式没有统一规范，相互之间没有联通、数据更没有整合，像一个个烟囱，因此称其为“烟囱式系统”。同样，在数据处理过程中，各个数据处理程序之间不能很好做到数据规范统一、处理数据流程统一、数据复用，各自独立，叫做“烟囱式”开发。

l 离线数仓+实时数仓

随着企业实时业务增多，统计的实时指标越来越多，复杂程度也越来越高，为了在实时链路中更好的复用数据，这是就有必要在实时链路中加入数据分层设计，构建真正的实时数仓。这种场景下Lambda架构中是由离线数仓和实时数仓两部分组成，其结构如下：

 

以上Lambda架构中“实时处理链路”这种传统实时与“实时数仓”区别在于，传统实时“烟囱式”开发导致代码耦合问题严重，当需求越来越多，有时需要明细数据，有时需要OLAP分析，这种模式难以应付这些需求，缺少完善的规范。“实时数仓”在保证数据实时性的前提下，实现了数据基于数据仓库管理，更加统一规范化，稳定性和业务性更强。

在Lambda架构中流处理计算的指标批处理依然计算，最终以批处理结果为准，即每次批处理计算后会覆盖流处理的结果，这是由于流处理过程中不完善做的折中办法，由数据服务处理，其功能主要是合并离线计算和实时计算结果。例如：在统计实时交易订单时，可能实时统计的结果需要当日分钟级别向外展示，T+1后才能展示昨日总的交易订单数，显然，后者是T+1每日离线批处理统计结果，那么假设当日有些用户进行了订单取消有可能T+1后统计统计结果与当日实时展示数据出现不一致问题，那么这里就需要使用数据服务来进行处理，统一数据，决定如何使用数据。

Lambda数据架构成为每一个公司大数据平台必备的架构，它解决了一个公司大数据批量离线处理和实时数据处理的需求。Lambda架构的核心理念是“流批一体”，如上图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过统一服务层对应用提供，确保访问的一致性，底层到底是批或流对用户透明。经历多年的发展，Lambda架构优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰分开，但是它也有一些致命缺点：

1. 同样的需求需要开发两套一样的代码

这是Lambda架构最大的问题，针对同一个需求需要开发两套代码，一个在批处理引擎上实现，一个在流处理引擎上实现，在写好代码后还需构造数据测试保证两者结果一致，另外，两套代码对于后期维护也非常麻烦，一旦需求变更，两套代码都需要修改，并且两套代码也需同时上线。

2. 集群资源使用增多

同样的逻辑需要计算两次，整体占用资源会增多。虽然离线部分是在凌晨运行，但是有可能任务多，在凌晨时造成集群资源使用暴增，报表产出效率就有可能下降，报表延迟对后续展示也有影响。

3. 离线结果和实时结果不一致

在此架构中经常我们看到次日统计的结果比昨晚的结果要少，原因就在于次日统计结果和昨日统计结果走了两条线的计算方式：次日统计结果是按照批处理得到了更为准确的批量处理结果。昨晚看的结果是通过流式运行的结果，依靠实时链路统计出的实时结果（实时结果统计累加），牺牲了部分准确性。对于这种来自批量和实时的数据结果对不上的问题，无解。

4. 批量计算T+1可能计算不完

随着物联网时代的到来，一些企业中数据量级越来越大，经常发现夜间运行批量任务已经无法完成白天20多个小时累计的数据，保证早上上班前准时出现数据已成为部分大数据团队头疼的问题。

5. 服务器存储大

由于批流两个过程都需要将数据存储在集群中，并且中间也会产生大量临时数据，会造成数据急速膨胀，加大服务器存储压力。

1.1.3.3 Kappa架构

随着Flink等流式处理引擎的不断完善，流处理技术相关的技术成熟发展（例如：Kafka、ClickHouse），针对Lambda架构的需要维护两套程序等以上缺点，LinkedIn的Jay Kreps结合实际经验和个人体会提出了Kappa架构。

Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用同一套代码。此外Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算，而如果需要重复计算时，Kappa架构下可以启动很多个实例进行重复计算,方式是通过上游重放完成(从数据源拉取数据重新计算)。

Kappa架构就是基于流来处理所有数据，流计算天然的分布式特征，注定了他的扩展性更好，通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。其架构如下：

Kappa架构构建的数仓当之无愧称为实时数仓，Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。重新处理数据看似比较麻烦，但在Kappa架构中并不复杂，其步骤如下：

1. 选择一个具有重放功能，能够保存历史数据的消息队列，根据要求设置历史数据保存时长，例如:Kafka，可以设置保存全部历史数据。
2. 当某个或某些指标有重新处理的需求时，按照新逻辑编写新的作业，然后从上游消息队列最开始地方重新消费数据，把结果写往一个新的下游结果表。
3. 当新作业赶上进度后，切换数据源，读取新作业产生的结果表。
4. 停止老的作业，删除老的结果表。

另外，Kappa 架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。

Kappa架构也有一定的缺点，其缺点例如：Kappa架构由于采集的数据格式不统一，每次都需要开发不同的Streaming程序，导致开发周期长。更多Kappa架构的问题在实时数仓发展趋势中讨论。

1.1.3.4 混合架构

传统离线大数据架构已经不能满足一些公司中实时业务需求，因为随着互联网及物联网发展，越来越多的公司多多少少涉及一些流式业务处理场景。由Lambda离线数仓+实时数仓架构到Kappa实时数仓架构，都涉及到实时数仓开发，那么现实业务开发中到底使用Lambda架构还是Kappa架构？

我们可以先看下以上三个架构之间的区别：

对比项	传统离线大数据架构	Lambda架构	Kappa架构
实时性	离线（无法处理实时业务）	离线+实时	实时（批流一体）
计算资源	只有批处理	批和流同时运行，资源消耗大	只有流处理，资源开销小
重新计算时吞吐量	批处理全量处理，吞吐量大	批处理全量处理，吞吐量大	流式全量处理，吞吐较批处理全量要低一些
开发、测试难度	批处理一套代码，开发、测试、上线难度小	批处理和流处理相同逻辑两条代码，开发、测试、上线难度大	只需实现一套代码，开发、测试、上线难度相对较小
运维成本	维护一套引擎，运维成本小	维护两套引擎，运维成本大	维护一套引擎，运维成本小

通过以上对比来看，三者对比结果如下：

从架构上来看 ，三套架构有比较明显区别，真正的实时数仓以Kappa架构为主，而离线数仓以传统离线大数据架构为主，Lambda架构可以认为是两者的中间态。目前在业界中所说的实时数仓大多是Lambda架构，这是由需求决定的。

从建设方法上来看 ，实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出事实宽表。另外实时数仓中实时流数据的join有隐藏时间语义，在建设中需注意。

从数据保障上来看 ，实时数仓因为要保证实时性，所以对数据量的变化较为敏感，在大促等场景下需要提前做好压测和主备保障工作，这是与离线数仓较为明显的一个区别。

目前在一些没有实时数据处理场景公司中，使用传统离线大数据架构居多，在这些公司中离线大数据架构性价比高，比较实用。

在一些涉及到实时业务场景的公司，在实际工作中到底选择哪种架构，需要根据具体业务需求来决定。很多时候并不是完全规范的Lambda架构或者Kappa架构，可以是两者的混合，比如大部分实时指标统计使用Kappa架构完成计算，少量关键指标使用Lambda架构用批处理重新计算，增加一次校对过程。为了应对更广泛的场景，大多数公司采用这种混合架构，离线和实时数据链路都存在，根据每个业务需求选择在合适的链路上来实现。注意：这种方式并不是Lambda架构，例如：某企业有多个业务模块，某些业务模块需要运行在Lambda架构中，某些业务模块需要运行在Kappa架构中。

1.1.3.5 实时数仓发展趋势

当前基于Hive的离线数据仓库已经非常成熟，随着实时计算引擎的不断发展以及业务对于实时报表的产出需求不断膨胀，业界最近几年就一直聚焦并探索于实时数仓建设。根据数仓架构演变过程，在Lambda架构中含有离线处理与实时处理两条链路，其架构图如下：

正是由于两条链路处理数据导致数据不一致等一些列问题所以才有了Kappa架构，Kappa架构如下：

Kappa架构可以称为真正的实时数仓，目前在业界最常用实现就是Flink + Kafka，然而基于Kafka+Flink的实时数仓方案也有几个非常明显的缺陷，所以在目前很多企业中实时数仓构建中经常使用混合架构，没有实现所有业务都采用Kappa架构中实时处理实现。Kappa架构缺陷如下：

1. Kafka无法支持海量数据存储。对于海量数据量的业务线来说，Kafka一般只能存储非常短时间的数据，比如最近一周，甚至最近一天。
2. Kafka无法支持高效的OLAP查询，大多数业务都希望能在DWD\DWS层支持即席查询的，但是Kafka无法非常友好地支持这样的需求。
3. 无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系。需要重新实现一套数据血缘、数据质量管理体系。
4. Kafka不支持update/upsert，目前Kafka仅支持append。实际场景中在DWS轻度汇聚层很多时候是需要更新的，DWD明细层到DWS轻度汇聚层一般会根据时间粒度以及维度进行一定的聚合，用于减少数据量，提升查询性能。假如原始数据是秒级数据，聚合窗口是1分钟，那就有可能产生某些延迟的数据经过时间窗口聚合之后需要更新之前数据的需求。这部分更新需求无法使用Kafka实现。

所以实时数仓发展到现在的架构，一定程度上解决了数据报表时效性问题，但是这样的架构依然存在不少问题，随着技术的发展，相信基于Kafka+Flink的实时数仓架构也会进一步往前发展，那么到底往哪些方向发展，我们可以结合大公司中技术选型可以推测实时数仓的发展大致会走向“批流一体”。

最近一两年中和实时数仓一样火的概念是“批流一体”，那么到底什么是“批流一体”？在业界中很多人认为批和流在开发层面上都统一到相同的SQL上处理是批流一体，也有一些人认为在计算引擎层面上批和流可以集成在同一个计算引擎是批流一体，比如：Spark/SparkStreaming/Structured Streaming/Flink框架在计算引擎层面上实现了批处理和流处理集成。

以上无论是在业务SQL使用上统一还是计算引擎上的统一，都是批流一体的一个方面，除此之外，批流一体还有一个最核心的方面就是存储层面上的统一。这个方面上也有一些流行的技术：delta/hudi/iceberg,存储一旦能够做到统一，例如：一些大型公司使用Iceberg作为存储，那么Kappa架构中很多问题都可以得到解决，Kappa架构将变成个如下模样：

这条架构中无论是流处理还是批处理，数据存储都统一到数据湖Iceberg上，这一套结构将存储统一后，解决了Kappa架构很多痛点，解决方面如下：

1. 可以解决Kafka存储数据量少的问题。目前所有数据湖基本思路都是基于HDFS之上实现的一个文件管理系统，所以数据体量可以很大。
2. DW层数据依然可以支持OLAP查询。同样数据湖基于HDFS之上实现，只需要当前的OLAP查询引擎做一些适配就可以进行OLAP查询。
3. 批流存储都基于Iceberg/HDFS存储之后，就完全可以复用一套相同的数据血缘、数据质量管理体系。
4. 实时数据的更新。

上述架构也可以认为是Kappa架构的变种，也有两条数据链路，一条是基于Spark的离线数据链路，一条是基于Flink的实时数据链路，通常数据都是直接走实时链路处理，而离线链路则更多的应用于数据修正等非常规场景。这样的架构要成为一个可以落地的实时数仓方案、可以做到实时报表产生，这得益于Iceberg技术：

l 支持流式写入-增量拉取

流式写入其实现在基于Flink就可以实现，无非是将checkpoint间隔设置的短一点，比如1分钟，就意味每分钟生成的文件就可以写入到HDFS，这就是流式写入。但是这里有两个问题，第一个问题是小文件很多，但这不是最关键的，第二个问题才是最致命的，就是上游每分钟提交了很多文件到HDFS上，下游消费的Flink是不知道哪些文件是最新提交的，因此下游Flink就不知道应该去消费处理哪些文件。这个问题才是离线数仓做不到实时的最关键原因之一，离线数仓的玩法是说上游将数据全部导入完成了，告诉下游说这波数据全部导完了，你可以消费处理了，这样的话就做不到实时处理。

数据湖就解决了这个问题。实时数据链路处理的时候上游Flink写入的文件进来之后，下游就可以将数据文件一致性地读走。这里强调一致性地读，就是不能多读一个文件也不能少读一个文件。上游这段时间写了多少文件，下游就要读走多少文件。我们称这样的读取叫增量拉取。

l 解决小文件多的问题

数据湖实现了相关合并小文件的接口，Spark/Flink上层引擎可以周期性地调用接口进行小文件合并。

l 支持批量以及流式的Upsert(Delete)功能

批量Upsert/Delete功能主要用于离线数据修正。流式upsert场景上文介绍了，主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的，而离线数仓做更新的话需要全量数据覆盖，这也是离线数仓做不到实时的关键原因之一，数据湖是需要解决掉这个问题的。

l 支持比较完整的OLAP生态

比如支持Hive/Spark/Presto/Impala等OLAP查询引擎，提供高效的多维聚合查询性能。

目前Iceberg部分功能还在开发中，有一些功能还不完善，但是整体实时数仓的发展会大致朝着这个方向行进。目前业界大多数公司还是处于Lambda架构，使用Kappa架构的公司一般都是实时业务居多的公司，随着数据湖技术的发展，这些公司实时数仓的构建慢慢会走向最终的“批流一体”。

 

1.2 各大公司实时数仓 实践

1.2.1 网易实时数仓实践

此架构是基于Kudu的实时数据数仓，通过Data Stream自己写的数据采集工具来采集日志数据写入Kafka，使用NDC(类似CDC)服务可以将binlog数据推送到Kafka，通过Flink读取Kafka数据结果写入Kudu,基于Kudu构建实时数仓好处就是延迟低（毫秒/秒级）；支持upsert；支持水平扩展。但是也存在一些问题，例如：突然数据量增多，基于内存会有很大的Compaction操作，会造成数据服务不可用;数据孤岛问题，Kudu很难与HDFS中的数据做贯通，形成数据孤岛；不支持更新主键。

1.2.2 汽车之家实时数仓实践

在2016年汽车之家使用Storm构建实时平台，存在很多痛点，例如：纯编码方式开发，开发成本高；Storm不支持状态，当有状态业务是借助Redis实现，计算效率低，假设数据扩增多，Redis集群扩容不及时容易产生问题；Storm不支持SQL开发，对数仓不友好等。

2019年之后所有实时业务转向Flink处理，使用以上架构，以上架构中数据接入包含三部分：Client log 、Server log 、DB CDC，三部分数据内容如下：

Client log:在汽车之家大部分数据都是端的数据，例如：用户手机端,PC端，数据包含用户行为数据，例如：浏览数据，播放数据时长日志。

Server log:包含数据质量监控的日志，服务端的日志，主要用来做一些监控报警，例如：Nginx日志，各种web应用的日志，各种中间件的日志，大数据各种应用的底层日志。

DB CDC: 各种实时大屏，日志看板，例如：实时订单展示。

在上面架构中数据接收后通过Flink处理写入Kafka主要原因是来自Client log 、Server log 、DB CDC 数据格式是不统一的，通过Flink处理后，将格式统一成规范的json数据再写入Kafka。数据写入Redis和ES的主要作用是做实时数据缓存。最终这些Flink处理后的数据用来BI展示、推荐、风险控制、实时监控。

1.2.3 顺丰实时数仓实践

顺丰是国内领先的快递物流综合服务商， 顺丰使用大数据服务支撑了高质量的物流服务，其快递流转过程如下：

正是由于复杂的业务所以构建数仓。早期采用了Lambda架构构建数仓，随着实时业务增多，Lambda架构的弊端也慢慢凸显，后期改为实时数仓。

实时数仓和离线数仓实际上解决的都是相同的业务问题，最大的区别在于时效性，离线数仓有小时级和天级的延迟，而实时数仓则是秒级和分钟级的延迟，其他部分都相似，例如：数据源、数据存储、数据开发都是比较相近。为了解决开发者的割裂感，将离线和实时业务进行统一，并且可以通过实时的引擎来加速离线报表产出。 顺丰实时数仓架构如下：

以上架构中 使用Hudi来加速宽表数据，这个是如何实现的？

Hudi的关键特性如下：

l 可回溯历史数据

l 在大规模数据集中更新删除

l 根据主键更新删除

l 在数据写入时支持复制

l 在数据读取时支持聚合

l 支持视图，增量视图和实时视图

l Hudi可以作为数据源发出增量数据

l 异步压缩小文件，合并小文件

以ODS层为例，在ODS层引入Hudi可以使原来ODS层T+1抽取数据变为实时抽取数据，同时使用Flink消费Kafka中的数据，获取增量数据，通过Hudi将数据增量更新到Hive DWD等宽表中，将离线增量转变为实时增量。

注意：Hudi写入的过程是批处理的过程，且Hudi强依赖于Spark，顺丰对Hudi进行了修改完善。

1.2.4 腾讯实时数仓实践

腾讯内部有QQ音乐、腾讯广告、腾讯看点、小程序、视频号等业务线每天数据量在万亿级别，这些服务线在构建各自的数据分析平台时采用的数据平台架构如下：

以上数据平台架构中，常常会使用一些离线调度系统定期调度Spark任务进行数据接入、ELT、展示过程，例如针对腾讯看点业务线，数据前方会有埋单，通过数据服务将数据接入到数据仓库，再通过ES/MySQL/ClickHouse对外提供数据展示。整个过程中,对于离线平台，数据接入、处理数据延迟一般是小时级别或者T+1级别，为了一些实时性需求，最初采用的是Lambda架构，分为批流两条线路，在实时链路中采用Flink处理，离线中使用Spakr进行处理，Lambda架构有一些痛点，例如：大大增加数据仓库阶段中组件复杂度、运维成本增加、数据不一致等，所以后期转换到基于Flink+Kafka的Kappa架构，在Kappa架构中也有痛点，例如：

l 对消息队列存储要求高，消息队列的回溯能力不及离线存储

l 消息队列本身对数据存储有时效性，且当前无法使用OLAP引擎直接分析消息队列中的数据

l 全链路依赖消息队列的实时计算可能因为数据的时序性导致结果不正确

最后决定升级改造Kappa架构，基于Flink+Iceberg来针对实时数据流构建实时数仓，架构如下：

腾讯采用的是Flink+Iceberg方式构建实时数仓，其架构图如上，即将原有Kappa架构中的Kafka替换成了Iceberg,有如下好处：

l 实现了存储层的流批统一，存储成本降低

l 中间层支持OLAP分析，可以基于Iceberg针对实时数仓中的某些层做一些OLAP分析，将结果输出到下游。

l Iceberg底层存储依赖于HDFS并且支持列式存储，可以基于中间某些层使用Flink做一些计算，那么可以将原来Kappa架构中离线链路中天级别延时降低到小时级别或者分钟级别。

将Kappa架构改造之后实际上也带来了一些缺点，例如：向Kafka中写数据与向HDFS中写数据相对比，肯定是向Kafka中写数据更快，所以将Kafka替换成Iceberg之后，数据延迟从实时变成近实时；Iceberg对接其他数据系统需要额外的开发工作，不如Kafka完善。这些缺点可以认为是Iceberg目前发展不完善导致，随着Iceberg的发展，这些问题也会一一得到解决。

1.2.5 滴滴实时数仓实践

在2019年之前，滴滴内部都是自建的实时服务，没有统一规定实时引擎，这些自建服务中包含Spark和Flink任务，开发成本比较高，使用低级api的方式进行业务开发。这个阶段更多的是业务驱动，没有专门的实时数仓概念,大家都是分散建设。

在2019年之后，公司内部统一了实时计算的引擎为Flink,并且对Flink引擎内部做了一些增强，实时数仓正式在某些业务上进行实践。在2020年下半年，公司内部对实时开发平台进行升级，实时数仓建设主要集中在任务统一规划和数仓规范性建设方面。目前，在滴滴中每日运行核心作业150+，覆盖的核心指标有200+(包括了公司各个业务线的产品)，资源总量10000+（core），各个业务线产品包含：滴滴出行（网约车，拼车各个业务线）、滴滴顺风车独立业务线、DIDI广告业务独立业务线、橙心优选独立业务线，体系架构如下：

以上体系架构图就是滴滴整体业务架构图，底层是数据源，中间也做了数据仓库分层，包括ODS层，DWD明细层是将ODS层数据库binlog、Public Log、Topic、消息队列同步过来，DWD包含三类数据：业务数据（订单交易），流量数据（主要是埋点获取用户行为数据，用作用户分析），维度数据（用户数据、司机数据、车辆行驶数据、拍照数据等维度数据），DWM层就是指标汇总层，对一些核心的指标做一些汇总，包括：冒泡、呼单、完单、PV、UV、财务、安全等。APP层更多是关于数据展现，包括数据看板，数据产品，还包含实时接口服务（主要提供给数据使用方，例如数据监管，保证数据一致性等），OLAP分析（数据检验，临时性业务分析）等。最上面是面向某些特定用户提供平台使用，如：高管、运营、业务、分析、开发。左侧数据体系建设规范包括表命名规范，字段命名规范，任务调度规范，数据规范、运维规范等。右侧是内部开发计算引擎平台。

滴滴整体数据链路架构图如下：

数据链路最左侧是数据源，通过平台任务汇集到ODS层Kafka、DDMQ(滴滴内部自研消息队列) ，后经Flink进行数据清洗和维度建设，维度存入HBase，数据经过清洗落入DWD层，再经过一些核心Flink任务，数据落入DWS层，在这两层有一些OLAP任务（部分核心任务基于DWD、DWS层进行OLAP查询分析），针对DWS层再经过一些Flink任务数据还会做一些指标汇总形成DM汇聚层，这一层对外提供数据服务形成APP层，APP层主要是一些产品、看板、报表、接口调度服务，主要是数据应用，包括构建指标体系，帮助业务同学看清业务发展情况、针对营销活动（补贴，营销活动），看到活动效果，快速进行策略调整、针对反作弊场景，构建算法策略，快速识别风险。目前消息队列使用的是Kafka和DDMQ,维度数据存入HBase, OLAP引擎正在由Druid向ClickHouse迁移。

1.3 业务处理架构设计实现

 

2 Doris和ck和StarRocks和 Apache Paimon Apache Iceberg Apache Hudi这几者的区别是什么，分别应用于（ods、dwd,dwm,dws.dm）层

数据湖格式：统一存储底座

这套工具主要负责数据的存储、组织和可靠管理。

 

工具	阵营	一句话定位	优势	短板
Apache Iceberg	批处理标准派	面向批处理的标准湖仓格式	开放标准，与计算引擎解耦；元数据设计高效，适合PB级数据	原生流式处理能力较弱，数据更新延迟为分钟级
Apache Hudi	平衡效率派	在批流之间寻求平衡的格式	支持增量数据处理（Upsert/Delete），更新性能较好	社区和生态普及度相比 Iceberg 略逊一筹
Apache Paimon	实时流式先锋	专为 Flink 设计的流式湖仓格式	原生流式写入，毫秒级可见，使用 LSM 树结构，更新性能最强	批处理能力相对较弱，生态较新

📍 OLAP 引擎：高性能计算引擎

这套工具则主要负责对数据进行快速的计算和分析。

 

工具	阵营	一句话定位	优势	短板
ClickHouse	极致单表性能派	追求极致单表性能的典范	单表、大宽表聚合查询性能极高，压缩比出色	多表关联能力较弱；Upsert/Delete 操作重度
Apache Doris	均衡易用派	易用、均衡的实时分析型数据库	支持 MySQL 协议，学习成本低。查询性能均衡，支持高并发点查	在大规模、极致复杂查询场景下，性能可能略逊于ClickHouse或StarRocks
StarRocks	性能+易用融合派	融合高性能与易用性的新一代MPP引擎	向量化执行引擎强大；支持主键更新，实时能力强；支持物化视图	社区生态相比 ClickHouse 和 Doris 还不够成熟

🏗️ 数仓分层中的角色扮演

在一个典型的现代数据仓库（或湖仓一体）架构中，它们各自扮演着不同的角色。从数据源到最终的应用，可以这样来规划：

 

分层	推荐使用技术（存储）	推荐使用技术（计算）	主要任务与阶段场景
ODS (操作数据存储层) 原始数据，与源系统基本一致。	Paimon / Hudi	Flink	通过 Flink CDC 将业务数据（如MySQL Binlog）毫秒级写入Paimon/Hudi表，构成ODS层。
DWD (明细数据仓库层) 数据清洗、标准化，以业务过程为核心。	Paimon / Iceberg	Flink / Spark	Flink/Spark 读取ODS层数据，进行ETL清洗（去重、纠错、关联维度）后写入DWD层。
DWM (数据中间层) 或 DWS (汇总数据仓库层) 轻度/高度聚合，以数据域为核心，面向分析主题。	Paimon / Iceberg	Flink / Spark	Flink/Spark 读取DWD数据，按主题进行轻/高度聚合（如用户、商品）后写入DWS层。
DM (数据集市层) 面向具体应用（如图表、报表）。	Doris / StarRocks	Doris / StarRocks	直接支撑BI报表、实时大屏、用户画像等高并发、低延迟的查询。
DIM (维度层，可单独列出) 存储维度属性（如“用户”、“商品”）。	Iceberg / Hudi	Flink / Spark	可由Flink/Spark加工后写入Hudi/Iceberg等湖格式存储。查询时再加载至Doris/StarRocks。

三种架构模式技术栈对比

 

技术栈	🏔️ 离线架构 (T+1)	⚡️ 实时架构 (秒级/毫秒级)	🔄 混合架构 (分钟级，流批一体)
核心目标	处理海量历史数据，追求高吞吐和稳定性	追求极致的低延迟，数据产生即可见	平衡吞吐与延迟，简化架构，一份数据同时支持流和批处理
数据摄入	Sqoop / DataX 全量/增量同步	Flink CDC 监听变更日志	Flink CDC / Spark Streaming (微批)
消息中间件	(通常不需要)	Kafka / Pulsar	Kafka / Pulsar (可选)
存储底座	HDFS	-	Apache Paimon (首选) / Apache Hudi, Iceberg
分层加工	Hive / Spark SQL 调度作业	Flink SQL 流式加工	Flink SQL / Spark 流式加工
查询分析层	Hive / Spark SQL	Doris / StarRocks / ClickHouse	Doris / StarRocks
调度与开发	Airflow / DolphinScheduler	Flink 作业持续运行	Flink / Spark 作业 + 调度系统
核心组件	HDFS, Hive, Spark,调度引擎	Flink, Kafka, Doris,StarRocks	Flink, Paimon, 对象存储/HDFS, Doris

📊 三种架构在各数据层的技术选型表

 

数据分层	🏔️ 离线架构 (T+1 批处理)	⚡️ 实时架构 (秒级/毫秒级)	🔄 混合架构 (分钟级，流批一体)
ODS层 (原始数据)	Apache Iceberg (或 Apache Hudi)	Apache Paimon (配合 Flink CDC)	Apache Paimon (统一存储底座)
DWD层 (明细数据)	Apache Iceberg (Spark 批处理清洗)	Apache Paimon (Flink 流式加工)	Apache Paimon (Flink 流批一体加工)
DWM层 (中间层)	Apache Iceberg (Spark SQL 聚合)	Apache Paimon (Flink 实时聚合)	Apache Paimon (Flink 分钟级滚动聚合)
DWS层 (汇总层)	Apache Iceberg (存储预计算结果)	Apache Paimon (或直接输出至 OLAP)	Apache Paimon (轻度汇总存储)
DM层 / ADS层 (数据集市/应用)	Doris 或 StarRocks 或 ClickHouse (批量导入查询)	StarRocks 或 Doris (实时外表查询或内表导入)	StarRocks 或 Doris (外表直读 Paimon 或物化视图加速)

⚙️ 技术选型流程建议

做技术选型可以按照这个逻辑推演，可能会比较清晰：

1. 先从 计算引擎 开始。如果流式处理是首要需求，必选 Flink；如果兼顾批处理且技术栈成熟，可选 Spark。

2. 结合计算引擎，再选 存储格式。核心是评估业务对数据延迟的要求到哪个量级。

   • 毫秒级：Apache Paimon 是最佳搭档，提供极致性能。

   • 分钟级：Apache Hudi 是稳妥选择，在性能和成本间取得良好平衡。

   • 小时级：Apache Iceberg 的开放生态和成熟度能提供最大的稳定性。

3. 最后，为 DM 层选型 OLAP 引擎。逻辑也很清楚：

   • 追求极致单表查询性能，选 ClickHouse。

   • 面对复杂查询和高并发报表，需要均衡性能，选 StarRocks 或 Doris (根据团队偏好)。

   • 如果已有 MySQL 技术栈，希望平滑迁移，Doris 是最优解。

4. 你完全可以将数据湖格式与OLAP引擎组合使用。例如，让 Paimon 统一存储 ODS/DWD/DWS 数据，再通过 StarRocks 读取 Paimon 表对外提供查询服务。

如果方便的话，你可以具体说说你的业务场景，比如数据量级（例如每天新增几亿条数据）、实时性要求（是分钟级还是秒级，又或者是T+1分析），以及团队熟悉的技术栈（比如是否习惯用Flink/Java），我可以帮你进一步分析更具体的选型和架构建议～