实时分析处理三大场景 Lambda 架构部署图 Kappa 架构部署图Omega vs. Lambda vs. Kappa

当下，瞬息万变的商业社会要求企业更快的做出决策，从“双十一”和春晚直播实时大屏、银行和税务的风险实时阻断、机器学习建模逐步在线化等趋势中，我们可以发现，企业除了离线数据分析还有大量的实时数据分析需求。因此，摸着“数据”过河，小步快跑就推动了企业“实时”需求的升级。在很多线上场景中，实时性已经成为了提升企业竞争力的核心手段。

运营层面：实时业务变化，实时营销效果，当日分时业务趋势分析等；

用户层面：搜索推荐排序，实时行为等特征变量的生产，为用户推荐更精准的内容；

风控层面：实时风险识别、反欺诈、异常交易等都是广泛应用实时数据的场景；

生产层面：实时监控系统的稳定性和健康状况等。

站在技术角度可以将实时需求分为三类：实时流处理、实时按需分析、离线分析。通过下图，以一个事件发生的前后作为时间轴，可以将时间线分为三个阶段，分别是事件发生的同时、事件发生后短时间内、事件发生后较长时间，对应的实时要求分别是实时流处理、实时按需分析、离线分析。

以一次银行转账为例，交易发生的同时要进行交易反欺诈检测，通过实时流处理系统将本次交易的时间、金额、位置等要素进行加工形成衍生特征提供给反欺诈应用系统；该笔交易结束后，需要立即反映到实时报表和统计分析中，同时业务用户也会按照特定需求查询到该笔交易（比如近 10 分钟内新增的大额交易），由于实时报表和实时统计分析需求千变万化，流处理系统难以满足，所以需要实时按需分析；这笔交易发生后的较长时间内，都会被用来进行报表统计、数据挖掘和机器学习，因此传统的离线分析也是基本需求之一。

目前，实时处理有两种典型的架构：Lambda 和 Kappa 架构。出于历史原因，这两种架构的产生和发展都具有一定局限性。即便引入流处理引擎实现了部分固定模式的实时分析，仍无达到 T+0 全实时水平。

Lambda架构

Lambda产生背景

当运行大量数据时，Hadoop 所耗费的时间也会变得越来越多，无法满足一些需要实时分析处理的场景（比如抖音、淘宝的动态推荐），因此新的流式计算引擎如 Spark Streaming、Flink、Storm 等开始出现。流处理、批处理配合使用才能满足绝大部分应用场景，因此Lambda 架构被提出。

Lambda实现原理

Lambda 架构通过把数据分解为服务层（Serving Layer）、速度层（Speed Layer，亦即流处理层）、批处理层（Batch Layer）三层来解决不同数据集的数据需求。在批处理层主要对离线数据进行处理，将接入的数据进行预处理和存储，查询直接在预处理结果上进行，不需再进行完整的计算，最后以批视图的形式提供给业务应用。

Lambda 架构逻辑图

批视图听起来有些抽象，由于服务层通常使用 MySQL，HBase 等实现，供业务应用查询使用，此处的批视图就是 MySQL 或 HBase 中的一些表（见下图），这些表存储着批处理作业产生的结果；流处理层主要是对实时增量数据进行处理，新数据通过流计算不断的更新实时视图，比如针对实时大屏场景，实时视图通常就是 MySQL 中的一张表，流处理作业在新数据到来后不停更新实时视图提供给到业务层；服务层主要是响应用户的请求，根据用户需求把批处理层和流处理层产生的数据合并到一起得到最终的数据集。

Lambda 在实际生产环境中的部署通常要比上图更加复杂，下图是贴近实际部署的典型示例。可以看出，实际情况要通过一系列不同的存储和计算引擎 (HBase、Druid、Hive、Presto、Redis 等) 复杂协同才能满足业务的实时需求，此外多个存储之间需要通过数据同步任务保持大致的同步。Lambda 架构在实际落地过程中极其复杂，使整个业务的开发耗费了大量的时间。

Lambda 架构在企业落地的实际情况

Lambda 优势与不足

优点：是将流处理和批处理分开，很好的结合了批处理和实时流计算的优点，架构稳定，实时计算成本可控，提高了整个系统的容错性。

缺点：(1) 由多个引擎和系统组合而成，批处理 (Batch)、流处理 (Streaming) 以及合并查询 (Merged Query) 的实现需要使用不同的开发语言，造成开发、维护和学习成本较高；(2) 数据在不同的视图 (View) 中存储多份，浪费存储空间，数据一致性的问题难以解决。

