当前，业界流行的集中数据湖表格式 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 失败
通过上图，初步看到，Paimon 在 query 场景下的性能与其他集中 OTF 格式有一定差距。
将每种OTF的运行时长累加：
这样对比就更明显，Iceberg 和 Delta Lake 在 Spark 引擎的查询性能相差不大，其次Hudi，Paimon 的执行时长则超过了 Iceberg 的两倍，而其中还有两个SQL用例执行失败，未累加进来。
