补数流程是什么
补数(回刷)是发现历史数据有问题后,重算指定日期区间的数据。它与日常调度最大的区别是范围可控、必须参数化:脚本要能接收起止日期,逐日重算并覆盖对应分区。补数前要评估影响范围——哪些下游任务需要跟着重跑、报表与接口缓存要不要刷新、对账口径会不会受影响;补完还要核对结果并留下操作记录。
基本信息
| 前置动作 | 评估影响范围,确认上游数据是否还在 |
|---|---|
| 脚本要求 | 日期区间参数化,支持指定起止日期 |
| 执行方式 | 按日串行执行,避免与日常调度并发 |
| 收尾动作 | 结果核对并记录操作工单 |
| 常见触发 | 上游数据修正、口径调整、任务失败留下缺口 |
典型使用场景
- 上游源数据修正:只重算受影响的日期区间,不整表重跑
- 口径调整上线:新旧口径并行一段,确认一致后再切换
- 任务失败留下缺口:补上缺失分区,并做行数与指标核对
- 补数窗口超过贴源保留期:先确认上游分区是否还在,再决定方案
- 避开日常调度窗口:补数任务串行执行,避免与调度任务争抢资源
各阶段关注点
| 阶段 | 关键动作 | 常见问题 |
|---|---|---|
| 补数前 | 评估下游影响、确认上游数据仍在、估算耗时 | 补到一半才发现上游分区已被清理 |
| 执行中 | 按日串行、覆盖写入、监控资源占用 | 与日常调度并发写同一分区,互相覆盖 |
| 补数后 | 核对行数与关键指标、通知下游重跑 | 下游未重跑,报表仍显示旧数据 |
| 记录 | 记录范围、原因、执行人与时间 | 事后无人知道某天数据被改过 |
补数脚本骨架
补数脚本骨架
-- 逐日重算,日期由外部传参,便于指定区间
INSERT OVERWRITE TABLE dwd_trade_order_di PARTITION (dt='2026-10-05')
SELECT order_id, customer_sk, pay_amt
FROM ods_order
WHERE dt='2026-10-05'; -- 覆盖写入,重跑幂等
-- 补数后核对:行数与关键指标是否符合预期
SELECT count(1), sum(pay_amt) FROM dwd_trade_order_di WHERE dt='2026-10-05';补数窗口越长,越要先确认上游 ODS 是否还保留对应分区:很多贴源表只保留有限天数,一旦上游分区已被清理,补数只能回到源系统重抽,链路与成本完全不同。
补数与日常调度并发写同一分区会互相覆盖:两边都以为自己写的是最终结果,实际谁后写谁生效。补数应串行执行,并暂停或错开涉及同一分区的日常任务。