首页/数据/数仓建模速查/补数流程:范围评估与脚本参数化
分层与规范64 条

补数流程:范围评估与脚本参数化

补数前评估影响范围(下游任务、报表缓存、对账),脚本参数化支持指定日期区间,补完做结果核对并记录操作工单。

数仓建模速查数据更新于 2026-10-13

补数流程是什么

补数(回刷)是发现历史数据有问题后,重算指定日期区间的数据。它与日常调度最大的区别是范围可控、必须参数化:脚本要能接收起止日期,逐日重算并覆盖对应分区。补数前要评估影响范围——哪些下游任务需要跟着重跑、报表与接口缓存要不要刷新、对账口径会不会受影响;补完还要核对结果并留下操作记录。

基本信息

前置动作评估影响范围,确认上游数据是否还在
脚本要求日期区间参数化,支持指定起止日期
执行方式按日串行执行,避免与日常调度并发
收尾动作结果核对并记录操作工单
常见触发上游数据修正、口径调整、任务失败留下缺口

典型使用场景

  • 上游源数据修正:只重算受影响的日期区间,不整表重跑
  • 口径调整上线:新旧口径并行一段,确认一致后再切换
  • 任务失败留下缺口:补上缺失分区,并做行数与指标核对
  • 补数窗口超过贴源保留期:先确认上游分区是否还在,再决定方案
  • 避开日常调度窗口:补数任务串行执行,避免与调度任务争抢资源

各阶段关注点

阶段关键动作常见问题
补数前评估下游影响、确认上游数据仍在、估算耗时补到一半才发现上游分区已被清理
执行中按日串行、覆盖写入、监控资源占用与日常调度并发写同一分区,互相覆盖
补数后核对行数与关键指标、通知下游重跑下游未重跑,报表仍显示旧数据
记录记录范围、原因、执行人与时间事后无人知道某天数据被改过

补数脚本骨架

补数脚本骨架
-- 逐日重算,日期由外部传参,便于指定区间
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 是否还保留对应分区:很多贴源表只保留有限天数,一旦上游分区已被清理,补数只能回到源系统重抽,链路与成本完全不同。
补数与日常调度并发写同一分区会互相覆盖:两边都以为自己写的是最终结果,实际谁后写谁生效。补数应串行执行,并暂停或错开涉及同一分区的日常任务。

易错点

  • 补数与日常调度并发写同一分区:结果互相覆盖,而且很难被发现
  • 脚本不支持日期参数:只能手改 SQL 里的日期,容易改错或漏改
  • 补数前不确认上游分区还在:跑到一半才发现源数据已被清理
  • 补完不通知下游:下游不重跑,报表长期显示旧数据
  • 补数不留记录:事后无人知道哪天被改过,对账出现差异时无从解释

数据来源与参考

  • DAMA-DMBOK 第2版
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