Spark 2.3.1升级至2.4后ETL作业运行时暴涨6倍的排查求助

问题场景 #

• 升级背景：为禁用Instance Metadata Service Version 1，从EMR 5.17.0（Spark 2.3.1）升级至EMR 5.23.1/5.27.1/5.32+（Spark 2.4.x）；测试无安全配置及EMR 5.20.1时问题仍存在，排除安全配置影响。
• 性能现象：无代码变更（所有代码基于Java 8编译），简单ETL作业耗时增至原6倍；4个最慢阶段中3个涉及大型RDD的leftOuterJoin操作，无报错仅耗时/成本剧增。
• 复现情况：spark-shell中复用已物化RDD并持久化到磁盘的代码片段，EMR 5.17中耗时4.6分钟，EMR 5.23.1中耗时20分钟；其他RDD持久化操作无异常。
• 已尝试：查阅Cloudera迁移指南及相关资料，未找到适配RDD场景的解决方案。

排查思路 #

1. 对比Spark版本间RDD Join实现逻辑差异 #

• 重点检查HashJoin/ShuffleHashJoin/SortMergeJoin的触发阈值变化：Spark 2.4.x可能调整了join策略的选择逻辑，例如自动选择SortMergeJoin的条件更严格，导致原本适用HashJoin的大型RDD场景被迫改用开销更高的SortMergeJoin。
• 通过Spark UI对比两个版本中join阶段的shuffle读写量、分区数、单任务执行时间，确认是否存在shuffle数据量激增或分区不合理的情况。

2. 验证RDD持久化的实际复用状态 #

• 尽管已物化RDD，但Spark 2.4.x对持久化RDD在join时的复用逻辑可能有调整，需确认是否存在重复计算或隐性重新shuffle的情况。
• 查看Spark UI的Storage页面，确认目标RDD确实已持久化到磁盘，且join阶段直接读取持久化数据而非重新计算上游依赖。

3. 核对Spark配置默认值差异 #

• 聚焦shuffle相关配置：对比spark.shuffle.sort.bypassMergeThreshold、spark.sql.join.preferSortMergeJoin（RDD join底层可能复用SQL引擎策略）、spark.shuffle.file.buffer、spark.reducer.maxSizeInFlight等参数的默认值，Spark 2.4.x可能修改了这些参数导致shuffle性能下降。
• 检查内存与并行度配置：确认spark.executor.memory、spark.executor.cores等是否被EMR新版本默认调整，导致资源分配不足。

4. 排查EMR集群底层环境变化 #

• 检查YARN配置差异：不同EMR版本的YARN容器内存限制、调度策略可能调整，导致Spark任务无法获取足够资源。
• 验证磁盘IO性能：确认EMR 5.23+是否使用了不同存储类型或IO调度策略，导致持久化RDD的读取速度变慢。

5. 开启详细日志追踪执行流程 #

• 在join阶段开启DEBUG级别的Spark日志，对比两个版本中join的执行步骤，排查是否存在额外shuffle、序列化/反序列化开销增加的情况。
• 分析任务GC日志，确认Spark 2.4.x中GC时间占比是否过高，导致任务执行缓慢。

解决办法 #

1. 强制优化RDD Join策略 #

• 手动对齐两个RDD的分区数：对大型RDD执行partitionBy操作，按join键分区后再执行leftOuterJoin，避免全局shuffle。
• 禁用SortMergeJoin偏好：设置spark.sql.join.preferSortMergeJoin=false，强制Spark优先选择HashJoin（适用于小表join大表的场景）。

2. 调整Shuffle相关配置 #

• 恢复Spark 2.3.1的shuffle默认参数到新版本，例如：
  • 设置spark.shuffle.sort.bypassMergeThreshold=200（Spark 2.3.1默认值），降低SortMergeJoin的触发概率；
  • 增大spark.shuffle.file.buffer至64k、spark.reducer.maxSizeInFlight至96m，提升shuffle读写效率。

3. 优化RDD持久化策略 #

• 使用序列化持久化级别：将RDD持久化级别改为StorageLevel.DISK_ONLY_SER，减少磁盘存储体积与读取时间；
• 显式触发物化：在join前调用rdd.count()强制RDD完成持久化，避免join阶段重新计算上游依赖。

4. 调整集群资源配置 #

• 增大executor资源配额：提升spark.executor.memory与spark.executor.cores，增加任务并行度；
• 调整YARN资源限制：修改yarn.nodemanager.resource.memory-mb与yarn.scheduler.maximum-allocation-mb，确保Spark任务能获取足够的容器资源。

5. 版本适配或补丁修复 #

• 升级至更高版本EMR：若问题是Spark 2.4.x的已知bug，尝试升级到EMR 5.32+及以上版本，查看是否有相关修复；
• 临时降级权衡：若安全配置允许，可临时降级到EMR 5.20.1以下版本，同时跟进官方补丁更新。

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