连续多日历史补数，为什么不能简单并行？
理解 T/T-1、滚动窗口与余额快照带来的跨天依赖，掌握「日期升序 + 单日依赖」的两层执行顺序，以及为什么全窗口并行会破坏快照链。
七天数据一次补完？先看跨天依赖
连续多日历史补数，为什么不能简单并行？
同一个 ODS 缺陷可能影响连续多个业务日期。看上去把 7 天一起提交、并行跑完最快，但余额快照、滚动窗口指标和累计口径会把前一天的结果带进后一天——简单并行不是更快，而是把错误换了个位置。
为什么连续多日的补数不能像单日重做那样各自独立执行？
核心概念
滚动补数窗口（Rolling Backfill Window）
一组连续业务日期及其跨天依赖的安全执行顺序。窗口内的每日结果通过快照、滚动指标或累计口径相互引用；执行时必须先满足跨天依赖，再满足单日内部的血缘与调度依赖。
为什么后一天会依赖前一天
日批数据里有一类结果不是当天独立计算的：余额快照以「前一天的状态」为起点，滚动 7 日指标读取前 6 天的结果，累计口径把历史金额一直带下来。这类任务在重做时，如果前一天的结果还是旧的，后一天算出来的仍然是错的。
所以跨天依赖不是调度器的偏好，而是数据语义：T 的输入里真的包含 T-1 的输出。判断补数窗口时，要沿血缘找出这些跨天引用，而不是只看任务名或日期范围。
- 余额快照：状态的起点来自前一天。
- 滚动窗口指标：窗口内前几天的结果会被再次读取。
- 累计口径：历史金额沿日期不断累加。
简单并行会破坏什么
把窗口内所有日期同时提交，会同时启动多天的任务：T 在 T-1 还没有完成时就读取旧快照，算出的结果把旧数据固化进新的日期；后续重做又可能再次覆盖，形成难以追踪的重复或回退。更麻烦的是，不同日期的写入顺序不确定，最终结果取决于谁先完成。
这与 14-6 的下游问题叠加时更危险：消费端可能已经读到了「新日期 + 旧快照」的混合结果，却把它当成完整修复。
- 快照链断裂：后一天读了前一天的旧结果。
- 写入顺序不确定：结果与执行顺序相关，无法复现。
- 下游可能消费混合状态：部分日期新、部分日期旧。
依赖链重做实验 · E7 滚动窗口与跨天依赖
窗口大小、跨天依赖与安全执行顺序
切换 3 / 5 / 7 天窗口，查看业务日期升序、T/T-1 跨天依赖和每日实例映射；点击「检查并行可行性」会列出简单并行会遇到的冲突；按顺序逐日执行或一键完成，观察补数进度如何推进。
正在加载交互实验…
两层顺序：日期升序 + 单日依赖
安全执行顺序是两层叠加：先按业务日期升序满足跨天依赖，再在每个日期内部按血缘与调度依赖执行。14-2 的当日重做顺序（上游先于下游）在每一天内部仍然成立。
窗口大小由影响范围决定：如果跨天引用只覆盖 3 天，就没必要补 7 天；如果滚动指标需要完整窗口，就必须把窗口内的日期全部补齐。这也是为什么补数任务要先做影响分析，再决定日期集合。
- 第一层：业务日期升序，满足跨天依赖。
- 第二层：单日内部按血缘 + 调度依赖执行。
- 窗口大小由跨天引用范围决定，不用固定天数。
放在一起看
全窗口并行与逐日串行
两种执行策略在速度与正确性上的差别。
看起来更快
- 所有日期同时启动，资源占用高。
- T 可能读到 T-1 的旧快照。
- 结果依赖完成顺序，不可复现。
- 需要人工排查混合状态。
依赖正确、结果可复现
- 先完成 T-1，再执行 T。
- 每天内部按血缘与调度依赖执行。
- 失败时从失败日期继续，不整窗重来。
- 与下游确认（14-6）配合形成完整闭环。