《数据仓库快速入门》

引言

  计算机专业半路出家从事大数据工作已经大半年之久(15年读大学的时候大数据还不是很火，好像就没怎么听到有大数据/人工智能专业的，当时还是CS、软件工程的天下)，还没有系统学习过大数据相关理论知识，虽然能够勉强胜任日常工作工作，但对于工作中涉及到的一些相关术语、相关概念也是一知半解，因此本文参考网上文献针对数据仓库相关进行学习，整理相关内容，并对大佬的架构图进行临摹，加强理解。

一、数据仓库概念

1-1 数仓架构

  架构就是把一个整体工作按需切分成不同部分的内容，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动。
数仓架构可以理解为是构成数据仓库的组件以及之间的具有交互机制的关系。一个基本的数仓库架构可以如下所示：

1-2 数仓基本特征

  数据仓库是面向主题的(Subject-Oriented)、集成的(Integrated)、非易失的(Non-Volatitle)和时变的(Time-Variant)数据集合，用于支持管理决策。
- (1) 主题性
  数据仓库是一般从用户实际需求出发，将不同平台的数据源按设定主题进行划分整合，面向主题的数据组织方式，就是在较高层次对分析对象数据的一个完整、统一并一致的描述。
- (2) 集成性
  在入数据仓库前必须进行抽取、清洗、转换，才能实现从面向事务转而面向主题的数据集合，数据集成是数据仓库建设中极其重要而又复杂的一步。
- (3) 稳定性
  数据的更新调整主要在数据集成环节完成，一旦进入数据仓库后，仅能进行查询和分析。
- (4) 动态性
  数据仓库数据会随着时间变化而定时更新，这里的定时可以通过相关调度工具进行任务的定时执行。

1-3 数仓建设目的

  想要了解数仓建设的目的，首先了解没有数仓建设之前的状况。数仓的数据往往用来为后面的即席查询、分析系统、数据集市、报表系统、数据挖掘系统做准备。在没有数仓建设之前，他们确实是直接对业务系统的数据做如此的操作，但是这样简单的访问，却会造成大量的问题。比如：

• 部分的业务系统都设置有权限，出于安全原因你不能直接访问
• 业务系统每次做版本升级，相应的报表系统还要进行再次测试
• 企业中用于多个业务系统，那么对应的多个报表系统的维护问题
• 不同业务系统之间形成数据孤岛，不能进行数据互通
• 业务系统的数据格式等问题
• 业务系统的数据存在脏数据的问题
• 直接操作业务数据做分析，对数据而言也是一种危险

正是因为存在上面的种种问题，才需要建设数仓，保证数据的安全性、以及使用的便利性。

二、离线数仓

  数据仓库概念是Inmon于1990年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。

2-1 数仓分层

分层原则：

• 空间换时间，通过大量的预处理来提升应用系统的用户体验；
• 便于数据分析，屏蔽底层复杂业务，将简单、完整、有效的数据暴漏给分析层；
• 削弱底层业务变动对整体模型的影响；
• 高内聚低耦合，主题之内数据高内聚，主题之间数据低耦合；
• 层次分明，便于管理，为数据仓库大规模开发奠定基础；

• 数据源层（Operational Data Store，ODS）
     ODS层，是最接近数据源中数据的一层，为了考虑后续需要追加数据的问题，这一层不对数据做任何处理。

