1. 流批一体概述：Lambda架构与Kappa架构的对比、流批一体的核心价值、实时数仓与离线数仓的融合趋势

大家好，我是这次课程的主讲。咱们直接进入正题。

流批一体这个概念，这几年在圈子里炒得挺热。但说实话，很多人对它的理解还停留在「用一套代码搞定实时和离线」这个层面。我个人觉得，这有点太表面了。

要真正搞懂流批一体，得先看看它要解决什么问题。说白了，就是传统架构里实时和离线「两张皮」带来的各种麻烦。

Lambda 架构：老牌架构的得与失

先聊聊 Lambda 架构。这玩意儿在 2011 年左右被提出来，算是大数据领域的经典设计了。

它的核心思路很简单：批处理层负责全量、准确的数据，速度层负责增量、低延迟的数据。最后通过一个服务层把两边的结果合并起来，对外提供服务。

我在 2016 年参与过一个电商大促项目，用的就是 Lambda 架构。当时觉得这设计挺完美的——离线跑 T+1 的报表，实时看秒级的大屏。但后来发现，维护成本是真高。

你想想看，一个简单的 UV 计算，批处理用 Hive 跑个 count distinct，实时用 Flink 维护一个 HyperLogLog。结果对不上，是批处理算错了还是实时丢了数据？排查起来相当痛苦。

Kappa 架构：简化，但并非万能

Kappa 架构的出现，就是为了解决 Lambda 架构的「两套代码」问题。它的核心理念是：一切皆流。所有数据都走实时流处理，离线计算只是流处理的一个特例——把历史数据重新「回放」一遍而已。

我记得第一次看到这个想法时，觉得挺惊艳的。但实际落地时，发现坑也不少。

另外，Kappa 架构在处理大规模历史数据时，性能往往不如批处理。你想想看，用 Flink 去重跑一个月的数据，和用 Spark 批量跑，效率差距还是挺明显的。

两种架构的对比

我把两者的核心差异整理了一下，方便你对照着看：

对比维度	Lambda 架构	Kappa 架构
数据处理方式	批处理 + 流处理	纯流处理
代码维护	两套代码，维护成本高	一套代码，维护成本低
数据一致性	批流结果需合并，易出现不一致	天然一致，但依赖消息队列可靠性
历史数据重跑	批处理直接重跑，效率高	需回放消息，效率较低
运维复杂度	高，需维护两套集群	低，一套集群搞定
适用场景	对历史数据准确性要求极高的场景	实时性要求高、历史数据重跑少的场景

流批一体的核心价值

讲完两种架构，咱们再聊聊流批一体到底解决了什么问题。我个人认为，它的核心价值可以概括为三点：

1. 一套代码，两种语义：同一份代码，既能跑批处理，也能跑流处理。业务逻辑只需要写一次，避免了 Lambda 架构里的「两张皮」问题。
2. 数据口径统一：批和流共用同一套计算引擎和存储格式，计算结果天然一致。再也不用半夜爬起来对数据了。
3. 运维成本降低：一套集群、一套监控、一套调度。出问题只需要查一个地方。

实时数仓与离线数仓的融合趋势

最后聊聊趋势。其实流批一体不仅仅是技术架构的演进，更是数据仓库建设思路的转变。

传统的离线数仓，以 Hive 为核心，T+1 产出数据。实时数仓则以 Kafka + Flink 为核心，秒级产出数据。这两者本来是井水不犯河水的。但业务方不干了——他们既要实时性，又要准确性。

所以现在的趋势是：实时数仓和离线数仓正在走向融合。具体表现在：

• 存储层融合：Hudi、Iceberg、Delta Lake 这些湖仓一体技术，让批和流共用同一份数据
• 计算层融合：Flink 既能做流处理，也能做批处理；Spark 也在加强流处理能力
• 元数据融合：统一的 Schema 管理和数据血缘，让批流的数据模型保持一致

嗯，说到 Schema 管理，这就是咱们这门课的核心了。流批一体搞得好不好，很大程度上取决于 Schema 治理做得到不到位。后面我会详细展开。

下面这张图，是我对本章内容的一个总结：

从 Lambda 到 Kappa，再到流批一体，本质上都是在追求「更简单、更一致、更高效」的数据处理方式。而 Schema 治理，就是让这一切变得可控的关键。