一、流批一体概述：从 Lambda 到 Kappa，我们到底在解决什么问题

大家好，我是老张。做数据工程十几年了，今天咱们聊聊流批一体。

说实话，这个概念的提出，背后是无数个踩坑的夜晚。我记得 2017 年帮一家电商公司搭实时数仓，白天跑批任务，晚上跑流任务，两套代码、两套运维、两套监控。每次数据对不上，排查起来简直要命。

嗯，这节课我们先搞清楚三个问题：架构怎么演进的？流批一体到底值不值得搞？数据一致性为什么是绕不开的坎？

1.1 Lambda 架构：两套系统，双倍痛苦

先说说 Lambda 架构。说白了，就是批处理一套、流处理一套，最后在服务层合并结果。

• 批处理层：用 Spark、Hive 跑全量数据，保证最终一致性
• 流处理层：用 Flink、Storm 处理实时增量，追求低延迟
• 服务层：把两边的结果合并，对外提供统一查询

听起来挺合理对吧？但我在项目中遇到过这样的场景：批处理凌晨 3 点跑完，流处理实时更新，结果用户早上 8 点查到的数据，批量和流量的聚合值差了 0.5%。排查了整整两天，最后发现是窗口边界没对齐。

1.2 Kappa 架构：一套系统，新的挑战

Kappa 架构的提出，其实是对 Lambda 的反思。它的核心思想很简单：只用一套流处理引擎，所有数据都走流管道。历史数据重放？那就把数据重新灌进 Kafka，让流任务重新跑一遍。

对比维度	Lambda 架构	Kappa 架构
代码维护	两套代码，容易不一致	一套代码，逻辑统一
运维复杂度	高，需要维护两套集群	低，单一引擎
历史数据重算	批处理天然支持	依赖消息队列重放
延迟与吞吐	批处理高吞吐，流处理低延迟	取决于引擎能力
一致性保障	最终一致性，合并层复杂	端到端一致性，依赖引擎

我个人习惯用 Kappa 架构做新项目。但要注意，Kappa 不是银弹。我曾经在一个 IoT 场景里尝试全量用 Kappa，结果历史数据重放时，Kafka 的 Topic 积压了 3 天，流任务根本追不上。嗯，这里要注意：Kappa 适合数据量可控、重放频率低的场景。

1.3 流批一体的核心价值

流批一体，说白了就是让一套引擎既能跑批，也能跑流。它的核心价值我总结为三点：

1. 统一编程模型：批和流用同一套 API，比如 Flink 的 DataStream API 或 Table API。开发效率提升 50% 以上。
2. 降低运维成本：一套集群、一套监控、一套部署。我见过一个团队从两套 Spark+Flink 集群合并成一套 Flink 集群，运维人力直接减半。
3. 数据一致性更可控：批和流共享状态和语义，避免了 Lambda 架构中两套结果对不上的问题。

1.4 数据一致性挑战：为什么这么难？

数据一致性，是流批一体绕不开的硬骨头。为什么难？我列几个典型的场景：

• 乱序数据：网络延迟、设备离线，数据到达顺序和实际发生顺序不一致。你想想看，一个订单支付事件先到，下单事件后到，你怎么算？
• 窗口边界：批处理按天、小时切分，流处理按事件时间窗口。边界对齐是个大问题。
• 状态一致性：流处理引擎维护的状态（比如计数、聚合值）在故障恢复后，必须和外部存储一致。
• 幂等性：数据重放时，同一个事件不能被重复计算。我曾经因为 Kafka 重平衡导致数据重复消费，结果一个 PV 指标翻了一倍。

1.5 架构演进全景图

下面这张图，是我自己总结的流批一体架构演进路线。从 Lambda 到 Kappa，再到真正的流批一体，每一步都是为了解决一致性问题。

1.6 小结：我们为什么要学这门课

回到最开始的问题。流批一体不是银弹，但它确实解决了 Lambda 架构的很多痛点。我个人认为，未来 3-5 年，流批一体会成为数据工程的主流范式。

这门课，我会从实际项目出发，带你一步步解决数据一致性这个核心难题。包括 Exactly-Once 语义的实现、Watermark 机制、状态一致性、端到端校验等等。每个知识点，我都会结合自己踩过的坑来讲。

嗯，准备好了吗？我们开始吧。