Flink检查点不断失败

Question

我们正在尝试使用RocksDB后端设置Flink有状态作业。 我们正在使用会话窗口，间隔为30分钟。我们使用gregationFunction，因此不使用任何Flink状态变量。 通过采样，我们的事件数/秒少于20k，新会话数为20-30。我们的会议基本上收集了所有事件。会话累加器的大小会随着时间增加。 我们总共使用10G内存和Flink 1.9，128个容器。 以下是设置：

state.backend: rocksdb
state.checkpoints.dir: hdfs://nameservice0/myjob/path
state.backend.rocksdb.memory.managed: true
state.backend.incremental: true
state.backend.rocksdb.memory.write-buffer-ratio: 0.4
state.backend.rocksdb.memory.high-prio-pool-ratio: 0.1

containerized.heap-cutoff-ratio: 0.45
taskmanager.network.memory.fraction: 0.5
taskmanager.network.memory.min: 512mb
taskmanager.network.memory.max: 2560mb

根据我们对给定时间的监控， rocksdb的内存大小小于10m， 我们的堆使用量小于1G，但是我们的直接内存使用量（网络缓冲区）使用的是2.5G。缓冲池/缓冲区使用率指标均为1（满）。 我们的检查站不断失败， 我想知道网络缓冲区部分会耗尽这么多的内存是否正常？

如果您能提出建议，我将不胜感激：） 谢谢！

Answer 1

对于它的价值，会话窗口确实在内部使用Flink状态。 （大多数源和接收器也是如此。）这可能是性能问题，具体取决于您将会话事件收集到会话累加器中的方式。如果您需要将所有事件收集在一起，为什么要使用AggregateFunction而不是Flink来做到这一点？

为了获得最佳的开窗性能，您想使用ReduceFunction或AggregateFunction来逐步缩小/聚合窗口，只保留一小部分最终将成为窗口结果的状态。另一方面，如果仅使用ProcessWindowFunction而不进行预聚合，则Flink将在内部使用附加列表状态对象，该对象在与RocksDB一起使用时非常有效-只需序列化每个事件即可将其附加到末尾列表中。最终触发窗口时，列表将作为可迭代的Iterable交付给您，该Iterable将按块反序列化。另一方面，如果您使用AggregateFunction推出自己的解决方案，则可能会使RocksDB在每次访问/更新时反序列化和重新序列化累加器。这会变得非常昂贵，并可能解释检查点失败的原因。

您共享的另一个有趣的事实是，缓冲池/缓冲区使用率指标表明它们已被充分利用。这表明存在明显的背压，这反过来可以解释检查点为何失败。检查点依赖于检查点障碍能够遍历整个执行图，在每个操作员走动时对其进行检查并在超时之前完成作业的完整扫描。使用背压，这可能会失败。

最常见的背压原因是配置不足-换句话说，使群集不堪重负。网络缓冲池被充分利用，因为运营商无法跟上。答案不是增加缓冲，而是消除/修复瓶颈。