由于 state.checkpoints.num-retained 配置导致触发 Flink 检查点（S3 后端）延迟

Question

以下是我的 Flink 检查点配置，我们有 S3 作为后端。我们正在 EMR 集群中运行这个 flink 作业（版本：1.17.0）

checkpoint-interval : 70000
min-pause-between-checkpoint : 15000
max-concurrent-checkpoint : 1
checkpoint-type: unaligned
TolerableCheckpointFailureNumber :2
Checkpoint-mode : atleast-once
incremental-checkpointing: true
state.backend: filesystem
state.checkpoints.dir: s3p://checkpoint-sp-test/_entropy_/
s3.entropy.key: _entropy_
s3.entropy.length: 1
presto.s3.connect-timeout: 1m
presto.s3.socket-timeout: 1m
presto.s3.max-connections: 6500
state.checkpoints.num-retained: 3
high-availability.type: zookeeper

总作业并行度：5.5K

使用上述配置，理想情况下，flink 检查点应该每 70 秒间隔发生一次，但我发现每个检查点都有 5-20 分钟的触发延迟[附屏幕截图]。

我还能够找出导致这种延迟的原因。它是检查点阻塞删除流程，在每次检查点调用之前都会触发。此检查点删除流程由“state.checkpoints.num-retained”设置控制，如果我设置 state.checkpoints.num-retained= 6000000（任何大数字），则所有检查点每 70 秒间隔发生一次。我正在考虑的解决方案之一是在检查点存储桶中添加 S3 生命周期规则，以在 1 天后清理所有检查点。

上面的方法可以工作，但是将“state.checkpoints.num-retained”设置为非常大的数字会产生副作用。我看到了新职位经理选举的副作用。每当选举新的作业管理器时，它首先尝试获取在“state.checkpoints.num-retained”设置上配置的检查点数量。如果将其设置为大，它只是在努力获取无限数量的旧检查点，并且作业将永远无法启动。

任何解决此问题的建议将不胜感激！

Answer 1

首先，Flink 会定期删除旧的检查点以释放存储空间。此清理过程由 state.checkpoints.num-retained 设置控制。当您将其设置为非常大的数字时，Flink 将保留大量检查点，因此清理过程可能会花费很长时间，因为它需要检查并可能删除大量旧检查点。当选举出新的作业管理器时，需要恢复 Flink 作业的状态。这涉及从保留的检查点获取元数据和可能的一些数据以恢复状态。如果您将 state.checkpoints.num-retained 设置为非常大的数字，则作业管理器在恢复过程中可能会遇到困难，因为它必须处理大量检查点，这可能非常耗时且占用资源。

我建议您使用S3生命周期规则设置一个合理的数量，以便在一段时间后自动清理旧的检查点。