Spark 3.1作业因YARN容器内存超限失败，如何解决？

一、先排查Key倾斜与Shuffle数据量问题 #

CoGroup Join会将相同Key的全量数据拉至同一Executor处理，大表场景下Key分布不均极易导致单Executor内存过载：

• 查看Spark UI的Shuffle Read模块，统计每个Task的Shuffle数据读取量，定位是否存在热点Key（某几个Task读取量远高于平均值）。
• 针对热点Key的处理：
  • 拆分热点Key：给热点Key添加随机后缀（如key + "_" + rand(0, n)），将热点Key拆分为n个小批次分别做CoGroup，最后合并结果。
  • 过滤无效Key：提前过滤两张表中无业务意义的Key（如Null值、空字符串），减少需处理的数据量。

二、优化Executor内存配置，避免盲目调大Overhead #

内存使用随Overhead配置上涨，大概率是Executor无限制占用堆外内存导致，需精准限制内存分配：

• 调整Executor堆内存与Core的比例：当前executor.core=5，建议堆内存设为10G-12G（1Core对应2-2.4G堆内存是更合理的资源配比），减少堆内存冗余，同时降低堆外内存的依赖。
• 改用百分比配置Overhead：将固定值改为堆内存的百分比，如spark.executor.memoryOverhead=0.2（即堆内存的20%），避免YARN分配过多容器内存后，Executor无节制占用堆外资源。
• 排查内存泄漏：
  • 添加GC日志配置：spark.executor.extraJavaOptions=-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，通过日志查看是否存在频繁Full GC或内存无法回收的情况。
  • 检查代码：确认自定义UDF、全局集合是否持有大对象未释放，或是否存在循环引用导致GC无法回收。

三、调整Shuffle配置，降低内存压力 #

Shuffle阶段是内存超限的高频触发点，通过以下配置优化：

• 增加Shuffle分区数：默认spark.sql.shuffle.partitions=200，大表场景下需调高至800-1500（按每分区数据量100M左右估算），分散单Task处理的数据量。
• 开启Shuffle Spill压缩：设置spark.shuffle.spill.compress=true，使用Snappy压缩磁盘上的Spill数据，减少IO耗时与内存占用时长。
• 调整Sort Shuffle阈值：若Shuffle分区数高于默认的spark.shuffle.sort.bypassMergeThreshold=200，可适当调高该值（如设为500），触发Bypass Sort逻辑，减少内存中排序的资源消耗。

四、代码层面优化CoGroup逻辑 #

• 替换CoGroup为普通Join：若业务逻辑允许，优先使用Spark原生Join（如Sort Merge Join），Spark对Join的内存优化策略更完善，可避免CoGroup带来的全量数据聚合压力。
• 拆分CoGroup流程：将CoGroup后的大结果集先写入磁盘（如Parquet格式），再分批次读取处理，避免内存中积压过多数据。
• 提前聚合数据：在CoGroup之前对两张表分别按Key做预聚合，减少每个Key对应的记录数，降低Shuffle与聚合阶段的内存占用。

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