• 数据仓库层 (Data Warehouse, DW)
    数据仓库层是我们在做数据仓库的时候要设计的最核心的一层。在这里，从ODS层中获得的数据按照主题建立各种数据模型。DW层又细分为DWD(Data Warehouse Detail)、DWM(Data Warehouse Middle)、DWS(Data Warehouse Service)。
  (1) 数据明细层 (DWD)
    该层一般保持和ODS层一样的数据粒度，并提供一定的数据质量保证。DWD层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、不规范数据、状态不一致数据、命名不规范数据都会被处理。
  ​   同时，为提高数据明细层的易用性，该层会采用一些维度退化的手法，将维度退化至事实表，减少事实表和维表之间的关联。
  ​ 在该层也会做部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性。
  (2) 数据中间层 (Data Warehouse Middle，DWM)
  ​   该层会在DWD层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。
  直观来讲，就是对通用的核心维度进行聚合操作，算出对应的统计指标
  (3) 维度表 (Dimension, DIM)
    如果维表过多，也可以针对维表设计单独的一层，维表主要包含两部分数据，
  ​ 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级别或者上亿级别。
  ​ 低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
  (4) 数据服务层 (Data Warehouse Service)
    DWS层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于DWD层上的基础数据，整合汇总分析某一个主题域的服务数据，一般是宽表。DWS层应覆盖80%的应用场景，又称为数据集市或宽表。
  ​   按照业务划分，如主题域流量、订单、用户等，生成的字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据并发。
  ​ 一般来讲，该层的数据表相对较少，一张表会涵盖较多的业务内容，由于其字段较多，因此一边拿会称该层的表为宽表。

• 数据应用层 (Application, APP)
  主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。

2-2 数仓建模

​   数仓建模主要是在DW层进行数仓建模，所以DW层是数仓建设的核心层。常见的建模方法有范式建模、维度建模、Datavalue模型、Anchor模型，从不同的角度看待业务问题。

2-2-1 范式建模（3NF）

  参考传统关系型数据库的建模模式，建立E-R模型，E-R步骤如下：

• 抽象出主体 （教师，课程）；
• 梳理主体之间的关系 （一个老师可以教多门课，一门课可以被多个老师教）；
• 梳理主体的属性 （教师：教师名称，性别，学历等）；
• 画出E-R关系图。

  ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式，且该建模方法需要满足3NF。Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模，BI架构提出分层架构，数仓底层ods、dwd也多采用ER关系模型就行设计。
  但是逐渐随着企业数据的高增长，复杂化，数仓全部使用ER模型建模显得越来越不合时宜。为什么呢，因为其按部就班的步骤，三范式等，不适合现代化复杂，多变的业务组织。

2-2-2 维度建模

  维度建模，是数据仓库大师Ralph Kimball提出的，是数据仓库工程领域最流行的数仓建模经典。
  维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。维度建模是面向分析的，为了提高查询性能可以增加数据冗余，反规范化的设计技术。

2-2-2-1 事实表

  ​ 发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中，事实表存储了每一个可度量的事件。
事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实，如下图所示，订单表就是一个事实表，它记录的就是现实中的一个操作性的事件

  ​ 如上图所示，订单表里并没有存储具有实际意义的数据，存储的只是各表主键的集合，通过每一个主键都可以获取一个相关维度的数据。
  ​ 事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。
注意：这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。

• 事务事实表，用于承载事务数据，通常粒度比较低，它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表，例如产品交易事务事实、ATM交易事务事实；
• 周期快照事实表，按照一定的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表；
• 累积快照事实表，用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见。

2-2-2-2 维度表

  ​ 维度，顾名思义，业务过程的发生或分析角度。比如从颜色、尺寸的角度来比较手机的外观，从cpu、内存等较比比较手机性能维。维度表一般为单一主键，在ER模型中，实体为客观存在的事物，会带有自己的 描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。

案例：某电商平台，经常需要对订单进行分析，以某宝的购物订单为例，以维度建 模的方式设计该模型。涉及到事实表为订单表、订单明细表，维度包括商品维度、用户维度、商家维度、区域维 度、时间维度。

• 商品维度：商品ID、商品名称、商品种类、单价、产地等；
• 用户维度：用户ID、姓名、性别、年龄、常住地、职业、学历等；
• 时间维度：日期ID、日期、周几、上/中/下旬、是否周末、是否假期等图片；

维度分为：
① 退化维度（DegenerateDimension）
在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。
② 缓慢变化维（Slowly Changing Dimensions）
维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD）。比如员工表中的部门维度，员工的所在部门有可能两年后调整一次。

2-2-2-3 维度建模分类

