Flink State Rescale效能優化

Aitozi 發表於 2022-01-22
Flink

背景

今天我們來聊一聊flink中狀態rescale的效能優化。我們知道flink是一個支援帶狀態計算的引擎,其中的狀態分為了operator state和 keyed state兩類。簡而言之operator state是和key無關只是到operator粒度的一些狀態,而keyed state是和key繫結的狀態。而Rescale,意味著某個狀態節點發生了併發的縮擴。在任務不修改併發重啟的情況下,我們只需要按照task,將先前job的各個併發的state handle重新分發處理下載遠端的持久化的state檔案即可恢復。而發生rescale時,狀態的資料分佈將發生變化,因此存在一個reshuffle的過程,那麼我們就來看看這個rescale的實現是怎麼做的,以及其問題和優化手段。

Rescale的實現

2017年社群有一篇部落格就比較深入的介紹了Operator 和 keyed state的rescale的實現,感興趣的話可以去了解下。
image.png image.png
這兩張圖對比了是否基於keyGroup來劃區的一個差別,社群中的版本使用的是基於keygroup的版本實現的,可以看到可以減少對於資料的random的訪問。但是從B中我們看到,以rescale後的subtask為例:

  • subtask-0: 需要將原先subtask-0的dfs檔案下載後將KG-3的資料剔除掉。這裡需要剔除的原因是: 雖然我們任務啟動後由於keyshuffle的原因,subtask-0不會再接收到KG-3的資料,但是後續如果繼續做checkpoint,會導致這部分資料重新被上傳到DFS檔案中,而如果繼續發生rescale,就可能導致和其他subtask-1上的KG-3的資料發生衝突導致資料問題
  • subtask-1: 需要download原先subtask-0和subtask-1的資料dfs檔案,並將subtask-0中的KG-1和KG-2的資料刪除,以及原先subtask-1中的 KG-5 和 KG-6刪除,並將其匯入到新的RocksDB例項中。

因此我們可以總結出rescale的大致流程中,首先會將當前task所涉及的db檔案恢復到本地,並從中挑選出屬於當前keygroup的資料重新構建出新的db。

從理論上分析,在不同的併發調整場景下,其rescale的代價也不盡相同
image.png
併發翻倍

image.png
1.5倍擴併發

image.png
併發減半

接下來,我們在程式碼中確認相關的邏輯(程式碼基於Flink1.15版本)。

根據stateHandle元資訊判斷是否是rescale

我們可以看到當restoreStateHandles的數量大於1,或者stateHandle的keyGroupRange和當前task的range不一致時就是rescale的過程
image.png
在不是rescale的場景下,恢復的流程只需要將相應IncrementalRemoteKeyedStateHandle對應的檔案下載到本地或者是直接使用local recovery中的 IncrementalLocalKeyedStateHandle所對應的本地檔案的目錄,直接執行 RocksDB.open()就可以將db資料恢復。

initialDB

首先根據keygroup的重疊比較,挑選出和當前keygroup有最大重疊範圍的stateHandle作為initial state handle。這樣的好處是可以儘可能利用最大重疊部分的資料,減少後續資料遍歷的過程。在挑選出initial state handle 建立db之後,首先需要將db中不屬於當前的task的keygroup的資料進行遍歷刪除。
image.png
因為flink中儲存的keyed state的資料已經按照keygroup作為字首作為排序,所以只需要刪除頭部和尾部的資料即可,這樣就不用遍歷全量的資料。
image.png
在當前的deleteRange的實現中是依賴遍歷db,通過writeBatch的方式進行批量執行刪除,這種方式當需要刪除的key的基數較大時會比較耗時,並且都會觸發io和compaction的開銷,而rocksdb提供了deleteRange的介面,可以通過指定start和end key來進行快速的刪除,經過測試下來基本只要ms級別就可以完成。參考 FLINK-21321

Bulk load

在完成base db裁剪之後,就需要將其他db的資料匯入到base db中,目前的實現還是通過writeBatch來加速寫入
image.png
FLINK-17971 中作者提供了sst ingest 寫入的實現,本質上是利用rocksdb 的sst writer的工具,通過sst writer能直接構建出sst 檔案,避免了直接寫的過程中的compaction的問題,然後通過 db.ingestExternalFile直接將其匯入db中。實際測試的過程中這樣的寫入效能有2-3倍的提升。

Rescale的優化應該迭代優化了很多次,最開始的實現應該是將所有的statehandle的資料download下來,將其遍歷寫入新的db,在 FLINK-8790 中首先將其優化成 base db + delete Range + bulk load的方式,後續的兩個pr又通過Rocksdb提供的deleteRange + SSTIngest 特性加速。雖然這些優化應用上只有rescale的提速很明顯,但是當我們遇到key的基數非常大時,就會出現我們遍歷原先的db next呼叫和 寫入的耗時也非常的大,因此rescale的場景可能還需要繼續優化。

關於RocksDB中deleteRange和SST Ingest功能筆者也做了一些研究,在後續的文章中會陸續更新出來,敬請期待

參考

https://blog.csdn.net/Z_Stand/article/details/115799605 sst ingest 原理
http://rocksdb.org/blog/2017/02/17/bulkoad-ingest-sst-file.html
https://rocksdb.org/blog/2018/11/21/delete-range.html delete range原理