大数据架构选型与设计

Posted 2023-04-08 回忆de天空

大数据架构选型与设计

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的研究员认为这两种信息处理的方式具有显著差别，以至于必须采取完全不同的架构和设计方法。但受限于当时的信息处理能力，这个研究仅仅停留在理论层面。

1. 探索阶段。

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

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

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

1. 确立阶段**（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之间建立了很好的桥梁，其思路如下：

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

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

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

1. 合并（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”只有一个“产品名称”，显示时使用“产品名称”来代替，所以“产品名称”也被认为是“键属性”的一部分。

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

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

总结 ：

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

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

星型模型：

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

雪花模型：

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

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

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

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

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

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

1.1.2.5 维度建模案例

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

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

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

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

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

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

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

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

建模设计如下：

1.1.2.6 数据仓库分层设计

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

上图中的数据流转我们更希望得到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架构最大的问题，针对同一个需求需要开发两套代码，一个在批处理引擎上实现，一个在流处理引擎上实现，在写好代码后还需构造数据测试保证两者结果一致，另外，两套代码对于后期维护也非常麻烦，一旦需求变更，两套代码都需要修改，并且两套代码也需同时上线。

1. 集群资源使用增多

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

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

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

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

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

1. 服务器存储大

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

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中写数据相对比，肯定是向Kaf

微服务之架构技术选型与设计

参考技术A

本文主要介绍了架构技术选型与设计-微服务选型，Spring cloud 实现采用的技术，希望对您的学习有所帮助。

架构技术选型与设计-DUBBODubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点(阿里巴巴现在使用架构为HSF)。 于2012-10-24最后版本2.5.3成为最后一版本，由当当接手维护，命名为dubbox；2017年突然继续dubbo进行维护，最后更新版本时间为 2017-10-11 22:21

Dubbo 核心部件:Provider： 暴露服务的提供方。Consumer：调用远程服务的服务消费方。Registry： 服务注册中心和发现中心。Monitor： 统计服务和调用次数，调用时间监控中心。（dubbo的控制台页面中可以显示）Container：服务运行的容器。Dubbo服务集群-集群容错模式

架构技术选型与设计-微服务选型

架构技术选型与设计-DUBBO

架构技术选型与设计-DUBBO

架构技术选型与设计-微服务选型Spring Cloud，从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。如果拿Dubbo与Netflix套件做对比，前者在国内影响力较大，后者在国外影响力较大，在背景上可以打个平手；但是若要与Spring Cloud做对比，由于Spring Source的加入，在背书上，Spring Cloud略胜一筹，但是在高并发上dubbo曾经在阿里的运营中实际承载过过亿用户同时在线的，而Netflix 并没有实际的上线应用中体现过。Spring Cloud下面有19个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。但是在选择框架上，方案完整度恰恰是一个需要重点关注的内容，当然从高可用和高并发一起考虑，Spring Cloud 无疑是最佳选择。

1、Spring Cloud Config 配置中心，利用git集中管理程序的配置。

2、Spring Cloud Netflix 集成众多Netflix的开源软件

3、Spring Cloud Bus 消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化

4、Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的应用程序

5、Spring Cloud Cloud Foundry Service Broker 为建立管理云托管服务的服务代理提供了一个起点。

6、Spring Cloud Cluster 基于Zookeeper, Redis, Hazelcast, Consul实现的领导选举和平民状态模式的抽象和实现。

7、Spring Cloud Consul 基于Hashicorp Consul实现的服务发现和配置管理。

8、Spring Cloud Security 在Zuul代理中为OAuth2 rest客户端和认证头转发提供负载均衡

9、Spring Cloud Sleuth SpringCloud应用的分布式追踪系统，和Zipkin，HTrace，ELK兼容。

10、Spring Cloud Data Flow 一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。

11、Spring Cloud Stream 基于Redis,Rabbit,Kafka实现的消息微服务，简单声明模型用以在Spring Cloud应用中收发消息。

12、Spring Cloud Stream App Starters 基于Spring Boot为外部系统提供spring的集成

14、Spring Cloud Task App Starters

15、Spring Cloud Zookeeper 服务发现和配置管理基于Apache Zookeeper。

16、Spring Cloud for Amazon Web Services 快速和亚马逊网络服务集成。

17、Spring Cloud Connectors 便于PaaS应用在各种平台上连接到后端像数据库和消息经纪服务。

18、Spring Cloud Starters （项目已经终止并且在Angel.SR2后的版本和其他项目合并

）19、Spring Cloud CLI 插件用Groovy快速的创建Spring Cloud组件应用。Spring Cloud共集成了19个子项目，里面都包含一个或者多个第三方的组件或者框架！

1、spring cloud ： 一个云应用工具，为云应用开发的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁定、决策竞选、分布式会话和集群状态管理等操作

2、spring cloud config ：配置管理开发工具包

3、 spring cloud Bus ：事件消息总线用于集群（例如：配置变化时间）中传播状态变化，与spring cloud config 联合实现热部署

4、 spring cloud Netflix Eureka ： 云端负载均衡基础，一个基于Rest的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移

5、 spring cloud Netflix Hystrix ： 容错管理工具，旨在通过控制服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力

6 、 Netflix ZUUL： 边缘服务工具，提供动态路由、监控、弹性、安全等边缘服务

7、 spring cloud sleuth ：日志收集工具包、封装Purpose 、Zipkin和Trace

8、 Spring Cloud Security ： 安全工具包，为应用程序添加安全控制，主要是OAuth2

9、 spring cloud turbine ：聚合服务器发送时间流，监控集群下Netflix 和 metrics 情况

Spring cloud 配置中心

Spring cloud 注册中心

Spring cloud 网关: 服务路由、安全认证、会话共享、客户端负载均衡、统一异常处理、跨域请求

Spring cloud 断路由