Do GPUs Really Need New Tabular File Formats?

本文证明，Parquet 文件中 GPU 扫描性能瓶颈源于次优的、以 CPU 为中心的配置文件，而非格式本身，并表明应用 GPU 感知设置可在不改变 Parquet 规范的前提下将有效读取带宽提升至 125 GB/s。

要点

想象一下，你拥有一个巨大的图书库（你的数据），存储在一个仓库（你的硬盘）中。你还有一位超级快速的机器人图书管理员（你的 GPU），它的职责是阅读这些书籍并回答问题。

多年来，这座图书馆一直使用一种名为Parquet的特定归档系统进行组织。该系统的设计初衷是面向人类图书管理员：它将书籍分组为小而 manageable 的堆，方便人类一次拿起一摞。

然而，机器人图书管理员则不同。它不会一次只拿起一摞；它拥有成千上万只手，可以同时抓取数十摞。但由于图书馆仍是按人类需求组织的，机器人大部分时间都在等待下一摞被递给它，或者它只动用了极少部分的手。机器人本身极其迅速，但图书馆的组织方式拖了它的后腿。

这篇论文提出了一个简单的问题：我们是否需要专门为机器人发明一种全新的归档系统？

作者们回答：不需要。 相反，我们只需遵循几条简单的规则，重新整理现有的书籍即可。

以下是他们解决问题的方法，基于四条主要的“通行规则”：

1. “更多书堆”规则（增加页数量）

• 问题： 旧系统将某个部分的所有数据放入一本巨大而厚重的书中。机器人试图阅读它，但由于书太大无法拆分，它一次只能使用一只手。
• 解决方案： 他们将那些巨著切分成许多更小、更薄的页面。现在，机器人可以用它的 100 只手一次抓取 100 页。
• 结果： 机器人不再无所事事；它正忙着同时动用所有的手。

2. “大箱子”规则（增加行组大小）

• 问题： 旧系统向机器人发送的是像邮票一样微小的包裹。尽管机器人速度很快，但送货卡车（驱动器与机器人之间的连接）却被过多的微小包裹堵住了。
• 解决方案： 他们开始发送巨大的、全尺寸搬家纸箱，而不是邮票大小的包裹。
• 结果： 送货卡车现在可以全速行驶，持续不断地为机器人输送数据。

3. “智能打包”规则（编码灵活性）

• 问题： 旧系统使用一种通用的、一刀切的方法来打包书籍。有时这能让书籍变小，但往往收效甚微。
• 解决方案： 他们逐一检查每本书，并选择最佳的压缩方式。如果一本书包含大量重复的单词，他们就使用特殊代码将其缩得极小；如果一本书本身就很短，他们就保持原样。
• 结果： 书籍在书架上占用的空间更少，因此送货卡车需要承载的重量更轻，使整个过程更快。

4. “别包装”规则（避免不必要的压缩）

• 问题： 有时，旧系统即使书籍本身已经很小，仍会用厚重的泡泡纸（压缩）将其包裹起来。机器人随后不得不花时间拆开包装，这浪费了能量。
• 解决方案： 他们决定：“如果泡泡纸不能让包裹显著变小，就不要使用它。”
• 结果： 机器人通过跳过那些不需要拆包的书籍的拆包步骤，节省了时间。

压轴大戏：机器人与人类的对决

作者们测试了这种新布局。

• 旧方式： 机器人速度缓慢，几乎未能发挥其超能力。
• 新方式： 通过仅重新组织现有的 Parquet 文件（无需发明新格式），他们使机器人的数据读取速度提高了125 倍。

他们还表明，当机器人与送货卡车协同工作（重叠读取与处理）时，效率会更高。事实上，经过重组的机器人速度如此之快，几乎达到了送货卡车本身的理论速度极限。

核心结论

该论文得出结论：我们不需要烧毁图书馆并从头重建一座新馆。我们只需通过一些聪明的调整重新上架书籍即可。

通过微调数据的打包和分组方式，现有的 Parquet 格式已经可以在现代 GPU 上以闪电般的速度运行。这省去了所有人学习新系统的麻烦，同时保持了所有旧软件的兼容性，同时仍获得了我们所需的巨大速度提升。

技术摘要

技术摘要：GPU 真的需要新的表格文件格式吗？

问题陈述

Apache Parquet 是现代分析系统中的事实标准列式文件格式，但其默认配置指南是由以 CPU 为中心的执行引擎塑造的。随着 GPU 加速数据处理日益普及，为 CPU 优化的 Parquet 文件往往严重未能充分利用 GPU 硬件，从而造成人为的性能瓶颈。尽管进行了广泛的 CPU 端测试，Parquet 读取仍然是 GPU 加速分析中的主要瓶颈；例如，NVIDIA RAPIDS 团队报告称，TPC-H 基准测试中约 85% 的运行时间消耗在 Parquet 扫描上，而非查询算子。这引出了核心研究问题：GPU 是否真的需要新的表格文件格式，还是可以通过优化现有的 Parquet 配置来实现高性能？