（1）星型模型
  星型模型是最常用的维度建模方式。星型模型以事实表为中心，所有维度表直接连接在事实表上，像星星一样，故称为星型模型。星型模型的维度建模由一个事实表和一堆维度表组成，且具有以下特点：

• 维表只和事实表关联，维表之间没有关联；
• 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
• 以事实表为核心，维表围绕核心呈星型分布。
  

（2）雪花模型
  雪花模型是对星型模型的扩展。雪花模型的维度表可以拥有其他维度表，虽然这种模型相比星型模型更加规范，但是由于这种模型不易理解，维护成本高，而且性能方面需要关联多层维度表，性能也比星型模型要低，所以一般不是很常用。如下图雪花模型所示，地址维度表可以拥有国家表、省份表、城市表的延展维度。

（3）星座模型
  星座模型是星型模型延伸而来，星型模型是基于一张事实表，而星座模型是基于多张事实表，而且共享维度信息。星型模型和星座模型都是多维表对应单事实表但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大多数维度建模都是采用星座模型。

2-2-2-3 维度建模过程

  维度建模步骤：选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。

  声明粒度，为业务最小活动单元或不同维度组合。以共同粒度从多个组织业务过程合并度量的事实表称为合并事实表，需要注意的是，来自多个业务过程的事实合并到合并事实表时，它们必须具有同样等级的粒度

2-2-3 DataVault模型

Data Vault是Dan Linstedt发起创建的一种模型方法论，Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理。同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。

  Data Vault模型是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键，用于定位和唯一标识记录或数据。
Data Vault模型包含三种基本结构 ：

• 中心表-Hub ：唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合；
• 链接表-Link：表示中心表之间的关系，通过链接表串联整个企业的业务关联关系；
• 卫星表- Satellite：历史的描述性数据，数据仓库中数据的真正载体。

Hub想像成人体的骨架，那么Link就是连接骨架的韧带组织， 而satelite就是骨架上的血肉。Data Vault是对ER模型更近一步的规范化，由于对数据的拆解和更偏向于基础数据组织，在处理分析类场景时相对复杂， 适合数仓低层构建，目前实际应用场景较少。

2-2-4 Anchor模型

  Anchor是对Data Vault模型做了更近一步的规范会处理，初衷是为了 设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于 是设计出的模型基本变成了k-v结构的模型，模型范式达到了6NF。
由于过度规范化，使用中牵涉到太多的join操作，目前木有实际案例，仅作了解。

三、实时数仓

  随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是Lambda架构。
再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的Kappa架构。

3-1 实时计算

  实时计算与离线计算所要求的时效不同，离线计算通常对数据的时效性要求不高，如在进行用户行为数据挖掘分析时，可以通过使用以周为维度、月为维度的用户历史数据，分析出相关用户特征；但实时计算通常对数据的时效要求比较高，而且对处理数据的时效亦比较高，通常为秒级。

3-1-1 实时计算3个特征

1. 无限数据，无限数据指的是一种不断增长的，基本上无限的数据集。这些通常被称为“流数据”，而与之相对的是有限的数据集；
2. 无界数据处理，一种持续的数据处理模式，能够通过处理引擎重复的去处理上面的无限数据，是能够突破有限数据处理引擎的瓶颈；
3. 低延迟，延迟是多少并没有明确的定义，但是我们都知道数据的价值将随着时间的流式降低，时效性将是需要持续解决的问题。

3-1-2 实时计算流程

  实时计算流程包括 数据同步、数据存储、数据计算、实时应用、元数据指标管理、数据质量及血缘分析步骤，如下：

(1) 数据同步
  数据从web平台中产生，通过数据同步系统导入到大数据平台，常用的同步工具有DataX(异构数据源同步)、Sqoop(关系数据库<—>hadoop)、Flume(日志同步)。
(2) 数据存储
  数据存储部分主要是对原始数据、清洗关联后的明细数据进行的存储操作，基于统一的实时数据模型分层理念，将数据依次存放至各层。以及将不同应用常见的数据可以分别存储在Kafka、HDFS、Kudu、Hive、ClickHouse、Hbase、ES中进行应用。
