Flink Watermark 和迟到数据怎么处理？
本文目录
面试怎么回答
Watermark 是 Event Time 的进度声明，用来告诉窗口何时可以触发，不是每条数据的等待时间。我会先从业务事件字段提取时间戳，再根据真实延迟分布和结果 SLA 设置有界乱序时间，同时检查并行分区和空闲分区，避免最慢输入阻塞整体进度。迟到数据分层处理：在 Allowed Lateness 内保留窗口并更新结果，超过范围的进入 Side Output 做监控和补偿，极端迟到由离线任务校正。Watermark 越保守结果越完整但延迟和状态成本越高，所以最终是实时性、完整性和资源成本之间的取舍。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
很多人会背一句：
“Watermark 等于最大事件时间减去允许乱序时间。”
这能解释一种常见生成方式，却没有回答生产里最重要的问题：
Watermark 到底代表什么，应该等多久，超过这条边界的数据又怎么处理？
Watermark 不是给每条数据设置等待时间，而是向下游声明 Event Time 已经推进到哪里。
它本质上是在结果时效、迟到容忍和状态成本之间划一条边界。
第一步：先区分 Event Time 和 Processing Time
Event Time 是事件真正发生的时间，通常来自消息字段；Processing Time 是数据到达算子并被处理的机器时间。
网络抖动、客户端缓存、Kafka 积压和任务恢复都会让两者不同。
如果业务要按“用户实际发生行为的时间”统计，就应该使用 Event Time，并从数据中提取正确时间戳。
Watermark 用来表示 Event Time 的处理进度。窗口看到 Watermark 越过结束时间后，就可以触发计算，而不需要无限等待可能永远不会来的数据。
第二步：Watermark 不是越大越好，也不是越晚越准
常见的有界乱序策略会根据已观察到的最大事件时间，减去一段乱序容忍时间来生成 Watermark。
这段时间应该来自真实数据分布，而不是拍脑袋：
- 大部分数据晚到多久
- P95、P99 延迟是多少
- 业务最晚多久必须看到结果
- 状态可以保留多久
- 极端迟到是否允许后续修正
容忍时间太短，窗口结果快，但更多数据会成为迟到数据；容忍时间太长，结果更完整，却会增加输出延迟和状态保留成本。
因此 Watermark 是业务 SLA 和数据延迟分布共同决定的。
第三步：注意并行分区和空闲分区
并行 Source 通常各自生成 Watermark。下游算子接收多个输入时，Event Time 进度会受到最慢输入的限制。
如果某个 Kafka 分区暂时没有数据，它的 Watermark 可能长期不推进，导致整个下游窗口迟迟不触发。
这时要根据数据源特征配置空闲分区检测，让长期无数据的分区不再阻塞整体 Watermark。
但如果只是某些分区真实严重延迟，不能简单当成空闲跳过，否则可能把仍会到达的数据变成迟到数据。
先区分“没有数据”和“数据堵住了”。
第四步：迟到数据要分层处理
Watermark 越过窗口结束时间后到达的数据，会进入迟到处理逻辑。
常见有三种方式：
方式一：允许一定迟到时间
通过 Allowed Lateness 暂时保留窗口状态。迟到但仍在允许范围内的数据到达后，可以再次触发窗口计算。
这要求下游能够接受更新结果，例如使用窗口主键做 Upsert，而不是每次都追加一条最终值。
方式二：输出到 Side Output
超过允许迟到范围的数据进入侧输出，单独监控、补偿或回放，避免静默丢弃。
方式三：离线校正
对极端迟到、历史补录或跨天回传的数据，实时链路不必无限等待，可以由离线任务按更完整的数据重算并修正结果。
实时结果和最终结果的口径要提前说清，否则迟到更新会让下游觉得“同一个指标一直在变”。
一个典型场景
比如统计每 10 分钟的播放次数，Watermark 乱序容忍设置为 2 分钟。
大部分事件几十秒内到达，窗口能够及时输出。但部分移动端事件因为离线缓存，20 分钟后才上报。
如果把 Watermark 直接延长到 20 分钟，所有窗口都会为了少量极端数据延迟输出，实时性明显下降。
更合理的设计是：实时窗口容忍主要延迟分布；短时间迟到通过 Allowed Lateness 更新；极端迟到进入 Side Output，并由补偿或离线链路修正。
真正要解决的是不同迟到程度的处理分层，而不是让实时任务无限等待。
为什么 Watermark 配置正确，窗口仍可能不出结果？
除了时间戳提取错误，还要检查：
- 某个并行分区 Watermark 是否停滞
- Source 是否长期空闲但没有配置 idleness
- 多流 Join 或 Union 是否被较慢输入限制
- 数据时间单位是否把秒当成毫秒
- 窗口时区和业务时区是否一致
- 任务恢复后时间进度是否符合预期
Watermark 的问题不能只看一条公式，还要看它在整条拓扑中的传播。