1. 补数场景概述

做数据工程这些年，我遇到过不少让人头疼的场景。其中最磨人的，就是补数。

说白了，补数就是「把过去某段时间缺失或错误的数据，重新跑一遍」。听起来简单？实际操作起来，坑多得很。

什么是数据补数

数据补数，也叫数据回刷或数据重跑。它指的是：当某个时间窗口内的数据出现异常时，我们手动触发一次或多次数据任务，把那段历史数据重新计算一遍，最终让数据恢复到正确状态。

举个例子。你有个每日报表任务，每天凌晨2点跑前一天的数据。结果某天凌晨3点，上游的订单数据才到。你的任务已经跑完了，报表里就少了那1小时的数据。怎么办？补数。

补数的触发条件

我总结了一下，补数主要分三种情况。每种我都踩过坑。

1. 上游延迟

这是最常见的。上游系统的数据没按时到，你的任务却按时跑了。

• 场景：业务库凌晨3点才同步完前一天的数据，但你的ETL任务凌晨2点就启动了。
• 后果：报表数据不全，指标偏低。
• 我的经验：有一次，上游的日志系统挂了6小时，恢复后数据凌晨5点才到齐。我不得不补了整整两天的数据。嗯，那两天我基本没睡。

2. 任务失败

任务跑着跑着就挂了。原因五花八门：内存溢出、网络抖动、SQL写错了……

• 场景：凌晨3点，你的Spark任务OOM了。任务重试3次都失败，最终被调度系统挂起。
• 后果：当天报表为空。
• 避坑指南：我曾经遇到过任务失败后自动重试，但重试时数据源已经变了，导致重复数据。后来我养成了一个习惯：补数前先检查数据源状态。

3. 数据回溯

这个比较特殊。不是数据错了，而是业务逻辑变了，需要重新计算历史数据。

• 场景：公司调整了GMV的计算口径，需要把过去3个月的数据全部按新口径重算。
• 后果：涉及的数据量巨大，可能几百TB甚至PB级。
• 我的建议：数据回溯最考验架构设计。如果一开始没考虑增量回溯，后面补数就是噩梦。

触发条件	典型原因	数据影响范围	补数频率
上游延迟	数据源同步延迟、网络抖动	通常为小时级或天级	较高
任务失败	OOM、SQL异常、资源不足	单次任务窗口	中等
数据回溯	业务口径变更、模型重构	数周至数月	较低但影响大

补数的核心挑战

你可能会想：补数不就是重新跑一遍吗？有什么难的？

我刚开始也这么想。直到有一次，我补了3天的数据，结果把线上报表搞乱了。用户看到的数字忽高忽低，业务方直接炸了。

补数的核心挑战，我归纳为四点：

挑战一：数据一致性

这是最要命的。补数期间，新旧数据同时存在。用户查到的可能是「半补半旧」的状态。

• 问题：补数任务还没跑完，用户已经看到了部分新数据。数据对不上。
• 我的教训：有一次补数时，我忘了暂停下游的消费任务。结果下游系统读到了「新旧混合」的数据，生成了错误的报表。从那以后，我补数前一定会先切断下游依赖。

挑战二：幂等性

补数任务可能会跑多次。如果任务不是幂等的，重复跑就会出问题。

• 问题：同样的数据跑两次，结果不一样。或者数据被重复写入。
• 解决方案：写入操作必须支持覆盖或去重。我一般用「分区覆盖」或「主键去重」来保证幂等。

挑战三：性能与时效

补数通常涉及大量历史数据。跑得太慢，业务等不及；跑得太快，资源又不够。

• 问题：补数任务和日常任务抢资源，导致日常任务也变慢。
• 我的做法：我会把补数任务安排在业务低峰期，并且限制并发度。说白了，就是错峰执行。

挑战四：数据完整性校验

补数跑完了，怎么知道数据是对的？

• 问题：没有校验机制，补完数也不敢上线。
• 我的经验：我习惯在补数后做三件事：总量对比、抽样核对、下游指标验证。这三步走完，我才敢说数据没问题。

补数场景知识体系

下面这张图，是我梳理的补数场景核心知识结构。你可以把它当作本章的思维导图。

好了，这一章我们聊了补数的基本概念、触发条件和核心挑战。说白了，补数就是「填坑」。但怎么填得稳、填得准、填得快，才是真正的技术活。