Flink RocksDB状态后端优化总结

截至当前，Flink 作业的状态后端仍然只有 Memory、FileSystem 和 RocksDB 三种可选，且 RocksDB 是状态数据量较大（GB 到 TB 级别）时的唯一选择。RocksDB 的性能发挥非常仰赖调优，如果全部采用默认配置，读写性能有可能会很差。

但是，RocksDB 的配置也是极为复杂的，可调整的参数多达百个，没有放之四海而皆准的优化方案。如果仅考虑 Flink 状态存储这一方面，我们仍然可以总结出一些相对普适的优化思路。本文先介绍一些基础知识，再列举方法。

Note：本文的内容是基于我们在线上运行的 Flink 1.9 版本实践得出的。在1.10版本及以后，由于 TaskManager 内存模型重构，RocksDB 内存默认成为了堆外托管内存的一部分，可以免去一些手动调整的麻烦。如果性能仍然不佳，需要干预，则必须将 state.backend.rocksdb.memory.managed 参数设为 false 来禁用 RocksDB 内存托管。

Stae R/W on RocksDB

RocksDB 作为 Flink 状态后端时的读写逻辑与一般情况略有不同，如下图所示。

Flink 作业中的每一个注册的状态都对应一个列族（column family），即包含自己独立的 memtable 和 sstable 集合。写操作会先将数据写入活动 memtable，写满之后则会转换为不可变 memtable，并 flush 到磁盘中形成 sstable。读操作则会依次在活动 memtable、不可变 memtable、block cache 和 sstable 中寻找目标数据。另外，sstable 也需要通过 compaction 策略进行合并，最终形成分层的 LSM Tree 存储结构，老生常谈了。

特别地，由于 Flink 在每个检查点周期都会将 RocksDB 的数据快照持久化到文件系统，所以自然也就不需要再写预写日志（WAL）了，可以安全地关闭WAL与fsync。

之前笔者已经详细讲解过 RocksDB compaction 策略，并且提到了读放大、写放大和空间放大的概念，对 RocksDB 的调优本质上就是在这三个因子之间取得平衡。而在 Flink 作业这种注重实时性的场合，则要重点考虑读放大和写放大。

Tuning MemTable

memtable 作为 LSM Tree 体系里的读写缓存，对写性能有较大的影响。以下是一些值得注意的参数。为方便对比，下文都会将 RocksDB 的原始参数名与 Flink 配置中的参数名一并列出，用竖线分割。