1. 流批一体概述：从Lambda架构到Kappa架构的演进
大家好，我是这次课程的主讲。咱们直接进入正题——流批一体。
先问个问题：你手头的实时数仓，是不是还跑着两套代码？一套离线批处理，一套实时流处理？维护起来是不是特别痛苦？
嗯，我经历过。2018年我刚接手一个电商大促项目，离线ETL用Hive，实时用Spark Streaming。两套逻辑，两套调度，两套运维。每次改业务口径，两边都得改，还经常对不上数。那段时间，我做梦都在对账。
所以，流批一体的出现，说白了就是来解决这个问题的。
1.1 Lambda架构：曾经的“标准答案”
先聊聊Lambda架构。它把数据处理分成了三层：
- 批处理层：处理全量历史数据，保证准确性
- 流处理层：处理实时增量数据，保证低延迟
- 服务层：合并两边的结果，对外提供服务
听起来很完美对吧？但实际跑起来，坑不少。
我曾经踩过的坑：有一次离线批处理跑完了，实时流还在处理。服务层合并时，同一笔订单在批处理层和流处理层各算了一次。结果报表上GMV翻了一倍。老板问我是不是大促效果太好，我都不敢吭声。
Lambda架构的核心问题在于：
- 两套代码：批处理和流处理逻辑必须分别实现
- 数据对账难：批和流的结果经常不一致
- 运维成本高：两套集群、两套调度、两套监控
你想想看，一个团队同时维护两套技术栈，光是沟通成本就够受的。
1.2 Kappa架构：简化，再简化
后来，LinkedIn的Jay Kreps提出了Kappa架构。核心思想很简单：只用一套流处理引擎，搞定所有事情。
怎么做到的？
- 所有数据都当作流来处理
- 历史数据通过“重放”的方式重新处理
- 不再区分批和流，统一用一套代码
我个人习惯把Kappa架构理解为“流处理的一统天下”。你不需要再纠结“这个逻辑放批处理还是流处理”，所有逻辑都写在流作业里。
核心价值：Kappa架构让“流批一体”从概念变成了可能。你只需要维护一套代码、一套引擎、一套运维体系。
但Kappa架构也不是银弹。我遇到过的问题是：
- 状态管理复杂：长时间运行的流作业，状态越来越大
- 重放效率：重新处理TB级历史数据，耗时可能比批处理还长
- Exactly-Once语义：实现起来比想象中难
1.3 流批一体的核心价值
说了这么多，流批一体到底能带来什么？我总结了几点：
| 价值点 | 说明 |
|---|---|
| 统一开发 | 一套代码搞定批和流，开发效率翻倍 |
| 统一运维 | 一套集群、一套监控、一套调度 |
| 数据一致性 | 批和流共用同一套逻辑，结果天然对齐 |
| 成本降低 | 减少重复计算，降低存储和计算资源消耗 |
| 架构简化 | 从Lambda的三层变成Kappa的一层 |
说白了，流批一体就是让你用更少的资源，做更多的事。
1.4 流批一体的挑战
但别高兴太早。我做了几个流批一体项目后，发现挑战也不少：
- 技术选型：Flink、Spark、Kafka Streams，选哪个？各有优劣
- 语义保证：Exactly-Once在分布式环境下很难完美实现
- 状态管理：大状态作业的调优和容灾
- 数据延迟：流处理对延迟敏感，批处理对吞吐敏感，如何平衡？
- 历史数据回溯：重放TB级数据时，性能和稳定性都是考验
我的建议：不要一上来就追求“纯Kappa”。很多场景下，Lambda + 统一代码框架（比如Flink SQL）反而是更务实的选择。先跑通，再优化。
1.5 架构演进全景图
下面这张图，是我自己画的Lambda到Kappa的演进路线。你可以直观地看到两者的区别。
1.6 我的选择建议
最后，说说我个人在实际项目中的选择逻辑：
- 团队技术栈：如果团队熟悉Flink，优先选Flink SQL做流批一体
- 数据规模：TB级以下，Kappa架构完全够用；PB级以上，考虑Lambda + 统一代码
- 延迟要求：秒级延迟必须上流处理；分钟级延迟，微批处理也能接受
- 成本敏感：流批一体能节省30%-50%的开发和运维成本
一句话总结：流批一体不是银弹，但它确实是当前大数据架构演进的主流方向。选对技术、做好权衡，你就能在成本和效率之间找到最佳平衡点。