Flink RocksDB 狀態(tài)后端參數(shù)調優(yōu)的示例分析

這篇文章將為大家詳細講解有關Flink RocksDB 狀態(tài)后端參數(shù)調優(yōu)的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

截至當前，F(xiàn)link 作業(yè)的狀態(tài)后端仍然只有 Memory、FileSystem 和 RocksDB 三種可選，且 RocksDB 是狀態(tài)數(shù)據(jù)量較大（GB 到 TB 級別）時的唯一選擇。RocksDB 的性能發(fā)揮非常仰賴調優(yōu)，如果全部采用默認配置，讀寫性能有可能會很差。

但是，RocksDB 的配置也是極為復雜的，可調整的參數(shù)多達百個，沒有放之四海而皆準的優(yōu)化方案。如果僅考慮 Flink 狀態(tài)存儲這一方面，我們仍然可以總結出一些相對普適的優(yōu)化思路。本文先介紹一些基礎知識，再列舉方法。

**Note：**本文的內容是基于我們在線上運行的 Flink 1.9 版本實踐得出的。在1.10版本及以后，由于 TaskManager 內存模型重構，RocksDB 內存默認成為了堆外托管內存的一部分，可以免去一些手動調整的麻煩。如果性能仍然不佳，需要干預，則必須將 state.backend.rocksdb.memory.managed 參數(shù)設為 false 來禁用 RocksDB 內存托管。

State R/W on RocksDB

RocksDB 作為 Flink 狀態(tài)后端時的讀寫邏輯與一般情況略有不同，如下圖所示。

Flink 作業(yè)中的每一個注冊的狀態(tài)都對應一個列族（column family），即包含自己獨立的 memtable 和 sstable 集合。寫操作會先將數(shù)據(jù)寫入活動 memtable，寫滿之后則會轉換為不可變 memtable，并 flush 到磁盤中形成 sstable。讀操作則會依次在活動 memtable、不可變 memtable、block cache 和 sstable 中尋找目標數(shù)據(jù)。另外，sstable 也需要通過 compaction 策略進行合并，最終形成分層的 LSM Tree 存儲結構，老生常談了。

特別地，由于 Flink 在每個檢查點周期都會將 RocksDB 的數(shù)據(jù)快照持久化到文件系統(tǒng)，所以自然也就不需要再寫預寫日志（WAL）了，可以安全地關閉WAL與fsync。

之前筆者已經詳細講解過 RocksDB 的 compaction 策略，并且提到了讀放大、寫放大和空間放大的概念，對 RocksDB 的調優(yōu)本質上就是在這三個因子之間取得平衡。而在 Flink 作業(yè)這種注重實時性的場合，則要重點考慮讀放大和寫放大。

Tuning MemTable

memtable 作為 LSM Tree 體系里的讀寫緩存，對寫性能有較大的影響。以下是一些值得注意的參數(shù)。為方便對比，下文都會將 RocksDB 的原始參數(shù)名與 Flink 配置中的參數(shù)名一并列出，用豎線分割。

• write_buffer_size | state.backend.rocksdb.writebuffer.size 單個 memtable 的大小，默認是64MB。當 memtable 大小達到此閾值時，就會被標記為不可變。一般來講，適當增大這個參數(shù)可以減小寫放大帶來的影響，但同時會增大 flush 后 L0、L1 層的壓力，所以還需要配合修改 compaction 參數(shù)，后面再提。

• max_write_buffer_number | state.backend.rocksdb.writebuffer.count memtable 的最大數(shù)量（包含活躍的和不可變的），默認是2。當全部 memtable 都寫滿但是 flush 速度較慢時，就會造成寫停頓，所以如果內存充足或者使用的是機械硬盤，建議適當調大這個參數(shù)，如4。

• min_write_buffer_number_to_merge | state.backend.rocksdb.writebuffer.number-to-merge 在 flush 發(fā)生之前被合并的 memtable 最小數(shù)量，默認是1。舉個例子，如果此參數(shù)設為2，那么當有至少兩個不可變 memtable 時，才有可能觸發(fā) flush（亦即如果只有一個不可變 memtable，就會等待）。調大這個值的好處是可以使更多的更改在 flush 前就被合并，降低寫放大，但同時又可能增加讀放大，因為讀取數(shù)據(jù)時要檢查的 memtable 變多了。經測試，該參數(shù)設為2或3相對較好。

