Spark 3查询分区列MIN值耗时远超Spark 2的原因排查

问题背景 #

我在Spark 2和Spark 3中执行同一查询，获取按dt列分区的Parquet表的最小dt值：

SELECT MIN(dt) FROM table_name

该表存储在S3上，每个dt对应独立文件夹，共约3200天数据。Spark 2中查询1分钟完成，Spark 3中耗时超1小时仍未结束，其执行计划显示全表扫描（无分区裁剪）：

AdaptiveSparkPlan (10)
+- == Current Plan ==
   HashAggregate (6)
   +- ShuffleQueryStage (5)
      +- Exchange (4)
         +- * HashAggregate (3)
            +- * ColumnarToRow (2)
               +- Scan parquet table_name (1)
+- == Initial Plan ==
   HashAggregate (9)
   +- Exchange (8)
      +- HashAggregate (7)
         +- Scan parquet table_name (1)

按分区表逻辑，Spark只需识别存在的分区目录，返回最小dt即可，无需扫描全表，因此对Spark 3的性能问题感到困惑。

核心原因分析 #

Spark 3在分区表元数据处理、分区裁剪逻辑上与Spark 2存在差异，导致未触发预期的分区元数据扫描，转而执行全表扫描：

• 分区元数据不同步：外部表的分区信息未在Metastore中正确注册，Spark 3依赖Metastore元数据做分区裁剪，而Spark 2可能直接扫描S3目录获取分区列表。
• 分区裁剪配置失效：Spark 3默认开启的分区裁剪相关参数被修改，或分区列存在NULL值导致裁剪逻辑不触发。
• AQE（自适应查询执行）干扰：AdaptiveSparkPlan可能在某些场景下覆盖了分区裁剪的优化路径，导致全表扫描。
• 分区目录格式不规范：分区目录未遵循dt=yyyy-MM-dd的命名规则，Spark 3无法识别为分区列，将其视为普通目录。

排查与解决步骤 #

• 验证分区元数据正确性
  执行DESCRIBE EXTENDED table_name，检查Partition Columns是否包含dt，以及分区数量是否与实际S3目录数匹配（约3200个）。
• 刷新分区元数据
  若为外部表，执行MSCK REPAIR TABLE table_name同步S3上的分区目录到Metastore，确保Spark 3能获取到最新分区信息。
• 强制触发分区裁剪
  修改查询，添加分区列非空约束或范围条件，强制Spark识别分区列：

  SELECT MIN(dt) FROM table_name WHERE dt IS NOT NULL
  -- 或添加范围条件
  SELECT MIN(dt) FROM table_name WHERE dt >= '1970-01-01'
  

• 检查并恢复分区裁剪配置
  确认以下参数设置为默认值（或true）：

  spark.sql.hive.metastorePartitionPruning=true
  spark.sql.sources.partitionDiscovery.enabled=true
  

• 临时关闭AQE测试
  关闭自适应查询执行后重新运行查询，验证是否是AQE导致的优化失效：

  SET spark.sql.adaptive.enabled=false;
  SELECT MIN(dt) FROM table_name;
  

• 检查分区目录命名
  确认S3上的分区目录严格遵循dt=yyyy-MM-dd格式，若存在格式错误（如缺少dt=前缀、日期格式不统一），修正后重新同步元数据。

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