任务都成功了，为什么数据还是可能迟到？
拖动上游到达时间，追踪迟到如何传播到 ADS，并用业务可用时间判断 SLA。
所有任务都成功了，为什么经营分析还是没等到？
任务都成功了，为什么数据还是可能迟到？
经营分析约定 07:30 使用 2026-09-30 的存款余额结果。把上游到达时间往后拖，观察延迟怎样经过 DWD、DWS 传到 ADS，以及最终是否错过业务可用时间。
如果 2026-09-30 的余额结果 07:42 才可用，任务最终 success 能抵消这次延迟吗？
核心概念
SLA（服务级别约定）
SLA 是业务约定的数据可用时间。本例要求 2026-09-30 存款余额结果在 07:30 前可供经营分析使用；DWD、DWS 的完成时间只是解释延迟的证据。
成功和按时是两件事
正常情况下，DAG 可以在 07:20 前完成 ADS，经营分析按约定使用结果。如果 AccountBalanceSnapshot 迟到，DWD 的开始时间会后移，DWS 和 ADS 只能依次等待，最终可能在 07:42 才可用。
07:42 的每个任务都可能显示 success，因为程序最终完成了；但业务消费者在 07:30 等不到结果，SLA 仍然没有满足。
- 任务状态回答“这次执行有没有完成”。
- SLA 回答“业务约定的时间前，结果能不能使用”。
- 上游到达、DWD / DWS 完成和 ADS ready 是同一条延迟证据链。
交付时效实验 · 拖动上游到达时间
看 ADS Ready 如何突破 07:30
拖动 AccountBalanceSnapshot 的实际到达时间，再推进同一条 DAG 到完成。结果会保留 2026-09-30 业务日期，并显示最终 ADS ready 时间和 SLA 是否满足。
正在加载交互实验…
SLA 从业务消费者开始定义
经营分析关心的是“07:30 能不能拿到 9 月 30 日存款余额”，所以 SLA 应写成结果可用约定，而不是只给某一个内部任务设置一个倒计时。DWD 和 DWS 的完成时间用于定位哪一段变慢。
把到达时间拖到 07:30 之后，延迟会沿依赖链向下传递。即使最后没有任何代码报错，也要把 SLA Miss 记录为交付问题。
- 业务日期仍是 2026-09-30，不会随迟到时间改变。
- 结果 ready 时间由整条必要链路共同决定。
- SLA 关注业务可用性，不在本章展开告警、值班或事故流程。