2、补数触发条件：上游数据延迟、系统故障恢复、数据质量修复、历史数据回溯
补数不是你想补，想补就能补的。我见过不少团队，一遇到数据对不上就手动跑补数，结果越补越乱。说白了，补数是一把手术刀，不是大砍刀。你得知道什么时候该动刀，什么时候该观察。
这一章，我们就来拆解补数的四个核心触发条件。每个条件背后，都有我踩过的坑和总结的经验。
2.1 上游数据延迟：最常见的补数场景
这是补数最频繁的场景，没有之一。上游系统因为各种原因——网络抖动、源库负载高、ETL 任务卡死——导致数据晚到了。下游任务等不起，要么空跑，要么报错。
核心判断标准：上游数据到达时间超过了调度系统为该任务设定的「最大等待阈值」。
举个例子。我参与过一个金融风控项目，上游交易数据每天凌晨 2 点前必须到位。但合作方的 Kafka 集群经常凌晨 3 点才推送完毕。调度系统如果死等，下游的模型训练任务就得推迟到凌晨 4 点以后，业务方早上 8 点拿不到风控报告，那可就炸锅了。
我的处理习惯是这样的：
- 设置等待超时：在 DAG 定义中，给上游数据源节点配置一个超时时间。比如最多等 60 分钟，超时则标记为「数据未就绪」。
- 触发补数流程：超时后，调度系统自动生成一个补数请求，范围是「当前任务实例 + 依赖的上游分区」。
- 重试与告警：补数任务启动后，如果连续重试 3 次仍失败，立刻告警给值班工程师。
我的经验：不要一上来就全量补数。先补缺失的分区，确认数据完整后再补下游。我曾经见过一个团队，上游延迟了 2 小时，他们直接全量重跑了过去 7 天的数据，结果把生产库的 IO 打满了。
2.2 系统故障恢复：从灾难中抢救数据
系统故障是补数的「硬场景」。比如调度节点宕机、数据库主从切换、HDFS NameNode 挂掉。故障恢复后，中间那一大段「数据黑洞」必须补上。
这里有个关键点：故障期间的依赖关系怎么重建？
我记得有一次，我们的大数据平台因为磁盘写满导致 YARN 集群瘫痪了 4 个小时。恢复后，调度系统里积压了上千个失败的任务实例。如果手动一个个点重跑，估计得干到第二天早上。
我当时的做法是：
- 先恢复元数据：确认调度系统的数据库和状态存储没有损坏。
- 标记故障时间窗口：将故障开始到恢复之间的所有任务实例标记为「待补数」。
- 按依赖层级分批补：先补最底层的源数据任务，再逐层向上补。不能一股脑全跑，否则下游任务会因为上游数据还没到位而再次失败。
避坑指南：我曾经犯过一个错误——故障恢复后直接启动了所有补数任务。结果因为资源争抢，补数任务和正常任务互相阻塞，导致系统再次接近瘫痪。后来我强制要求：补数任务必须使用独立的资源池，并且限制并发数。
2.3 数据质量修复：发现脏数据后的补救
数据质量问题是补数中最头疼的。因为很多时候，数据本身没有「报错」，但算出来的结果是错的。比如某个字段因为上游代码 bug 被截断了，或者某个维表关联错了。
这种场景下，补数不是简单的「重跑」，而是「修复 + 重跑」。
| 数据质量问题类型 | 补数策略 | 注意事项 |
|---|---|---|
| 字段截断/丢失 | 修复上游逻辑后，全量重跑受影响分区 | 需要确认下游消费方是否已经消费了错误数据 |
| 维表关联错误 | 回刷维表快照，重新关联并补数 | 维表变更可能影响历史数据的一致性 |
| 聚合计算逻辑错误 | 修正代码后，重跑所有受影响的聚合任务 | 注意幂等性，避免重复计算 |
| 数据重复/去重失败 | 先清理重复数据，再补数 | 清理操作需要谨慎，最好先备份 |
我建议在调度系统中为每个任务维护一个「数据质量版本号」。每次修复逻辑后，版本号递增。补数时，系统自动检查版本号是否一致，不一致则强制补数。这样可以避免「修了代码但忘了补数据」的尴尬。
2.4 历史数据回溯：业务需求驱动的补数
这种场景和故障无关，纯粹是业务需求。比如：
- 业务方要重新计算过去 3 个月的营收报表，因为统计口径变了。
- 算法团队要重新训练模型，需要从半年前开始重新生成特征数据。
- 合规审计要求补全某段时间内的所有数据快照。
历史数据回溯的补数，往往范围大、时间长、资源消耗高。我见过最夸张的一次，一个电商大促后的数据回溯，补了整整 6 个月的数据，跑了 3 天才跑完。
处理这种场景，我有三个原则：
- 必须走审批流程：回溯补数不能由开发人员直接触发，需要业务方提交申请，评估影响范围后执行。
- 分阶段执行：不要一次性提交所有补数任务。先补一个月的，验证数据正确性，再补剩下的。
- 设置资源上限：回溯补数只能使用集群空闲资源，不能影响正常任务。我通常会给回溯补数任务设置一个「最大并行度」和「最低优先级」。
核心要点：历史数据回溯的补数，技术难度不高，但管理复杂度很高。调度系统需要提供「批量补数申请」、「进度追踪」、「影响分析」等功能，否则很容易失控。
2.5 四种触发条件的对比与选择
为了让你更直观地理解这四种场景的差异，我画了一张对比图。
从图中你可以看到，四种触发条件的「自动化程度」和「影响范围」完全不同。上游延迟和故障恢复，调度系统应该自动检测并触发补数。而数据质量修复和历史回溯，必须有人工介入的环节。
我的建议：在调度系统的设计阶段，就把这四种触发条件作为「一等公民」来对待。为每种条件设计独立的补数策略、资源配额和告警规则。不要试图用一个「万能补数按钮」解决所有问题，那只会制造更多问题。
嗯，这一章的内容就到这里。四种触发条件，每一种都有它的脾气。理解了它们，你就能在补数这件事上做到「该出手时就出手，不该出手时绝不乱动」。