一、增量计算概述
大家好，我是这次课程的主讲。做了十几年大数据架构，我见过太多团队在数据计算上栽跟头。今天咱们先聊聊最基础的问题——什么是增量计算，以及它为什么值得你花时间了解。
1.1 什么是增量计算
增量计算，说白了就是只处理变化的那部分数据。
举个例子。你每天要统计全公司一万人的考勤。全量计算的做法是：每天凌晨把所有人的打卡记录重新算一遍。增量计算呢？只处理昨天到今天之间新增或修改的打卡记录，然后跟昨天的结果合并。
嗯，听起来很简单对吧？但实际落地时坑不少。我曾经在一个项目中，团队坚持用全量重算，结果数据量从 100 万涨到 1 亿，任务跑不完。后来改成增量，延迟从 6 小时降到 15 分钟。
核心定义：增量计算是一种只处理数据集中发生变化的部分（新增、更新、删除），并将结果与历史状态合并的计算模式。
1.2 增量计算 vs 全量计算
我习惯用一个表格来对比这两者的差异。你一看就明白。
| 对比维度 | 全量计算 | 增量计算 |
|---|---|---|
| 处理范围 | 每次处理全部数据 | 只处理变化的数据 |
| 计算延迟 | 通常较高（小时级） | 低（秒级到分钟级） |
| 资源消耗 | 高，随数据量线性增长 | 低，只与变化量相关 |
| 实现复杂度 | 简单，无状态 | 复杂，需维护状态 |
| 数据一致性 | 天然一致 | 需额外保证 |
| 适用场景 | 小数据量、离线报表 | 大数据量、实时场景 |
你想想看，如果你的数据量只有几千条，全量计算完全够用。但数据量一旦上了千万甚至亿级，全量重算的成本就变得不可接受了。
我的经验：选全量还是增量，先看数据量级。日增数据量超过全量的 10%，或者全量计算时间超过业务容忍延迟，就该考虑增量方案了。
1.3 增量计算的核心价值
为什么这几年增量计算这么火？三个字：快、省、准。
- 快：只处理变化数据，延迟从小时级降到秒级。我在电商大促项目中，用增量计算把实时大屏的刷新延迟从 5 分钟压到了 10 秒以内。
- 省：计算资源只消耗在变化的数据上。同样的集群，全量计算只能支撑 10 个任务，增量计算可以支撑 50 个。
- 准：增量计算可以做到精确一次（Exactly-Once）语义，保证结果不丢不重。
但要注意，增量计算不是银弹。它需要你维护中间状态，处理乱序数据，还要应对数据回溯。这些坑，我后面会一个一个讲。
1.4 适用场景
我总结了几类最适合增量计算的场景：
- 实时数仓：比如 Flink 实时 ETL，只处理 CDC 变更数据。
- 指标聚合：比如实时 PV/UV、GMV 统计，每天只累加新数据。
- 特征工程：机器学习模型的在线特征计算，只更新变化特征。
- 数据同步：比如 MySQL 到 Hive 的增量同步，只同步 binlog。
- 流式关联：比如订单流和支付流的实时 Join，只处理新到达的事件。
避坑指南：我曾经在一个项目中，把增量计算用在了需要全量排序的场景上。结果增量结果和全量结果对不上，排查了三天才发现是排序语义的问题。记住：增量计算适合可加性和幂等性的操作，不适合需要全局视角的运算。
1.5 增量计算的核心逻辑
下面这张图展示了增量计算的基本流程。我建议你仔细看看，后面的章节都会围绕这个框架展开。
这张图里，状态存储是增量计算的核心。没有状态，你就没法知道「增量」相对于什么。我见过不少团队，一开始没设计好状态管理，后面数据回溯时痛苦不堪。
1.6 本章小结
好了，这一章我们聊了增量计算的基本概念。记住三个要点：
- 增量计算只处理变化的数据，不是全量重算
- 它的核心价值是快、省、准，但实现复杂度更高
- 状态管理是增量计算的灵魂，选型时要重点考虑