(3) 数据计算
  计算层主要使用Flink、Spark、Presto以及Clickhouse自带的计算能力等四种计算引擎，Flink计算引擎主要用于实时数据同步，流式ETL、关键系统秒级实时指标计算场景，Spark SQL主要用于复杂多维分析的准实时指标计算需求场景，Presto和ClickHouse主要满足多维自助分析、对查询响应时间要求不太高的场景。
(4) 实时应用
  实时大屏、实时报表、OLAP等等。
(5) 元数据指标管理
  主要对实时的Kafka表、kudu表、clickhouse表、hive表等进行统一管理，以数仓模型中表的命令方式规范表的命名，明确每张表的字段含义、使用方，指标管理则是尽量通过指标系统将所有的实时指标统一管理，明确计算口径，提供给不同的业务方使用；
(6) 数据质量及血缘分析
​   数据质量分为平台监控和数据监控两个部分，血缘分析则是主要对实时数据依赖关系、实时任务的依赖关系进行分析。

3-2 实时架构

  目前主要的实时架构主要是Lambda架构、Kappa架构两种，对比如下：

对比项	Lambda架构	kappa架构
计算资源	批核流同时运行，资源开销大	只有流处理，仅针对新需求开发阶段运行两个作业，资源开销小
重新计算时吞吐	批式全量处理，吞吐较高	流式全量处理、吞吐较批处理低
开发、测试	每个需求都需要两套不同代码、开发、测试、上线难度较大	只需维护一套系统、运维成本小
运维成本	维护两套系统(引擎)、运维成本大	只需维护一套系统、运维成本小

3-2-1 Lambda架构

Lambda架构，数据从底层的数据源开始，经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算：

• 一条线是进入流式计算平台(例如Storm、Flink或者SparkStreaming)，实时计算一些指标
• 另一条线进入批量数据处理离线计算平台(例如Mapreduce、Hive、Spark SQL),计算T+1的相关业务指标，这些指标需要隔日才能看到

优点：

• 稳定性高；
• 对于实时计算部分成本可控；
• 批处理可以利用晚上时间计算，错开实时计算与离线计算高峰；

不足：

• 维护成本高，使用两套大数据处理引擎，维护两个复杂的分布式系统，成本非常高；
• 批处理计算可能无法在计算窗口内完成，随着数据量增大，夜间窗口已经无法完成白天数据积累的计算；
• 数据源变化都要重新开发、开发周期长，业务反应不够迅速；

3-2-2 Kappa架构

​   Kafka创始人Jay Kreps认为在很多常见下，维护一套Lambda架构的大数据处理平台耗时耗力，于是提出在某些场景下，没有必要维护一个批处理层，直接使用一个流处理层即可满足需求，即下图所示的Kappa架构图：

  Kappa架构只关注流式计算，数据以流的方式被采集过来，实时计算引擎将计算结果放入数据服务层以供查询。可以认为Kappa架构是Lambda架构的一个简化版本，只是去除掉了Lambda架构中的离线批处理部分。

Kappa架构的兴起的两个原因（Kafka+Flink）

• Kafka不仅起到消息队列的作用，也可以保存更长时间的历史数据，以替代Lambda架构中批处理层数据仓库部分。流处理引擎以一个更早的时间作为起点开始消费，起到批处理的作用;
• Flink流处理引擎解决了事件乱序下计算结果的准确性问题。
  Kappa架构相对更简单，实时性更好，所需的计算资源小于Lambda架构，随着实时处理的需求在不断增长，更多的企业开始使用Kappa架构。但这并不意味着Kappa架构能够取代Lambda架构。

​ Lambda和Kappa架构都有各自的适用领域：例如流处理与批处理分析流程比较统一，且允许一定的容错，用kappa架构比较合适，少量关键指标(例如交易金额、业绩统计等)使用Lambda架构进行批量计算，增加一次校对过程。

