欧美一区二区三区老妇人-欧美做爰猛烈大尺度电-99久久夜色精品国产亚洲a-亚洲福利视频一区二区

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

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

目前創(chuàng)新互聯(lián)建站已為1000+的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機、成都網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計、明溪網(wǎng)站維護等服務(wù)，公司將堅持客戶導向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

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

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

測試場景


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

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


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

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

  • 使用 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 進行了如下基礎(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

機器配置

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


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

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


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

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


對比結(jié)果

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

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

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

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

網(wǎng)頁名稱：Flink使用RocksDB和Gemini的性能對比實驗分析是怎樣的
分享路徑：http://chinadenli.net/article4/pddcie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、標簽優(yōu)化、做網(wǎng)站、靜態(tài)網(wǎng)站、面包屑導航、小程序開發(fā)

廣告

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

成都網(wǎng)頁設(shè)計公司