當前，業界流行的集中數據湖表格式 Hudi/Iceberg/DeltaLake，和最近出現并且在國內比較火的 Paimon。我們現在看到的很多是針對流處理場景的讀寫性能測試，那么本篇文章我們將回歸到大數據最基礎的場景，對海量數據的批處理查詢。本文主要介紹通過 TPC-DS 3TB 的數據的99個SQL，對這幾種數據湖表格式的查詢性能做一個全面的測試。
測試環境
我們選擇使用 Aamzon EMR Serverless 作為測試的基礎環境，版本選擇 EMR 最新的 7.1.0。Spark 版本為 3.5.0。
Amazon EMR Serverless 已經集成了 Hudi，Iceberg，Delta Lake，所以我們直接使用集成的版本，而Paimon，是通過外部依賴使用的是 paimon-spark-3.5-0.8.1
測試數據是通過 TPC DS 工具生成好的 3TB 的 parquet 數據文件，我們把著 3TB 的文件分別以這幾種表格式的類型寫入各自的表中。
每張表的數量如下：
| 表名 | 記錄數 |
|---|---|
| call_center | 48 |
| catalog_page | 36000 |
| catalog_returns | 432006840 |
| catalog_sales | 4320004419 |
| customer | 30000000 |
| customer_address | 15000000 |
| customer_demographics | 1920800 |
| date_dim | 73049 |
| household_demographics | 7200 |
| income_band | 20 |
| inventory | 1033560000 |
| item | 360000 |
| promotion | 1800 |
| reason | 67 |
| ship_mode | 20 |
| store | 1350 |
| store_returns | 864006076 |
| store_sales | 8251110748 |
| time_dim | 86400 |
| warehouse | 22 |
| web_page | 3600 |
| web_returns | 215999442 |
| web_sales | 2159391499 |
| web_site | 66 |
每個表格式的版本
| OTF | Version |
|---|---|
| Hudi | 0.14.1 |
| Iceberg | 1.4.3 |
| DeltaLake | 3.0.0 |
| Paimon | 0.8.1 |
Spark 配置參數
--conf spark.dynamicAllocation.enabled=false
--conf spark.driver.cores=4
--conf spark.driver.memory=5g
--conf spark.executor.cores=4
--conf spark.executor.memory=6g
--conf spark.executor.instances=47
測試結果
我們分別在EMR Serverless 使用最大資源配置 400 vCPUs, 3000 GB memory, 20000 GB disk 運行了4 種OTF的查詢測試，得到如下的結果，下圖是每一個sql的執行時長，所以數值越小，說明查詢用時越短。
測試過程中 Iceberg，Delta Lake 的SQL 是全部運行成功的
Hudi 在執行 q2，q3 失敗
Paimon 在執行 q4，q5 失敗，發現應該是在運行作業的時候，shuffle 數據導致磁盤空間不足，因此在啟動 Paimon 作業的時候，在EMRServerless啟動參數中，又單獨添加了指定磁盤大小的參數 spark.emr-serverless.executor.disk=100g
通過上圖，初步看到，Paimon 在 query 場景下的性能與其他集中 OTF 格式有一定差距。
將每種OTF的運行時長累加：
這樣對比就更明顯，Delta Lake 在 Spark 下的查詢性能更優，著應該跟 spark 背后的 databrick 的優化有不小的關系， Iceberg 其次，第三是 Hudi。而 Paimon 表現最差，它的執行時長(5100+s)則超過了 Iceberg(2100+s) 的兩倍，相比 Deltalake（1600+s）也有三倍的差距。
)
