增量计算核心概念：批处理 vs 流处理，增量 vs 全量，Lambda架构与Kappa架构
聊增量计算之前，得先把几个基础概念掰扯清楚。很多同学一上来就问我：「老师，增量计算是不是就是流处理？」
嗯，还真不是。这俩东西有关系，但完全是两个维度的事。
我习惯把这一章叫做「地基课」。地基打不牢，后面盖楼肯定歪。咱们一个一个来拆。
批处理 vs 流处理：两种不同的时间观
先看一张对比图，帮你快速建立整体认知：
批处理和流处理，说白了就是「攒够了再算」和「来一条算一条」的区别。
我在项目中遇到过不少团队，一上来就想上流处理。结果业务场景其实只是每天跑一次报表，根本不需要毫秒级延迟。你想想看，杀鸡用牛刀，运维成本翻好几倍，图啥？
全量 vs 增量：计算量的「降维打击」
这个对比更直接。全量计算，每次把整个数据集重新算一遍。增量计算，只算「上次之后新来的那部分」。
举个例子你就明白了：
- 全量：每天凌晨把过去 3 年的订单全部重跑一遍，生成报表。数据量 10 亿条，跑 2 小时。
- 增量：只处理昨天新增的 50 万条订单，合并到前一天的结果上。跑 3 分钟。
差别有多大？你自己感受一下。
| 对比维度 | 全量计算 | 增量计算 |
|---|---|---|
| 计算量 | O(N)，N 为全量数据 | O(Δ)，Δ 为新增数据 |
| 存储开销 | 每次全量结果独立存储 | 仅存基线 + 增量变更 |
| 数据一致性 | 天然一致（全量重算） | 需处理乱序、迟到数据 |
| 适用场景 | 首次加载、数据修复、小数据量 | 持续更新、大数据量、实时场景 |
Lambda 架构：批 + 流的「双轨制」
讲 Lambda 架构之前，先看一张图，帮你理解它的整体结构：
Lambda 架构是 Nathan Marz 提出来的，核心思路就是「两条腿走路」：
- 批处理层：全量计算，保证数据精确。延迟高，但结果可靠。
- 流处理层：增量计算，保证低延迟。结果可能有点偏差，但胜在快。
- 服务层：把两边的结果合并，对外提供统一查询。
听起来挺完美对吧？但我在实际项目中踩过坑。Lambda 架构最大的问题就是「维护两套代码」。批处理写一套 Spark SQL，流处理再写一套 Flink SQL，逻辑一样，实现不同。一旦业务逻辑变了，两边都得改，还容易改出不一致。
Kappa 架构：流处理「一统天下」
Kappa 架构是 Jay Kreps 提出来的。他的想法很简单：既然流处理已经能处理全量数据了，为什么还要保留批处理那条线？
Kappa 架构的核心思路：
- 所有数据都走流处理管道
- 需要重算历史数据时，重新消费 Kafka 里的全量日志
- 只维护一套流处理代码
说白了，就是把 Kafka 当作一个「可重放的数据库」。数据不丢，顺序不乱，想重算到哪个时间点都行。
| 对比维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 代码维护 | 两套代码（批 + 流） | 一套代码（纯流） |
| 数据重算 | 批处理层全量重跑 | 重新消费 Kafka 日志 |
| 存储成本 | 批视图 + 流视图 两份存储 | 仅一份流视图 |
| 适用场景 | 对精确度要求极高的场景 | 能接受最终一致性的场景 |
怎么选？给你一个决策框架
别纠结，我帮你总结了一个简单的判断逻辑：
- 选 Lambda：业务对数据精确度有硬性要求（比如金融对账），且团队有足够人力维护两套代码。
- 选 Kappa：业务能接受秒级延迟内的最终一致性，团队规模小，想降低运维复杂度。
- 选混合：大部分场景走 Kappa，关键链路（如财务、审计）走 Lambda 做兜底校验。
好了，这一章的核心概念就聊到这儿。批处理和流处理是「计算模式」，全量和增量是「计算策略」，Lambda 和 Kappa 是「架构模式」。把这几个概念理清楚，后面讲增量计算在数据湖里的具体落地，你才能听得明白。