1. 流批一体概述：为什么需要流批一体？
大家好，我是这次课程的主讲。做了十几年数据架构，我见过太多团队在流和批之间反复横跳。今天咱们就来聊聊，为什么会出现流批一体这个思路，它到底解决了什么问题。
先问大家一个问题：你的数据仓库里，是不是同时跑着两套代码？一套给离线批处理用，另一套给实时流处理用？如果是，那你大概率已经感受到了维护两套系统的痛苦。
Lambda 架构的痛点
Lambda 架构，说白了就是「两条腿走路」。一条腿跑批处理，保证全量数据的准确性；另一条腿跑流处理，追求数据的低延迟。最后在服务层把两边的结果合并。
听起来挺合理对吧？但我在项目中踩过的坑，真不少。
Lambda 架构的核心问题
- 代码维护成本高：同一套业务逻辑，要在批处理和流处理里各写一遍。改一个字段，两边都得改，稍不注意就对不上了。
- 数据一致性难保证：批处理结果和流处理结果合并时，经常出现数据重叠或缺失。我遇到过凌晨两点被叫起来排查数据对不上的情况，最后发现是两套系统的窗口边界没对齐。
- 运维复杂度爆炸：批处理用 Hive/Spark，流处理用 Flink/Storm，两套集群、两套监控、两套告警。出问题了你得先判断是批的锅还是流的锅。
举个例子。我曾经帮一家电商公司做实时大屏，要求展示「今日实时销售额」和「历史累计销售额」。Lambda 架构下，实时销售额走 Flink，历史数据走 Hive。结果呢？每天凌晨 0 点，实时数据和离线数据交接的时候，销售额总会跳变。用户看到大屏上的数字突然掉下去，吓得以为系统崩了。
为什么会这样？因为实时数据有延迟，离线数据有回溯，两边的时间窗口定义不一样。你想想看，这种问题靠修修补补能解决吗？
Kappa 架构的局限
Kappa 架构的出现，就是为了解决 Lambda 的「两套代码」问题。它的核心思想很简单：只用一套流处理引擎，搞定所有事情。历史数据重放一遍，就当是流数据重新处理。
听起来很优雅，对吧？但实际用起来，坑也不少。
| Kappa 架构的局限 | 具体表现 |
|---|---|
| 历史数据重放效率低 | 处理 TB 级历史数据时，流引擎的吞吐量远不如批引擎。我见过一个项目，重放 3 个月的数据跑了整整两天。 |
| 状态管理复杂 | 流处理的状态后端（比如 RocksDB）在处理海量历史数据时，容易成为瓶颈。状态膨胀、GC 频繁，都是常见问题。 |
| Exactly-Once 语义代价高 | 为了保证数据不丢不重，Kappa 架构需要依赖 Kafka 等消息队列的持久化和回溯能力。一旦消息队列出问题，整个链路都得重建。 |
| 不适合复杂 ETL | 很多离线场景需要多表 Join、复杂聚合、数据倾斜处理。这些在流引擎上实现起来，远不如批处理顺手。 |
避坑指南：我曾经在一个金融项目中尝试全量使用 Kappa 架构。结果发现，每天凌晨的 T+1 报表计算，用 Flink 跑要 4 小时，而用 Spark 跑只要 40 分钟。最后不得不回到 Lambda 的老路。所以，Kappa 架构更适合「数据量可控、历史数据重放频率低」的场景。
流批一体的核心思想
Lambda 太累，Kappa 太理想。那有没有一种架构，既能享受批处理的吞吐和准确性，又能拥有流处理的低延迟？
这就是流批一体的出发点。它的核心思想其实就一句话：同一套引擎，同一套 SQL，同一套元数据，同时支持流和批两种执行模式。
流批一体的三个关键点
- 统一的编程模型：写一次代码，既能在流模式下跑，也能在批模式下跑。业务逻辑不需要维护两套。
- 统一的存储层：流表和批表共享同一份元数据和存储格式。数据不再需要「从 Kafka 搬到 HDFS」这种冗余操作。
- 统一的调度与运维：一个集群、一套监控、一套告警。流作业和批作业只是执行模式的不同，底层资源池是共享的。
你可能会问：这跟 Kappa 架构有什么区别？区别大了。Kappa 是「只用流」，而流批一体是「流和批都是同一引擎的不同执行模式」。举个例子，Flink 在流批一体架构下，处理实时数据时用流模式，处理历史数据时自动切换到批模式。引擎内部会优化执行计划，批模式用批调度、批 shuffle，流模式用流调度、流 shuffle。用户根本不需要关心底层差异。
说白了，流批一体不是要消灭批处理，也不是要消灭流处理。它是要把两者的优势结合起来，让开发者只关注业务逻辑，而不是底层引擎的差异。
我的个人经验：在选型流批一体框架时，不要只看宣传。我建议你拿自己最复杂的 ETL 任务去测试，看看它在流模式和批模式下的表现。很多框架号称「流批一体」，实际上只是把批处理包装成了流处理，性能惨不忍睹。
流批一体的知识体系
下面这张图，是我对本章知识体系的总结。你可以看到，流批一体并不是凭空出现的，它是在 Lambda 和 Kappa 的基础上演进而来。
从图上你可以看到，流批一体并不是简单的「二选一」，而是对 Lambda 和 Kappa 的扬弃。它保留了 Lambda 的「批处理保证准确性」和 Kappa 的「流处理保证低延迟」，同时去掉了「两套代码」和「历史重放效率低」的痛点。
嗯，这里要注意一点：流批一体不是银弹。如果你的场景只有纯流处理，或者纯批处理，那没必要强行上流批一体。它最适合的场景是：既有实时需求，又有离线需求，而且业务逻辑高度重合。
我记得有一次给客户做技术选型，对方问：「我们现在的 Lambda 架构跑得好好的，为什么要换成流批一体？」我的回答是：如果你不觉得痛，那就别换。但如果你每天被两套代码的对账问题折磨，被凌晨的数据不一致告警吵醒，那流批一体值得你认真考虑。