2、流批一体核心概念：Lambda架构、Kappa架构、流批一体架构的演进与对比
聊到流批一体，绕不开三个词：Lambda、Kappa、流批一体。很多新手容易搞混，觉得它们只是换了个名字。其实不是。
这三个架构，代表了三种不同的设计哲学。我最早接触 Lambda 时，觉得它太笨重。后来在日志场景里踩了坑，才明白每个架构都有它的生存空间。今天咱们就掰开揉碎，把它们的来龙去脉讲清楚。
2.1 Lambda 架构：经典但笨重的“双轨制”
Lambda 架构是 Nathan Marz 在 2011 年左右提出的。它的核心思想很简单：用两条路处理数据。
- 批处理层（Batch Layer）：负责全量数据，保证最终一致性。通常用 Hadoop、Spark 跑 T+1 任务。
- 流处理层（Speed Layer）：负责实时数据，提供低延迟的近似结果。常用 Storm、Flink。
- 服务层（Serving Layer）：将批和流的结果合并，对外提供服务。
说白了，就是“既要又要”。既要批处理的准确性，又要流处理的实时性。但代价是什么？
Lambda 架构的问题很明显：
- 维护两套代码：批和流的逻辑必须保持一致，但实现方式完全不同。改一个业务逻辑，要改两遍。
- 数据口径难对齐：批处理用精确去重，流处理用近似算法，结果天然有差异。
- 运维成本高：两套集群、两套监控、两套告警。出问题时，先得定位是批的问题还是流的问题。
不过，Lambda 架构也有它的优势。在早期技术不成熟时，它是唯一能同时满足准确性和实时性的方案。直到现在，很多银行、证券的核心系统还在用 Lambda，因为它的批处理层可以随时重跑历史数据，保证数据正确。
2.2 Kappa 架构：简化，但并非万能
2014 年，Jay Kreps 提出了 Kappa 架构。它的想法很激进：去掉批处理层，只用流处理。
怎么做到的？核心是两点：
- 用消息队列做数据缓冲：所有数据先进 Kafka，保留足够长的历史。
- 流处理引擎重放数据：需要重新计算时，从 Kafka 的某个 offset 开始重放，相当于“批处理”变成了“流处理的历史回放”。
你想想看，这样一来，代码只有一套，运维只有一套，数据口径天然一致。是不是很完美？
嗯，理想很丰满，现实很骨感。我在项目中试过 Kappa 架构，遇到了几个棘手的问题：
- Kafka 存储成本高：要保留几天的数据还好，但要保留几个月甚至一年的数据，Kafka 的磁盘开销会让你肉疼。
- 重放效率低：全量重放几亿条日志，流处理引擎的吞吐量远不如批处理引擎。我试过用 Flink 重放一周的日志，跑了整整 6 个小时。
- 复杂计算场景吃力：比如多维分析、大表 Join，流处理引擎的 State 管理会变得非常复杂。
所以，Kappa 架构更适合数据量可控、计算逻辑简单的场景。比如实时监控、简单聚合。但对于日志场景这种海量数据、复杂 ETL 的场景，Kappa 架构有点力不从心。
2.3 流批一体架构：融合与进化
既然 Lambda 太笨重，Kappa 又不够强，那有没有更好的方案？
有，就是流批一体架构。它的核心思想是：同一套引擎、同一套 SQL、同一套元数据，同时支持流处理和批处理。
说白了，就是让批处理跑在流处理引擎上，或者让流处理跑在批处理引擎上。目前主流的选择是 Flink，因为它原生支持流批一体。
我个人的习惯是，在日志场景里这样落地：
- 实时链路：Flink 消费 Kafka，做实时 ETL、实时聚合，结果写入 Elasticsearch 或 ClickHouse。
- 离线链路：Flink 读取 HDFS 上的历史日志，用同样的 SQL 逻辑做批量计算，结果写入 Hive 或 HBase。
- 元数据统一：用 Hive Metastore 管理表结构，Flink 实时和离线任务共享同一份 Schema。
这样做的好处很明显：
- 一套代码：实时和离线用同一个 Flink SQL 作业，只是运行模式不同。
- 口径一致：同一个算子，实时跑和离线跑，结果完全一样。
- 运维简化：只需要维护 Flink 集群，不需要两套独立的系统。
| 维度 | Lambda 架构 | Kappa 架构 | 流批一体架构 |
|---|---|---|---|
| 处理引擎 | 批 + 流（两套） | 流（一套） | 流批一体（一套） |
| 代码维护 | 两套代码 | 一套代码 | 一套代码 |
| 数据一致性 | 需补偿逻辑 | 天然一致 | 天然一致 |
| 历史重算 | 高效（批处理） | 低效（流重放） | 高效（批模式） |
| 运维复杂度 | 高 | 中 | 低 |
| 适用场景 | 强一致性要求 | 简单实时计算 | 日志 ETL、复杂分析 |
2.4 架构演进路线图
为了让你更直观地理解这三种架构的演进关系，我画了一张图：
2.5 日志场景的架构选择建议
说了这么多，到底该选哪个？我根据实际经验，给你几个建议：
- 如果团队小、资源少：直接上流批一体架构。用 Flink 搞定一切，省心省力。
- 如果历史数据需要频繁重算：流批一体架构的批模式比 Kappa 的重放效率高得多。
- 如果业务对准确性要求极高：可以考虑 Lambda 架构，但要做好补偿逻辑的维护准备。
- 如果只是简单的实时监控：Kappa 架构就够了，别搞复杂了。
我曾经在一个日志平台项目里，一开始选了 Kappa 架构。结果业务方要求支持 90 天历史数据回溯，Kafka 的磁盘直接爆了。后来改成流批一体架构，实时用 Flink 消费 Kafka，离线用 Flink 读 HDFS，问题迎刃而解。
所以，架构没有银弹。理解每种架构的优缺点，结合自己的场景做选择，才是正解。