实时数据产品架构总览：Lambda、Kappa 与流批一体

做实时数据产品，第一个绕不开的问题就是：架构怎么选？

我见过不少团队，一上来就拍脑袋选了 Lambda，结果维护成本高得吓人。也见过迷信 Kappa 的，最后被历史数据回溯搞得焦头烂额。说白了，没有银弹。

这一章，我把三种主流架构掰开揉碎讲清楚。你不仅能看懂它们的设计思路，还能知道在什么场景下该选谁。

1. Lambda 架构：经典但沉重

Lambda 架构是 2011 年由 Nathan Marz 提出的。它的核心思想很简单：用两条路处理数据。

• 批处理层（Batch Layer）：存储全量原始数据，定期计算。优点是准确，缺点是延迟高。
• 流处理层（Speed Layer）：实时处理增量数据。优点是快，缺点是可能不精确。
• 服务层（Serving Layer）：合并批和流的结果，对外提供服务。

2. Kappa 架构：简化但有限

Kappa 架构是 Jay Kreps 在 2014 年提出的。它的想法很直接：既然流处理能搞定一切，为什么还要批处理？

• 统一处理层：只用一套流引擎（比如 Kafka + Flink）。
• 数据重放：需要回溯历史数据时，直接从 Kafka 重放消息。
• 结果存储：输出到 KV 存储或 OLAP 引擎。

听起来很美，对吧？但实际落地时，坑也不少。

Kappa 最适合的场景是：数据源单一、回溯需求少、对实时性要求极高。比如实时监控、在线推荐。

3. 流批一体架构：未来的方向

流批一体，说白了就是让同一套引擎、同一套代码，既能跑流模式，也能跑批模式。Flink 是这方面的代表。

• 统一 API：Table API / SQL 在流和批上语义一致。
• 动态切换：运行时根据数据量自动选择流或批执行计划。
• Exactly-Once 语义：端到端一致性，不再需要手动对齐。

但流批一体也不是万能的。它要求你的数据模型和计算逻辑在流和批上完全一致。有些场景，比如复杂的多维聚合，流批一体的优化器可能还不够智能。

4. 三种架构对比

维度	Lambda	Kappa	流批一体
代码维护	两套代码	一套代码	一套代码
计算引擎	批 + 流（如 Spark + Flink）	仅流（如 Flink）	统一引擎（如 Flink）
数据回溯	批处理层天然支持	依赖消息队列重放	流批模式切换
实时性	秒级（流层）	毫秒级	毫秒级
准确性	高（批层修正）	中等（依赖 Exactly-Once）	高（统一语义）
运维复杂度	高	中	低
适用场景	金融、风控、历史报表	实时监控、在线推荐	广告、IoT、数据中台

5. 选型建议

怎么选？我个人的习惯是分三步走：

1. 看数据量：每天 TB 级以上，优先考虑 Lambda 或流批一体。Kappa 在超大规模下容易撑不住。
2. 看回溯需求：如果经常需要重跑历史数据（比如财务对账），Lambda 的批处理层更靠谱。Kappa 的重放机制在数据量大时很慢。
3. 看团队能力：如果团队只有 3-5 人，别碰 Lambda。直接上流批一体，用 Flink SQL 搞定大部分逻辑。

6. 架构总览图

下面这张图，把三种架构的核心流程画出来了。你可以直观地看到它们的差异。

7. 总结

架构选型没有标准答案。Lambda 经典但沉重，Kappa 简洁但有限，流批一体是趋势但还不够完美。

我的建议是：从流批一体开始。如果遇到性能瓶颈，再考虑引入批处理层做 Lambda 混合。别一开始就把架构搞复杂了——你想想看，业务还没跑起来，先被架构拖死，多冤。