我们有一个订阅了PubSub事件流的DataFlow作业。我们应用了1小时的滑动窗口，时间为10分钟。在我们的代码中，我们执行Count.perElement来获取每个元素的计数，然后我们想通过Top.of运行它来获得前N个元素。
高层次： 1）从pubSub IO读取 2）Window.into（SlidingWindows.of（windowSize）。每个（句点））// windowSize = 1小时，句点= 10分钟 3）Count.perElement 4）Top.of（n，comparisonFunction）
我们所看到的是窗口正在被应用两次，因此数据似乎在当前时间之后1小时40分钟（而非50分钟）加水印。当我们深入了解Dataflow控制台上的作业图时，我们发现对数据执行了两个groupByKey操作： 1）作为Count.perElement的一部分。从此步骤开始的数据上的水印比当前时间晚50分钟，这是预期的。 2）作为Top.of的一部分（在Combine.PerKey中）。这个水印似乎比现在的时间落后了50分钟。因此，以下步骤中的数据在1:40分钟后加水印。
这最终表现在一些下游图表迟到了50分钟。
因此，似乎每次应用GroupByKey时，窗口似乎都会重新启动。
这是预期的行为吗？无论如何，我们可以使窗口仅适用于Count.perElement并在此之后将其关闭？
我们的代码就是：
pypeg2答案 0 :(得分：1)
每次有GroupByKey时都不会应用窗口。您看到的滞后可能是两个问题的结果，两个问题都应该得到解决。
第一个是按键为第一组后续窗口缓冲的数据阻止水印前进，这意味着早期的窗口被按键锁定在第二组。这已在最新版本的SDK中修复。
第二个是滑动窗口导致数据量显着增加。添加了一个新的优化，它使用了组合（您提到的Count和Top）来减少数据量。