Spark处理大于内存的数据集时为何不溢写磁盘反而报OOM错误？

问题成因 #

1. Python UDF内存开销不在Spark溢写管控范围 #

Spark的磁盘溢写逻辑仅覆盖JVM堆内的Execution内存使用场景，而Python UDF运行在独立的Python进程中，这部分内存消耗会被计入YARN Container的总内存配额，但Spark本身无法感知、也不会为Python进程的内存占用触发溢写逻辑。你当前每个Executor仅配置1GB memOverhead，需要同时承担JVM堆外内存、Python进程内存开销，多个task并行跑UDF时很容易突破总内存阈值被YARN杀掉。

2. 全局dropDuplicates的哈希表内存超预期 #

dropDuplicates本质是对全字段做分组聚合，默认用HashAggregate实现，需要在Execution内存中维护哈希表，哈希表的内存占用通常是原始反序列化数据的2_{4倍（需要额外存储哈希值、指针、聚合状态等）。你单task读取80MB序列化数据，反序列化后通常膨胀3}5倍，单task仅哈希表就需要占用480MB~1.6GB内存，5个task并行执行时很容易占满12GB堆内内存分配给Execution的配额，而哈希表内存增长速度快于溢写线程处理速度时，会出现未及溢写就OOM的情况。

3. explode操作的突发内存消耗 #

虽然整体数据增量仅1%，但单条记录最大爆炸200倍，若单个task同时处理多条大爆炸系数的记录，会出现突发内存上涨，这种瞬时峰值根本等不到溢写逻辑触发，直接就会突破内存阈值。

低成本优化方案（无需增加Executor数量） #

• 调整Executor内存分配比例：将12GB堆内+1GB memOverhead改为10GB堆内+3GB memOverhead，总配额不变的前提下给Python UDF留出足够的堆外内存空间。
• 调大spark.sql.shuffle.partitions到4000_{4800，降低单task处理的数据量，单task序列化数据量从80MB降到50}60MB，直接降低反序列化和聚合哈希表的内存占用。
• 强制使用SortAggregate：设置spark.sql.execution.useAggregateHashMap=false，基于排序的聚合逻辑溢写触发更稳定，不会出现哈希表的突发内存占用，仅损失少量性能即可避免OOM。
• 拆分Stage执行：在全局dropDuplicates之后增加一次轻量action操作（比如df.count()），让聚合阶段的内存完全释放后再执行explode和Python UDF逻辑，避免多阶段内存占用叠加。

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