历史数据如何重做而不影响当天日切？
区分「当日」与「历史」两种恢复模式，理解日切完成门禁、平行 Job / Plan 的绑定与隔离，以及为什么平行计划必须使用最新加工程序。
历史日期可以重做，但不能随便重做
历史数据如何重做而不影响当天日切？
同一批 ODS 缺陷往往影响多个业务日期：除了 2026-10-16 的当日恢复，还要补做 2026-10-10 这样的历史日期。历史重做不能在白天随时启动——必须先等当日全部跑批结束，再生成一套与当前生产隔离的平行 Job / Plan。
为什么历史重做必须先等当日跑批结束？
核心概念
平行 Job / Plan（Parallel Job / Plan）
为历史业务日期单独生成的一套重做计划：绑定指定 business_date、沿用当前有效的血缘与调度依赖、使用最新加工程序，并与当前正常生产计划隔离，不修改正常实例的状态。
先分清「当日」和「历史」
「当日」不是一个自然日，而是当前生产日切批次：它可能从晚上跑到第二天凌晨，跨过自然日仍然属于同一批。当日出现问题时，恢复动作发生在现有生产链路上——停止、等待、验证、重新调用，不会另起一套计划，这一段就是 14-3 的内容。
「历史」是当日批次之外的其他业务日期：比如已经完成日切的 2026-10-10。历史日期的结果已经被消费、被报表引用，重做它属于补做，不能和当前生产抢同一条 Job / Plan。
- 当日 = 当前生产日切批次，可跨自然日，沿现有 Job / Plan 恢复。
- 历史 = 其他业务日期，需要独立的平行 Job / Plan。
- 两者的隔离基础是 business_date 参数与计划对象，而不是自然日期。
门禁：当日跑批结束前，禁止启动历史重做
历史重做如果与当日跑批同时进行，两套任务可能同时读写同一批表、争抢资源，甚至在依赖关系上互相等待。更危险的是状态一致性：当日批次还在推进时生成平行计划，很容易把「当日正常实例」也纳入重做范围，导致当前生产状态被重置。
因此平台先检查日切完成门禁：当日所有实例都进入终态后，历史重做才允许生成平行 Job / Plan。门禁不通过时给出可解释的原因（哪些实例还没结束），而不是悄悄排队等待。
- 门禁对象是当日批次，不依赖自然日期。
- 未完成时不允许生成平行计划，避免当前生产被改写。
- 门禁状态与原因都要可见，不能静默跳过。
依赖链重做实验 · E4 当日 / 历史模式与平行 Job / Plan
当日未完时门禁如何阻断，完成后平行计划如何生成
切换当日重做与历史重做；模拟当日跑批完成前后，「生成平行 Job / Plan」分别被门禁阻断或放行。放行后可以切换历史目标日期，查看平行计划绑定的 business_date、最新程序版本与当前状态的隔离说明。
正在加载交互实验…
平行 Job / Plan 的三条约束
第一，绑定指定历史日期：平行计划的 business_date 参数是历史目标日期，实例、分区与目标表都指向那一天的写入单元。第二，使用当前有效的血缘与调度依赖：不复制历史执行顺序，因为程序与依赖关系可能已经演进。第三，统一使用最新加工程序，而不是历史版本。
最后也是最重要的隔离要求：生成平行计划不改变当前正常 Job / Plan 的状态。当日已经成功的实例保持成功，正在运行的实例保持运行；历史重做只操作历史日期的实例。
- 绑定历史 business_date，而不是在当天追加一份结果。
- 按当前有效血缘 / 依赖执行，不复制历史运行顺序。
- 使用最新程序；平行计划与当前计划状态隔离。
放在一起看
当日重做与历史重做的区别
两种恢复模式的目标相同，但对象、门禁与计划形态不同。
当前生产链路上的恢复
- 对象：当前日切批次的受影响实例。
- 计划：沿现有生产 Job / Plan，不生成平行计划。
- 门禁：先停止 / 等待，ODS 验证通过后重做。
- 目标：尽快恢复当前批次并继续交付。
历史日期的平行计划
- 对象：指定历史业务日期的受影响实例。
- 计划：新生成平行 Job / Plan，绑定历史日期。
- 门禁：当日全部跑批结束，且程序 / 语义兼容。
- 目标：补正历史结果，并通知下游重新装数。