🚀 AWS EMR Spark 内存溢出（OOM）排查终极指南

在 EMR 大规模计算中，Spark 内存溢出是家常便饭，别慌！按以下步骤逐一排查，定能精准定位 🎯。

一、 确定 OOM 的“犯罪现场” 🕵️‍♂️

首先通过 Spark UI 或 CloudWatch 查看异常日志，判断是哪种类型的 OOM：

• Driver OOM： 通常是收集了太多数据到本地（如 collect() 过大结果集）。
• Executor OOM（堆内）： 处理单条记录过大、存在严重的数据倾斜、或缓存策略不当。
• Container/Off-heap OOM： 通常是使用了 PySpark、UDF 或 Pandas 库，导致堆外内存（Overhead）不足。

二、 针对性排查思路 🛠️

1. 数据倾斜（Data Skew）—— 最常见的元凶 📉

如果只有少数几个 Task 运行缓慢且最终挂掉，多半是数据倾斜。解决方法：

• 使用 repartition 重新打散数据。
• 对倾斜 Key 加盐（Salt），将 Key 拆分为多个小 Key 进行并行处理。
• 开启 Adaptive Query Execution (AQE)：在 Spark 3.x 中配置 spark.sql.adaptive.skewJoin.enabled=true，让 Spark 自动帮你优化！✨

2. Executor 内存分配不均 ⚖️

检查 spark.executor.memory 与 spark.memory.fraction。如果你的代码涉及大量 Shuffle，调大 spark.memory.fraction（默认0.6）可能有用，但要小心导致执行内存被挤压。

3. PySpark 与堆外内存泄漏 🐍

如果你在处理大规模图片、视频或复杂对象，Python 进程占用的内存往往超出了 JVM 分配的限制。尝试增加：

• spark.executor.memoryOverhead：适当增加到 Executor 内存的 15%-20%。
• 检查是否有大规模创建全局变量或在循环中不断追加 List/Dict 的代码。

4. 广播 Join 大爆炸 💥

如果广播表过大，会将 Driver 或 Executor 直接撑爆。检查：

• spark.sql.autoBroadcastJoinThreshold：是否默认值太大了？手动调小它。

三、 性能调优实战技巧 ⚡

1. 监控利器： 开启 AWS EMR 的 Managed Scaling 和 Spark UI 历史服务器，对比失败任务的内存曲线。
2. 序列化优化： 使用 Kryo 序列化器（spark.serializer=org.apache.spark.serializer.KryoSerializer），能显著减少内存占用。
3. 分治法： 如果任务实在太大，考虑将一个大任务拆解为多个小型 ETL 任务，通过 S3 进行中间存储流转。