DataFusion项目中分区列与数据列联合过滤的问题分析

问题背景

在Apache DataFusion项目中，当启用pushdown_filters参数时，涉及分区列与数据文件列联合条件的过滤查询会出现异常结果。这是一个相对不易察觉但影响数据准确性的重要问题。

问题现象

当用户创建了一个分区表，并执行同时涉及分区列和文件数据列的过滤条件时（例如分区列 != 数据列），查询结果会包含本应被排除的记录。具体表现为：

1. 表按part列分区，包含三个分区：a、b、c
2. 每个分区文件中val列的值分别为"a"、"b"、"xyz"
3. 执行WHERE part != val查询时，理论上只应返回part=c且val=xyz的记录
4. 实际结果却包含了所有记录，包括part=a,val=a和part=b,val=b这些明显不符合条件的记录

技术原理分析

这个问题源于DataFusion的谓词下推(Predicate Pushdown)优化机制。当pushdown_filters启用时，系统会尝试将过滤条件尽可能下推到数据源层执行，以减少需要读取和处理的数据量。

对于分区表，过滤条件的处理分为两部分：

1. 分区列过滤：直接根据分区路径信息进行过滤，无需读取文件内容
2. 数据列过滤：需要读取文件后才能应用过滤条件

问题出在当过滤条件同时涉及分区列和数据列时，系统错误地将这类混合条件标记为"精确"(Exact)谓词，导致下推执行时只应用了分区过滤部分，而忽略了数据列部分的过滤条件。

解决方案

修复方案相对简单但有效：将所有同时引用分区列和数据列的过滤条件标记为"不精确"(Inexact)。这样系统就不会将这些条件完全下推到分区过滤阶段，而是保留到需要读取数据文件后再应用完整的过滤条件。

这种处理方式虽然可能牺牲少量性能（因为无法完全利用分区过滤的优势），但保证了查询结果的正确性，是合理的设计取舍。

影响范围与发现过程

这个问题虽然重要，但在实际应用中可能不太常见，原因有二：

1. 同时使用分区列和数据列的复杂过滤条件在实际业务场景中相对少见
2. 许多大型项目（如InfluxData和Comet）并未使用DataFusion的ListingTable实现

该问题由项目贡献者在优化谓词下推功能时无意引入，经过较长时间才被发现，这也说明了其不易察觉的特性。贡献者在发现问题后迅速提出了修复方案，体现了开源社区的快速响应能力。

最佳实践建议

对于DataFusion用户，建议：

1. 在升级到包含修复的版本前，避免使用同时涉及分区列和数据列的复杂过滤条件
2. 对于关键业务查询，应验证查询结果的正确性
3. 理解谓词下推优化的原理和限制，合理设计表结构和查询

该问题的修复不仅解决了具体问题，也提醒开发者在使用高级查询优化功能时需要全面考虑各种边界情况，确保功能在各种使用场景下都能保持正确性。