Spark从3.2.1升级至3.4.2后性能下降问题咨询

已知版本差异导致的性能影响点 #

Spark 3.4.x相对于3.2.x在核心执行逻辑和默认配置上有不少调整，部分变更可能直接导致作业性能下滑：

• 自适应执行（Adaptive Execution）的子特性默认开启范围扩大，比如spark.sql.adaptive.skewJoin.enabled默认从false改为true，若作业无数据倾斜场景，该特性会带来额外的检测开销。
• Shuffle排序逻辑做了优化，但在小数据量或低并发场景下，新逻辑的额外开销会凸显。
• 动态分区修剪（Dynamic Partition Pruning）的逻辑增强，部分场景下可能出现误判，导致扫描更多分区数据。

关键配置调整建议 #

针对上述问题，可通过以下配置调整快速验证性能恢复：

• Shuffle 分区与自适应执行优化：

  # 手动设置合适的Shuffle分区数（根据数据量调整，建议200-1000）
  spark.sql.shuffle.partitions=500
  # 保留自适应执行，但限制最小合并分区数，避免生成过多小分区
  spark.sql.adaptive.coalescePartitions.minPartitionNum=200
  # 若无需数据倾斜处理，关闭skewJoin检测
  spark.sql.adaptive.skewJoin.enabled=false
  

• 广播Join阈值调整：

  # 增大广播阈值，减少不必要的Shuffle操作（示例为50MB，根据实际数据大小调整）
  spark.sql.autoBroadcastJoinThreshold=52428800
  

• 内存与序列化优化：

  # 确保使用Kryo序列化降低开销
  spark.serializer=org.apache.spark.serializer.KryoSerializer
  # 调整Executor内存overhead，避免OOM或GC频繁（建议为executor内存的10%-20%）
  spark.executor.memoryOverhead=4g
  

• 临时关闭潜在影响特性：

  # 若动态分区修剪导致扫描数据量异常，临时关闭验证
  spark.sql.optimizer.dynamicPartitionPruning.enabled=false
  

其他用户的类似问题及解决经验 #

• 不少用户反馈升级后Shuffle阶段耗时翻倍，通过手动指定spark.sql.shuffle.partitions并关闭squeezePartitions特性（spark.sql.adaptive.squeezePartitions.enabled=false）解决。
• 部分用户遇到广播Join未触发，导致全量Shuffle，调整spark.sql.autoBroadcastJoinThreshold到合理值后恢复性能。
• 有用户因Spark 3.4默认启用的spark.sql.execution.arrow.maxRecordsPerBatch过小，导致批量处理效率下降，调整为100000后改善。

排查步骤 #

1. 对比新旧版本作业的Spark UI，定位耗时差异最大的阶段（Shuffle、数据扫描、Task执行等）。
2. 查看Task级别的Metrics，重点关注GC时间、Shuffle读写量、数据倾斜情况。
3. 逐个调整配置进行验证，确定哪个变更对性能恢复最有效。

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