Polars项目中Parquet文件扫描时is_not_nan()表达式的异常行为分析

在数据处理领域，Polars作为一个高性能的DataFrame库，其表达式系统提供了丰富的操作功能。然而，近期在Polars 1.27.1版本中发现了一个值得注意的问题：当扫描Parquet文件时，is_not_nan()表达式未能正确过滤数据。

问题现象

当开发者尝试从Parquet文件中读取数据并使用is_not_nan()表达式进行过滤时，发现返回的结果集为空。而同样的操作在内存中的LazyFrame上却能正常工作。具体表现为：

1. 使用is_nan()过滤时能正确返回包含NaN值的行
2. 使用is_not_nan()过滤时返回空DataFrame
3. 如果先创建一个标记列标识非NaN值，再基于该列过滤，则能获得预期结果

技术背景

Polars在处理Parquet文件时采用了谓词下推(Predicate Pushdown)优化技术，这允许将过滤条件直接下推到数据扫描阶段，从而减少需要加载和处理的数据量。这种优化依赖于Parquet文件的统计信息(statistics)来判断哪些数据块可以跳过。

问题根源

经过分析，这个问题与Polars的谓词下推优化实现有关。当使用is_not_nan()表达式时：

1. 谓词下推优化错误地评估了Parquet文件的统计信息
2. 导致系统认为所有行组(row group)都可以被跳过
3. 最终返回了空结果集

解决方案

目前已知的临时解决方案包括：

1. 禁用谓词下推优化：在collect()时设置predicate_pushdown=False
2. 禁用统计信息使用：在scan_parquet()时设置use_statistics=False

根据仓库维护者的反馈，这个问题可能已经在主分支(main)中得到修复，建议用户关注后续版本更新。

最佳实践建议

对于需要处理包含NaN值的数据集时，建议：

1. 在关键过滤操作后添加数据验证步骤
2. 对于生产环境中的重要数据处理流程，考虑添加结果行数检查
3. 在升级Polars版本后，重新测试相关过滤逻辑

这个问题提醒我们，在使用高级优化功能时，应当充分理解其工作原理和潜在边界情况，特别是在处理特殊值(如NaN)时更需谨慎。