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

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

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名與空間、網(wǎng)絡(luò)空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、富縣網(wǎng)站維護(hù)、網(wǎng)站推廣。

截至當(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)配置，讀寫(xiě)性能有可能會(huì)很差。

但是，RocksDB 的配置也是極為復(fù)雜的，可調(diào)整的參數(shù)多達(dá)百個(gè)，沒(méi)有放之四海而皆準(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 來(lái)禁用 RocksDB 內(nèi)存托管。

State R/W on RocksDB

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

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

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

之前筆者已經(jīng)詳細(xì)講解過(guò) RocksDB 的 compaction 策略，并且提到了讀放大、寫(xiě)放大和空間放大的概念，對(duì) RocksDB 的調(diào)優(yōu)本質(zhì)上就是在這三個(gè)因子之間取得平衡。而在 Flink 作業(yè)這種注重實(shí)時(shí)性的場(chǎng)合，則要重點(diǎn)考慮讀放大和寫(xiě)放大。

Tuning MemTable

memtable 作為 LSM Tree 體系里的讀寫(xiě)緩存，對(duì)寫(xiě)性能有較大的影響。以下是一些值得注意的參數(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)記為不可變。一般來(lái)講，適當(dāng)增大這個(gè)參數(shù)可以減小寫(xiě)放大帶來(lái)的影響，但同時(shí)會(huì)增大 flush 后 L0、L1 層的壓力，所以還需要配合修改 compaction 參數(shù)，后面再提。
max_write_buffer_number | state.backend.rocksdb.writebuffer.count memtable 的最大數(shù)量（包含活躍的和不可變的），默認(rèn)是2。當(dāng)全部 memtable 都寫(xiě)滿但是 flush 速度較慢時(shí)，就會(huì)造成寫(xiě)停頓，所以如果內(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 前就被合并，降低寫(xiě)放大，但同時(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ì)減少，無(wú)形中會(huì)增加讀放大。
block_cache_size | state.backend.rocksdb.block.cache-size block cache 的大小，默認(rèn)為8MB。由上文所述的讀寫(xiě)流程可知，較大的 block cache 可以有效避免熱數(shù)據(jù)的讀請(qǐng)求落到 sstable 上，所以若內(nèi)存余量充足，建議設(shè)置到128MB甚至256MB，讀性能會(huì)有非常明顯的提升。

Tuning Compaction

compaction 在所有基于 LSM Tree 的存儲(chǔ)引擎中都是開(kāi)銷最大的操作，弄不好的話會(huì)非常容易阻塞讀寫(xiě)。建議看官先讀讀前面那篇關(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 的頻率，減少寫(xiě)放大，但是也會(huì)造成舊數(shù)據(jù)無(wú)法及時(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ǔ)推算出來(lái)的，所以要小心調(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ù)之前講過(guò)。當(dāng)開(kāi)啟之后，上述閾值的乘法因子會(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)烈建議開(kāi)啟。

Generic Parameters

max_open_files | state.backend.rocksdb.files.open 顧名思義，是 RocksDB 實(shí)例能夠打開(kāi)的最大文件數(shù)，默認(rèn)為-1，表示不限制。由于sstable的索引和布隆過(guò)濾器默認(rèn)都會(huì)駐留內(nèi)存，并占用文件描述符，所以如果此值太小，索引和布隆過(guò)濾器無(wú)法正常加載，就會(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。

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

新聞名稱：FlinkRocksDB狀態(tài)后端參數(shù)調(diào)優(yōu)的示例分析
標(biāo)題網(wǎng)址：http://muchs.cn/article24/gesije.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開(kāi)發(fā)、App開(kāi)發(fā)、用戶體驗(yàn)、Google、營(yíng)銷型網(wǎng)站建設(shè)、外貿(mào)建站

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容