Tuning Block/Block Cache

block 是 sstable 的基本存儲單位。block cache 則扮演讀緩存的角色，采用 LRU 算法存儲最近使用的 block，對讀性能有較大的影響。

• block_size | state.backend.rocksdb.block.blocksize block 的大小，默認值為4KB。在生產環(huán)境中總是會適當調大一些，一般32KB比較合適，對于機械硬盤可以再增大到128~256KB，充分利用其順序讀取能力。但是需要注意，如果 block 大小增大而 block cache 大小不變，那么緩存的 block 數(shù)量會減少，無形中會增加讀放大。

• block_cache_size | state.backend.rocksdb.block.cache-size block cache 的大小，默認為8MB。由上文所述的讀寫流程可知，較大的 block cache 可以有效避免熱數(shù)據(jù)的讀請求落到 sstable 上，所以若內存余量充足，建議設置到128MB甚至256MB，讀性能會有非常明顯的提升。

Tuning Compaction

compaction 在所有基于 LSM Tree 的存儲引擎中都是開銷最大的操作，弄不好的話會非常容易阻塞讀寫。建議看官先讀讀前面那篇關于 RocksDB 的 compaction 策略的文章，獲取一些背景知識，這里不再贅述。

• compaction_style | state.backend.rocksdb.compaction.style compaction 算法，使用默認的 LEVEL（即 leveled compaction）即可，下面的參數(shù)也是基于此。

• target_file_size_base | state.backend.rocksdb.compaction.level.target-file-size-base L1層單個 sstable 文件的大小閾值，默認值為64MB。每向上提升一級，閾值會乘以因子 target_file_size_multiplier（但默認為1，即每級sstable最大都是相同的）。顯然，增大此值可以降低 compaction 的頻率，減少寫放大，但是也會造成舊數(shù)據(jù)無法及時清理，從而增加讀放大。此參數(shù)不太容易調整，一般不建議設為256MB以上。

• max_bytes_for_level_base | state.backend.rocksdb.compaction.level.max-size-level-base L1層的數(shù)據(jù)總大小閾值，默認值為256MB。每向上提升一級，閾值會乘以因子 max_bytes_for_level_multiplier（默認值為10）。由于上層的大小閾值都是以它為基礎推算出來的，所以要小心調整。建議設為 target_file_size_base 的倍數(shù)，且不能太小，例如5~10倍。

• level_compaction_dynamic_level_bytes | state.backend.rocksdb.compaction.level.use-dynamic-size 這個參數(shù)之前講過。當開啟之后，上述閾值的乘法因子會變成除法因子，能夠動態(tài)調整每層的數(shù)據(jù)量閾值，使得較多的數(shù)據(jù)可以落在最高一層，能夠減少空間放大，整個 LSM Tree 的結構也會更穩(wěn)定。對于機械硬盤的環(huán)境，強烈建議開啟。

Generic Parameters

• max_open_files | state.backend.rocksdb.files.open 顧名思義，是 RocksDB 實例能夠打開的最大文件數(shù)，默認為-1，表示不限制。由于sstable的索引和布隆過濾器默認都會駐留內存，并占用文件描述符，所以如果此值太小，索引和布隆過濾器無法正常加載，就會嚴重拖累讀取性能。

• max_background_compactions/max_background_flushes | state.backend.rocksdb.thread.num 后臺負責 flush 和 compaction 的最大并發(fā)線程數(shù)，默認為1。注意 Flink 將這兩個參數(shù)合二為一處理（對應 DBOptions.setIncreaseParallelism() 方法），鑒于 flush 和 compaction 都是相對重的操作，如果 CPU 余量比較充足，建議調大，在我們的實踐中一般設為4。

關于“Flink RocksDB 狀態(tài)后端參數(shù)調優(yōu)的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。