RAPIDS cuDF项目中的Parquet混合编码读取性能优化分析

背景介绍

在数据处理领域，Apache Parquet是一种广泛使用的列式存储格式，而RAPIDS cuDF是基于GPU加速的数据处理库。当使用cuDF读取由PyArrow生成的Parquet文件时，特别是包含高基数字符串列的文件时，会遇到性能瓶颈问题。

问题本质

PyArrow 18.1.0版本后，默认情况下会优先使用字典编码(dictionary encoding)来存储字符串列，当字典过大时再回退到普通编码(plain encoding)。这种混合编码方式导致cuDF在读取时需要执行两次解压缩操作：

1. 第一次解压缩针对字典编码部分
2. 第二次解压缩针对普通编码部分

这种双重解压操作显著增加了读取时间，特别是第一次解压操作性能通常较差。

性能对比

通过实际测试可以观察到明显的性能差异：

• 读取默认PyArrow写入的混合编码Parquet文件：约122毫秒
• 读取禁用字典编码后写入的Parquet文件：约66毫秒

性能差距接近一倍，这对于大规模数据处理场景来说影响显著。

技术细节分析

问题的核心在于cuDF当前的实现方式：

1. 字典页需要先解压，因为分块读取器(chunked reader)使用字典数据作为子过程计算的一部分
2. 数据页的解压依赖于字典数据来确定子过程
3. 当使用分块读取时，无法避免这些单独的解压调用

潜在优化方案

针对这一问题，可以考虑以下几种优化路径：

1. 合并解压调用：当不使用分块读取时，可以将字典页和数据页的解压操作合并为单个调用，然后在设备上继续解码
2. 主机端解压字典：在主机端解压字典页，在设备上继续解码过程
3. 混合解码策略：在主机端解压和解码字典页，在设备上解压和解码普通页，最后合并结果

实际应用影响

在NDS-H SF10基准测试中，可以观察到：

• lineitem表：cuDF和PyArrow都产生混合编码
• supplier表：仅PyArrow产生混合编码
• partsupp表：PyArrow和cuDF都产生混合编码
• part表：PyArrow和cuDF都产生混合编码
• orders表：PyArrow和cuDF都产生混合编码
• customer表：仅PyArrow产生混合编码

这种不一致的行为表明cuDF在某些情况下也会产生混合编码列，这需要进一步调查。

结论与展望

Parquet文件的混合编码读取性能问题是实际应用中常见的瓶颈。通过优化解压策略，特别是针对非分块读取场景，可以显著提升cuDF的Parquet读取性能。未来的工作可以集中在实现上述优化方案，并深入理解cuDF产生混合编码列的条件，以提供更一致的性能表现。

对于数据工程师和科学家来说，了解这一性能特征有助于在实际工作中做出更明智的存储格式选择，特别是在处理高基数字符串列时，可以考虑禁用字典编码以获得更好的读取性能。