如果为flink的keyBy操作符提供distinct键，然后是翻滚窗口，会发生什么情况

Question

我的flink作业有keyBy操作符，它以date~clientId(日期为yyyymmddhhMM，MM为分钟，5分钟后更改)为关键字。此操作符之后是5分钟的翻滚窗口。我们有平均300万/分钟事件的kafka输入，高峰时间大约2000万/分钟的事件。检查点持续时间和两个检查点之间的最小停顿时间为3分钟。

下面是我的疑虑：

2)如果我将此窗口更改为30分钟，则需要进行哪些更改。

3)窗口大小对检查点时间的影响。

4)在任何5分钟内不同客户的数量增加5-10倍的场景中，会有什么影响。这会造成数据失真吗？因为在我的工作中，1-2个子任务总是需要大约1-2分钟，而其他800个子任务只需要10-15秒就能完成。

org.apache.flink.streaming.runtime.tasks.SystemProcessingTimeService$TriggerTask.上的TimerException{java.nio.channels.ClosedByInterruptException}可能的原因是。

Answer 1

以下是几点：

keyBy不是运算符，也没有状态。keyBy只是对如何对流进行重新分区的声明。跟随keyBy的翻滚窗口具有状态，该状态在窗口完成后被清除。如果您查看web UI的检查点统计信息部分中的细分，您可以看到每个子任务具有多少状态。

下面是一个例子：

​

​

在任意5分钟内不同客户端的数量增加5-10倍的情况下会产生什么影响。这会造成数据失真吗？因为我工作中的1-2个子任务总是需要大约1-2分钟，而其他800个子任务需要10-15秒才能完成。

也许您有一个或几个客户端的事件比其他客户端多得多？

理解为什么要在处理时间窗口之后进行基于事件时间的键控，而不是使用事件时间窗口，这将是很有趣的。(我假设您使用的是处理时间窗口，如果我错了，请纠正我。)

你知道一次有多少个不同的时间段是活动的吗？例如，12:00-12:05的窗口将接收许多时间戳在12:00-12:05范围内的事件，以及一些11:55-12:00的事件，这些事件在12:00之前没有到达。如果可能有那么多延迟，可能还有更早的时间范围的事件。如果不了解活动的按键空间是什么样子，就很难考虑按键偏差。