Apache Flink-增量检查点-意外的CPs大小
源在内存中创建任意数量的事件，每秒吞吐量为1个事件。每个事件都有用于分区流的唯一id（使用keyBy运算符），并通过映射函数向托管状态（使用ValueState）添加约100KB。然后将事件简单地传递给不执行任何操作的接收器。
使用上面描述的设置，我们发送了1200个事件，检查点间隔和最小暂停设置为5秒。当事件以恒定的速度和相等的状态量出现时，我们期望检查点的大小或多或少是恒定的。然而，我们观察到检查点大小的线性增长峰值（最后一个峰值几乎为120MB，接近整个预期受管理状态的大小），其间有小检查点。对于监控，我们使用了Flink和Prometheus与Grafana曝光的度量，请看一些：检查点图表
我们想了解为什么我们观察到CPs峰值，为什么它们不断增长？
提前道谢。
共有1个答案
Flink的增量检查点需要（1）很好地扩展到非常大的状态，并且（2）允许从检查点恢复的效率相当高，即使在一次运行数周或数月之后执行数百万个检查点。特别是，有必要定期合并/合并旧的检查点，这样就不会最终试图从延伸到遥远过去的无界检查点链中恢复。这就是为什么您会看到一些检查点比其他检查点做更多的工作，即使在恒定负载下也是如此。还请注意，在使用少量状态进行测试时，这种影响更为明显（120 MB与一些Flink用户报告使用的10+TB状态相比很小）。
要更详细地了解Flink的增量检查点是如何工作的，我建议从Flink向前看Stefan Richter的谈话。
更新：
-
首先也是最重要的： null 现在，这项工作一直很好，直到上周，我们有一个激增（10倍以上）的流量。从那时候起，Flink变成了香蕉。检查点大小开始从500MB缓慢增长到20GB，检查点时间大约需要1分钟，并且随着时间的推移而增长。应用程序开始失败，并且永远无法完全恢复，事件迭代器的年龄增长也永远不会下降，因此没有新的事件被消耗。 因为我是一个新的闪现，我不确定我做滑动计数的方式是不是完全没有优化
-
我知道我们可以直接从左连接实现它，但由于一些限制，我们使用交叉连接，所以我需要走这条路... 请分享您的想法，欢迎提出建议 更新1我们没有使用关联，这就是为什么我们严格交叉连接。
-
null 我浏览了完整的flink仪表板，但我没有得到任何线索，如何检查是增量检查点正在发生还是完全检查点正在发生。请帮助我如何设置RocksDB的日志记录来了解增量检查点是否正在发生。我在文档中看到RocksDB日志记录会在性能和存储方面造成巨大的成本，这是为了测试目的，之后我将禁用它
-
我在我的Flink应用程序（版本1.11.1）中使用事件时语义，该应用程序运行在AWS-kinesis analytics中。此应用程序的源为kinesis stream，汇为Postgres。notifyCheckpointComplete（）上触发DB接收器时，检查点间隔为10秒。我正在使用多个协处理函数和ValueState连接不同的流，然后再将其放入Postgres。 观察到，检查点数据大
-
我有多个Kafka主题（多租户），我运行同一个作业运行多次基于主题的数量，每个作业消耗来自一个主题的消息。我已将文件系统配置为状态后端。 假设有3个作业正在运行。这里的检查站是如何工作的？这3个作业是否都将检查点信息存储在同一路径中？如果任何作业失败，该作业如何知道从何处恢复检查点信息？我们过去常常在向flink集群提交作业时提供作业名称。这和它有什么关系吗？一般来说，Flink如何区分作业及其检