Apache Flink - 增量检查点 - CP 的意外大小

Question

在处理过程中添加一些托管状态后，尽管使用 RocksDb 的增量检查点，但我们发现检查点的大小和持续时间令人担忧地增长。

为了隔离问题，我们使用源、地图运算符和接收器创建了简单的拓扑。

源在内存中以每秒 1 个事件的吞吐量创建任意数量的事件。每个事件都有唯一的 id，用于分区流（使用 keyBy 运算符）并通过 map 函数，该函数将大约 100kB 增加到托管状态（使用 ValueState）。然后将事件简单地传递给什么都不做的接收器。

使用上述设置，我们发送了 1200 个事件，检查点间隔和最小暂停设置为 5 秒。由于事件以恒定的速度和等量的状态出现，我们预计检查点的大小或多或少是恒定的。然而，我们观察到检查点大小的峰值呈线性增长（最后一个峰值几乎为 120MB，接近整个预期托管状态的大小），中间有小检查点。对于监控，我们使用了 Flink 和 Prometheus 与 Grafana 公开的指标，请参阅： checkpoint charts

我们想了解为什么我们会观察到 CP 峰值以及为什么它们会不断增长？

是什么原因导致一些 CP 节省了预期的大小（大约 500kB），而一些 CP 的大小却在整个当前托管状态大小附近，即使负载是恒定的？

使用增量检查点时，lastCheckpointSize 指标究竟测量了什么？

任何提示，解释将不胜感激，

提前致谢。

Answer 1

Flink 的增量检查点需要 (1) 很好地扩展到非常大的状态，并且 (2) 允许从检查点恢复相当有效，即使在一次运行数周或数月后执行数百万个检查点之后也是如此。特别是，有必要定期合并/合并较旧的检查点，以免最终尝试从无限的检查点链恢复到遥远的过去。这就是为什么你会看到一些检查点比其他检查点做更多的工作，即使在恒定负载下也是如此。另请注意，在使用少量状态进行测试时，这种效果会更加明显（与一些 Flink 用户报告的 10+ TB 状态相比，120 MB 很小）。

要更详细地了解 Flink 的增量检查点如何工作，我建议观看 Stefan Richter's talk from Flink Forward。

更新：

对于那些更熟悉 RocksDB 的人来说，问题是 RocksDB 压缩对某些检查点的影响会比其他检查点更大，并且对于小状态，可能只会很少发生。