同样是“再跑一次”,到底有什么不同?
区分 Retry、Rerun、Backfill 与意外双入口;观察运行范围、写入语义和下游副作用。
同样是“再跑一次”,到底有什么不同?
杭州分行 2026-09-30 的余额结果需要重新执行时,先判断这是 Retry、Rerun 还是 Backfill,再决定日期范围和 DAG 起点。还要检查迁移期间是否有两个仍启用的生产入口指向同一逻辑。
9 月 30 日结果错了,应该重试一次、重跑一天,还是补跑一段日期?
幂等(Idempotency)
对同一个业务日期和目标分区,用相同输入重复执行时,结果应保持同一份业务结果,而不是因为写入动作重复就多出一份余额。
先确定“跑哪一天”
Retry 不会改变业务日期:DWD 的 Attempt 1 失败后,Attempt 2 仍处理 2026-09-30。Rerun 是对已经存在的 2026-09-30 重新发起一次运行;Backfill 则把 2026-09-25 到 2026-09-30 这段历史日期逐日补齐。
迟到的余额快照属于 9 月 30 日时,应回到这个业务日期的目标分区重算,而不是在 10 月 1 日追加一份看似最新的余额。
- Retry:同一任务实例的下一次 Attempt。
- Rerun:已有业务日期的一次重新执行。
- Backfill:一段历史业务日期的批量补跑。
选择“再跑一次”的含义
切换 Retry、Rerun、Backfill,观察运行实例、业务日期和日期范围如何变化;再选择从 DWS 或 ADS 开始,比较哪些上游结果可以复用。
再决定从 DAG 的哪个位置开始
如果 DWD 的明细结果仍然正确,只是 DWS 逻辑修正,可以从 DWS 开始并继续到 ADS,复用已经成功的 DWD。若 AccountBalanceSnapshot 本身发生修正,就要让修正重新经过 DWD、DWS 和 ADS。
因此重跑范围有两个维度:要计算哪些业务日期,以及从 DAG 的哪个位置开始。不能只看到“重跑”两个字就默认整条链路都要重做。
- DWD 正确、DWS 逻辑错误:复用 DWD,重新执行 DWS → ADS。
- 输入快照修正:重新执行 DWD → DWS → ADS。
- 是否复用上游,要看上游结果是否仍然代表当前输入和规则。
同一分区,覆盖和追加会留下什么?
调度系统可以发起重跑,但不能替加工任务决定写入语义。
按目标分区覆盖
- 第一次:杭州分行余额 = 100 万。
- Rerun 同一个 snapshot_date。
- 结果仍然是 100 万,目标分区只有一份结果。
INSERT APPEND
- 第一次:杭州分行余额 = 100 万。
- Rerun 再追加一行相同结果。
- 查询得到 200 万,任务虽成功,结果却重复。
主动 Rerun,不等于两个入口同时触发
Rerun 是明确的运行行为:有人为恢复或纠错而发起一次运行,有目标业务日期、范围和运行记录。它回答“为什么这次要再跑”。
双入口事故发生在配置层:迁移过程中旧 JOB 未下线、新 JOB 已启用;两个独立定义都认为自己应该在 2026-09-30 执行,于是分别触发同一生产逻辑和目标。它不是一个 Run 的第二次 Attempt,也不必然带有恢复意图。
- Rerun:一个明确的操作意图,检查目标日期、重跑范围、原因和 run history。
- 双入口:两个 enabled schedule 各自触发,排查定义状态、ownership、独立 run record 与下游产物。
旧 JOB 和新 JOB 都开着,会发生什么?
先保持两个入口 ON,运行一次 2026-09-30;观察触发、执行、写入和下游产物数量。再比较幂等 / 非幂等目标,并关闭旧入口验证单入口恢复。
用 cutover checklist 收敛到唯一生产入口
迁移前确认这个业务产物的负责人、生产入口、业务日期和目标;切换时按已约定的顺序 disable 旧入口、enable 新入口,并确认实际 enabled/disabled 状态,而不是只看配置提交成功。
切换后核对该业务日期的 run history、任务实例和下游证据:生产逻辑实际执行几次、目标分区有几份数据、生成多少文件、发起多少次推送。表结果正确并不能证明没有重复运行或重复副作用。
有意双跑用于影子比较并非一概禁止,但应由明确 owner 负责,隔离目标并控制通知、文件和外部推送等副作用,记录比较窗口与清理条件。调度平台的去重能力及组织发布门禁各不相同,需按本地约定验证。
- 迁移前:明确唯一生产入口、owner、业务日期和目标。
- 切换时:核验旧入口 disabled、新入口 enabled,保留变更与 run history。
- 切换后:对照 run record、目标数据、文件与推送证据。