当前，业界流行的集中数据湖表格式 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）也有三倍的差距。