​ 还有一些比较复杂的场景，批处理与流处理产生不同的结果(使用不同的机器学习模型、专家系统，或者实时计算难以处理的复杂计算)，可能更适合Lambda架构。

3-3 实时分层

  实时数仓分层为了避免需求响应的烟囱式构建，实时数仓也引入了类似于离线数仓的的分层理念，主要为了提升模型的复用率，同时也要考虑模型的复用率，同时也要考虑易用性、一致性以及计算的成本。

1. ODS层
   以Kafka为支撑，将所有需要实时处理的相关数据放到Kafka队列中来实现贴源数据层；
2. DWD层
   实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源join、流式数据于离线维度信息等组合，将一些相同粒度的业务系统、维度中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据；
3. DIM层
   存放用于关联查询的维度信息，可以根据数据现状来选择存储介质，例如使用HBase或者MySQL；
4. DWS层
   ​ 轻度汇总层是为了便于面向ADHoc查询或者OLAP分析构建的轻度汇总结果集合，适合数据维度、指标信息比较多的情况，为了方便根据自定义条件的快速筛选和指标聚合，推荐使用MPP类型数据库进行存储，此层可视场景情况是否构建；
5. APP层
   面向实时数据场景需求构建的高度汇总层，可以根据不同的数据应用场景决定使用存储介质或者引擎；例如面向业务历史明细、BI支持等OLAP分析场景，可以使用Durid、GreenPlum,面向实时监控大屏、高并发汇总指标等需求，可以使用KV模式的HBase；数据量较小的时候，也可以使用MySQL来进行存储。

3-4 基于Flink构建的实时数仓

  随着业务场景的丰富，更多的实时需求不断涌现，在追求实时任务高吞吐低延迟的同时，对计算过程中间状态管理，灵活时间窗口支持，以及exactly once语义保障的诉求也越来越多。
  为什么选择Flink实时计算平台？之所以选择用Flink替代原有的Storm、SparkStreaming是基于以下原因考虑的，这也是实时数仓关注的核心问题：

1. 高吞吐、低延迟；

2. 端到端的Exactly-once,保证了数据的准确性；

3. 可容错的状态管理，实时数仓里面会进行很多的聚合计算，这些都需要对于状态进行访问和管理；

4. 丰富的API，对Streaming/Table/SQL支持良好，支持UDF、流式join、时间窗口等高级用法；

5. 完善的生态体系，实时数仓的构建会涉及多种存储，Flink在这方面的支持也比较完善；

基于Flink的实时数仓数据转换过程
  数据在实时数仓中的流转过程，实际和离线数仓非常相似，只是由Flink替代Hive作为了计算引擎，把存储由HDFS更换成了Kafka，但是模型的构建思路与流转并没有发生变化。

3-5 实时数仓建设

3-5-1 分层建设

  从方法论来讲，实时和离线是非常相似的，离线数仓早期的时候也是具体问题具体分析，当数据规模涨到一定量的时候才会考虑如何治理。分层是一种非常有效的数据治理方式，所以在实时数仓如何进行管理的问题上，首先考虑的也是分层的处理逻辑。

各层次作用

• 贴源层
    在数据源的层面，离线和实时在数据源是一致的，主要分为日志类和业务类，日志类又包括用户日志，埋点日志以及服务器日志等；
• 明细层
    在明细层，为了解决重复建设的问题，要进行统一构建，利用离线数仓的模式，建设统一的基础明细数据层，按照主题进行管理，明细层的目的是给下游提供直接可用的数据，因此要对基础层进行统一的加工，比如清洗、过滤、扩维等；
• 汇总层
    汇总层通过Flink的简洁算子直接算出结果，并且形成汇总指标池，所有的指标都统一在汇总层加工，所有人按照统一的规范管理建设，形成可复用的汇总结果。

从这可以看出，实时数仓和离线数仓的分层非常相似，比如 数据源层，明细层，汇总层，以及应用层，两者的命名的模式可能都是一样的。但是两者还是又很多的区别，比如：

