目标
数据源注定会迟到：移动端离线事件、合作方批量文件、时钟漂移。假装不会迟到，就只能在丢数据与重复计数之间二选一。事件时间窗口、迟到路由、以及带着版本标记的显式重述，让迟到成为被妥善处理的正常情况，而不是悄悄算错的理由。
步骤要点
- 按领域分级迟到容忍度：运维指标容许几小时、财务对账容许几天、会话键不容许迟到，每个领域的窗口设计由此驱动。
- 按事件时间开窗并推进水位：处理按事件时间戳分组，水位声明管道等待多久才关窗，迟到事件能找到自己真正所属的窗口。
- 按迟到类别路由：容忍内的事件更新其窗口，超出容忍的进迟到流供评审，绝不静默丢弃。
- 显式重述已发布聚合：迟到数据改变已发布数字时重算受影响窗口，以带版本标记的 v2 发布，下游能区分新旧。
- 把迟到本身当监控信号：跟踪迟到分布与超容忍率，源头变慢早于正确性争议被发现。
排错提示
两天数字对不上且无解释多半是处理时间窗口放错了迟到事件，改事件时间加水位；重算后悄悄覆盖让两个时间点看数的消费者永久分歧，重述必须带版本标记；迟到流只是调试页上的计数等于变相丢弃，它要可查询可评审。
适用边界
无限等待迟到会拖垮时效，容忍度是业务决策不是技术参数，要与消费方共同签署；重述机制要求下游能识别版本，老旧消费者需先升级再谈重述。
代码示例
domain: financial reconciliation
tolerance: 72h (event time)
10-22 run: event at 10-19 22:41Z arrives (46h late)
-> within tolerance -> joins 10-19 window
-> 10-19 daily total changes 41,203 -> 41,417
-> RESTATEMENT: daily_v2 published
consumers see version marker (v2)
10-23 run: event at 10-15 arrives (7d late)
-> beyond tolerance -> late-arrival stream
-> weekly review decides: manual adjustment
lateness monitor: p95 lateness 3.2h (baseline 1.1h)
-> source degradation alert fired