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

Question

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

为找出问题所在，我们使用源，地图运算符和接收器创建了简单的拓扑。

源在内存中创建任意数量的事件，每秒吞吐量为1个事件。每个事件都有唯一的ID，该ID用于对流进行分区（使用keyBy运算符），并通过map函数将大约100kB的值添加到托管状态（使用ValueState）。然后将事件简单地传递到不执行任何操作的接收器。

使用上述设置，我们已发送1200个事件，检查点间隔和最小暂停时间设置为5秒。由于事件以恒定的速度和相等的状态出现，因此我们期望检查点的大小或多或少是恒定的。但是，我们观察到检查点大小呈线性增长的峰值（最后一个峰值接近120MB，接近整个预期管理状态的大小），并且中间存在小的检查点。为了进行监控，我们使用了Flink和Prometheus与Grafana一起公开的指标，请参阅以下内容： checkpoint charts

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

是什么原因导致某些CP节省了预期的大小（大约500kB），有些甚至在负载恒定的情况下仍具有整个当前受管状态大小的大小？

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

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

谢谢。

Answer 1

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

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