1. 与离线数仓相比，实时数仓的层次更少一些
     从目前建设数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部，但是实时数仓中，app应用层已经落入应用系统的存储介质中，可以把该层与数仓的表分离。
     应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟。
     汇总层少见的好处：在汇总统计的时候，往往为了零容忍一部分数据的言辞，可能会人为的制造一些延迟来保证数据的准确。举例：在统计跨天相关的订单事件中的数据，可能会等到00：00：05或者00：00：10再统计，确保00：00前的数据已经全部接收到位，再进行统计。所以汇总层的层次太多的话，就会更大的加重认为造成的数据延迟。

2. 与离线数仓相比，实时数仓的数据源存储不同
     在建设离线数仓的时候，基本整个离线数仓都是建立在Hive表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。比如常见的情况下，明细数据或者汇总数据都会存在kafka里面，但是像城市、渠道等维度信息需要借助Hbase，MySQL或者其他KV存储等数据库来进行存储。

3-5-2 Lambda架构实时数仓

​   Lambda架构是比较经典的架构，以前实时的场景不是很多，以离线为主，当附加了实时场景后，由于离线和实时的时效性不同，导致技术生态是不一样的。Lambda架构相当于附加了一条实时生产链路，在应用层进行一个整合，双路生产，各自独立。这在业务应用中也是顺理成章采用的一种方式。
  ​ 双路生产会存在一些问题，比如加工逻辑double，开发运维也会double，资源同样会变成两个资源链路。因为存在以上问题，所以又演进了一个Kappa架构。

3-5-3 Kappa架构实时数仓

  ​Kappa架构从架构涉及来讲比较简单，生产统一，一套逻辑同时生产离线和实时。但是在实际应用场景中有比较大的局限性，因为实时数据的同一份表，会使用不同的方式存储，这就导致关联时需要跨数据源，操作数据又很大的局限性，所以在业内直接使用Kappa架构生产落地的案例不多见，且场景比较单一。

​   ​ 关于Kappa架构，熟悉实时数仓生产的同学，可能会有一个疑问。因为我们呢经常会面临业务变更，所以很多业务逻辑是需要迭代的。之前产出的一些数据，如果口径变更了，就需要重算，甚至重刷历史数据。对于实时数仓来说，怎么去解决数据重算问题？

​   ​kappa架构在这一块的思路是：首先要准备号一个能存储历史数据的消息队列，比如Kafka，并且这个消息队列是可以支持你从某个历史的节点重新开始消费的。接着需要重新起一个任务，从原来比较早的一个时间节点去消费Kafka上的数据，然后当这个新的任务运行的进度已经能够和现在的正在跑的任务齐平的时候，你就可以把现在任务的下游切换到新的任务上面，旧的任务就可以停掉，并且原来产出的表也可以被删掉。

3-5-4 流&批处理结合实时数仓

​   随着实时OLAP技术的发展，目前开源的OLAP引擎在性能上，易用性方面有了很大的提升，如Doris、Presto等，加上数据库技术的迅速发展，使得流批结合的方式变得简单。

  数据从日志统一采集到消息队列，再到实时数仓，作为基础数据流的建设是统一的。之后对于日志类实时特征，实时大屏类应用走实时流计算。对于Binlog类业务分析走实时OLAP批处理。

​   我们看到流批结合的方式与上面几种架构的存储方式发生了变化，由Kafka换成了Iceberg,Iceberg是介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把他定义成一种数据组织格式，底层存储还是HDFS，那么为什么加了中间层，就对流批结合处理的比较号了呢？Iceberg的ACID能力可以简化整个流水线的设计，降低整个流水线的延迟，并且所具有的修改、删除能力能够有效的降低开销，提升效率。Iceberg可以有效支持批处理的高吞吐数据扫描和流计算按分区粒度并发实时处理。

参考文献

[1] 《数据仓库》一文读懂数据仓库建设.
[2] 实时数仓与离线数仓总结(一).
[3] 4种数仓建模