Foreword
截至當(dāng)前，F(xiàn)link作業(yè)的狀態(tài)后端仍然只有Memory九昧、FileSystem和RocksDB三種可選，且RocksDB是狀態(tài)數(shù)據(jù)量較大（GB到TB級(jí)別）時(shí)的唯一選擇能曾。RocksDB的性能發(fā)揮非常仰賴調(diào)優(yōu)瘫里，如果全部采用默認(rèn)配置，讀寫性能有可能會(huì)很差卷扮。但是荡澎，RocksDB的配置也是極為復(fù)雜的，可調(diào)整的參數(shù)多達(dá)百個(gè)晤锹，沒有放之四海而皆準(zhǔn)的優(yōu)化方案摩幔。如果僅考慮Flink狀態(tài)存儲(chǔ)這一方面，我們?nèi)匀豢梢钥偨Y(jié)出一些相對(duì)普適的優(yōu)化思路鞭铆。本文先介紹一些基礎(chǔ)知識(shí)或衡，再列舉方法。
Note：本文的內(nèi)容是基于我們?cè)诰€上運(yùn)行的Flink 1.9版本實(shí)踐得出的车遂。在1.10版本及以后封断，由于TaskManager內(nèi)存模型重構(gòu)（傳送門），RocksDB內(nèi)存默認(rèn)成為了堆外托管內(nèi)存的一部分舶担，可以免去一些手動(dòng)調(diào)整的麻煩坡疼。如果性能仍然不佳，需要干預(yù)衣陶，則必須將
state.backend.rocksdb.memory.managed參數(shù)設(shè)為false來禁用RocksDB內(nèi)存托管柄瑰。
State R/W on RocksDB
RocksDB作為Flink狀態(tài)后端時(shí)的讀寫邏輯與一般情況略有不同，如下圖所示剪况。
Flink作業(yè)中的每一個(gè)注冊(cè)的狀態(tài)都對(duì)應(yīng)一個(gè)列族（column family）教沾，即包含自己獨(dú)立的memtable和sstable集合。寫操作會(huì)先將數(shù)據(jù)寫入活動(dòng)memtable译断，寫滿之后則會(huì)轉(zhuǎn)換為不可變memtable授翻，并flush到磁盤中形成sstable。讀操作則會(huì)依次在活動(dòng)memtable、不可變memtable堪唐、block cache和sstable中尋找目標(biāo)數(shù)據(jù)隆箩。另外，sstable也需要通過compaction策略進(jìn)行合并羔杨，最終形成分層的LSM Tree存儲(chǔ)結(jié)構(gòu)捌臊，老生常談了。
特別地兜材，由于Flink在每個(gè)檢查點(diǎn)周期都會(huì)將RocksDB的數(shù)據(jù)快照持久化到文件系統(tǒng)理澎，所以自然也就不需要再寫預(yù)寫日志（WAL）了，可以安全地關(guān)閉WAL與fsync曙寡。
之前筆者已經(jīng)詳細(xì)講解過RocksDB的compaction策略（傳送門）糠爬，并且提到了讀放大、寫放大和空間放大的概念举庶，對(duì)RocksDB的調(diào)優(yōu)本質(zhì)上就是在這三個(gè)因子之間取得平衡执隧。而在Flink作業(yè)這種注重實(shí)時(shí)性的場(chǎng)合，則要重點(diǎn)考慮讀放大和寫放大户侥。
Tuning MemTable
memtable作為L(zhǎng)SM Tree體系里的讀寫緩存镀琉，對(duì)寫性能有較大的影響。以下是一些值得注意的參數(shù)蕊唐。為方便對(duì)比屋摔，下文都會(huì)將RocksDB的原始參數(shù)名與Flink配置中的參數(shù)名一并列出，用豎線分割替梨。
write_buffer_size|state.backend.rocksdb.writebuffer.size
單個(gè)memtable的大小钓试，默認(rèn)是64MB。當(dāng)memtable大小達(dá)到此閾值時(shí)副瀑，就會(huì)被標(biāo)記為不可變弓熏。一般來講，適當(dāng)增大這個(gè)參數(shù)可以減小寫放大帶來的影響糠睡，但同時(shí)會(huì)增大flush后L0挽鞠、L1層的壓力，所以還需要配合修改compaction參數(shù)铜幽，后面再提滞谢。max_write_buffer_number|state.backend.rocksdb.writebuffer.count
memtable的最大數(shù)量（包含活躍的和不可變的），默認(rèn)是2除抛。當(dāng)全部memtable都寫滿但是flush速度較慢時(shí)，就會(huì)造成寫停頓母截，所以如果內(nèi)存充足或者使用的是機(jī)械硬盤到忽，建議適當(dāng)調(diào)大這個(gè)參數(shù)，如4。min_write_buffer_number_to_merge|state.backend.rocksdb.writebuffer.number-to-merge
在flush發(fā)生之前被合并的memtable最小數(shù)量喘漏，默認(rèn)是1护蝶。舉個(gè)例子，如果此參數(shù)設(shè)為2翩迈，那么當(dāng)有至少兩個(gè)不可變memtable時(shí)持灰，才有可能觸發(fā)flush（亦即如果只有一個(gè)不可變memtable，就會(huì)等待）负饲。調(diào)大這個(gè)值的好處是可以使更多的更改在flush前就被合并堤魁，降低寫放大，但同時(shí)又可能增加讀放大返十，因?yàn)樽x取數(shù)據(jù)時(shí)要檢查的memtable變多了妥泉。經(jīng)測(cè)試，該參數(shù)設(shè)為2或3相對(duì)較好洞坑。
Tuning Block/Block Cache
block是sstable的基本存儲(chǔ)單位盲链。block cache則扮演讀緩存的角色，采用LRU算法存儲(chǔ)最近使用的block迟杂，對(duì)讀性能有較大的影響刽沾。
block_size|state.backend.rocksdb.block.blocksize
block的大小，默認(rèn)值為4KB排拷。在生產(chǎn)環(huán)境中總是會(huì)適當(dāng)調(diào)大一些悠轩，一般32KB比較合適，對(duì)于機(jī)械硬盤可以再增大到128~256KB攻泼，充分利用其順序讀取能力火架。但是需要注意，如果block大小增大而block cache大小不變忙菠，那么緩存的block數(shù)量會(huì)減少何鸡，無形中會(huì)增加讀放大。block_cache_size|state.backend.rocksdb.block.cache-size
block cache的大小牛欢，默認(rèn)為8MB骡男。由上文所述的讀寫流程可知，較大的block cache可以有效避免熱數(shù)據(jù)的讀請(qǐng)求落到sstable上傍睹，所以若內(nèi)存余量充足隔盛，建議設(shè)置到128MB甚至256MB，讀性能會(huì)有非常明顯的提升拾稳。
Tuning Compaction
compaction在所有基于LSM Tree的存儲(chǔ)引擎中都是開銷最大的操作吮炕，弄不好的話會(huì)非常容易阻塞讀寫。建議看官先讀讀前面那篇關(guān)于RocksDB的compaction策略的文章访得，獲取一些背景知識(shí)龙亲，這里不再贅述陕凹。
compaction_style|state.backend.rocksdb.compaction.style
compaction算法，使用默認(rèn)的LEVEL（即leveled compaction）即可鳄炉，下面的參數(shù)也是基于此杜耙。target_file_size_base|state.backend.rocksdb.compaction.level.target-file-size-base
L1層單個(gè)sstable文件的大小閾值，默認(rèn)值為64MB拂盯。每向上提升一級(jí)佑女，閾值會(huì)乘以因子target_file_size_multiplier（但默認(rèn)為1，即每級(jí)sstable最大都是相同的）谈竿。顯然团驱，增大此值可以降低compaction的頻率，減少寫放大榕订，但是也會(huì)造成舊數(shù)據(jù)無法及時(shí)清理店茶，從而增加讀放大。此參數(shù)不太容易調(diào)整劫恒，一般不建議設(shè)為256MB以上贩幻。max_bytes_for_level_base|state.backend.rocksdb.compaction.level.max-size-level-base
L1層的數(shù)據(jù)總大小閾值，默認(rèn)值為256MB两嘴。每向上提升一級(jí)丛楚，閾值會(huì)乘以因子max_bytes_for_level_multiplier（默認(rèn)值為10）。由于上層的大小閾值都是以它為基礎(chǔ)推算出來的憔辫，所以要小心調(diào)整趣些。建議設(shè)為target_file_size_base的倍數(shù)，且不能太小贰您，例如5~10倍坏平。level_compaction_dynamic_level_bytes|state.backend.rocksdb.compaction.level.use-dynamic-size
這個(gè)參數(shù)之前講過。當(dāng)開啟之后锦亦，上述閾值的乘法因子會(huì)變成除法因子舶替，能夠動(dòng)態(tài)調(diào)整每層的數(shù)據(jù)量閾值，使得較多的數(shù)據(jù)可以落在最高一層杠园，能夠減少空間放大顾瞪，整個(gè)LSM Tree的結(jié)構(gòu)也會(huì)更穩(wěn)定。對(duì)于機(jī)械硬盤的環(huán)境抛蚁，強(qiáng)烈建議開啟陈醒。
Generic Parameters
max_open_files|state.backend.rocksdb.files.open
顧名思義，是RocksDB實(shí)例能夠打開的最大文件數(shù)瞧甩，默認(rèn)為-1钉跷，表示不限制。由于sstable的索引和布隆過濾器默認(rèn)都會(huì)駐留內(nèi)存亲配，并占用文件描述符尘应，所以如果此值太小惶凝，索引和布隆過濾器無法正常加載吼虎，就會(huì)嚴(yán)重拖累讀取性能犬钢。max_background_compactions/max_background_flushes|state.backend.rocksdb.thread.num
后臺(tái)負(fù)責(zé)flush和compaction的最大并發(fā)線程數(shù)，默認(rèn)為1思灰。注意Flink將這兩個(gè)參數(shù)合二為一處理（對(duì)應(yīng)DBOptions.setIncreaseParallelism()方法）玷犹，鑒于flush和compaction都是相對(duì)重的操作，如果CPU余量比較充足洒疚，建議調(diào)大歹颓，在我們的實(shí)踐中一般設(shè)為4船惨。
The End
除了上述設(shè)置參數(shù)的方法之外烈菌，用戶還可以通過實(shí)現(xiàn)ConfigurableRocksDBOptionsFactory接口棵癣，創(chuàng)建DBOptions和ColumnFamilyOptions實(shí)例來傳入自定義參數(shù)瓢对，更加靈活一些搀暑≡┒郑看官可參考Flink預(yù)先定義好的幾個(gè)RocksDB參數(shù)集（位于PredefinedOptions枚舉中）獲取更多信息啸驯。
寫得有點(diǎn)亂了傲隶，民那晚安晚安喊括。
