深入分析Rapidsai/cudf项目中Parquet解码失败问题

问题背景

在Rapidsai/cudf项目的使用过程中，开发人员发现当启用主机解压缩功能(LIBCUDF_HOST_DECOMPRESSION=ON)时，某些PDS查询会出现间歇性失败。这一问题在使用PDS SF100文件时尤为明显，特别是当这些文件被pandas使用默认pyarrow引擎重写后。

问题现象

具体表现为两种错误模式：

1. 运行时错误(RuntimeError)，错误信息为"Parquet data decode failed with code(s) 0x1"
2. 另一种类似的错误信息为"Parquet data decode failed with code(s) 0x2"

这些错误主要出现在查询q1、q3、q7、q8、q21等操作中。有时错误会导致基准测试运行器继续执行，有时则会导致运行器挂起。

问题复现

开发人员通过简化测试用例成功复现了该问题。在重复读取特定Parquet文件时，部分读取操作会失败或挂起。测试代码示例如下：

for _ in range(10):
    path = '/path/to/lineitem.parquet'
    try:
        t0 = time.time()
        df = cudf.read_parquet(path,
                             columns=["l_orderkey", "l_extendedprice", 
                                     "l_discount", "l_shipdate"])
        t1 = time.time()
        print('读取成功', t1 - t0)
    except Exception as e:
        t1 = time.time()
        print('读取失败', e, t1 - t0)

问题分析

经过深入分析，开发人员发现：

1. 该问题与主机解压缩功能直接相关，当启用LIBCUDF_HOST_DECOMPRESSION时出现
2. 问题在pyarrow写入的文件中更为常见，而在Polars写入的文件中较少出现
3. 问题可能与解压缩工作线程数量设置有关，调整LIBCUDF_NUM_HOST_WORKERS参数也会影响问题出现频率
4. pyarrow写入的文件通常包含更大的压缩块，这可能是问题触发的一个因素

技术细节

该问题的根本原因在于cudf的Parquet读取器实现中，特别是在主机解压缩路径下的数据处理逻辑存在缺陷。当处理较大的压缩数据块时，解压缩过程中可能出现数据损坏或同步问题，导致解码失败。

错误代码0x1和0x2分别代表不同的解码失败场景：

• 0x1通常表示数据格式不匹配或损坏
• 0x2则可能指示解压缩过程中的缓冲区问题

解决方案

该问题最终通过代码提交得到修复。修复方案主要针对cudf项目中parquet读取器的实现进行了优化，特别是在主机解压缩路径下的数据处理逻辑。

对于用户而言，解决方案包括：

1. 更新到包含修复的cudf版本
2. 临时解决方案可以关闭主机解压缩功能(LIBCUDF_HOST_DECOMPRESSION=OFF)
3. 调整工作线程数量可能缓解问题(LIBCUDF_NUM_HOST_WORKERS)

经验总结

这个问题揭示了在大规模数据处理中几个关键点：

1. 主机与设备间的数据传输和解压缩需要特别谨慎处理
2. 不同库(pyarrow vs Polars)生成的文件可能在实现细节上有重要差异
3. 线程数量的设置对数据处理稳定性有直接影响
4. 压缩块大小的选择会影响处理性能和稳定性

对于数据处理框架开发者而言，这个问题强调了全面测试不同数据源和工作负载的重要性，特别是在涉及主机-设备协同处理的场景下。