DuckDB与PyArrow在S3查询性能差异分析

性能对比现象

在使用DuckDB和PyArrow处理存储在S3上的地理空间数据时，发现了一个显著的性能差异。当执行相同的查询操作时，DuckDB耗时约35秒，而PyArrow仅需2.5秒。这一现象在Windows、MacOS和Redhat UBI系统上均可复现。

测试环境与数据特征

测试数据为28GB的GeoParquet文件集，采用Hive分区方式存储（按year/month/day分区），并按device_id排序。数据集包含63个文件，其中最大的单个文件约1.8GB。查询条件涉及时间范围(year=2025, month=1, day=1)和两个字段(device_id和mmsi)的数组匹配。

技术实现差异

DuckDB实现方式

DuckDB通过以下步骤执行查询：

1. 建立数据库连接并加载必要扩展(spatial, aws, httpfs)
2. 使用SQL语法执行包含ANY操作的查询
3. 通过fetch_record_batch方法获取结果

PyArrow实现方式

PyArrow采用更直接的过滤方式：

1. 构建复合过滤条件(pc.field组合)
2. 直接应用filter方法筛选数据集
3. 转换为表格和Pandas DataFrame

性能瓶颈分析

通过启用ARROW_S3_LOG_LEVEL调试日志发现：

1. 文件读取模式差异：虽然两者都读取相同的4个Parquet文件，但DuckDB会读取更多字节范围，且存在重复读取同一字节范围的情况。

2. 大文件处理效率：性能差异主要出现在处理1.8GB的大文件时，DuckDB的字节范围读取策略导致额外开销。

3. 查询优化差异：PyArrow的过滤实现可能更高效地利用了Parquet文件的元数据和统计信息，减少了不必要的数据扫描。

解决方案与优化建议

1. 查询语法优化：尝试使用IN操作符替代ANY操作符，但测试显示性能改善有限（37.3秒 vs 40秒）。

2. 底层优化：DuckDB社区已提出相关性能优化方案，建议测试最新修复版本。

3. 数据访问策略：考虑调整DuckDB的字节范围读取策略，减少重复读取。

4. 索引利用：确保充分利用Parquet文件内置的统计信息和排序特性。

结论

对于特定的大规模地理空间数据查询场景，PyArrow展现出比DuckDB更优的性能表现。这一差异主要源于两者在底层数据访问策略和查询执行计划上的不同实现。建议用户在实际应用中根据具体场景和性能需求选择合适的工具，并关注DuckDB后续版本中针对此类问题的优化进展。