1. 流批一体概述：从 Lambda 到 Kappa，我们到底在解决什么问题？
大家好，我是老张。做数据架构十几年了，今天咱们聊聊流批一体。
说实话，我第一次接触这个领域的时候，也被各种概念绕得头晕。Lambda、Kappa、流处理、批处理……听起来都挺高大上，但落地的时候才发现，坑比想象的多。
这一章，我带你理清楚流批一体的来龙去脉。咱们不搞虚的，直接看架构、看对比、看场景。
1.1 为什么会有 Lambda 架构？
先说说 Lambda 架构是怎么来的。
早些年，数据处理分两派：一派做批处理，用 Hadoop、Hive，跑 T+1 报表；另一派做流处理，用 Storm、Spark Streaming，搞实时监控。两套系统各干各的，互不干扰。
但问题来了——业务方想要一个统一的视图。比如电商大促，既要看昨天的总销售额（批处理），又要看当前秒杀订单量（流处理）。两套数据口径还不一样，对不上账。
于是 Nathan Marz 提出了 Lambda 架构。核心思路很简单：
- 批处理层：处理全量历史数据，保证准确性
- 流处理层：处理实时增量数据，保证低延迟
- 服务层：合并两边的结果，对外提供统一查询
听起来挺完美，对吧？
Lambda 架构的核心思想：用两套引擎分别处理历史和实时数据，最后在服务层合并。批处理保证准确，流处理保证时效。
1.2 Lambda 架构的痛点——我在项目中踩过的坑
嗯，这里我要说点实话。Lambda 架构在理论上很优雅，但实际落地的时候，我遇到过不少麻烦。
第一个坑：维护两套代码
批处理和流处理逻辑一样，但代码完全不同。批处理用 Hive SQL，流处理用 Flink SQL，两边各写一遍。改一个业务逻辑，要改两套代码，还要保证结果一致。我曾经在一个项目中，因为批流口径没对齐，对账对了一周。
第二个坑：数据口径不一致
批处理跑的是全量数据，流处理跑的是增量数据。时间窗口、去重逻辑、聚合方式稍有不同，结果就对不上。业务方拿着两份报表来问我：“老张，为什么实时看是 100 万，第二天报表变成 98 万？”
第三个坑：运维成本高
两套集群、两套调度、两套监控。出问题的时候，要同时排查批处理和流处理链路。说实话，运维同学挺崩溃的。
避坑指南：我曾经在一个金融项目中，因为 Lambda 架构的批流口径不一致，导致风控报表延迟了 3 天。后来我们花了大量精力做数据校验和对账。如果你团队不大，建议慎重选择 Lambda。
1.3 Kappa 架构——能不能只用一套引擎？
既然 Lambda 这么麻烦，那有没有更简单的方案？
Jay Kreps 提出了 Kappa 架构。核心思想就一句话：只用一套流处理引擎，搞定所有事情。
怎么做到的？
- 所有数据都走消息队列（比如 Kafka），以流的形式接入
- 流处理引擎（比如 Flink）既处理实时数据，也处理历史数据
- 需要重算历史数据时，直接从 Kafka 的 offset 位置重新消费
说白了，Kappa 架构把批处理当作“特殊的流处理”——把历史数据重新放回流里跑一遍。
我的建议：如果你的业务场景以实时为主，历史重算频率不高，Kappa 架构会更清爽。我最近几个项目都用的 Kappa，运维成本确实低了不少。
1.4 Lambda vs Kappa：一张表看懂区别
咱们直接上对比表，这样更直观。
| 对比维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 处理引擎 | 批处理 + 流处理，两套引擎 | 仅流处理，一套引擎 |
| 代码维护 | 两套代码，逻辑需对齐 | 一套代码，逻辑统一 |
| 数据准确性 | 批处理保证最终一致 | 依赖消息队列的持久化和重放 |
| 延迟 | 流处理低延迟，批处理高延迟 | 统一低延迟 |
| 历史重算 | 重新跑批处理作业 | 从 Kafka 重新消费 |
| 运维复杂度 | 高，两套集群 | 低，一套集群 |
| 适用场景 | 对准确性要求极高，历史数据重算频繁 | 实时性要求高，历史重算较少 |
你想想看，如果你的业务需要频繁重算历史数据（比如金融对账），Lambda 的批处理层能保证准确性。但如果你的业务以实时为主（比如实时大屏、实时推荐），Kappa 会更省心。
1.5 流批一体的核心价值
聊完 Lambda 和 Kappa，咱们回到流批一体本身。它到底解决了什么问题？
核心价值一：统一技术栈
以前批处理用 Spark，流处理用 Flink，现在 Flink 自己就能做批处理。一套引擎、一套 SQL、一套运维。说白了，就是让开发同学少折腾。
核心价值二：数据一致性
批和流用同一套代码、同一个算子、同一个状态后端。结果天然一致，不用再对账了。我记得以前做 Lambda 的时候，每次上线都要写数据校验脚本，现在省了这一步。
核心价值三：降低运维成本
一套集群、一套监控、一套调度。出问题的时候，只需要排查一条链路。运维同学终于可以睡个好觉了。
核心价值四：灵活应对业务变化
业务逻辑变了？改一套代码，批和流同时生效。不需要再等批处理任务跑完才能看到新逻辑的效果。
一句话总结：流批一体的本质，是用一套架构同时满足实时和离线场景，让数据从产生到消费的链路更短、更稳、更一致。
1.6 适用场景——什么时候该用流批一体？
不是所有场景都适合流批一体。我根据自己的经验，列了几个典型场景：
- 实时数仓：既要实时写入，又要离线回溯。比如电商的实时 GMV 看板，同时支持按天、按周的历史趋势分析。
- 实时特征工程：机器学习模型需要实时特征，但训练时又需要历史特征。流批一体可以统一特征生产链路。
- 实时监控与告警：既要秒级延迟的实时告警，又要小时级的趋势分析。一套架构搞定。
- 数据湖入湖：实时数据入湖的同时，还要做历史数据的批量回填。流批一体能统一入湖链路。
但也要注意，如果你的业务以纯离线为主（比如 T+1 报表），或者对实时性完全没要求，那用传统的批处理架构就够了，没必要上流批一体。
注意：流批一体不是银弹。如果你的团队对流处理不熟悉，或者业务场景以离线为主，强行上流批一体反而会增加复杂度。我见过不少团队，为了“技术先进”而上流批一体，最后运维成本比 Lambda 还高。
1.7 流批一体的知识体系总览
最后，我用一张图来总结本章的核心内容。这张图涵盖了 Lambda 架构、Kappa 架构、流批一体的核心价值与适用场景，方便你建立整体认知。
这张图把 Lambda 架构、Kappa 架构、核心价值和适用场景串在了一起。你可以看到，流批一体并不是要取代谁，而是在不同场景下选择最合适的架构。