流批一体架构基础：Lambda、Kappa 与核心理念
这一章，我们来聊聊流批一体架构的来龙去脉。说实话，我最早接触大数据架构时，Lambda 还是主流。那时候做数据质量，真是两头受气——批处理慢，流处理不准。后来 Kappa 出来了，大家觉得终于有救了，结果发现也不是万能药。
嗯，我们先从最经典的 Lambda 架构说起。
Lambda 架构：批与流的“双轨制”
Lambda 架构是 Nathan Marz 提出的。它的核心思路很简单：用两条路处理数据。
- 批处理层（Batch Layer）：存储全量原始数据，定期计算。结果准确，但延迟高。
- 流处理层（Speed Layer）：实时处理增量数据。延迟低，但结果可能不精确。
- 服务层（Serving Layer）：合并批和流的结果，对外提供服务。
我在项目中遇到过这样一个场景：业务方要求 T+1 的报表必须 100% 准确，同时又要看实时大屏。当时我们就是 Lambda 架构。批处理跑 Hive，流处理用 Storm。结果呢？
Lambda 架构的痛点
- 两套代码，维护成本翻倍。批处理写一套逻辑，流处理再写一套，很容易出现不一致。
- 数据质量难对齐。批处理修正了历史数据，流处理还在用旧逻辑，服务层合并时经常出现“数据抖动”。
- 存储冗余。批处理层存一份全量数据，流处理层可能还要存一份增量状态。
说白了，Lambda 架构就像两条铁轨并行。火车（数据）必须同时跑在两条轨道上，最后再并轨。一旦两条轨道的逻辑不同步，翻车是迟早的事。
Kappa 架构：流处理“一统天下”
Kappa 架构是 Jay Kreps 提出的。他的想法很激进：为什么非要两条路？只用流处理不行吗？
Kappa 架构的核心是：所有数据都走流处理管道。如果需要重新计算，就从头回放数据。这依赖于一个关键组件——不可变的消息日志（比如 Kafka）。
我个人的习惯：在评估 Kappa 架构时，先问三个问题：
- 数据源是否支持全量回放？
- 流处理引擎能否处理历史数据积压？
- 业务能否接受“最终一致性”？
如果三个答案都是“是”，Kappa 值得一试。
Kappa 架构的优势很明显：
- 一套代码，逻辑统一。数据质量问题更容易定位。
- 架构简单，运维成本低。
- 天然支持实时。
但它的短板也很致命：
- 流处理引擎的容错机制不如批处理成熟。一旦状态丢失，恢复起来很麻烦。
- 对于复杂的 ETL 和聚合操作，流处理的性能可能不如批处理。
- 数据回放时，如果数据量巨大，耗时可能比批处理还长。
我曾经在一个 IoT 项目里尝试过纯 Kappa 架构。设备数据通过 Kafka 接入，Flink 做实时计算。一开始很顺利，直到有一天需要修正一个历史 bug。我们回放了 3 天的数据，结果 Flink 的状态后端撑爆了。嗯，从那以后我学乖了——Kappa 不是银弹。
流批一体：取长补短
流批一体架构，说白了就是用同一套引擎、同一套 API、同一套元数据，同时支持批处理和流处理。它试图融合 Lambda 和 Kappa 的优点，同时规避它们的缺点。
流批一体的核心理念可以概括为三点：
| 理念 | 说明 | 对数据质量的影响 |
|---|---|---|
| 统一编程模型 | 批和流使用相同的算子、相同的逻辑表达 | 避免两套代码不一致导致的质量问题 |
| 统一存储 | 批和流共享同一份数据源和状态存储 | 消除数据冗余，保证数据一致性 |
| 统一调度 | 批任务和流任务在同一个调度体系下管理 | 便于监控和问题追溯 |
你想想看，如果批和流用的是同一套代码，那数据质量保障就简单多了。你只需要关注一套逻辑的正确性，而不是两套。
注意：流批一体不是“流处理替代批处理”。它是在架构层面统一了表达，但在执行层面，批处理仍然可以利用批量优势（比如谓词下推、向量化读取），流处理仍然可以利用低延迟优势（比如事件时间、水位线）。
目前主流的流批一体引擎包括 Flink、Spark Structured Streaming、Kafka Streams 等。其中 Flink 的流批一体做得最彻底——它把批处理看作“有界流”，流处理看作“无界流”，底层共享同一个运行时。
下面这张图展示了流批一体架构的核心逻辑：
从这张图可以看出，流批一体的关键在于引擎层统一。数据从接入到输出，中间的处理逻辑是同一套。批处理和流处理只是数据边界的区别——有界数据走批处理路径，无界数据走流处理路径。
这对数据质量意味着什么？
- 一致性：同一套代码，批和流的结果天然一致。不再需要 Lambda 架构中的“合并层”来修正偏差。
- 可回溯性：流处理可以像批处理一样回放历史数据，方便问题排查和数据修复。
- 简化监控：只需要监控一套引擎的指标，而不是两套。
避坑指南：我曾经在一个项目中，团队为了追求“流批一体”，强行把所有的批处理逻辑都改成了流处理。结果呢？一些复杂的多表关联在流处理中性能极差，延迟从分钟级变成了小时级。后来我们做了个折中：核心链路用流批一体，边缘场景保留独立的批处理任务。记住，流批一体是手段，不是目的。
最后，我用一个表格总结一下三种架构的对比：
| 维度 | Lambda 架构 | Kappa 架构 | 流批一体架构 |
|---|---|---|---|
| 代码维护 | 两套代码 | 一套代码 | 一套代码 |
| 数据一致性 | 需合并层修正 | 最终一致性 | 天然一致 |
| 延迟 | 批处理高，流处理低 | 低 | 批处理可优化，流处理低 |
| 容错 | 批处理成熟，流处理较弱 | 依赖消息日志回放 | 统一容错机制 |
| 适用场景 | 对准确性要求极高的报表 + 实时大屏 | 纯实时场景，数据可回放 | 大多数现代数据平台 |
嗯，这一章的内容就到这里。流批一体架构不是凭空出现的，它是对 Lambda 和 Kappa 的扬弃。理解了这三种架构的演进，你就能明白为什么数据质量保障在流批一体时代有了新的挑战和机遇。