數據處理能力相差 2.4 倍？Flink 使用 RocksDB 和 Gemini 的性能對比實驗

微博機器學習平臺使用 Flink 實現多流 join 來生成在線機器學習須要的樣本。時間窗口內的數據會被緩存到 state 裏，且 state 訪問的延遲一般決定了做業的性能。開源 Flink 的狀態存儲主要包括 RocksDB 和 Heap 兩種，而在去年的 Flink Forward 大會上咱們瞭解到阿里雲 VVP 產品自研了一款更高性能的狀態存儲插件 Gemini，並對其進行了測試和試用。

在本篇文章中咱們將對 RocksDB、Heap 和 Gemini 在相同場景下進行壓測，並對其資源消耗進行對比。測試的 Flink 內核版本爲 1.10.0。

測試場景

咱們使用真實的樣本拼接業務做爲測試場景，經過將多個流的數據union後對指定key作聚合（keyby），在聚合函數裏從各個流中獲取相應的字段，並將須要的字段從新組合成一個新的對象存儲到 value state 裏。這裏對每一個新的對象都定義一個 timer，用 timer 功能來替代 TimeWindow，窗口結束時將數據發射到下游算子。使用 timer 功能的主要緣由是 timer 更靈活，更方便用戶自定義，在平臺的實用性，可擴展性上表現更好。

MemoryStateBackend vs. RocksDBStateBackend

首先須要說明的是，MemoryStateBackend 不建議在線上使用，這裏主要是經過測試量化一下使用 Heap 存儲 state 的資源消耗。

咱們在測試中對 checkpoint 的配置以下：

CheckpointInterval:10分鐘
CheckpointingMode: EXACTLY_ONCE
CheckpointTimeout:3分鐘

同時對 RocksDB 增長了以下配置：

setCompressionType：LZ4_COMPRESSION
setTargetFileSizeBase：128 * 1024 * 1024
setMinWriteBufferNumberToMerge：3
setMaxWriteBufferNumber：4
setWriteBufferSize：1G
setBlockCacheSize：10G
setBlockSize：4 * 1024
setFilter：BloomFilter(10, false)

測試發現，相同做業處理相同的數據量時，使用 MemoryStateBackend 的做業吞吐和 RocksDB 相似（輸入 qps 爲 30 萬，聚合後輸出 qps 爲 2 萬），但所須要的內存(taskmanager.heap.mb)是 RocksDB 的 8 倍，對應的機器資源是 RocksDB 的 2 倍。

由此咱們得出如下結論：

• 使用 MemoryStateBackend 須要增長很是多的 Heap 空間用於存儲窗口內的狀態數據（樣本），相對於把數據放到磁盤的優勢是處理性能很是好，但缺點很明顯：因爲 Java 對象在內存的存儲效率不高，GB 級別的內存只能存儲百兆級別的真實物理數據，因此會有很大的內存開銷，且 JVM 大堆 GC 停機時間相對較高，影響做業總體穩定，另外遇到熱點事件會有 OOM 風險。
• 使用 RocksDB 則須要較少的 Heap 空間便可，加大 Native 區域用於讀緩存，結合 RocksDB 的高效磁盤讀寫策略仍然有很好的性能表現。

GeminiStateBackend vs. RocksDBStateBackend 

能夠經過以下方式，在 Ververica Platform 產品中指定使用 Gemini state backend:

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

同時咱們對 Gemini 進行了以下基礎配置：

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

機器配置

做業使用資源對應參數

內存相關參數

對比結果

Note：全量的樣本拼接負載使用 16 臺機器沒法徹底服務，所以咱們經過對數據進行不一樣比例的抽樣來進行壓測。當出現反壓時，咱們認爲做業已經達到性能瓶頸。

結論

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

做者簡介：

曹富強、晨馨，微博機器學習研發中心-高級系統工程師。現負責微博機器學習平臺數據計算/數據存儲模塊，主要涉及實時計算 Flink、Storm、Spark Streaming，數據存儲Kafka、Redis，離線計算 Hive、Spark 等。目前專一於Flink/Kafka/Redis在微博機器學習場景的應用，爲機器學習提供框架，技術，應用層面的支持。