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

时间:2018-10-31 10:48:19

标签: apache-flink

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

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

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

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

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

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

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

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

谢谢。

1 个答案:

答案 0 :(得分:0)

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

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