我的流媒体flink作业的检查点时间平均为2-3s（15-20％的时间）和3-4分钟（8-12％的时间），平均2分钟。我们有两个有状态的运算符。首先是kafka使用者作为源（FlinkKafkaConsumer010），另一个是hdfs接收器（CustomBucketingSink）。这两个保存点的状态约为1-1.5Gb，检查点的状态为800mb-6Gb（平均3gb）。我们有30秒的滚动处理窗口。检查点持续时间和两次检查之间的最小间隔为3分钟。我的工作平均每分钟消耗约300万条记录，高峰时间平均消耗约2000万/分钟的记录。 clink和内存足以容纳flink。
现在这是我的疑问：
1]即使与其他检查点状态相比，很少有检查点状态大小更小（减少70-80％），与其他检查点状态相比，也要花费数分钟（15-20％的时间）。这需要5-10秒。 >
2）与平均800mb-1gb相比，缓冲区对齐大小有时会增加到7-8gb，但检查点时间不受此影响。我猜应该花更多的时间，因为它应该等待检查点障碍。
3）如果增加滚动窗口的大小，会影响响应时间。我认为它不应该影响保存点时间和检查点时间。
4）陷入hdfs的子任务很少需要2-3分钟（5-10％的时间）。因此，尽管98％的子任务在30-50秒内完成。 1-2（95％的时间，只有一个）子任务需要2-3分钟。这会延迟整个检查点时间。问题不在运行此子任务的节点上，因为它有时发生在某个节点上，有时发生在另一个节点上。
5）我们每6-8个小时遇到一次异常，这会重新启动工作。 org.apache.flink.streaming.runtime.tasks.SystemProcessingTimeService $ TriggerTask.run（SystemProcessingTimeService.java:288）上的TimerException {java.nio.channels.ClosedByInterruptException}
6）如何最小化对齐缓冲时间。
7）保存点时间随着输入速率或状态大小的增加或减少而增加或减少，但是检查点时间并不相同。检查点时间有时与状态大小成反比关系，或者我们可以看到它不受状态大小的影响。
8）每当我们重新启动作业时，所有子任务在所有节点上花费2-3天的统一时间，但之后1-2个子任务则花费2-3分钟，而其他子任务则花费15-30秒。我可能在这种行为上是错误的，但据我观察，这也是一种情况。
我的流媒体flink作业的检查点时间平均为2-3s（15-20％的时间）和3-4分钟（8-12％的时间），平均2分钟。我们有两个有状态的运算符。首先是kafka消费者作为来源（...
请注意，窗口是有状态的，除非进行增量聚合，否则较长的窗口将具有更多状态，这反过来会影响检查点的大小和持续时间。
知道您使用的是哪个状态后端，以及是否使用增量检查点将很有帮助。