为什么下推过滤器未提升Spark从S3读取Parquet数据的性能？

1. 谓词下推未生效，导致全量数据扫描 #

这是最高概率的触发原因：

• 最常见的诱因是过滤条件与列的数据类型不匹配：如果你的qk列在Parquet文件中以整数类型存储，而查询中使用字符串类型字面量（'0000000'）做过滤，Spark会对列值执行隐式类型转换（整数转字符串）再做比较，这类转换会导致Parquet文件中存储的min/max统计信息无法被使用，谓词下推直接失效。此时Spark必须读取所有750个文件的完整数据做过滤，开销极大。
• 你可以通过Spark UI的SQL执行计划查看PushedFilters项，确认qk的过滤条件是否被成功下推，如果未出现在下推列表中即可确认是该问题。
• 另外如果写入Parquet时手动关闭了统计信息收集（比如设置了spark.sql.parquet.writeStatistics=false），文件中没有存储列的min/max统计，也会导致下推无法生效。

2. 谓词下推生效但S3元数据访问开销超过实际数据读取开销 #

如果确认下推已生效，该现象则是对象存储的访问特性导致：

• 你查询的qk='0000000'远小于所有文件的qk最小值（0230001），Spark需要逐个读取750个Parquet文件的Footer（通常位于文件末尾的数KB区域）来获取统计信息，才能确认所有文件都不包含目标值。
• S3是对象存储，单次小范围GET请求的延迟通常在10_{30ms，750次请求的累积延迟可达7.5s}22.5s。而你查询存在的qk='0230101'时，由于数据按qk排序写入，只有少数几个文件的min/max范围包含该值，Spark只需要读取这几个文件的实际数据做统计，虽然单请求读取的字节数更多，但总请求数远小于750，总耗时反而更低。

快速排查优化建议 #

• 先执行prod_df.printSchema()确认qk列的数据类型是否和过滤条件的字面量类型一致，避免隐式转换导致下推失效。
• 对下推生效的场景，可以开启spark.sql.parquet.readSummaryMetadata=true复用Parquet全局统计信息减少文件级元数据请求，也可以对qk列做范围分区进一步减少需要扫描的文件数量。

内容的提问来源于stack exchange，提问作者jk1