Flink 1.10.1 中使用 RocksDB 状态后端的检查点问题

Question

我们的 Flink 工作遇到了一个非常难以观察的问题。

Job 相当简单，它：

1. 使用 Flink Kinesis 连接器从 Kinesis 读取消息
2. 对消息进行密钥处理并将它们分发给大约 30 个不同的 CEP 操作员，以及几个自定义的 WindowFunctions
3. 从 CEP/Windows 发出的消息被转发到将消息写入 SQS 的 SinkFunction

我们运行 Flink 1.10.1 Fargate，使用 2 个 4vCPU/8GB 的​​容器，我们使用 RocksDB 状态后端，配置如下：

state.backend: rocksdb
state.backend.async: true
state.backend.incremental: false
state.backend.rocksdb.localdir: /opt/flink/rocksdb
state.backend.rocksdb.ttl.compaction.filter.enabled: true
state.backend.rocksdb.files.open: 130048

该作业以 8 的并行度运行。

当作业从冷启动时，它使用很少的 CPU 并且检查点在 2 秒内完成。 随着时间的推移，检查点大小会增加，但时间仍然是非常合理的几秒钟：

在此期间，我们可以观察到 TaskManager 的 CPU 使用率由于某种原因而缓慢增长：

最终，检查点时间将开始飙升至几分钟，然后将开始重复超时（10 分钟）。 此时：

• 检查点大小（完成时）约为 60MB
• CPU 使用率很高，但不是 100%（通常在 60-80% 左右）
• 查看正在进行的检查点，通常 95% 以上的操作员在 30 秒内完成检查点，但少数会坚持下去并且永远不会完成。 SQS sink 将始终包含在其中，但SinkFunction并不丰富且没有状态。
• 在这些操作员上使用背压监视器会报告高背压

最终，这种情况可以通过以下两种方式之一解决：

1. 由于失败的检查点比例阈值，足够多的检查点无法触发作业失败
2. 检查点最终开始成功，但永远不会回到最初的 5-10 秒（当状态大小更像是 30MB 与 60MB 时）

我们真的不知道如何调试它。 与您在此处的某些问题中看到的那种状态相比，我们的状态似乎很小。 我们的数量也很低，我们经常低于 100 条记录/秒。

我们非常感谢您对我们可以研究的领域的任何输入以进行调试。

谢谢，

Answer 1

几点：

状态随着时间的推移逐渐增长并不罕见。 也许您的密钥空间正在增长，并且您正在为每个密钥保留一些状态。 如果您依赖状态 TTL 来使陈旧状态过期，那么它的配置方式可能无法像您预期的那样快速清除过期状态。 无意中创建 CEP 模式也相对容易，这些模式需要在排除某些可能的匹配之前长时间保持某种状态。

下一步是确定背压的原因。 最常见的原因是作业没有足够的资源。 随着时间的推移，随着管理的用户数量（例如）的增加，大多数作业逐渐需要更多资源。 例如，您可能需要增加并行度，或为实例提供更多内存，或增加接收器的容量（或连接到接收器的网络速度），或为 RocksDB 提供更快的磁盘。

除了供应不足外，其他导致背压的原因包括

• 阻塞 i/o 正在用户函数中完成
• 大量计时器同时触发
• 不同来源之间的事件时间偏差导致大量状态被缓冲
• 数据倾斜（一个热键）压倒了一个子任务或插槽
• 长时间的 GC 暂停
• 争用关键资源（例如，使用 NAS 作为 RocksDB 的本地磁盘）

启用RocksDB 本机指标可能会提供一些见解。

Answer 2

将此属性添加到您的配置中：

state.backend.rocksdb.checkpoint.transfer.thread.num: {threadNumberAccordingYourProjectSize}

如果你不添加这个，它将是 1（默认）

链接： https : //github.com/apache/flink/blob/master/flink-state-backends/flink-statebackend-rocksdb/src/main/java/org/apache/flink/contrib/streaming/state/RocksDBOptions。爪哇#L62