flink检查点时间与缓冲区对齐大小或对齐时间有何关系？

Question

现在我的疑虑是：

1）即使当少数检查点状态大小比其它检查点状态小（70-80%小）时，它也需要几分钟（15-20%的时间），而其它检查点状态则需要5-10秒。

2）缓冲区对齐大小有时会增加到7-8GB，而平均为800MB-1GB，但检查点时间不受此影响。我想它应该需要更多时间，因为它应该等待检查点屏障。

4）很少的子任务在hdfs中需要2-3分钟（5-10%的时间），所以98%的子任务在30-50秒内完成，而1-2个（95%的时间，只有一个）子任务需要2-3分钟，这延迟了整个检查点时间。问题不是在这个子任务运行的节点上，因为它有时发生在某个节点上，有时发生在另一个节点上。

5）我们每6-8小时会得到一次异常，这会重新启动作业。TimerException{java.nio.channels.closedByInterruptException}在org.apache.flink.streaming.runtime.tasks.SystemProcessingTimeService$TriggerTask.run（SystemProcessingTimeService.java:288)

6）如何最小化对齐缓冲时间。

7）保存点时间随输入速率或状态大小的增加或减少而增加或减少，但检查点时间并不相同，检查点时间有时与状态大小呈反比关系，或者可以看出它不受状态大小的影响。

8）当我们重新启动作业时，所有的子任务在所有节点上花费2-3天的时间是一致的，但是之后1-2个子任务花费2-3分钟，而其他的子任务花费15-30秒。我可能在这种行为上是错误的，但是据我观察，这也是一种情况。

Answer 1

请注意，窗口是有状态的，除非您正在进行增量聚合，否则较长的窗口具有更多的状态，这将反过来影响检查点大小和持续时间。

了解您使用的是哪种状态的后端，以及是否使用增量检查点将会很有帮助。

首先，我将尝试寻找导致背压的慢速下沉子任务的原因，而背压又会导致痛苦的检查点。例如，可能是数据偏斜或资源匮乏。一些常见的原因包括CPU、网络或磁盘带宽不足，或AWS（或其他API）速率限制。例如，看起来您有很多CPU，但是一个热键可能会给一个线程带来太多的负载，从而阻碍整个集群。