導讀 本文将分享Iceberg實時數倉資料分析的性能優化，主要内容包括以下4個方面：
1. Iceberg MOR原理介紹
2. Arctic基于Iceberg性能優化
3. 優化效果評估--CH-benchmark
4. 未來規劃
分享嘉賓｜史大洋 網易數帆 軟體工程師
編輯整理｜吳旺旺 東北大學
出品社群｜DataFun
01
Iceberg MOR原理介紹
1.MOR介紹
MOR是Merge On Read的簡稱，是一種行級更新技術，本質上是out-of-place update，更新和删除不直接修改曆史資料，而是單獨記錄資料變更，在讀取的時候再合并曆史資料和變更得到修改後的值。這種方式更新的時候代價比較小，讀取的時候代價較大。比較适合實時寫入的場景，因為實時寫入對資料湖寫入性能要求比較高。
2.Iceberg内部的三種檔案
Iceberg 内部主要有三種資料檔案。第一種檔案是data-file，data-file存儲的是正常 insert操作插入的資料。第二種檔案是equality-delete-file存儲的是删除資料，它根據标記的字段，現在一般是主鍵，然後跟data-file主鍵字段進行比對，如果比對相等，這條主鍵比對上的值就會被丢棄。第三種檔案是position-delete-file存儲的是删除資料，它根據标注的檔案位置進行删除。
3.equality-delete作用方式
在讀取的時候，equality-delete資料會被先讀入記憶體，然後按照equality-delete-columns訓示的列建構hash表。然後讀取data資料，取相應的列和hash表進行比對，丢棄掉和hash表比對的資料。像示意圖中所示的equality-delete它标志的是“id=1”這條資料被删除，然後在記憶體中建構Hash表之後會讀取對的file，如果對應的file中發現“id=1”的這條資料就會被删除，最終讀出來的資料是“id=2”和“id=3”的資料。
4.Positioned-delete作用方式
Position-delete有兩種作用形式：
- 建構bitmap
先把position-delete-file資料讀入記憶體，position-delete-file隻是标記要删除data-file的行号，是以需要按照删除的行号建構bitmap，這種方式對記憶體的消耗非常小。在讀取data-file的時候，丢棄掉與bitmap裡行号比對的資料。例如圖中所示bitmap内儲存行号為2，于是data-file中行号為2即id=3的資料會被丢棄。
- Sort-Merge
另一種作用方式是Sort-Merge。data-file的行号是自然增加的，position-delete-file記錄的删除行号也是升序排序。于是可以對兩種檔案做Sort-Merge。
5.Iceberg檔案組織形式及task結構
圖中所示的Flink做了三次寫入及送出，每次寫入時，insert操作的資料會寫入data-file。delete操作的資料會寫兩種檔案，一個是equality-delete-file，一個是position-delete-file。equality-delete-file總是作用于曆史快照的資料，它不會作用于目前快照的data-file，于是它需要一個position-delete-file來作用于目前快照。
在讀取的時候，task按照data-file為主導劃分，一個data-file可以劃分為一個或多個task。每一個task是一個最小讀取單元。
02
Arctic基于Iceberg性能優化
1.Arctic簡介
Arctic是網易研發的一個開放式架構下的湖倉管理系統，在開放的資料湖格式 Iceberg之上，提供了更多面向流和更新場景的優化，以及一套可插拔的資料自優化機制self-optimizing和管理服務。基于Arctic可以幫助各類資料平台，工具和産品快速搭建開箱即用、流批統一的湖倉。
2.為什麼需要 Optimize
在使用資料湖的時候經常會遇到一些問題，第一個是小檔案問題，小檔案太多。因為實時送出每一個快照都需要送出，寫入的檔案都比較零碎。第二個是備援資料太多，記錄了很多delete資料，這些delete資料應該和data-file資料進行删除。非常多的delete-file，一方面增加了存儲，另一方面delete在讀取的時候性能非常低。第三是資料組織形式比較低效的問題。第四是過期無效檔案的殘留問題，在原資料中已經标志一個檔案删除了，但是它并不會真的被删除，這些檔案需要定時的清理。
3.Arctic Self-optimizing
Self-optimizing具有三個特性。一是定時監控，Self-optimizing提供一套自動執行的機制，定時掃描每個表檢查，發現這個表需要做optimizing的時候會自動排程起來做optimizing。二是資源隔離，提供資源組管理和配額設定，每個組中可以配置一些不同的參數以及排程政策規則，允許資源在表級隔離和共享。三是靈活部署，基于Flink引擎部署，支援YARN、K8s，支援通過AMS線上擴縮容。
4.Self-optimizing -- 小檔案合并
常見的小檔案合并是把多個小檔案合并成一個大檔案，小檔案合并的好處是降低了HDFS的NameNode的壓力，降低Iceberg中繼資料的數量，減少查詢時打開檔案的代價。
5.Self-optimizing -- 消除delete檔案
Flink寫入的時候會有非常多的delete檔案，在讀取的時候讀取這些delete檔案，會帶來一定的性能損耗，如果把delete和data-file合并成一個新的檔案，這樣既減少了檔案數量，也減少了讀取的資料量，并且降低了MOR時應用delete檔案的代價，釋放了CPU和記憶體。
6.Self-optimizing -- Equality-delete轉Position-delete
equality-delete-file會先讀入記憶體，然後建構hash表和data-file資料進行比對，這樣對于記憶體消耗比較高，且需要讀取 data-file 時額外讀取比對字段。position-delete-file可以讀入記憶體建構bitmap比對，也可以通過sort-merge比對，對于記憶體消耗較少，且不需要額外的字段比對。通過把equality-delete-file轉換為position-delete-file 可以提高查詢性能，和上文的消除delete方式相比，這種方式可以在删除比例不高的時候減少寫放大。在轉換過程中我們讓一個position-delete-file對應一個data file，這樣可以充分利用Iceberg的data-skipping，讓讀取的時候避免讀其他無效的position-delete檔案。
7.Self-optimizing性能優化效果對比圖
這張圖展示的是 self-optimizing 對性能的影響，藍色表示有self-optimizing的情況，橘黃色表示沒有self-optimizing的情況。橫軸表示的是更新資料寫入時間。上圖表明沒有self-optimizing，Iceberg的MOR性能會急劇下降。在60~90minutes的時候表基本上不可用，此時讀取資料已經讀取不出相應的資料。有self-optimizing的Iceberg的性能會維持在一個非常平穩的水準。
8.Delete 檔案重複讀取問題
- 問題所在
如圖所示，有6個date-file以及6個equality-delete-file，在讀取的時候，每1個data-file對應着6個equality-delete-file，于是plan出來的6個task，而每1個task都會讀這6個equality-delete-file，也就說這個equality-delete-file被讀取了36次，也就是他多讀了30次的data-file，對性能的損耗是非常高的。
- Mixed Iceberg format精細化data檔案和delete檔案對應關系
引入檔案分組政策，檔案寫入的時候按照主鍵進行hash分組，可以精确化對應data-file和equality-file的關系。這種分桶政策是一種一緻性哈希的方案，這種方案的好處是可以低成本修改分組數量。
- Mixed Iceberg format複用delete資料
對于不同data-file檔案對應的equality-delete-file檔案相等的情況下，可以将不同的data-file檔案合并到同一個Task，進而複用delete-file資料。讀取的時候，相同的node下的多個data檔案配置設定在一個task裡面，讀取的時候delete檔案隻讀取一次。
- Mixed Iceberg format task均衡配置設定
在進行分組操作後，因為資料的分布不均衡，每個組下的資料量差異會很大，在實際使用中經常發現一些資料傾斜的問題，有的節點可能十幾秒就執行完了，有的節點二十幾秒才執行完，嚴重拖累了整體的一個執行效率。如何均衡配置設定這些file-group，等效于K-way number partitioning problem，是一個NP-Hard問題。我們采用排序+貪心算法配置設定，具體步驟就是先對 Task 從大到小排序，然後依次取出放入最小的 parttion 裡面。最終得到一個很好的次優解。
- Delete檔案複用及task配置設定政策效果
通過性能對比圖，可以看出在實時場景下性能有許多提升。
9.對性能影響較大的參數
檔案類型。檔案類型對查詢性能影響較大，parquet檔案相較于AVRO由于采用列存模式具有較高的壓縮比，寫入和讀取的IO會更少，并且可以列裁剪，謂詞過濾，讀取性能很高，有時能達到數倍差距，但是parquet對記憶體消耗更高，有時甚至因為同時讀取的parquet檔案過多導緻OOM。
壓縮類型。各種壓縮類型的特性都有差別，有的壓縮比更高但是解壓縮代價就更高，有的壓縮比不高但是解壓縮代價更低，需要根據機器、業務情況進行選擇。
03
優化效果評估
1.TPC-C、TPC-H
如何對優化政策給出一個比較标準的評估，目前各個資料湖都會釋出一些測試報告，但各方口徑并不一緻。傳統比較标準的測試方案有兩套，TPC-C和TPC-H，TPC-C用于OLTP負載，使用隻讀和更新密集型業務事務的混合來評估性能。TPC-H是一個決策支援基準測試，它對檢查大量資料、執行高度複雜的查詢并回答關鍵業務問題的決策支援系統進行模組化。但是這兩種都不能很好的評估資料湖在行級更新場景下的性能。
2.CH-benchmark
最終采用了CH-benchmark的方案，CH-benchmark以未經修改的TPC-C的模式與事務為基礎，結合經過調整的TPC-H查詢，形成了一個複雜的混合工作負載。
通過方案中的benchmark工具，分為兩部分進行執行，第一步先生成TPCC資料，然後寫入MySQL，在MySQL上進行資料事務型的資料更新，模拟實際業務中的MySQL使用情況，然後通過Flink CDC同步變更資料進資料湖，在資料湖裡面模拟一個最典型的場景，就是CDC資料入湖，然後在資料湖裡源源不斷産生變更資料，通過查詢引擎進行TPCH查詢。
04
未來規劃
- 異步資料全局排序（普通排序、Z-order）
- 異步二級索引建構