1. 流批一体概述：Lambda架构的痛点、Kappa架构的局限、流批一体的核心思想与价值
大家好，我是这次课程的主讲。在正式开始之前，我想先聊聊我自己的经历。
几年前我接手过一个金融风控项目，每天要处理上亿条交易日志。团队一开始选了Lambda架构，结果呢？维护两套代码、两套集群，线上事故频发。后来我们尝试切到Kappa，又发现历史回溯时根本扛不住。说白了，那时候的架构选型，就像在「实时」和「准确」之间走钢丝。
这节课，我们就来拆解一下这些架构的来龙去脉。你想想看，为什么业界最终会走向「流批一体」？
1.1 Lambda架构：看起来很美好
Lambda架构是2011年由Nathan Marz提出的。它的核心思路很简单：用批处理层保证数据的完整性，用速度层保证数据的低延迟。
听起来很合理，对吧？但我在实际项目中踩过的坑，可不少。
Lambda架构的核心组成
- 批处理层（Batch Layer）：存储全量原始数据，定期计算离线视图。典型技术：Hadoop、Spark SQL。
- 速度层（Speed Layer）：处理实时增量数据，提供低延迟视图。典型技术：Storm、Flink。
- 服务层（Serving Layer）：合并批视图和实时视图，对外提供统一查询。
嗯，这里要注意。Lambda架构最大的问题，不是技术实现，而是「人」的问题。
1.2 Lambda架构的四大痛点
我总结了一下，Lambda架构在实际落地中，有四个绕不开的坑：
| 痛点 | 具体表现 | 我的亲身经历 |
|---|---|---|
| 代码维护成本高 | 批处理和流处理需要两套逻辑，同样的ETL要写两次 | 我曾经因为批流两套代码对不上，导致线上特征数据差了3个小时 |
| 数据口径不一致 | 批处理用T+1的聚合逻辑，流处理用滑动窗口，结果天然对不上 | 业务方天天问：为什么实时报表和离线报表数字不一样？ |
| 运维复杂度爆炸 | 同时维护Hadoop集群和Flink集群，资源隔离、监控告警都得搞两套 | 有一次批处理集群GC导致任务延迟，结果实时集群也跟着背锅 |
| 数据回溯困难 | 修复历史数据时，批处理层要重跑，速度层要重放，流程极其繁琐 | 我记得有一次修复一个bug，批流两边各花了3天，最后发现修反了 |
说白了，Lambda架构把「实时」和「准确」这两个目标，强行拆成了两套系统。但数据本身是同一份，人为割裂只会带来无穷无尽的麻烦。
1.3 Kappa架构：理想很丰满，现实很骨感
2014年，Jay Kreps提出了Kappa架构。他的想法很激进：只用一套流处理引擎，搞定所有事情。历史数据通过重放Kafka日志来回溯，不再需要批处理层。
我第一次看到这个方案时，觉得太酷了。但真正落地时，才发现事情没那么简单。
Kappa架构的核心逻辑
所有数据都进入Kafka，流处理引擎（如Flink）从Kafka消费数据。需要回溯时，重置消费者偏移量，重新消费历史数据。
1.4 Kappa架构的三大局限
Kappa架构虽然简化了架构，但它在实际场景中，有几个硬伤：
- 历史回溯性能差：重放几天的数据还好，但如果是几个月甚至几年的数据，Kafka的吞吐量根本扛不住。我见过一个项目，重放3个月的数据花了整整2天。
- 状态管理复杂：流处理引擎的状态后端（如RocksDB）在长时间回溯时，状态恢复和Checkpoint的稳定性是个大问题。我曾经因为状态膨胀，导致Flink TaskManager频繁OOM。
- 数据倾斜难处理：批处理可以通过Shuffle和Sort来应对数据倾斜，但流处理是增量计算的，遇到热点Key时，很难像批处理那样做全局重分区。
你想想看，如果Kappa架构真的完美，那为什么现在大多数公司还在用Lambda？
1.5 流批一体的核心思想
流批一体，不是简单的「把批处理和流处理合并成一个框架」。它的核心思想是：同一份数据，同一套代码，同一个引擎。
说白了，就是让批处理成为流处理的一种特殊形式。批处理 = 有界流，流处理 = 无界流。两者在API层面统一，在运行时层面共享优化。
流批一体的三大核心原则
- API统一：批处理和流处理使用相同的算子（如Map、Filter、Join），开发者只需写一次逻辑。
- 语义一致：批处理和流处理保证相同的计算结果，消除数据口径差异。
- 部署统一：同一套集群、同一套监控、同一套运维体系。
我记得在2019年，我们团队开始尝试用Flink的批流一体能力重构特征计算链路。刚开始很痛苦，但一旦跑通，那种「一次开发，到处运行」的感觉，真的很爽。
1.6 流批一体的核心价值
流批一体到底能带来什么？我总结了四个字：降本增效。
| 价值维度 | 具体收益 | 我的实际数据 |
|---|---|---|
| 开发效率提升 | 一套代码搞定批流，不再需要两套逻辑 | 我们团队开发周期从2周缩短到3天 |
| 运维成本降低 | 统一集群、统一监控、统一告警 | 运维人力从3人降到1人 |
| 数据一致性保证 | 批流计算结果天然对齐，不再有口径争议 | 业务方投诉率下降了90% |
| 资源利用率优化 | 批流任务可以混部，资源可以弹性伸缩 | 集群整体利用率提升了40% |
嗯，这里要特别强调一下。流批一体不是银弹。如果你的场景对延迟要求极高（毫秒级），或者数据量级极小，传统的Lambda架构可能仍然有它的优势。但对于大多数互联网场景，流批一体是更优的选择。
1.7 流批一体的技术演进路线
从Lambda到Kappa，再到流批一体，这个演进过程其实反映了业界对「实时计算」认知的深化。我画了一张图，帮你理清这个脉络：
从这张图你可以看到，流批一体并不是凭空出现的。它是在Lambda和Kappa的基础上，吸收了各自的优点，同时解决了它们的痛点。
1.8 什么时候该选流批一体？
我个人的经验是，如果你的场景满足以下条件，流批一体是首选：
- 数据量中等偏大：每天几亿到几十亿条数据，批流两套系统维护成本太高。
- 实时性要求中等：秒级到分钟级延迟，不需要毫秒级响应。
- 数据口径要求严格：实时报表和离线报表必须一致，不能有差异。
- 团队规模有限：没有足够的人力维护两套系统。
避坑指南
我曾经在一个IoT项目中强行推流批一体，结果因为数据量太大（每天千亿级），Flink的状态后端扛不住，最后不得不回退到Lambda。所以，选型一定要结合自己的实际场景，不要为了「新」而「新」。
1.9 小结
好了，这一节的内容就到这里。我们回顾一下核心要点：
- Lambda架构的痛点在于两套系统带来的维护成本、数据不一致和回溯困难。
- Kappa架构虽然简化了架构，但在历史回溯、状态管理和数据倾斜方面有局限。
- 流批一体的核心是「同一份数据，同一套代码，同一个引擎」，它解决了Lambda和Kappa的痛点。
- 流批一体的价值在于降本增效，但选型时要结合自己的实际场景。