一、增量计算概述：从一次痛苦的调度说起

我记得刚带大数据团队那会儿，接手了一个离线报表系统。每天凌晨两点，全量任务准时启动，把过去一整天的用户行为日志重新算一遍。数据量从 500GB 涨到 2TB 只用了三个月，任务跑完经常拖到早上七点——业务方上班一看，报表还是昨天的。

后来我实在扛不住了，跟老板说：「这么搞下去，集群扩容的速度永远赶不上数据增长的速度。」 也就是从那时起，我开始认真研究增量计算。

1.1 什么是增量计算

增量计算的核心思想很简单——只算变化的部分。

举个例子。你有一个用户画像表，每天新增 10 万用户，修改 5 万用户的标签。全量计算会把 1 亿用户全部重算一遍；增量计算只处理那 15 万条变化数据，然后跟昨天的结果合并。

从技术实现上看，增量计算通常包含三个环节：

• 变化捕获：识别出哪些数据发生了变化（比如通过 binlog、消息队列、文件时间戳）
• 增量处理：只对变化数据执行业务逻辑（聚合、关联、去重）
• 结果合并：将增量结果与历史快照合并，产出最新状态

说白了，增量计算就是「只做减法，不做加法」。你想想看，如果每天只有 0.1% 的数据变了，你却要重算 100% 的数据，这本身就是一种浪费。

1.2 为什么需要增量计算

这个问题，我在不同场合被问过很多次。答案其实就三个字：扛不住。

具体来说，有四个维度的驱动力：

维度	全量计算的痛点	增量计算的优势
计算延迟	数据量越大，跑得越慢，T+1 都难保证	秒级到分钟级延迟，支持近实时场景
资源消耗	每次重算都要扫描全表，CPU/内存/IO 全部拉满	只处理变化数据，资源开销降低 80%~95%
成本控制	集群规模随数据量线性增长，预算爆炸	同样的集群可以支撑 5~10 倍的数据量
业务时效	只能做离线分析，无法支撑实时决策	支持实时大屏、实时风控、实时推荐

1.3 增量计算 vs 全量计算

很多人问我：增量计算是不是能完全替代全量计算？我的回答是：不能，也不应该。

这两种模式各有各的适用场景。我习惯从三个角度来对比：

• 数据量级：全量适合小数据（百万级以下），增量适合大数据（千万级以上）
• 变更频率：全量适合低频变更（每天一次），增量适合高频变更（秒级到分钟级）
• 一致性要求：全量天然保证最终一致性，增量需要额外处理乱序、延迟、重复等问题

下面这张图是我自己总结的选型决策流程，你可以参考一下：

1.4 典型应用场景

增量计算不是理论概念，它在生产环境中已经非常成熟。我挑几个自己实际接触过的场景说说：

场景一：实时数仓与 OLAP 加速

这是最常见的应用。比如 ClickHouse 的 ReplacingMergeTree + 增量导入，或者 Druid 的实时节点 + 批量合并。我去年帮一个电商客户做过优化：他们用 Flink CDC 实时同步 MySQL binlog 到 ClickHouse，全量导入从 40 分钟降到增量导入的 3 秒，报表延迟从 T+1 变成秒级。

场景二：实时特征工程

推荐系统和广告系统对特征时效性要求极高。用户刚点了一个商品，下一秒推荐模型就要看到这个行为。全量重算根本来不及，只能用增量方式更新特征。我记得有个项目，用户行为特征从 200 多个维度涨到 800 多个，增量计算框架扛住了，全量方案早就崩了。

场景三：流式 ETL 与数据同步

从业务数据库（MySQL、PostgreSQL）同步数据到数仓或搜索引擎，增量 CDC 是标配。Debezium + Kafka + Flink 这套组合拳，我几乎在每个中大型项目里都见过。全量同步只做一次（初始化），后续全是增量。

场景四：实时监控与告警

服务器指标、业务指标、安全日志……这些场景的数据是源源不断的流。你不可能等一天的数据攒齐了再算告警规则，必须每条数据进来就做增量判断。我做过一个日处理 50 亿条日志的监控系统，增量计算引擎把 CPU 使用率从 85% 降到了 30%。

场景	典型数据源	增量方式	常用引擎
实时数仓	MySQL binlog、Kafka	CDC + 流式写入	Flink、Doris、ClickHouse
特征工程	用户行为日志	窗口聚合 + 状态更新	Flink、Spark Streaming
数据同步	业务数据库	CDC + 消息队列	Debezium、Canal、DataX
实时监控	Metrics、日志流	滑动窗口 + 增量聚合	Flink、Kafka Streams