大数据任务补数据：范围圈定、依赖处理与回填验证 SOP

补数据的本质不是"把任务重跑一遍"，而是在保证数据正确、不污染下游的前提下，把历史区间重放一遍。大多数补数事故发生在三个环节：范围圈定错误、依赖未处理、回填期间下游消费了中间态。下面给出一套可复用的五步补偿执行 SOP：范围圈定、依赖与黑名单处理、资源隔离、执行与进度管理、回填验证。

第一步：圈定补数范围

• 确认业务口径：补哪个业务日期/分区范围（date range）、哪些维度（如 region、tenant 过滤条件）、涉及哪些表；
• 确认上游数据已就绪：补数区间对应的源数据是否已完整落地，尤其注意跨日、跨月、跨年的边界；
• 以最小影响面为原则：能按分区补就不全表补，能带业务键过滤就带过滤条件；
• 输出一份回填清单：任务名、分区范围、预计数据量、回填原因、发起人，作为审计记录留存。

范围圈定是出错率最高的环节。任何回填先做 dry-run，只输出将要处理的分区清单而不真正执行，人工核对后再放行。dry-run 阶段还要确认三个边界问题：时间边界（按业务日期还是按处理日期补，两者在跨天任务上结果不同）、粒度边界（明细与汇总是否一起补）、来源边界（从源系统重算还是从中间层重算，选择不同来源会影响结果一致性）。

第二步：依赖与黑名单处理

• 上游依赖：先确认依赖任务在目标区间已成功，检查上游分区存在且数据质量通过，再启动回填；
• 下游黑名单：回填期间把下游消费任务挂起，或改为只读取已打完成标记的数据，防止下游读到"部分写、部分未写"的中间态；
• 自依赖与循环依赖：检查任务是否读取自己昨天的输出（T+1 自依赖），这类任务必须按时间正序逐日执行；
• 参数化：回填统一通过业务日期参数驱动，禁止手改全局配置或直接改代码。

下游黑名单的实现有两种常见方式：一是调度层挂起（暂停下游任务的调度），二是数据层标记（目标分区写入完成标记文件，下游只读带标记的分区）。前者简单但影响面大，后者精细但要求下游逻辑支持标记判断。建议核心链路两种都用：先挂起关键下游，再依赖标记兜底。依赖处理的目标是让回填期间"数据生产链路上只有回填任务在动"，其他都冻结。

第三步：资源隔离

• 独立队列/资源组：回填任务与日常任务分队列，避免抢占在线任务的资源；
• 限流与并发控制：按分区限制并发数（例如同时最多 N 个分区），防止打爆源库与下游存储；
• 重试策略：失败自动重试并采用指数退避，设置重试次数上限，超过则告警人工介入；
• 分批执行：大范围回填先跑一个分区验证，再逐步放大批次。

资源隔离不只是"分队列"：还要考虑回填对源库的读压力（大范围回填会放大对源系统的查询量）与对目标存储的写压力（并发写同一张表可能引发锁或小文件问题）。经验做法是：回填并发从 1 开始，每批翻倍，观察源库与目标存储的指标，达到警戒线就停止放大。

第四步：执行与进度管理

• 按拓扑顺序执行：先上游后下游，同一批次内按依赖排序；
• 进度可观测：每个分区的开始/结束时间、处理行数、状态落表，提供进度视图；
• 支持暂停与恢复：暂停的是调度而非直接 kill 任务，避免留下半截输出。

进度表是回填的"仪表盘"：每一行是一个分区，记录待执行、执行中、成功、失败、跳过五种状态。有了进度表，大范围回填（几百个分区）才可管理：可以看到整体进度百分比、失败分区的重试按钮、以及哪些分区被跳过及原因。进度表本身也要留档，回填结束后作为审计证据。

第五步：回填验证

• 行数与主键去重校验：与预期比对（源系统计数、历史正确快照、或同区间上次成功数据）；
• 抽样内容比对：抽取关键业务字段，与标准数据（源表或同区间历史正确数据）逐字段比对；
• 质量规则复跑：在回填结果上重新执行非空率、唯一性、取值域等质量规则；
• 分区完整性：确认目标区间所有分区都成功且非空跑——跑出 0 行也要确认是否合理；
• 下游放行：验证通过后恢复下游消费，并对比下游产出（如指标表）与预期值。

验证不是"跑完看一眼行数"：对于关键表，建议同时做三类校验——数量级校验（行数与金额汇总与预期偏差在阈值内）、字段级校验（抽样字段值分布与标准数据对比）、规则校验（质量规则全部通过）。校验脚本要在回填前就准备好，而不是回填完再写，否则容易带着情绪"补一个凑合能过的检查"。

典型失败模式与规避方法

• 范围多写一格：多补了未要求的日期，污染已发布数据。规避：每次回填先 dry-run 输出范围清单并人工确认。
• 依赖未就绪就开跑：上游还在写入，回填读到一半数据。规避：回填前检查上游分区完成标记。
• 下游未挂起：回填期间下游读到中间态，指标偏差且事后难以定位。规避：回填必须伴随下游黑名单，黑名单随回填生命周期自动生效与解除。
• 并发过高打爆源库：一次性并发几十个分区读取源库，拖垮在线业务。规避：限流加分批，先小后大。
• 重跑即覆盖、无留痕：回填覆盖原数据且无备份，出错无法回退。规避：回填前对目标分区做快照或留档，保留原始版本。
• 回填任务与日常任务混跑：抢占资源导致在线任务变慢或失败。规避：独立队列与资源组。
• 验证环节缺失：只重跑不验证，回填结果本身是错的也照常发布。规避：把验证脚本与回填脚本绑定，验证不通过则回填任务标记为失败。

下一步

把以上步骤固化成一份 check-list 与一个参数化的回填脚本模板（输入：任务名、日期范围、并发数、黑名单配置），并在一个非关键任务上完整演练一次，验证 dry-run、暂停恢复与验证脚本三个关键环节后再推广到核心任务。