一、增量与全量概述

做数据的人，几乎天天跟这两个词打交道。我刚开始带团队那会儿，有个新人问我：「增量计算和全量计算，不就是跑一次和跑多次的区别吗？」我当时笑了笑，没直接回答。后来他踩了个坑——全量跑了一夜没跑完，第二天早上老板要数据，他傻眼了。

嗯，今天我们就来好好聊聊这两个概念。

什么是全量计算

全量计算，说白了就是「从头算一遍」。每次计算都拿全部数据作为输入，重新跑整个逻辑。

举个例子：

-- 全量计算：每天重新统计所有用户的订单总额
SELECT user_id, SUM(amount) AS total_amount
FROM orders
GROUP BY user_id;

这段 SQL 每次执行，都会扫描 orders 表里的所有记录。不管昨天的数据有没有变，它都重新算一遍。

我在项目中遇到过一家电商公司，每天凌晨用全量跑用户画像。数据量大概 5 亿行，跑一次要 4 个小时。刚开始还能忍，后来业务增长到 20 亿行，直接跑崩了。这就是全量计算的典型瓶颈——数据量越大，成本越高。

什么是增量计算

增量计算就聪明多了。它只处理「变化的那部分数据」。上次算过的结果保留着，这次只算新增或修改的数据，然后合并进去。

还是那个例子：

-- 增量计算：只处理今天新增的订单
INSERT INTO user_order_summary (user_id, total_amount)
SELECT 
    new.user_id,
    COALESCE(old.total_amount, 0) + new.daily_amount
FROM (
    SELECT user_id, SUM(amount) AS daily_amount
    FROM orders
    WHERE order_date = CURRENT_DATE
    GROUP BY user_id
) new
LEFT JOIN user_order_summary old
    ON new.user_id = old.user_id
ON DUPLICATE KEY UPDATE
    total_amount = old.total_amount + new.daily_amount;

你看，这里只扫描了当天的订单数据。如果每天只有 100 万条新订单，那计算量就小太多了。

我曾经帮一个金融客户做风控系统。他们原来每天全量跑一次交易风险评分，跑完都快中午了。改成增量后，每 5 分钟处理一次新交易，延迟从 6 小时降到 5 分钟。业务方高兴坏了。

两者的核心区别

我整理了一张对比表，这样看更清楚：

对比维度	全量计算	增量计算
数据范围	全部数据	变化数据
计算频率	低（通常 T+1）	高（可实时）
资源消耗	高，与数据总量成正比	低，与变化量成正比
结果一致性	天然一致	需额外保证
实现复杂度	简单	复杂
适用场景	历史回溯、数据校正	实时报表、监控告警

为什么会这样？你想想看，全量计算就像期末考试——把所有知识点重新复习一遍。增量计算就像日常作业——只复习今天讲的内容。期末考试虽然全面，但累啊。日常作业轻松，但容易漏掉前面的知识点。

为什么需要协同

到这里你可能会问：那直接用增量不就行了？

没那么简单。我在实际项目中吃过不少亏。

我曾经遇到过一个场景：某天凌晨的数据管道出了故障，增量计算漏掉了 2 小时的数据。等发现的时候，已经累积了 3 天的偏差。最后只能全量重跑，把结果拉回来。

所以，增量计算和全量计算不是二选一的关系。它们更像是搭档——

• 日常用增量：保证时效性，降低计算成本
• 定期用全量：校正数据，修复偏差
• 异常时用全量：快速恢复，重建中间状态

下面这张图，是我做架构设计时经常用的协同模型：

你看这个架构：数据源进来后，先做分流判断。大部分走增量通道，保证时效性。同时，全量通道定期（比如每天凌晨）跑一次，把增量结果校正一遍。如果发现偏差，就用全量结果覆盖。

这样做的好处很明显：

• 平时快：增量计算秒级或分钟级出结果
• 定期准：全量计算保证数据最终一致
• 异常稳：出问题能快速恢复

嗯，这一章的内容就到这儿。增量与全量的概念、区别、以及为什么需要协同，你应该有个清晰的认知了。后面的章节，我们会深入具体的实现方案和实战案例。