题干与适用场景
你要计算每 5 分钟的订单金额与订单数。客户端离线、网络重试和多区域传输会让事件晚到，且同一订单可能重复发送。业务希望 1 分钟内看到初值，最终报表在 24 小时内可校正。
回答要区分事件时间与处理时间，说明窗口何时发射、迟到事件进入哪条路径，以及下游如何识别修正结果。
面试官考察点
时间语义
强回答先定义事件时间戳、处理时间、窗口边界和时区，再解释 watermark 只是系统对“窗口内大多数数据已到达”的估计。
结果生命周期
候选人应区分早期结果、窗口结束结果、迟到修正和超时丢弃，不能把一次输出假设成永久正确。
状态与成本
需要说明状态保留、allowed lateness、重算范围、热点 key 和检查点，否则窗口越等越久会造成状态失控。
可观测性
要能监控 watermark lag、迟到分布、修正比例、丢弃数量、重复率和结果新鲜度。
回答前需要澄清的问题
- 指标按事件发生时间还是到达时间统计？
- 初值允许多大误差，最终一致的截止时间是多少？
- 迟到事件是否必须修正已发布报表？
- 事件是否带稳定的 event_id，重复应如何去重？
- 单个 key 的最大吞吐和可接受状态大小是多少？
- 超过截止时间的事件要丢弃、隔离，还是进入离线重算？
30 秒回答框架
“我采用事件时间窗口，并让输入携带 event_id 与事件时间。主流处理器用 watermark 触发窗口的初值，设置有限的 allowed lateness 接收迟到修正；修正以同一窗口键和版本号写出。超过截止时间的事件进入隔离与批量重算，不静默改写历史。指标覆盖 watermark 延迟、迟到分位数、修正率、丢弃量和状态大小。”
分步骤深入解答
第一步：定义窗口与时间
以 UTC 事件时间切固定窗口，例如 [10:00, 10:05)。处理时间只用于延迟告警和触发早期结果，不能替代业务时间。窗口键包含租户、商品或地区，避免跨维度混算。
第二步：生成 watermark
每个分区根据已观察到的事件时间推进 watermark，再由全局策略取安全下界。低流量分区必须有 idle 检测，否则一个没有新事件的分区会拖住整条管道。
第三步：安排触发与累积
先用 processing-time trigger 发出近似结果，再在 watermark 越过窗口结束时发出主结果。选择 accumulating 或 discarding 模式，并让输出携带 windowend、revision 和 isfinal。
第四步：处理迟到与重复
在 allowed lateness 内，按 event_id 去重后更新窗口状态并发出新 revision。重复事件不增加金额；同一事件的重放必须得到相同结果。窗口状态要保留到截止时间之后再清理。
第五步：设置超时回退
超过 allowed lateness 的事件写入 quarantine，记录原因和原始 payload。离线任务按窗口重算最近 24 小时，并用幂等 upsert 或更高 revision 覆盖可修正结果。
第六步：验证与发布
用可控时间戳测试乱序、重复、空闲分区、重启恢复和迟到边界。发布端按 (metric, windowend, revision) 去重，最终报表只消费 isfinal=true 或已过业务截止时间的版本。
高质量示范回答
“我先把事件时间、窗口和截止策略写成契约。每个事件带稳定 eventid、eventtime 和 schema_version，流处理器按租户与指标做 5 分钟窗口。分区 watermark 推进时考虑 idle 分区，全局 watermark 作为窗口完成的保守估计。
系统立即发出 early revision，watermark 越过窗口结束后发出主 revision，并在 30 分钟 allowed lateness 内接受迟到事件。每次输出包含窗口边界、revision 和最终标记，下游按键幂等写入。超过 30 分钟的事件进入隔离表，由 24 小时重算任务生成更高 revision；超过报表截止时间则只做审计，不回写业务账本。
我会监控 watermark lag、p50/p95/p99 迟到时长、修正率、丢弃率、重复率、状态字节数、重算积压和最终结果延迟。容量估算按活跃窗口数乘以每窗口状态，并用 checkpoint 与状态 TTL 控制故障恢复成本。”
常见错误
- 用处理时间代替事件时间 → 离线客户端的数据落入错误窗口 → 保留 event_time，并把处理时间只用于运维触发。
- 把 watermark 当成全局真相 → 迟到事件被静默丢失 → 明确它是估计值，配置 allowed lateness 和隔离路径。
- 只发一次窗口结果 → 修正无法传播 → 使用 revision 与最终标记让下游可幂等更新。
- 无限制等待迟到事件 → 状态和成本无界 → 设业务截止时间，超时转离线重算。
- 只按事件 payload 去重 → 重试改变顺序就重复计数 → 使用稳定 event_id 和持久去重状态。
- 忽略空闲分区 → watermark 停滞、延迟告警失真 → 识别 idle 分区并从全局下界暂时排除。
- 只测顺序输入 → 边界行为上线才暴露 → 注入乱序、重复、晚到、重启和恢复测试。
追问及应对
追问一：watermark 为什么会停滞？
某个分区可能没有新数据、连接异常或估计器保守。用 idle timeout、分区心跳和 watermark lag 告警区分真实静默与故障。
追问二：allowed lateness 如何取值？
根据历史迟到分布、业务截止时间和状态成本选择，并以 p99 迟到时长为起点做回放验证。它不是越长越正确，过长会扩大状态和修正窗口。
追问三：如何避免修正风暴？
对迟到事件做微批合并、限制每窗口修正频率，并在下游按 revision 只保留最新值；高峰期可把非关键指标降级为批量修正。
追问四：超过截止时间的事件能否直接丢弃？
不能静默丢弃。先写隔离与审计，统计业务影响；若账务或合规要求完整性，就必须运行重算或人工处理。
追问五：重启后如何保证结果不倒退？
检查点保存窗口状态、去重状态和 watermark；输出使用单调递增 revision，下游拒绝旧 revision，恢复后从日志重放并做一致性校验。
来源一：Apache Beam Programming Guide
Beam 文档定义 watermark、trigger、allowed lateness 与累积模式，并说明迟到数据可以触发新的 pane。
来源二：Apache Kafka Streams Core Concepts
Kafka Streams 文档说明 grace period 如何决定窗口继续接收乱序记录，以及超过窗口结束加 grace 后的丢弃语义。
来源三：Dataford 流处理面试题
公开面试题将 watermark、迟到路由、重算和监控列为回答要点，为本题的面试场景与追问提供依据。