Flink 检查点间隔和状态大小

Question

我们正在运行一些 flink 作业，所有这些作业都有一个 kafka 源和多个 cassandra sink。我们严重依赖于带reduce 功能的时间窗口和键控数据。 我们的 tps 目前在 100-200 左右。 我有几个关于检查点和保存状态的大小的问题： 1. 由于我们使用reduce函数，状态大小是否仅受打开窗口数量的影响？如果每小时窗口和分钟窗口都具有相同的累加器，我们是否应该期望类似的状态大小？由于某种原因，看到每小时窗口的状态比分钟窗口大得多，而每日窗口的状态比每小时窗口大。 2. 什么是合理的开窗数量？什么被认为是一个大国？什么是最常见的检查点时间间隔（我们的时间间隔是 5 秒，这对我来说似乎太频繁了），对于 1 GB 的状态，我们应该期望检查点保存时间在合理的存储中占用多长时间？如何在合理的时间内检查 TB 的状态（我读过一些系统有）？我知道这些是抽象的问题，但不确定我们的 flink 设置是否按预期工作，以及随着数据的增长会发生什么。 3. 在 ui 中看到异步和同步检查点时间。谁能解释为什么flink同时使用两者？

感谢任何可以帮助解决任何问题的人。

Answer 1

有很多因素会影响检查点的性能，包括您正在运行的 Flink 版本、您使用的状态后端以及它是如何配置的，以及涉及哪种时间窗口（例如滑动窗口与翻滚窗口） ）。当涉及到状态 TB 时，增量检查点会产生巨大的影响。

影响很大的一个因素是不同时间间隔所涉及的不同键的数量。您已经指出这些是键控窗口，我预计在一个小时的过程中，使用的不同键比典型的一分钟内要多得多。当第一个事件被分配给它们时，窗口是惰性创建的，因此为一小时长的窗口创建的键控窗口比一分钟长的窗口要多得多。对于一整天的键控窗口也会产生同样的效果，但程度较轻。

您的每个作业的操作员在检查点处理期间都会经历一个（希望是短暂的）同步阶段，无论大部分检查点是同步还是异步完成的。使用基于堆的状态后端，同时支持同步和异步快照——您需要异步快照以获得最佳性能。