1、增量计算概述

大家好，我是这次课程的主讲。做了十几年后端和大数据，我见过太多团队在日志处理上栽跟头。今天咱们先聊聊增量计算——这个听起来简单、用起来却门道不少的概念。

什么是增量计算

增量计算，说白了就是「只算变化的部分」。

举个例子。你有一份 10TB 的日志，每天新增 200GB。全量计算就是每天把这 10TB 重新跑一遍——嗯，听着就心疼。增量计算呢？只处理那 200GB 的新数据，旧数据的结果直接复用。

我刚开始做日志处理时，总觉得全量计算更「安全」——反正全跑一遍，肯定不会漏。直到有一次，一个 5TB 的日志任务跑了 14 个小时，把下游的实时报表全堵死了。从那以后，我才真正开始研究增量计算。

为什么需要增量计算

原因其实就三个字：扛不住。

• 数据量太大——每天几百 GB 甚至 TB 级的日志，全量跑一次，集群 CPU 和内存直接拉满
• 时间窗口太紧——业务要求分钟级延迟，全量计算动辄几小时，根本没法交差
• 成本太高——全量计算消耗的计算资源是增量计算的 10 倍甚至更多，老板看了账单会心疼

我记得有个电商客户，双十一当天的日志量是平时的 50 倍。如果用全量计算，光那一天的集群费用就够买一辆车了。后来改成增量计算，成本直接降了 80%。

增量计算 vs 全量计算

这两者的区别，我用一张表来说明：

对比维度	全量计算	增量计算
处理范围	全部历史数据	仅新增/变更数据
计算延迟	小时级到天级	秒级到分钟级
资源消耗	高（与数据总量成正比）	低（与增量数据量成正比）
实现复杂度	低（简单粗暴）	高（需要维护状态和偏移量）
容错恢复	容易（重跑即可）	较难（需要精确一次语义）
适用场景	数据量小、离线报表、历史回溯	数据量大、实时监控、流式处理

你想想看，全量计算就像每次打扫房间都把家具搬出去再搬回来——干净是干净，但累啊。增量计算呢？每天只擦擦灰尘、拖拖地，省时省力。

应用场景分析

增量计算在日志处理中，几乎无处不在。我挑几个典型的说说：

1. 实时日志聚合

比如统计每小时的 API 调用量、错误率。全量计算要扫描过去所有日志，增量计算只需要聚合最近一小时的日志，然后累加到昨天的结果上。

2. 日志指标监控

像 P99 延迟、QPS 这类指标，增量计算可以维护一个滑动窗口，每次只处理新进来的日志，窗口外的数据自动过期。

3. 日志清洗与格式化

原始日志往往是杂乱的 JSON 或文本，需要解析成结构化数据。增量计算可以只处理新写入的日志文件，已经处理过的跳过。

4. 日志关联分析

比如把应用日志和数据库慢查询日志关联起来。增量计算可以按时间窗口分批关联，而不是每次全量 join。

下面这张图，展示了增量计算在日志处理中的核心流程：

你看，整个流程其实不复杂。核心就三步：只拿新的 → 检查上次处理到哪了 → 处理并合并结果。但每一步都有细节，后面几章我会逐一展开。

我个人习惯，在开始任何增量计算项目前，先问自己三个问题：

1. 数据源支持增量读取吗？——比如 Kafka 有 offset，文件系统有 mtime，数据库有 binlog
2. 计算结果可以增量合并吗？——比如计数、求和可以，但去重、中位数就比较麻烦
3. 能接受偶尔的重复计算吗？——如果业务要求精确一次，那状态管理就得下功夫

这三个问题想清楚了，增量计算的方向就不会偏。