Spark ORC谓词下推配置与实际执行不符问题咨询

你的疑惑非常典型，很多人都会被物理计划里的PushedFilters标记误导，我来拆解一下背后的逻辑：

• 物理计划的PushedFilters只是优化器的「规划意图」，不是实际执行的证明
  当你写下where(col("a")===1318138224)时，Spark的Catalyst优化器会在逻辑计划阶段识别出这个过滤条件可以下推到数据源层，所以在物理计划里会标注PushedFilters: [IsNotNull(a), EqualTo(a,1318138224)]。但这只是优化器认为应该下推的条件，而实际是否真的让ORC reader执行这个过滤，完全由spark.sql.orc.filterPushdown这个配置开关控制。

  当这个配置设为false时，Spark虽然生成了包含下推标记的物理计划，但ORC reader并不会在读取文件时过滤数据——它会把所有ORC文件的内容全部加载到Spark的内存中，再由Spark在内存层面执行过滤。这就是为什么你的代码耗时3分钟：因为要读取大量无关数据进来。

• 为什么配置设为true后物理计划看起来一致？
  物理计划的文本输出只会展示优化器的规划结果，不会区分「计划下推」和「实际执行下推」。真正的差异藏在数据读取的实际行为里：当spark.sql.orc.filterPushdown=true时，ORC reader会在读取文件的过程中直接应用过滤条件，只把满足a=1318138224的行加载到Spark中，这就是你在Spark UI的Stages模块里看到输入数据量大幅减少的原因，也是代码耗时降到30秒的核心原因。

• 如何验证谓词下推是否真的生效？
  除了看Spark UI的输入数据量，你还可以：

  1. 开启Spark的详细日志（调整日志级别到DEBUG），查看ORC reader相关的日志，会看到是否在读取时应用了过滤条件；
  2. 对比两种配置下读取的文件块数量/大小——下推生效时，只会扫描包含目标数据的文件或文件块，而不是全部文件内容。

总结一下：物理计划里的PushedFilters只是优化器的规划标记，ORC的谓词下推必须开启spark.sql.orc.filterPushdown=true才会真正在数据源层面执行过滤，从而大幅减少数据读取量、提升性能。

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