流式计算里迟到数据怎么处理？Watermark 是什么？

一句话：Watermark 是事件时间的「到齐声明」——我相信这个时间点之前的数据基本齐了，可以关窗。迟到不是故障，是关窗之后才来的事实。

先别用处理时间做业务窗口。 处理时间是作业墙上的钟，源抖动、反压、重启都会把 10:59 的支付算进 11 点窗口。摄取时间是进入 Kafka/作业的时间，只比处理时间稳一点。GMV、漏斗、会话必须按事件时间（业务发生时刻），乱序是常态。

Watermark 怎么走。 常见有界乱序：watermark = max(event_time) - 允许乱序。它是单调不减的事件时间进度，不是「再等 N 分钟」的 sleep。窗口 [10:00, 11:00) 在 watermark ≥ 11:00 时关闭；允许延迟 10 分钟，则 watermark ≥ 11:10 之前仍可更新该窗，之后再来就算迟到。

伪代码：

# 允许 5 分钟乱序；窗关后再留 10 分钟可更新
watermark = max_event_time_seen - 5min
if event_time >= window.end:            # 还没到齐，窗开着
    accumulate(window)
elif watermark < window.end + allowed_lateness:
    update(window)                      # 迟到但还在宽限
else:
    side_output(late_event)             # 真正迟到，不要静默丢

迟到三条路，按代价选：
1. 允许延迟内更新：完整度优先，状态和延迟都变大。
2. 侧输出 / 迟到流：窗结果先发，迟到单独进补数作业，不挡主链路 SLA。
3. 丢弃：只适合监控毛刺，资金/对账禁止静默丢。

落到数仓。 实时窗是有界近似；终态在离线。事实表按 event_date 分区，不要按到达日。迟到事件 MERGE 回事件日，再重跑该分区的 DWS/ADS，用主键对账实时与离线。

-- 迟到仍落回事件日，禁止写进「今天到达」的分区冒充今日增量
MERGE INTO dwd_pay_txn t
USING late_pay s
ON t.pay_id = s.pay_id AND t.dt = s.event_date
WHEN MATCHED THEN UPDATE SET amount = s.amount, src_lsn = s.src_lsn
WHEN NOT MATCHED THEN INSERT *;
-- 然后只重跑 dt = 事件日 的下游，不要全量刷新

口述收尾：先说「窗口跟事件时间，watermark 是到齐声明」，再主动提允许延迟、侧输出和离线按事件日补数。面试官要的是你会做完整度与延迟的交易，不是会画一条水位线。