Apache Beam中DirectRunner与DataflowRunner在滑动窗口使用OUTPUT_AT_EOW时的行为不一致问题排查

看起来你遇到了一个挺让人头疼的Beam跨Runner行为差异问题，我来帮你拆解一下背后的核心原因，以及为什么OUTPUT_AT_EOW会导致这种不一致：

首先，我们得先理清楚你这套窗口逻辑中timestamp_combiner的作用：
你先给元素分配了1分钟的固定窗口，并用OUTPUT_AT_EARLIEST把每个元素的输出时间戳设为所在固定窗口的起始时间；接着又套了15分钟滑动窗口（每分钟滑动一次），这里用了OUTPUT_AT_EOW——这个选项会让同一个元素在每个它所属的滑动窗口中，都拥有不同的输出时间戳，具体来说就是该滑动窗口的结束时间减1毫秒。而如果用OUTPUT_AT_EARLIEST，所有滑动窗口中的元素副本都会共享同一个最早的时间戳。

接下来就是两个Runner的核心差异了：

• DirectRunner（本地执行）：它的水印推进是模拟出来的“理想状态”，哪怕开了多进程，全局水印还是会快速推进到所有元素的最大时间戳。这意味着每个滑动窗口都会等到所有属于它的元素副本都到齐后才触发聚合，所以你看到的结果是每个窗口只输出一次，而且计数是完整的。
• DataflowRunner（分布式执行）：它的水印推进是基于各个Worker的实际处理进度，是渐进式的。当同一个元素的不同副本拥有跨度极大的时间戳（从最早的滑动窗口结束时间到最晚的，差了14分钟左右），水印会分阶段往前推进：某个滑动窗口的水印刚到结束时间，该窗口的部分元素副本可能还在其他Worker上处理，没来得及进入窗口，此时就会触发一次聚合（所以计数很小）。而且你设置了allowed_lateness=0，窗口一旦触发就会关闭，后续到达的元素副本再也进不去这个窗口，最终就出现了大量小计数的窗口输出，总数量是DirectRunner的好几倍。

至于你用多进程DirectRunner模拟Dataflow没成功，是因为DirectRunner的水印逻辑本质还是全局模拟，和Dataflow分布式环境下的渐进式水印推进完全不一样，没法还原真实的分布式场景。

解决建议 #

1. 优先用OUTPUT_AT_EARLIEST：这样所有元素副本的时间戳统一，两个Runner的水印推进节奏一致，聚合结果自然就对齐了；
2. 若必须用OUTPUT_AT_EOW：可以把allowed_lateness设为一个足够大的值（比如5-10分钟），给Dataflow足够的时间收集齐所有元素副本再触发窗口，不过这会增加处理延迟；
3. 简化窗口逻辑：如果业务允许，直接基于原始事件时间戳做滑动窗口，去掉嵌套的固定窗口，也能避免这类时间戳变换带来的差异。

备注：内容来源于stack exchange，提问作者Mark Chin