到目前为止，Flink作业的状态后台只有三个选项:内存、文件系统和RocksDB，当状态数据较大(GB到TB)时，RocksDB是唯一的选项。 RocksDB的性能依赖于调优。如果采用默认配置，读写性能可能会很差。 但是RocksDB的配置极其复杂，可调参数多达数百个，没有通用的优化方案。 如果只考虑Flink状态存储这方面，还是可以总结出几个比较通用的优化思路。 本文先详细介绍一点基础知识，然后列举方法。 注:本文内容基于我们对Flink版本上线运行的实践。 在1.10及以后的版本中，由于TaskManager内存模型的重新配置，RocksDB内存默认成为了堆外托管内存的一部分，可以省去一点手动调整的麻烦。 如果性能仍然很差并且需要干预，则必须通过设置状态来禁用RocksDB内存托管。backend.rocksdb.memory.managed参数设置为false。 作为Flink状态背景的RocksDBRocksDB上状态R/W的读写逻辑与一般情况略有不同，如下图所示。 Flink job中的每个注册状态对应一个列族，即包含自己独立的memtable和sstable集合。 写操作会先把数据写到活动的memtable中，然后在它满了之后会转换成不可变的memtable，并刷新到磁盘中形成一个sstable。 读操作会依次在活动memtable、不可变memtable、块缓存和sstable中寻找目标数据。 另外，sstable还需要通过压缩策略进行合并，最终形成分层的LSM树存储结构，这是老生常谈了。 尤其是因为Flink会在每个检查点周期将RocksDB的数据快照持久化到文件系统中，自然就不需要写预写日志(WAL)，WAL和fsync可以安全关闭。 笔者之前已经详细解释过RocksDB的压缩策略，提到了读放大、写放大和空间放大的概念。RocksDB的调优本质上就是要在这三个因素之间取得平衡。 但是当Flink是实时工作的时候，我们要重点关注读放大和写放大。 TunmemtableMemtable作为LSM树系统中的读写缓存，对写性能有很大的影响。 以下是一些值得注意的参数 为了方便比较，RocksDB的原始参数名会和Flink配置中的参数名一起列出，用竖线隔开。 write _ buffer _ size | state . back end . rocksdb . write buffer . size单个memtable的大小默认为64MB。 当memtable大小达到这个阈值时，它被标记为不可变的。 一般来说，适当增加这个参数可以减少写放大的影响，但同时会增加冲洗后L0和L1层的压力，所以需要修改压缩参数，后面会提到。 max _ write _ buffer _ number | state . back end . rocksdb . write buffer . count mem tables的最大数量(包括活动的和不可变的)，默认为2。 当所有memtable已满，但刷新速度较慢时，会导致写暂停。所以如果内存足够或者用户使用的是机械硬盘，建议适当增加这个参数，比如4。 min _ write _ buffer _ number _ to _ merge | state . back end . rocksdb . write buffer . number-to-merge刷新发生前合并的memtable的最小数目，默认情况下为1。 例如，如果这个参数设置为2，那么当至少有两个不可变的memtable时，就有可能触发flush(也就是说，如果只有一个不可变的mem table，它将等待)。 增加该值的好处是，在刷新之前可以合并更多的更改，从而减少写入放大，但同时也可以增加读取放大，因为读取数据时需要检查更多的memtable。 经过测试，这个参数设置为2或3比较好。 调优块/块Cacheblock是sstable的基本存储单位。 块缓存起到读缓存的作用，使用LRU算法存储最近使用的块，对读性能影响很大。 block _ size | state . back end . rocksdb . block . block size块的大小，默认值为4KB。 在生产环境中，总会调整到很小的量。一般32KB比较合适，对于机械硬盘可以提高到128~256KB，充分利用其顺序读取能力。 但需要注意的是，如果在块缓存大小保持不变的情况下，块大小增加，缓存的块数会减少，这必然会增加读取放大。 block _ cache _ size | state . back end . rocksdb . block . cache-size块缓存的大小，默认情况下为8MB。 从上述读写过程可以看出，较大的块缓存可以有效防止热数据读请求落在sstable上。因此，如果内存余量足够，建议设置为128MB甚至256MB，这样会显著提高读取性能。 Tun compaction压缩是所有基于LSM树的存储引擎中开销最大的操作，做不好很容易阻塞读写。 建议读者先看前面关于RocksDB的压缩策略的文章，了解一点背景知识，这里就不赘述了。 compression _ style | state . back end . rocksdb . compression . style压缩算法，就用默认的级别(即分级压缩)即可，后面的参数也是基于此。 target _ file _ size _ base | state . back end . rocksdb . compression . level . target-file-size-base L1层中单个表文件的大小阈值，默认值为64MB。 每向上一级，阈值将乘以因子target_file_size_multiplier(但默认值为1，即每一级的sstable最多相同)。 显然，增加这个值可以减少压缩的频率，减少写放大，但也会造成旧数据不能及时清除，从而增加读放大。 这个参数不好调整，一般不建议设置在256MB以上。 max _ bytes _ for _ level _ base | state . back end . rocksdb . compression . level . max-size-level-base L1数据总大小阈值，默认值为256MB。 每升一级，阈值乘以系数max_bytes_for_level_multiplier(默认值为10)。 因为上层的大小阈值是基于它计算的，所以应该仔细调整。 建议设置为target_file_size_base的倍数，不能太小，比如5~10倍。 参数level _ compression _ dynamic _ level _ bytes | state . back end . rocksdb . compression . level . use-dynamic-size之前已经提到过。 开启时，上述阈值的乘法因子会变成除法因子，可以动态调整各层的数据量阈值，让更多的数据落在最高层，可以减少空间放大，让整个LSM树结构更加稳定。 对于机械硬盘的环境，强烈建议开启。 泛型参数max _ open _ files | state . back end . RocksDB . files . open，顾名思义，就是rocks db的一个实例可以打开的最大文件数。默认值为-1，表示没有限制。 因为sstable的索引和bloom filter默认情况下都会驻留在内存中，并且会占用文件描述符，如果值太小，索引和bloom filter将无法正常加载，严重拖累读取性能。 max _ background _ compaction/max _ background _ flushes | state . back end . rocks db . thread . num后端中负责刷新和压缩的最大并发线程数默认为1。 注意Flink将这两个参数组合成一个解(对应dboptions . setincreaseparallelism()方法)。由于flush和compaction都是比较繁重的操作，如果CPU余量足够，建议增加，在我们的实践中一般设置为4。 结论除了以上设置参数的方法，客户还可以通过实现可配置的RocksdBoptions工厂接口，创建dBoptions和ColumnFamilyOptions实例，导入自己的设置参数，更加灵活，也更少。 读者可以参考Flink的几个预定义的RocksDB参数集(在PredefinedOptions枚举中)了解更多信息。 本文转载自LittleMagic的博客，参考链接:https://www.jianshu.com/p/bc7309b03407