尽管在RocksDb中使用了增量检查点，但在处理过程中添加了一些托管状态后，我们发现检查点的大小和持续时间令人担忧地增长。
为了隔离问题，我们使用源，地图运算符和接收器创建了简单的拓扑。
源在内存中创建任意数量的事件，每秒吞吐量为1个事件。每个事件都有一个唯一的ID，该ID用于对流进行分区（使用keyBy运算符），并通过map函数将大约100kB的值添加到托管状态（使用ValueState）。然后将事件简单地传递到不执行任何操作的接收器。
使用上述设置，我们已发送了1200个事件，检查点间隔时间和最小暂停时间设置为5秒。由于事件以恒定的速度和相等的状态出现，因此我们期望检查点的大小或多或少是恒定的。但是，我们观察到检查点大小呈线性增长的峰值（最后一个峰值接近120MB，接近整个预期管理状态的大小），并且中间存在小的检查点。为了进行监控，我们使用了Flink和Prometheus与Grafana一起公开的指标，请参阅以下内容：检查点图表
我们想了解为什么我们会观察到CP峰值，为什么它们会持续增长？
是什么原因导致某些CP节省了预期的大小（大约500kB），而有些CP的大小大约是整个当前受管状态的大小，即使负载是恒定的？
使用增量检查点时，lastCheckpointSize度量标准精确测量了什么？
任何提示，解释将不胜感激，
提前致谢。
Flink的增量检查点需要（1）很好地扩展到非常大的状态，并且（2）允许从检查点进行还原是相当有效的，即使一次运行数周或数月后执行了数百万个检查点也是如此。特别是，有必要定期合并/合并较旧的检查点，以免最终无法尝试从无限制的检查点链中恢复到遥远的过去。这就是为什么即使在恒定负载下，您也会看到一些检查点比其他检查点做更多工作的原因。还要注意，在少量状态下进行测试（与某些Flink用户报告使用的10 TB以上的状态相比，120 MB很小，这种效果更明显）。
为了更详细地了解Flink的增量检查点的工作原理，建议您观看Flink Forward上Stefan Richter的演讲。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句