溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的

發(fā)布時間：2022-01-04 16:13:59 來源：億速云 閱讀：201 作者：柒染 欄目：大數(shù)據(jù)

今天就跟大家聊聊有關(guān)Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

摘要：我們將對 RocksDB、Heap 和 Gemini 在相同場景下進(jìn)行壓測，并對其資源消耗進(jìn)行對比。測試的 Flink 內(nèi)核版本為 1.10.0。

微博機(jī)器學(xué)習(xí)平臺使用 Flink 實現(xiàn)多流 join 來生成在線機(jī)器學(xué)習(xí)需要的樣本。時間窗口內(nèi)的數(shù)據(jù)會被緩存到 state 里，且 state 訪問的延遲通常決定了作業(yè)的性能。開源 Flink 的狀態(tài)存儲主要包括 RocksDB 和 Heap 兩種，而在去年的 Flink Forward 大會上我們了解到阿里云 VVP 產(chǎn)品自研了一款更高性能的狀態(tài)存儲插件 Gemini，并對其進(jìn)行了測試和試用。

測試場景


我們使用真實的樣本拼接業(yè)務(wù)作為測試場景，通過將多個流的數(shù)據(jù)union后對指定key做聚合（keyby），在聚合函數(shù)里從各個流中獲取相應(yīng)的字段，并將需要的字段重新組合成一個新的對象存儲到 value state 里。這里對每個新的對象都定義一個 timer，用 timer 功能來替代 TimeWindow，窗口結(jié)束時將數(shù)據(jù)發(fā)射到下游算子。使用 timer 功能的主要原因是 timer 更靈活，更方便用戶自定義，在平臺的實用性，可擴(kuò)展性上表現(xiàn)更好。
MemoryStateBackend vs. RocksDBStateBackend

首先需要說明的是，MemoryStateBackend 不建議在線上使用，這里主要是通過測試量化一下使用 Heap 存儲 state 的資源消耗。
 
我們在測試中對 checkpoint 的配置如下：

CheckpointInterval:10分鐘CheckpointingMode: EXACTLY_ONCECheckpointTimeout:3分鐘

同時對 RocksDB 增加了如下配置：

setCompressionType：LZ4_COMPRESSIONsetTargetFileSizeBase：128 * 1024 * 1024setMinWriteBufferNumberToMerge：3setMaxWriteBufferNumber：4setWriteBufferSize：1GsetBlockCacheSize：10GsetBlockSize：4 * 1024setFilter：BloomFilter(10, false)

測試發(fā)現(xiàn)，相同作業(yè)處理相同的數(shù)據(jù)量時，使用 MemoryStateBackend 的作業(yè)吞吐和 RocksDB 類似（輸入 qps 為 30 萬，聚合后輸出 qps 為 2 萬），但所需要的內(nèi)存(taskmanager.heap.mb)是 RocksDB 的 8 倍，對應(yīng)的機(jī)器資源是 RocksDB 的 2 倍。

Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的


由此我們得出以下結(jié)論：

  • 使用 MemoryStateBackend 需要增加非常多的 Heap 空間用于存儲窗口內(nèi)的狀態(tài)數(shù)據(jù)（樣本），相對于把數(shù)據(jù)放到磁盤的優(yōu)點(diǎn)是處理性能非常好，但缺點(diǎn)很明顯：由于 Java 對象在內(nèi)存的存儲效率不高，GB 級別的內(nèi)存只能存儲百兆級別的真實物理數(shù)據(jù)，所以會有很大的內(nèi)存開銷，且 JVM 大堆 GC 停機(jī)時間相對較高，影響作業(yè)整體穩(wěn)定，另外遇到熱點(diǎn)事件會有 OOM 風(fēng)險。

  • 使用 RocksDB 則需要較少的 Heap 空間即可，加大 Native 區(qū)域用于讀緩存，結(jié)合 RocksDB 的高效磁盤讀寫策略仍然有很好的性能表現(xiàn)。

GeminiStateBackend vs. RocksDBStateBackend 

可以通過如下方式，在 Ververica Platform 產(chǎn)品中指定使用 Gemini state backend:

state.backend=org.apache.flink.runtime.state.gemini.GeminiStateBackendFactory

同時我們對 Gemini 進(jìn)行了如下基礎(chǔ)配置：

// 指定Gemini存儲時的本地目錄kubernetes.taskmanager.replace-with-subdirs.conf-keys= state.backend.gemini.local.dirstate.backend.gemini.local.dir=/mnt/disk3/state,/mnt/disk5/state// 指定Gemini的page壓縮格式（page是Gemini存儲的最小物理單元）state.backend.gemini.compression.in.page=Lz4// 指定Gemini允許使用的內(nèi)存占比state.backend.gemini.heap.rate=0.7// 指定Gemini的單個存儲文件大小state.backend.gemini.log.structure.file.size=134217728// 指定Gemini的工作線程數(shù)state.backend.gemini.region.thread.num=8

機(jī)器配置


Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的


作業(yè)使用資源對應(yīng)參數(shù)


Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的


內(nèi)存相關(guān)參數(shù)


Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的


對比結(jié)果


Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的


Note：全量的樣本拼接負(fù)載使用 16 臺機(jī)器無法完全服務(wù)，因此我們通過對數(shù)據(jù)進(jìn)行不同比例的抽樣來進(jìn)行壓測。當(dāng)出現(xiàn)反壓時，我們認(rèn)為作業(yè)已經(jīng)達(dá)到性能瓶頸。

由以上對比可以看出，在數(shù)據(jù)、作業(yè)處理邏輯、硬件配置等都相同的前提下，使用 Gemini 成功處理的數(shù)據(jù)量是 RocksDB 的 2.4 倍（17280 vs 7200 條/s）。同時通過硬件資源消耗的對比可知，RocksDB 更快達(dá)到磁盤 IO 瓶頸，而 Gemini 則具備更高的內(nèi)存和 CPU 利用率。

看完上述內(nèi)容，你們對Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。

向AI問一下細(xì)節(jié)

免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI
助
手