[Paper] Data Lakehouse 架构中数据加载与存储效率的研究——面向分析数据系统的构建
发布: (2026年4月23日 GMT+8 17:07)
6 分钟阅读
原文: arXiv
Source: arXiv - 2604.21449v1
概览
最近，Ivan Borodii 和 Halyna Osukhivska 进行了一项研究，对三种领先的 Data Lakehouse 技术——Apache Hudi、Apache Iceberg 和 Delta Lake——进行基准测试，使用 Apache Spark 作为处理引擎。通过加载结构化（CSV）和半结构化（JSON）数据集，规模最高达 7 GB，作者找出了在分析工作负载中 加载速度 与 存储占用 之间提供最佳平衡的架构。
关键贡献
- 首次并排性能比较 Hudi、Iceberg 和 Delta Lake 在相同的 Spark ETL 流水线上的表现。
- 评估 两个核心指标： (1) 数据加载时间，和 (2) 生成表的磁盘占用大小。
- 提供有洞察的指导，帮助 根据数据类型、数据量以及速度与存储效率的优先级 选择合适的湖仓。
- 开源友好的实验框架（四个顺序 ETL 作业），可用于进一步的基准测试。
方法论
-
数据集 – 使用了两种格式：
- CSV（完全结构化）
- JSON（半结构化）
文件大小从几百兆字节到 7 GB 不等，以模拟真实的批量加载。
-
处理引擎 – 所有作业均在 Apache Spark 上运行（使用相同的 Spark 版本、集群规模和配置），以保持计算层的一致性。
-
ETL 工作流 – 对每个湖仓系统，作者执行 四个顺序步骤：
- 读取 源文件到 Spark DataFrame。
- 转换（简单的类型转换、列重命名）。
- 写入 数据到湖仓表，使用系统特定的写入 API。
- 提交 事务（如适用）。
-
捕获的指标 –
- 加载时间：从 Spark 读取到成功提交的实际时间。
- 磁盘占用：压缩/优化后表目录的总大小（如果系统自动执行了此操作）。
-
重复与取平均 – 每个实验重复多次；结果取平均以平滑瞬时的集群噪声。
结果与发现
| Lakehouse | Best for Loading Speed | Best for Storage Efficiency | Observations |
|---|---|---|---|
| Delta Lake | Fastest across all file sizes and both CSV/JSON. Consistently lower load times even for 7 GB files. | Moderate – larger on‑disk size than Iceberg, but still acceptable. | Optimized write path and efficient transaction log handling give it an edge in pure throughput scenarios. |
| Apache Iceberg | Slightly slower than Delta Lake but still competitive. | Most compact storage; benefits from built‑in file‑pruning and metadata management. | Ideal when disk cost or long‑term archival matters more than raw ingest speed. |
| Apache Hudi | Slowest in batch load tests; high latency for both CSV and JSON. | Larger on‑disk footprint compared to Iceberg. | Not suited for bulk batch loads; shines in incremental upserts and streaming use‑cases (outside the scope of this study). |
- 数据类型影响：JSON（半结构化）对所有系统都产生了适度的开销，但相对排名保持不变。
- 规模影响：随着文件大小的增加，Delta Lake 与其他系统之间的性能差距扩大，验证了 Delta 在大批量摄取方面的可扩展性。
实际影响
- 数据工程师 可以在构建优先考虑 快速、可重复的批处理加载（例如，夜间数据仓库、ETL 刷新）的管道时采用 Delta Lake。
- 设计 成本敏感的分析平台（例如，多租户湖仓、长期数据湖）的 架构师 可能会倾向于使用 Apache Iceberg，以在不牺牲合理摄入速度的前提下压缩存储开销。
- 流式 / CDC 工作负载：尽管 Hudi 在此批处理基准中表现落后，但其 以 upsert 为中心的设计 使其成为 实时变更数据捕获 管道、事件驱动分析或物联网流的有力候选。
- 该研究的 以 Spark 为中心的基准套件 可以直接嵌入 CI 流水线，以在集群升级或配置调整后持续验证性能。
限制与未来工作
- 范围仅限于批处理 ETL – 增量、流式以及 merge‑on‑read 场景（Hudi 通常擅长的）未进行评估。
- 实验在 单一 Spark 集群配置 上运行；不同的硬件、云服务提供商或 Spark 调优参数可能导致结果不同。
- 仅测试了 CSV 和 JSON 格式；其他常见来源（Parquet、Avro、ORC）可能会影响压缩和布局行为。
- 未来的研究可以将基准扩展到 并发查询工作负载、元数据可扩展性，以及跨云存储层的 成本建模。
作者
- Ivan Borodii
- Halyna Osukhivska
论文信息
- arXiv ID: 2604.21449v1
- 类别: cs.DC, cs.DB
- 出版日期: 2026年4月23日
- PDF: 下载 PDF