数仓重做成功，为什么下游还要重新装数？
识别装数、接口、文件、报表、监管五类消费方式，按「已消费旧结果」的证据给出重装 / 刷新 / 更正动作，并完成通知与确认闭环。
数仓修复了，报表还是错的
数仓重做成功，为什么下游还要重新装数？
历史重做完成、数仓内部全部 SUCCESS 之后，经营报表仍然展示旧数字、接口缓存仍然返回旧结果、已投递的文件还是错的、监管报送也停留在旧口径。问题不在数仓任务，而在下游已经消费了重做前的旧结果。
数仓任务 SUCCESS，为什么不能代表消费端已经恢复？
核心概念
消费闭环（Consumer Closure）
从「消费端消费了哪个版本的结果」出发，判断需要重装 / 刷新 / 更正，并跟踪通知与确认，直到消费端恢复一致的完整过程。它和数据链重做是两段不同的工作。
重做成功只覆盖数仓内部
血缘链重做解决的是「数仓内部的结果是否与修复后的输入一致」。它让 DWD、DWS、ADS 和目标表重新算出正确结果，但不会自动改写已经离开数仓的东西：报表系统里的缓存、已经投递给合作方的文件、下游数据库已经装载的数据、监管报送系统里的口径。
因此重做完成之后需要单独回答：哪些消费方已经消费了旧结果？它们各自以什么方式消费？对它们来说「正确的数据」如何送达？
- 数仓 SUCCESS = 数仓内部结果已更新。
- 消费端有自己的存储、缓存和确认机制。
- 重做与下游恢复是两段工作，不能被同一个 SUCCESS 覆盖。
先识别消费方式与消费证据
消费方式决定恢复动作：接口推送需要重新装数并确认对方收到；文件投递需要重新生成并投递文件；报表需要刷新缓存或重算；监管报送需要更正并重新报送；还没有消费过的下游只需等待新结果，不需要重装。
判断依据是消费证据，而不是猜测：消费端当前装载的是哪个批次 / 版本的结果？是否已经消费重做后的新结果？没有证据时不能假设「它应该已经更新了」。10-1 到 10-5 已经介绍了三类典型消费模式，可以直接复用它们的边界。
- 装数 / 接口 / 文件 / 报表 / 监管：动作各不相同。
- 消费证据描述「现在装载的是哪一版」，不是「应该拿到哪一版」。
- 未消费旧结果的下游不需要重装，但需要知道新结果已经可用。
依赖链重做实验 · E6 下游重新装数与确认闭环
数仓全部 SUCCESS 之后，闭环还差几步
查看六类消费方：已装载旧结果的接口、文件、报表与监管分别需要重装 / 刷新 / 更正并确认；未消费旧结果的装载任务无需处理；已消费新结果的接口保持已确认。逐项确认或一键确认，观察闭环状态如何收敛。
正在加载交互实验…
重装之后还要通知与确认
重装动作本身不等于恢复完成。接口推送要确认对方收到并使用了新版本；文件投递要确认文件到达并被处理；报表要确认缓存已刷新；监管报送要确认更正记录已经提交。这些确认需要留痕，才能回答「消费端到底恢复了没有」。
通知与确认是闭环的组成部分，而不是可选的礼貌动作。没有确认时，即使数仓重做成功，也只能说「已经重新交付」，不能说「消费端已恢复」。
- 动作完成后必须跟踪确认，确认状态要可查询。
- 确认的证据包括接收回执、消费批次、缓存版本或报送记录。
- 全部受影响消费方确认后，闭环才算完成。
- 交付完成信号与消费证据的检查方法见 13-2。
放在一起看
两种「恢复完成」
同一个重做动作，两种收尾方式给出的结论完全不同。
数仓内部一致
- 目标任务全部 SUCCESS。
- 数仓表结果已与修复输入一致。
- 下游缓存 / 文件 / 报送仍是旧结果。
- 结论：数仓恢复完成，消费端未恢复。
消费端恢复一致
- 按消费方式完成重装 / 刷新 / 更正。
- 通知下游并跟踪确认。
- 确认证据可查询、可追溯。
- 结论：整条交付链恢复完成。