方法论

作者进行了一项系统性研究，以评估 Parquet 配置选择如何影响 GPU 扫描性能。实验设置利用单块 NVIDIA A100 GPU，通过 GPUDirect Storage (GDS) 从本地 NVMe SSD 读取最大的 TPC-H SF300 表（lineitem）。该研究采用了 PystachIO，这是一个基于 NVIDIA RAPIDS cuDF 库构建的 GPU 加速分析系统，能够完全重叠 I/O 与 GPU 计算。

方法论包括：

1. 建立基线：使用 DuckDB 的默认设置生成 Parquet 文件（每个列块一个页面，每个行组 (RG) 122,880 行，Parquet V1 编码以及标准压缩）。
2. 配置迭代：系统性地修改文件参数以测试四个特定维度：
   • 页面数量：增加每个 RG 的页面数量，以匹配 GPU 内核网格大小。
   • 行组 (RG) 大小：增加每个 RG 的行数，以创建适合 GDS 的更大 I/O 单元。
   • 编码灵活性：允许从 Parquet V1 和 V2 方案中为每个块选择最佳编码。
   • 压缩选择性：跳过那些压缩后大小减少未超过特定阈值（10%）的列块压缩。
3. 工具开发：作者开发了一个 Parquet 重写工具（用 Rust 编写），用于将现有 Parquet 文件转换为这些优化配置，而无需更改文件格式规范。
4. 性能指标：评估重点在于有效读取带宽（逻辑原始数据大小除以扫描运行时间）以及在不同数据集规模（最高至 SF1000）下 TPC-H 查询（Q6 和 Q12）的端到端查询运行时间。

主要贡献与见解

本文根据实验结果提出了四项主要见解：

1. 页面数量优化：GPU 解码内核在页面之间并行化。默认配置通常导致页面过少，致使 GPU 未被充分利用。将页面数量增加到 100 或更多 可显著提高解码效率和存储总线带宽。
2. RG 大小优化：GPU I/O 栈 (GDS) 的行为与 CPU 栈不同，更倾向于更大的 I/O 单元（MB 级）以饱和存储带宽。默认的 RG 大小（导致约 100 KB 的块）并非最优。将 RG 大小增加到 数百万行（例如 1000 万行）可使 GDS 饱和 SSD。
3. 编码灵活性：将编码限制为 Parquet V1 会限制压缩效率。允许从 V1 和 V2 方案中选择最小的编码大小（例如，对整数利用 Delta Binary Packed），可以提高压缩率。这减少了 I/O 瓶颈，并利用 GPU 上高效的 V2 解码。
4. 避免不必要的压缩：盲目应用压缩会增加解压缩开销。研究表明，当大小减少低于 10% 的阈值 时跳过压缩可提高性能，特别是在 GPU 受计算限制的场景中（例如，从多个 SSD 读取时）。

结果

通过将上述 GPU 感知配置应用于完全兼容的 Parquet 文件，作者取得了以下结果：

• 有效带宽：优化后的配置在使用 4 块 SSD 时实现了高达 125 GB/s 的有效读取带宽，相比基线有了显著提升。
• 可扩展性：当应用编码灵活性时，有效带宽随 SSD 数量线性扩展，而基线配置则过早达到饱和。
• 查询性能：在 TPC-H 查询（Q6 和 Q12）上，使用优化 Parquet 文件的 GPU 系统显著优于 CPU 系统（ClickHouse 和 DuckDB），并保持在理论最小运行时间（由 SSD 带宽定义）附近。
• 无需新格式：该研究表明，无需切换到新文件格式即可实现高 GPU 性能，从而保留了 Parquet 生态系统的互操作性优势。

意义与主张

本文认为，对于高性能 GPU 分析而言，新文件格式并非绝对必要。相反，性能差距主要是由于继承自以 CPU 为中心的默认设置的不佳配置选择所致。

• 实践指导：这项工作提供了关于如何优化 Parquet 以适用于 GPU 数据库的首个实践指导，通过配置而非格式替换实现了显著加速。
• 未来工作的基准：作者为未来的 GPU 文件格式建立了强有力的基准。他们断言，任何提出的新格式必须优于这些优化的 Parquet 配置（其实现了约 125 GB/s 的带宽），而不仅仅是优于未优化的默认配置。
• 生态系统保护：通过保持与现有 Parquet 规范及生态系统的兼容性，所提出的方法避免了迁移到专有或新格式所带来的成本。
• 硬件无关性：虽然专注于 GPU，但重写工具并非特定于硬件；它根据目标硬件的特性应用配置，表明任何硬件上的频繁查询都可能从这种重写中受益。

作者总结道，尽管存在针对 GPU 内存内解码的新格式，但现实场景中的主要瓶颈仍然是存储 I/O。因此，在考虑全新的文件格式设计之前，优化现有 Parquet 格式以最大化存储吞吐量并最小化解压缩开销是一个关键且紧迫的步骤。