作者：LittleMagic
截至目前，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 記憶體托管。
State 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 配置中的參數名一并列出，用豎線分割。
-
write_buffer_size | state.backend.rocksdb.writebuffer.size
單個 memtable 的大小，預設是64MB。當 memtable 大小達到此門檻值時，就會被标記為不可變。一般來講，适當增大這個參數可以減小寫放大帶來的影響，但同時會增大 flush 後 L0、L1 層的壓力，是以還需要配合修改 compaction 參數，後面再提。
- max_write_buffer_number | state.backend.rocksdb.writebuffer.count
- 的最大數量（包含活躍的和不可變的），預設是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.blocksize
- 的大小，預設值為4KB。在生産環境中總是會适當調大一些，一般32KB比較合适，對于機械硬碟可以再增大到128~256KB，充分利用其順序讀取能力。但是需要注意，如果 block 大小增大而 block cache 大小不變，那麼緩存的 block 數量會減少，無形中會增加讀放大。
- block_cache_size | state.backend.rocksdb.block.cache-size
- cache 的大小，預設為8MB。由上文所述的讀寫流程可知，較大的 block cache 可以有效避免熱資料的讀請求落到 sstable 上，是以若記憶體餘量充足，建議設定到128MB甚至256MB，讀性能會有非常明顯的提升。
Tuning Compaction
compaction 在所有基于 LSM Tree 的存儲引擎中都是開銷最大的操作，弄不好的話會非常容易阻塞讀寫。建議看官先讀讀前面那篇關于 RocksDB 的 compaction 政策的文章，擷取一些背景知識，這裡不再贅述。
- compaction_style | state.backend.rocksdb.compaction.style
- 算法，使用預設的 LEVEL（即 leveled compaction）即可，下面的參數也是基于此。
-
target_file_size_base | state.backend.rocksdb.compaction.level.target-file-size-base
L1層單個 sstable 檔案的大小門檻值，預設值為64MB。每向上提升一級，門檻值會乘以因子 target_file_size_multiplier（但預設為1，即每級sstable最大都是相同的）。顯然，增大此值可以降低 compaction 的頻率，減少寫放大，但是也會造成舊資料無法及時清理，進而增加讀放大。此參數不太容易調整，一般不建議設為256MB以上。
-
max_bytes_for_level_base | state.backend.rocksdb.compaction.level.max-size-level-base
L1層的資料總大小門檻值，預設值為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 參數集（位于 PredefinedOptions 枚舉中）擷取更多資訊。
本文轉載自 LittleMagic 的部落格，原文連結：
https://www.jianshu.com/p/bc7309b03407更多 Flink 技術交流可掃碼加入社群釘釘大群。