增量计算核心思想：从全量到增量的思维转变

说实话，我刚入行那几年，做数据加工就一个思路——全量跑。每天凌晨把整个表拉一遍，算完覆盖。简单粗暴，但心里踏实。直到有一次，一个日活千万级的用户画像任务，全量跑一次要 6 小时，业务方早上 9 点开会要用数据，我凌晨 3 点就得爬起来调度。嗯，那滋味真不好受。

后来我慢慢意识到，很多场景下我们根本不需要重新算一遍历史。你想想看，昨天的用户画像和今天的，差别可能不到 5%。那为什么要把 100% 的数据重新算一遍？这就是增量计算要解决的核心问题。

2.1 全量计算的痛点

先聊聊全量计算。它的逻辑很简单：每次计算都基于原始数据全集，从头到尾跑一遍。公式长这样：

result = f(all_data)  // 每次都用全部数据重新计算

我在项目中遇到过不少全量计算的坑，总结下来主要有三个：

• 计算资源浪费：90% 的历史数据根本没变化，却要反复读取、计算。集群资源就这么被白白消耗掉了。
• 时效性差：数据量越大，跑得越慢。业务方要的是分钟级延迟，全量计算给的是小时级。
• 成本居高不下：存储、计算、网络，每一项都在烧钱。我见过一个团队，全量跑一次要花掉 2000 块钱的云资源，一天跑两次，一个月就是 12 万。

2.2 增量计算的核心逻辑

增量计算的思路完全不同。它只处理变化的数据，然后跟上次的结果合并。公式是这样的：

result_new = result_old + delta(f(changed_data))

说白了，就是「记住旧结果，只算新变化」。这背后依赖三个关键能力：

1. 变化捕获：能识别出哪些数据变了。比如通过 binlog、审计字段、事件流等方式。
2. 增量计算：只对变化的数据执行计算逻辑。比如只算新增的订单、只更新修改的用户信息。
3. 结果合并：把增量计算结果跟历史结果合并，得到最新状态。合并策略可能是覆盖、累加、去重等。

2.3 全量与增量的对比

为了让你更直观地理解两者的差异，我整理了一张对比表：

从这张表能看出来，增量计算并不是银弹。它用复杂度换取了性能和时效性。我个人习惯是：小数据量或者一次性任务，直接用全量，省心；大数据量或者高频任务，必须上增量，否则扛不住。

2.4 增量计算的核心挑战

增量计算虽然好，但实现起来有不少坑。我总结了三个最常见的：

• 状态管理：增量计算需要维护中间状态（比如累加器、窗口、去重集合）。状态怎么存、怎么恢复、怎么保证不丢，都是问题。
• 数据一致性：增量计算是分步执行的，如果中间某一步失败了，结果可能对不上。需要引入事务或幂等机制来保证最终一致性。
• 延迟数据处理：现实中的数据经常迟到。比如用户凌晨 2 点的点击，下午 3 点才上报。增量计算必须能处理这种「乱序数据」。

2.5 增量计算的知识体系

为了让你对增量计算有一个全局认识，我画了一张知识体系图。它涵盖了增量计算的三个核心层面：变化捕获、增量计算、结果合并，以及每个层面下的关键技术。

从这张图能看出来，增量计算不是单一技术，而是一套完整的方法论。每个层面都有多种实现方式，具体选哪种，取决于你的业务场景和数据特征。

2.6 什么时候该用增量计算？

我个人的判断标准很简单，就三条：

• 数据量大：单表超过 1 亿行，或者日增量超过 100 万条。这时候全量计算已经开始吃力了。
• 变化率低：每天变化的数据占比不到 20%。变化率越低，增量计算的收益越大。
• 时效性要求高：业务要求分钟级甚至秒级的数据更新。全量计算根本满足不了。