我正在使用Flink Kubernetes Operator在Kubernetes集群中运行Flink作业，并行度为3。作业中的每个操作员维护大约140 MB的平均状态大小。但是，当我在作业重新启动期间尝试从S3恢复400 MB的保存点时，遇到了严重的延迟。
鉴于Flink在具有S3存储的Kubernetes环境中的设置，我正在寻求如何有效快速地从保存点恢复状态的建议。
具体而言，我想谈谈以下几点：
用于加速在Kubernetes集群中运行的Flink作业的恢复过程的策略和优化，该作业具有多个并行度和大约140 MB的操作符状态。建议在Flink Kubernetes Operator或Flink配置中进行配置或调整，以提高S3的保存点恢复性能。任何最佳实践或Kubernetes特定的注意事项，可以帮助减少恢复状态和简化作业重启所需的时间。如果您在Kubernetes环境中运行Flink以及处理S3的保存点恢复方面有经验或见解，我将非常感谢您的宝贵建议。谢谢你，谢谢！
1条答案
按热度按时间a5g8bdjr1#
根据您获取保存点的原因，您可以通过使用更有效的状态快照类型来加快重新启动过程。Flink文档中的这张表列出了针对您可能正在执行的不同操作任务的4种类型的快照，并解释了哪些快照类型支持这些不同的操作。
规范保存点是最灵活的格式，但恢复起来更昂贵（假设您使用的是RocksDB状态后端）。这是因为RocksDB SST文件必须从保存点中存储的数据重建。如果您可以使用本机保存点，它应该更快，可能快得多。
另一种加快重启速度的方法是使用 * 任务本地恢复 *。我还没有尝试在Kubernetes上实现这一点，但请参阅 * 在Pod重启时启用本地恢复 * 上的文档。
免责声明：我不熟悉Flink Kubernetes Operator如何实现这些操作，或者如何配置它。它可能支持也可能不支持我的建议。