实时数据处理

以一个事件发生的前后作为时间轴，可以将时间线分为三个阶段，分别是事件发生的同时、事件发生后短时间内、事件发生后较长时间，对应的实时要求分别是实时流处理、实时按需分析、离线分析。目前，实时处理有两种典型的架构： Lambda 和 Kappa 架构。出于历史原因，这两种架构的产生和发展都具有一定局限性。

Lambda 架构通过把数据分解为批处理层、速度层、服务层来解决不同数据集的数据需求。

服务层通常使用 MySQL、HBase 等实现，供业务应用查询使用，此处的批视图就是批处理层和流处理层加工后存放于 MySQL 或 HBase 中的一些结果表。Lambda 架构在实际落地过程中非常复杂，难以保证数据一致性，同时也很难处理可变更数据。

在生产环境中，Lambda 架构要通过一系列不同的存储和计算引擎 (如HBase、Druid、Hive、Presto、Redis 等) 复杂协同和数据同步任务才能满足业务的实时需求，整个业务的开发耗费了大量的时间。数据在不同的视图中存储多份，浪费存储空间，数据一致性的问题难以解决。

Kappa 架构在 Lambda 架构的基础上移除了批处理层，利用流计算的分布式特征，加大流数据的时间窗口，统一批处理和流处理。

Kappa 架构的流处理系统通常使用 Spark Streaming 或者 Flink等实现，服务层通常使用MySQL 或 HBase 等实现。Kappa 架构依赖 Kafka 等消息队列来保存所有历史，而 Kafka 难以实现数据的查询、更新和纠错，发生故障或者升级时需要重做所有历史，周期较长；此外，Kappa 架构无法实时汇集多个可变数据源形成的数据集快照，不适合即席查询。

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

Omega 架构由流数据处理系统和实时数仓构成。相比 Lambda 和 Kappa，Omega 架构新引入了实时数仓和快照视图，快照视图是归集了可变更数据源和不可变更数据源后形成的 T+0 实时快照，随着源库的变化实时变化。

偶数打造的流处理系统 WASP 既可以实现实时连续的流处理，也可以实现 Kappa 架构中的批流一体。但与 Kappa 架构不同的是，Omega 架构通过实时数仓 OushuDB 存储来自 Kafka 的全部历史数据，规避了 Kafka 难以实现数据更新和纠错的问题，大幅提高效率。此外，整个服务层可以在实时数仓中实现，无需额外引入 MySQL、HBase 等组件，极大简化了数据架构。