详解离线数仓和实时数仓的区别

​

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

​

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

​

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

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

02

Lambda 架构

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

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

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

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

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

​

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

      2、离线数仓+实时数仓

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

​

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

在 Lambda 架构中流处理计算的指标批处理依然计算，最终以批处理结果为准，即每次批处理计算后会覆盖流处理的结果，这是由于流处理过程中不完善做的折中办法，由数据服务处理，其功能主要是合并离线计算和实时计算结果。

例如：在统计实时交易订单时，可能实时统计的结果需要当日分钟级别向外展示，T+1 后才能展示昨日总的交易订单数，显然，后者是 T+1 每日离线批处理统计结果，那么假设当日有些用户进行了订单取消有可能 T+1 后统计统计结果与当日实时展示数据出现不一致问题，那么这里就需要使用数据服务来进行处理，统一数据，决定如何使用数据。

Lambda 数据架构成为每一个公司大数据平台必备的架构，它解决了一个公司大数据批量离线处理和实时数据处理的需求。Lambda 架构的核心理念是“流批一体”，如上图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。

无论哪种计算模式，最终的处理结果都通过统一服务层对应用提供，确保访问的一致性，底层到底是批或流对用户透明。经历多年的发展，Lambda 架构优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰分开，但是它也有一些致命缺点：

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

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

2)集群资源使用增多

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

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

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

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

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

5)服务器存储大

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

03

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 架构的问题在实时数仓发展趋势中讨论。

04

混合结构

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

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

​

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

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

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

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

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

在一些涉及到实时业务场景的公司，在实际工作中到底选择哪种架构，需要根据具体业务需求来决定。很多时候并不是完全规范的 Lambda 架构或者 Kappa 架构，可以是两者的混合，比如大部分实时指标统计使用 Kappa 架构完成计算，少量关键指标使用 Lambda 架构用批处理重新计算，增加一次校对过程。

为了应对更广泛的场景，大多数公司采用这种混合架构，离线和实时数据链路都存在，根据每个业务需求选择在合适的链路上来实现。注意：这种方式并不是 Lambda 架构，例如：某企业有多个业务模块，某些业务模块需要运行在 Lambda 架构中，某些业务模块需要运行在 Kappa 架构中。

​