2023年社群有一篇部落格就比較深入的介紹了operator 和 keyed state的rescale的實現，感興趣的話可以去了解下。
這兩張圖對比了是否基於keygroup來划區的乙個差別，社群中的版本使用的是基於keygroup的版本實現的，可以看到可以減少對於資料的random的訪問。但是從b中我們看到，以rescale後的subtask為例:
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的代價也不盡相同
併發翻倍
1.5倍擴併發
併發減半
接下來，我們在**中確認相關的邏輯（**基於flink1.15版本）。
首先根據keygroup的重疊比較，挑選出和當前keygroup有最大重疊範圍的statehandle作為initial state handle。這樣的好處是可以盡可能利用最大重疊部分的資料，減少後續資料遍歷的過程。在挑選出initial state handle 建立db之後，首先需要將db中不屬於當前的task的keygroup的資料進行遍歷刪除。
因為flink中儲存的keyed state的資料已經按照keygroup作為字首作為排序，所以只需要刪除頭部和尾部的資料即可，這樣就不用遍歷全量的資料。
在當前的deleterange的實現中是依賴遍歷db，通過writebatch的方式進行批量執行刪除，這種方式當需要刪除的key的基數較大時會比較耗時，並且都會觸發io和compaction的開銷，而rocksdb提供了deleterange的介面，可以通過指定start和end key來進行快速的刪除，經過測試下來基本只要ms級別就可以完成。參考 flink-21321
在完成base db裁剪之後，就需要將其他db的資料匯入到base db中，目前的實現還是通過writebatch來加速寫入
在 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功能筆者也做了一些研究，在後續的文章中會陸續更新出來，敬請期待
sst ingest 原理
delete range原理
FLASH ActionScript 效能優化
一.圖形方面的優化 1.減少同時在螢幕上物體的個數 2.儘量減少螢幕需要重畫的範圍。3.盡量避免全屏滾動 4.保持幀數在16 20,每一幀都連續，比將幀數設定的很高，但是每一幀的計算超過幀時間，讓人感覺更舒服。5.如果乙個物體不需要顯示，盡量將他從螢幕上刪除，而不是將他設定成不可見。因為即使不可見的...
調優 Nginx效能調優
一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...
Spark效能調優 JVM調優
通過一張圖讓你明白以下四個問題 1.jvm gc機制，堆記憶體的組成 2.spark的調優為什麼會和jvm的調優會有關聯？因為scala也是基於jvm執行的語言 3.spark中oom產生的原因 4.如何在jvm這個層面上來對spark進行調優 補充 spark程式執行時 jvm堆記憶體分配比例 r...