Kappa 架构

Kappa 产生背景

既然 Lambda 架构难保证数据一致性，双倍维护系统成本，那么一套系统解决批处理和流处理的诉求就产生了，对应的解决方案便是 Kappa 架构（即批流一体）。

Kappa 实现原理

Kappa 架构在 Lambda 架构的基础上移除了批处理层，利用流计算的分布式特征，加大流数据的时间窗口，统一批处理和流处理，处理后的数据可以直接给到业务层使用。因为在 Kappa 架构下，作业处理的是所有历史数据和当前数据，其产生的结果我们称之为实时批视图（Realtime_Batch_View）。

Kappa 架构逻辑图

在 Kappa 架构中，输入数据在源端采集后通常存储在 Kafka 中，在流处理程序需要升级迭代时，会启动一个新版本作业（StreamJob_Version_N+1）, 该作业会从 Kafka 中读取所有历史数据和新增数据，直到追上旧版本作业（StreamJob_Version_N），旧的作业版本才可以停掉。Kappa 架构通过这种方法升级流处理程序。

Kappa 架构的流处理系统通常使用 Spark Streaming 或者 Flink 等实现，服务层通常使用MySQL 或 HBase 等实现。

Kappa 优势与不足

优点：由于所有数据都通过流处理计算，开发人员只需要维护实时处理模块，不需要离线实时数据合并，运维简单，生产统一。

缺点：(1) 依赖 Kafka 等消息队列来保存所有历史，而 Kafka 难以实现数据的查询、更新和纠错，发生故障或者升级时需要重做所有历史，周期较长；(2) Kappa 主要是针对不可变更数据，无法实时汇集多个可变数据源形成的数据集快照，不适合即席查询。

Kappa 架构实际应用起来有较大的局限性，因此 Kappa 架构在业内生产落地的案例不多见，且场景比较单一。

Omega 架构

Omega 产生背景

既然 Kappa 架构实际落地困难，Lambda 架构又很难保障数据的一致性，两个架构又都很难处理可变更数据（如关系数据库中不停变化的实时数据），那么自然需要一种新的架构满足企业实时分析的全部需求，这就是 Omega 全实时架构。Omega 架构由偶数科技于 2021 年初提出，同时满足实时流处理、实时按需分析和离线分析。

Omega 实现原理

Omega 架构由流处理系统和实时数仓构成。相比 Lambda 和 Kappa，Omega 架构新引入了实时数仓和快照视图 (Snapshot View) 的概念，快照视图是归集了可变更数据源和不可变更数据源后形成的 T+0 实时快照，可以理解为所有数据源在实时数仓中的镜像和历史，随着源库的变化实时变化。

因此，实时查询可以通过存储于实时数仓的快照视图得以实现。实时快照提供的场景可以分为两大类：一类是多个源库汇集后的跨库查询，比如一个保险用户的权益视图；另一类是任意时间粒度的分析查询，比如最近 5 分钟的交易量、最近 10 分钟的信用卡开卡量等等。

另外，任意时间点的历史数据都可以通过 T+0 快照得到（为了节省存储，T+0 快照可以拉链形式存储在实时数仓 ODS 中，所以快照视图可以理解为实时拉链），这样离线查询可以在实时数仓中完成，离线查询结果可以包含最新的实时数据，完全不再需要通过 MPP+Hadoop 组合来处理离线跑批及分析查询。

Omega 架构逻辑图

流处理系统 WASP 既可以实现实时连续的流处理，也可以实现 Kappa 架构中的批流一体，但与Kappa 架构不同的是，OushuDB 实时数仓存储来自数据源的全部历史数据（详见下图），而在 Kappa 架构中源端采集后通常存储在 Kafka 中。

Omega 架构部署图

因此，当需要流处理应用版本变更的时候，流处理引擎不再需要访问 Kafka，而是访问实时数仓 OushuDB 获得所有历史数据，规避了 Kafka 难以实现数据更新和纠错的问题，大幅提高效率。此外，整个服务层可以在实时数仓中实现，而无需额外引入 MySQL、HBase 等组件，极大简化了数据架构。

在 Omega 全实时架构的加持下，偶数率先实现了具备实时能力的湖仓一体，即实时湖仓。实时湖仓统一了湖仓市（数据湖、数仓、集市），避免数据孤岛的同时，极大提升了企业实时数据分析能力，让企业在快速更迭的商业环境中立于不败之地。