PyGDF项目中Parquet文件读取时的Host解压问题分析

问题背景

在GPUOpenAnalytics的PyGDF项目（基于CUDA的DataFrame库）中，当启用主机端解压功能（LIBCUDF_HOST_DECOMPRESSION=ON）时，部分PDS查询会出现间歇性失败。这个问题在使用pyarrow引擎重写的PDS SF100文件上尤为明显，表现为Parquet数据解码失败，错误代码0x1或0x2。

问题现象

开发人员在使用cudf-polars运行查询时，观察到以下典型错误：

1. 运行时错误：RuntimeError: CUDF failure at.../parquet/reader_impl.cpp:427: Parquet data decode failed with code(s) 0x1
2. 有时错误代码会变为0x2
3. 问题查询包括q1、q3、q7、q8、q21等
4. 有时错误会导致程序继续运行，有时则会导致程序挂起

问题复现

通过简化测试用例，可以稳定复现该问题：

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

测试发现：

• 某些读取操作会挂起
• 某些会抛出解码失败异常
• 使用Polars写入的文件不会出现此问题，仅在使用pyarrow写入的文件中出现

环境因素

问题出现在以下环境中：

• 基础镜像：rapidsai/base:25.04a-cuda12.8-py3.12-arm64
• 硬件平台：NVIDIA GH200
• 当调整主机工作线程数时也会触发类似问题

技术分析

1. 压缩块大小差异：pyarrow写入的文件比Polars写入的文件有更大的压缩块，这可能是触发问题的因素之一

2. 主机解压实现：当前的主机解压实现可能存在边界条件处理不完善的情况，特别是在处理大压缩块时

3. 多线程问题：调整工作线程数会触发问题，表明可能存在线程同步或资源竞争问题

4. 错误代码含义：

   • 0x1通常表示解压失败
   • 0x2可能表示数据损坏或解压缓冲区不足

解决方案

该问题已通过cudf项目的PR #18395修复。修复可能涉及以下方面：

1. 改进主机解压算法的鲁棒性
2. 优化大压缩块的处理逻辑
3. 增强线程安全性和资源管理
4. 完善错误处理和恢复机制

最佳实践建议

1. 对于关键生产环境，建议暂时禁用主机解压功能（LIBCUDF_HOST_DECOMPRESSION=OFF）

2. 如果必须使用主机解压：

   • 保持默认工作线程数
   • 优先使用Polars写入的Parquet文件
   • 监控并更新到包含修复的版本

3. 对于性能敏感场景，可以考虑使用GPU解压方案

总结

这个问题展示了在大规模数据处理中，主机端解压实现需要考虑多种边界条件和性能因素。特别是在异构计算环境中，CPU和GPU之间的协同工作需要精心设计。PyGDF团队通过代码审查和修复，提升了库在主机解压场景下的稳定性和可靠性。