flink調優之RocksDB設定

肥仔佳文豬發表於2022-04-10

一、開啟監控

RocksDB是基於LSM Tree實現的,寫資料都是先快取到記憶體中,所以RocksDB的寫請求效率比較高。RocksDB使用記憶體結合磁碟的方式來儲存資料,每次獲取資料時,先從記憶體中blockcache中查詢,如果記憶體中沒有再去磁碟中查詢。使用

RocksDB時,狀態大小僅受可用磁碟空間量的限制,效能瓶頸主要在於RocksDB對磁碟的讀請求,每次讀寫操作都必須對資料進行反序列化或者序列化。當處理效能不夠時。僅需要橫向擴充套件並行度即可提高整個Job的吞吐量。

flink1.13中引入了State訪問的效能監控,即latency tracking state、此功能不侷限於State Backend的型別,自定義實現的State Backend也可以複用此功能。

 

state訪問的效能監控會產生一定的效能影響,所以預設每100次做一次抽樣sample,對不同的state Backend效能損失影響不同。

對於RocksDB State Backend,效能損失大概在1%左右

對於heap State Backend,效能損失最多可達10%(記憶體本身速度比較快,一點損失影響就很大)

關於效能監控的一些引數,正常開啟第一個引數即可,

state.backend.latency-track.keyed-state-enabled:true   //啟用訪問狀態的效能監控

state.backend.latency-track.sample-interval:100            //取樣間隔

state.backend.latency-track.histroy-size:128                  //保留的取樣資料個數,越大越精確

state.backend.latency-track.state-name-as-variable:true  //將狀態名作為變數

 

 0代表是任務編號,filter.visit-state是定義的狀態的變數名

 

 

 

有很多這種統計值可以檢視,中位值,75分位值等。

二、RocksDB狀態優化

①開啟增量檢查點:

RocksDB是目前唯一可用於支援有狀態流處理應用程式增量檢查點的狀態後端,可以修改引數開啟增量檢查點:

state.backend.incremental:true  //預設false,可以改為true

或程式碼中指定 new EmbededRocksDBStateBackend(true)

②開啟本地恢復:當flink任務失敗時,可以基於本地的狀態資訊進行恢復任務。可能不需要從hdfs拉取資料。本地恢復目前僅涵蓋鍵值型別的狀態後端(RocksDB)。MemoryStateBackend不支援本地恢復並忽略此選項

state.backend.local-recovery:true

③如果你有多塊磁碟,可以考慮指定本地多目錄

state.backend.rocksdb.localdir:

/data1/flink/rocksdb,/data2/flink/rocksdb,/data3/flink/rocksdb

不要配置單塊磁碟的多個目錄,務必將目錄配置到多塊不同的磁碟上,讓多塊磁碟來分擔io壓力

三、增量檢查點優化效果案例

提交一個任務,具體引數如下

bin/flink run \

-t yarn-per-job \

-d \

-p 5 \

-Dyarn.application.queue=test \

-Djobmanager.memory.process.size=2048mb \

-Dtaskmanager.memory.process.size=4096mb \

-Dtaskmanager.numberOfTaskSlots=2 \

-Dstate.backend.latency-track.keyed-state-enabled=true \      //開啟狀態監控

-c com.xxx.xxx.Demo \

 

在flink ui檢視狀態的監控

 

 

 

 然後重新提交任務,在提交時增加引數:

-Dstate.backend.incremental=true  \                      //開啟增量檢查點

-Dstate.backend.local-recovery=true \                    //開啟本地恢復

程式碼中增加 env.setStateBackend(new EmbeddedRocksDBStateBackend())   //狀態後端使用RocksDB

 

 

檢視兩張圖的checkpointed data size,可以發現,第一次任務(第一張圖)checkpoint時是全量備份,所以狀態是越來越大的,從1m+增加到了3m+, 而第二次任務它每次checkpoint的狀態大小是有大有小的,範圍在200kb-1.2m之間

再檢視End to End Duration,第一次任務的狀態後端是記憶體儲存,而時間卻略大於第二次任務,說明增量的RocksDB的效果有可能好於全量的memory

四、調整RockSDB的預定義選項。

預定義選項就是一個選項集合,如果調整預定義選項達不到預期,再去調整block、writebuffer等引數。

當前支援的預定義選項有支援的選項有: 

DEFAULT

SPINING_DISK_OPTIMIZED

SPINNING_DISK_OPTIMIZED_HIGH_MEM

FLASH_SSD_OPTIMIZED  (有條件使用ssd的可以使用這個選項)

我們一般使用第三個SPINNING_DISK_OPTIMIZED_HIGH_MEM,設定為機械硬碟+記憶體模式

該模式下flink會幫我們設定一些它認為比較ok的引數(選項集合),具體如下:

可以在提交任務時指定

state.backend.rocksdb.predefined-options:SPINNING_DISK_OPTIMIZED_HIGH+MEN   

也可以在程式碼中指定:

EmbededRocksDBStateBackend embededRocksDBStateBackend = new EmbededRocksDBStateBackend();

EmbededRocksDBStateBackend,setPredefinedOptions(PredefinedOptions.SPINNING_DISK_OPTIMIZED_HIGH_MEM);

env.setStateBackend(embeddedRocksDBStateBackend); 

 

相關文章