Flink RocksDB 状态后端参数调优实践 - 网站源码_资源分享

点选下方 “zhisheng隆哥蒙或首页一起高速成长

截至当前，Flink 工作台的状况前端依然只有 Memory、FileSystem 和 RocksDB 四种可选，且 RocksDB 是状况统计信息量较大（GB 到 TB 等级）时的惟一选择。RocksDB 的操控性充分发挥非常倚赖Listary，假如全部采用预设实用性，随机存取操控性有可能会极差。

但是，RocksDB 的实用性也是极其繁杂的，可修正的模块共约千个，没有此地无银三百两的强化计划。假如仅考虑 Flink 状况储存这另一方面，他们依然能归纳出许多相对基本概念的强化路子。责任编辑先介绍许多基本知识，再列出方法。Note：责任编辑的内容是如前所述我们新浪网上运行的 Flink 1.9 版课堂教学得出结论的。在1.10版及以后，虽然 TaskManager 缓存数学模型解构，RocksDB 缓存预设成为了堆外代销缓存的一部分，能褫夺许多全自动修正的麻烦事。如果操控性依然欠佳，须要干涉，则必须将 state.backend.rocksdb.memory.managed 模块标为 false 来停止使用 RocksDB 缓存代销。

State R/W on RocksDB

RocksDB 作为 Flink 状况前端时的随机存取方法论与一般情况大同小异，如下表所示图右图。 Flink RocksDB 状态后端参数调优实践

Flink 工作台中的每一个注册登记的状况都相关联一个列族（column family），即包涵自己独立的 memtable 和 sstable 子集。写操作方式林美珠将统计数据载入公益活动 memtable，刻下之后则会切换为不容变 memtable，并 flush 到硬盘中逐步形成 sstable。读操作方式则会依序在公益活动 memtable、不容变 memtable、block cache 和 sstable 中找寻目标统计数据。另外，sstable 也须要通过 compaction 策略进行分拆，最终逐步形成多层的 LSM Tree 储存结构，可有可无了。特别地，虽然 Flink 在每一回车周期性单厢将 RocksDB 的统计数据镜像长久Nozeroy硬盘，所以自然也就不须要再写预写日志（WAL）了，能安全地关闭WAL与fsync。之前笔者已经详细讲解过 RocksDB 的 compaction 策略，并且提到了读放大、写放大和空间放大的概念，对 RocksDB 的Listary本质上就是在这三个因子之间取得平衡。而在 Flink 工作台这种注重实时性的场合，则要重点考虑读放大和写放大。 Flink RocksDB 状态后端参数调优实践

Tuning MemTable

memtable 作为 LSM Tree 体系里的随机存取缓存，对写操控性有较大的影响。以下是许多值得注意的模块。为方便对比，下文单厢将 RocksDB 的原始模块名与 Flink 实用性中的模块名一并列出，用竖线分割。write_buffer_size | state.backend.rocksdb.writebuffer.size单个 memtable 的大小，预设是64MB。当 memtable 大小达到此阈值时，就会被标记为不容变。一般来讲，适当增大这个模块能减小写放大带来的影响，但同时会增大 flush 后 L0、L1 层的压力，所以还须要配合修改 compaction 模块，后面再提。max_write_buffer_number | state.backend.rocksdb.writebuffer.countmemtable 的最大数量（包涵活跃的和不容变的），预设是2。当全部 memtable 都刻下但是 flush 速度较慢时，就会造成写停顿，所以假如缓存充足或者使用的是机械硬盘，建议适当调大这个模块，如4。min_write_buffer_number_to_merge | state.backend.rocksdb.writebuffer.number-to-merge在 flush 发生之前被分拆的 memtable 最小数量，预设是1。举个例子，假如此模块标为2，那么当有至少两个不容变 memtable 时，才有可能触发 flush（亦即假如只有一个不容变 memtable，就会等待）。调大这个值的好处是能使更多的更改在 flush 前就被分拆，降低写放大，但同时又可能增加读放大，因为读取统计数据时要检查的 memtable 变多了。经测试，该模块标为2或3相对较好。

Tuning Block/Block Cache

block 是 sstable 的基本储存单位。block cache 则扮演读缓存的角色，采用 LRU 算法储存最近使用的 block，对读操控性有较大的影响。block_size | state.backend.rocksdb.block.blocksizeblock 的大小，预设值为4KB。在生产环境中总是会适当调大许多，一般32KB比较合适，对于机械硬盘能再增大到128~256KB，充分利用其顺序读取能力。但是须要注意，假如 block 大小增大而 block cache 大小不变，那么缓存的 block 数量会减少，无形中会增加读放大。block_cache_size | state.backend.rocksdb.block.cache-sizeblock cache 的大小，预标为8MB。由上文所述的随机存取流程可知，较大的 block cache 能有效避免热统计数据的读请求落到 sstable 上，所以若缓存余量充足，建议设置到128MB甚至256MB，读操控性会有非常明显的提升。

Tuning Compaction

compaction 在所有基compaction_style | state.backend.rocksdb.compaction.stylecompaction 算法，使用预设的 LEVEL（即 leveled compaction）即可，下面的模块也是如前所述此。target_file_size_base | state.backend.rocksdb.compaction.level.target-file-size-baseL1层单个 sstable 文件的大小阈值，预设值为64MB。每向上提升一级，阈值会乘以因子 target_file_size_multiplier（但预标为1，即每级sstable最大都是相同的）。显然，增大此值能降低 compaction 的频率，减少写放大，但是也会造成旧统计数据无法及时清理，从而增加读放大。此模块不太容易修正，一般不建议标为256MB以上。max_bytes_for_level_base | state.backend.rocksdb.compaction.level.max-size-level-baseL1层的统计数据总大小阈值，预设值为256MB。每向上提升一级，阈值会乘以因子 max_bytes_for_level_multiplier（预设值为10）。虽然上层的大小阈值都是以它为基础推算出来的，所以要小心修正。建议标为 target_file_size_base 的倍数，且不能太小，例如5~10倍。level_compaction_dynamic_level_bytes | state.backend.rocksdb.compaction.level.use-dynamic-size这个模块之前讲过。当开启之后，上述阈值的乘法因子会变成除法因子，能够动态修正每层的统计信息量阈值，使得较多的统计数据能落在最高一层，能够减少空间放大，整个 LSM Tree 的结构也会更稳定。对于机械硬盘的环境，强烈建议开启。

Generic Parameters

max_open_files | state.backend.rocksdb.files.open顾名思义，是 RocksDB 实例能够打开的最大文件数，预标为-1，表示不限制。虽然sstable的索引和布隆过滤器预设单厢驻留缓存，并占用文件描述符，所以假如此值太小，索引和布隆过滤器无法正常加载，就会严重拖累读取性能。max_background_compactions/max_background_flushes | state.backend.rocksdb.thread.num后台负责 flush 和 compaction 的最大并发线程数，预标为1。注意 Flink 将这两个模块合二为一处理（相关联 DBOptions.setIncreaseParallelism() 方法），鉴于 flush 和 compaction 都是相对重的操作方式，假如 CPU 余量比较充足，建议调大，在他们的课堂教学中一般标为4。

结语

除了上述设置模块的方法之外，用户还能通过实现 ConfigurableRocksDBOptionsFactory 接口，创建 DBOptions 和 ColumnFamilyOptions 实例来传入自定义模块，更加灵活许多。看官可参考 Flink 预先定义好的几个 RocksDB 模块集（

责任编辑转载自 LittleMagic 的博客，原文链接：

https://www.jianshu.com/p/bc7309b03407