我们正在运行一些flink作业，所有这些作业都有一个kafka源和多个cassandra接收器。我们在很大程度上依赖具有缩减功能的时间窗口以及关键数据。 目前，我们的销售点约为100-200。 我对检查点和所保存状态的大小有一些疑问： 1.由于我们使用的是reduce函数，状态大小是否仅受打开的窗口数的影响？如果一个小时窗口和一个分钟窗口都具有相同的累加器，那么我们应该期望类似的状态大小吗？由于某种原因，人们看到小时窗口的状态要比分钟窗口大得多，而每日窗口的状态要比小时窗口大。 2.被认为是合理数量的打开的窗户？什么被认为是大国？最常见的检查点时间间隔是多少（我们是5秒，这在我看来似乎太常见了），对于1 gb的状态，我们期望检查点将合理的存储时间节省多长时间？如何在合理的时间内检查状态TB（我读过某些系统的状态）？我知道这些是抽象的问题，但是不确定我们的flink设置是否按预期运行，以及随着数据的增长会发生什么。 3.在ui中同时看到异步和同步检查点时间。谁能解释为什么flink同时使用两者？
感谢任何可以帮助解决任何问题的人。
答案 0 :(得分：2)
有很多因素会影响检查点性能，包括运行的Flink版本，正在使用的状态后端以及如何配置它，以及涉及哪种类型的时间窗口（例如，滑动窗口与滚动窗口） ）。当涉及到TB的状态时，增量检查点可能会产生巨大的影响。
影响最大的一个因素是不同时间间隔所涉及的不同键的数量。您已经指出了这些是带键的窗口，并且我希望在一个小时的过程中，比典型的分钟要使用更多不同的键。当第一个事件分配给它们时，窗口是惰性创建的，因此，为一个小时的窗口创建的键控窗口将比为一分钟的窗口创建的键控窗口更多。对于为期一天的键控窗口，也会产生相同的效果，但程度较小。
您的每个作业操作员都将在检查点处理过程中经历一个（希望简短的）同步阶段，无论检查点的大部分是同步还是异步完成。借助基于堆的状态后端，支持同步和异步快照-您将需要异步快照以获得最佳性能。