Spark EMR执行器容器因Java堆内存不足报错求解决方案

针对你使用EMR 200-r7g16xlarge集群（64核/488GB节点）运行Spark任务时出现的Executor堆内存溢出问题，结合提交配置，给出以下优化建议：

一、调整Executor内存分配策略 #

• 当前每个Executor配置为5核/34GB堆内存+5GB内存开销，单节点可容纳12个Executor（512=60核，剩余4核给系统；39GB12=468GB，剩余20GB给节点系统），节点资源利用率合理，但可尝试微调堆内存：将spark.executor.memory提升至36GB，spark.executor.memoryOverhead降至4GB，保持总容器内存39GB不变，直接增加堆内存容量。
• 若集群节点充足，可减少Executor实例数量、提升单Executor内存：比如将每个Executor调整为8核/50GB堆内存+6GB内存开销，单节点可运行8个Executor，单Executor堆内存更大，更适合处理大分区数据。

二、优化窗口函数相关配置与逻辑 #

• 你设置的spark.sql.windowExec.buffer.spill.threshold和spark.sql.windowExec.buffer.in.memory.threshold均为2000000（约2MB），阈值过小会导致频繁磁盘溢写，反而降低性能且可能因频繁IO引发内存波动。建议将阈值调至50000000（50MB）左右，平衡内存使用与磁盘溢写频率。
• 检查窗口函数的PARTITION BY字段：若该字段基数过小（如只有少数几个值），会导致单个窗口的数据量过大，直接撑爆Executor内存。需优化分区字段，尽量让每个窗口的数据量均匀分布；若无法调整字段，可尝试对分区字段加盐（添加随机前缀）拆分窗口，处理完成后再合并结果。

三、调整分区数量与数据分布 #

• 当前初始分区数（24000）和重分区数（24000）设置过大，会导致每个分区数据量过小，增加任务调度开销；但如果分区数过小，又会导致单分区数据量过大。建议根据总数据量调整：假设总数据量为10TB，将初始分区数调整为12000（每个分区约800MB），既保证并行度，又避免单分区内存压力过大。
• 排查数据倾斜：通过Spark UI的Stage页面查看每个Task的输入数据量，定位是否存在单个Task数据量远超平均值的情况。若存在数据倾斜：
  • 对倾斜Key添加随机前缀，拆分为多个小分区并行处理；
  • 若倾斜由Join操作引发，可将小表广播（broadcast()），避免大表分区倾斜；
  • 调整Join策略，优先使用Broadcast Hash Join替代Sort-Merge Join（当小表足够小时）。

四、优化Spark内存管理配置 #

• 调整堆内内存分配比例：默认情况下Spark堆内存中存储（Storage）与执行（Execution）各占50%，窗口函数属于执行操作，可将spark.memory.fraction调至0.8（默认0.6），spark.memory.storageFraction调至0.2（默认0.5），给执行操作分配更多内存。
• 开启列存储压缩：设置spark.sql.inMemoryColumnarStorage.compressed=true，对内存中的列存储数据进行压缩，降低内存占用。

五、检查代码层面内存问题 #

• 排查UDF或窗口函数逻辑：是否在代码中创建了大量冗余对象、缓存了不必要的数据，或存在内存泄漏（如全局变量持续累积数据）。
• 避免在Executor端加载过大的数据集：若有自定义逻辑需加载外部数据，确保数据量在Executor内存承受范围内，或采用分批次加载的方式。

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