在跑离线任务的时候最让人头疼的不是计算慢而是明明前一天还稳定的作业第二天突然在Shuffle阶段大面积OOM。一个接一个的executor被打爆任务反复重试监控面板红色告警不断。尤其在大促或月末跑数这种时间窗口紧张的时候遇到这种问题连排查都是抢时间的。我这几年处理过不少类似的故障从七八台小集群到几十台的中型集群都遇到过。Shuffle阶段的OOM表象就那几个但真正的原因往往是数据倾斜、参数不匹配、代码低效三类问题混在一起单靠“把executor内存调大”解决不了甚至会把问题拖得更久。这篇文章不写大而全的参数手册只讲我在实际排查和调优中验证过的思路、顺序和细节希望能让遇到同类问题的人少走弯路。1. Shuffle阶段为什么总是“内存杀手”1.1 Shuffle过程拆解Map端与Reduce端的内存占用Shuffle说白了就是把数据从上游的Map任务“理顺”再按key分发到下游的Reduce任务去。这个“理顺分发”的过程天然比普通的map/filter操作更吃内存。Map端在做ShuffleWrite的时候每个task会把输出的key-value先写进一个内存缓冲区。基于排序的shuffle会在这个缓冲区里做排序排完如果放不下了就spill溢写到磁盘。这里的问题在于如果某个分区命中的数据特别多这个缓冲区就会反复被写满、spill、排序既有大量磁盘IO又占内存。Reduce端更难控制。每个Reduce任务要从上游所有Map任务拉取属于自己的数据拉下来的数据先落在内存里的一个聚合缓冲中再做combine或者aggregation。如果你用的是groupByKey这类操作同一个key的所有value必须全部留在内存里等着聚合这几乎就是往内存里塞一整份分布式的数据。所以Shuffle阶段的OOM绝大多数不是“哪一行代码写得明显错了”而是“某个环节的数据量远超预期内存缓冲被直接打穿”。这也是为什么排查难度高——你光看代码往往什么都看不出来。1.2 看懂OOM报错的三种现场我在排查OOM时第一件事是看报错的类型。不同报错对应的修复方向完全不同如果用错药方越改越乱。最常见的三种现场java.lang.OutOfMemoryError: Java heap space。这个最直白说明JVM堆内空间被对象全占满了。一般出现在Reduce端的聚合阶段或者Map端spill之前的缓冲区膨胀。此时优先怀疑shuffle分区数太少、单个task数据过大、或者GroupByKey/HashAggregation把数据堆积在了内存里。java.lang.OutOfMemoryError: Direct buffer memory。堆外内存爆了也就是direct buffer或各种native层缓冲区占满了。这种一般和spark.executor.memoryOverhead设置不足有关系尤其是K8s或Yarn环境下container里面除了JVM堆还有一堆元空间和网络缓冲。这种现场最容易被人误判成“堆不够”然后盲目加executor.memory结果越加越崩。ExecutorLostFailure / FetchFailedException。严格说这不算OOM但实际场景里它经常和OOM伴随发生。一个executor崩了之后其他executor去拉它的数据块拉不到就会报FetchFailed。很多人被这个误导以为要调节流参数或者网络参数实际上根因还是某个executor先内存爆了controller在这里需要先把ExecutorLostFailure当作“后续现象”处理而不是只盯着FetchFailed调fetch参数。1.3 自我诊断先分清“真OOM”还是“被杀”这里有个特别普遍的坑就是你看着Yarn或者K8s的事件里写的是“Container killed by OOM killer”但实际上JVM日志里根本没有OutOfMemoryError。我遇到过好几次这类情况Yarn上报executor被物理机层面的oom killer杀了作业日志里却干干净净完全没有OOM堆栈。新手一般就没方向了老手会先去查spark.executor.memoryOverhead。原因不复杂。Spark里的executor内存配置其实只是JVM堆大小但真正的容器内存等于堆内存 overhead内存。overhead主要覆盖线程栈、元空间、JNI、网络缓冲区、Direct Memory等。很多人设了executor.memory8g却没设置memoryOverhead默认值是“max(384MB, 8g*10%)”也就是约819MB。如果8g堆本身真用到了6~7GBJVM里虽然还没报OOM但进程整体占用已经逼近甚至超过了container限额内核一看超限直接杀。这种情况你去调大executor.memory往往是让限制变大但同时物理机内存压力也变大很容易引发雪崩。所以遇到executor被杀第一反应不是调大堆而是先看overhead和物理机总内存规划。2. 排查思路从UI指标到根因定位2.1 第一步不是调参而是看监控我见过太多人一上线就改参数这里加两个G那里调大并发结果问题原地踏步。调优这事第一步永远是观察。打开Spark Web UI重点看三个页面Stage页面能看到每个Stage的Shuffle Read/Write数据量。我一般先看失败的那个Stage把失败task的Shuffle Read字节数和成功task比一比。如果出现“几个task拉到几百MB其他task只有几十MB”这种悬殊差距基本可以断定是数据倾斜。Executors页面这里能看到每个executor的Storage Memory、Shuffle Spill (Memory)、Shuffle Spill (Disk)等指标。如果Shuffle Spill (Memory)的峰值特别高说明缓冲数据接近内存极限已经在持续溢写了如果Shuffle Spill (Disk)也大说明内存已经兜不住了溢写压力巨大磁盘IO也会拖慢整个作业。Event Timeline配合看executor是被驱逐、被kill还是任务超时重试。是否伴随“lost executor”或“node blacklisted”等事件。看的时候记得把时间范围和失败时间对上别拿整个作业的聚合数据去判断那样会把极端的task数据稀释掉。我习惯把失败Stage的上万个task按Shuffle Read大小拉出来排序只看头部几十个倾斜情况一目了然。2.2 内存模型前置知识堆内划分与堆外开销要调Shuffle的内存参数必须先理解Spark 2.x之后的内存管理模型。很多人盯着spark.executor.memory这个值却不知道JVM堆里其实分了好几块。简化来讲executor堆内分三块Reserved Memory固定300MB左右保留内存存Spark内部对象用不参与其他分配。User Memory占比为(1 - spark.memory.fraction)。默认memory.fraction是0.6所以User Memory占堆的40%。这里存用户代码里创建的对象、数据结构、以及通过mapPartitions这类算子处理时产生的临时对象。用户代码如果大量生成Java对象却不释放挤的就是这里。Unified Memory统一内存由spark.memory.fraction决定默认占堆的60%又被分为Storage内存和Execution内存各占一半由storageFraction控制默认0.5。Storage内存用来缓存RDD、DataFrame等数据块Execution内存用来给shuffle聚合、排序、join等操作使用。关键设计是两边可以互相借用但Execution借Storage内存在某些条件下可以把Storage的缓存块挤出去。我在实际调Shuffle时最关心的其实是Execution Memory这一块。Shuffle聚合、merge、sort都在这块内存里进行。如果storageFraction默认0.5意味着统一内存里一半被Storage占着。如果你同时在作业里缓存了大量数据集Storage内存占得满满当当Execution内存即使能借用也在激烈竞争shuffle阶段的内存压力会显著上升。所以一种很实用的战术就是如果作业里没有大量缓存需求把spark.memory.storageFraction调低比如0.2~0.3相当于把统一内存更多留给Execution给Shuffle腾地方。这个调整在很多场景下比重接加executor内存还管用。2.3 用GC日志和堆转储找具体“凶手”UI只能看到表象要确定具体是什么对象把内存吃满了还得靠GC日志。我给executor配的extraJavaOptions里常带这几项-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintTenuringDistribution然后把日志输出到容器日志目录。出问题后把GC日志拉出来看两点是否反复Full GC如果是说明对象一直在老年代堆积且无法回收。单次Full GC后老年代占用是否只降一点点如果是说明内存里有大量长生命周期的大对象极可能就是shuffle聚合用的集合或缓存块。GC日志配合jmap是更好但容器崩了就没办法连上去dump所以我的经验是优先在Spark UI和GC日志里找结论堆转储只是最后手段。如果真想dump要在executor还没死之前用jmap把堆导出来然后灌进MAT或VisualVM看柱状图。shuffle阶段里最常出现的“元凶”就是byte[]、Object[]或者ConcurrentHashMap$Node前者对应大量序列化后的缓存数据后两者对应shuffle聚合时的集合结构。2.4 快速判断数据倾斜task间数据量对比数据倾斜是Shuffle OOM的头号原因。判断方法很直接在Stage页找到最后一个失败的stage点进去看Summary Metrics或Tasks列表按Shuffle Read Size排序。比如某个任务的Shuffle Read Size中位数是20MB但是某3个task分到了800MB这就是教科书级的倾斜。再进一步到SQL的物理计划里看这个Stage对应的SQL片段是group by哪个键基本就能锁定热点key。有些时候肉眼不好定可以写一个简单的查询去统计key分布SELECT key, COUNT(*) AS cnt FROM ( SELECT your_shuffle_key AS key FROM the_table WHERE dt 2025-01-01 ) t GROUP BY key ORDER BY cnt DESC LIMIT 20;能看到前几个key的数量级是后面的几十倍就实锤了。这类倾斜处理我放在后面案例里详细讲因为它不是单纯调参数能解决的往往需要改代码逻辑。3. shuffle调优关键参数逐项拆解3.1 executor内存与进程内存的边界先明确一组最小换算关系进程内存container memory spark.executor.memoryJVM堆 spark.executor.memoryOverhead元空间、栈、DirectMemory等这里的memoryOverhead在Yarn和K8s上都适用K8s场景用spark.executor.kubernetes.memoryOverheadFactor但底层逻辑一样。设executor.memory8g时实际进程大约占8g 1g默认10%再加上NodeManager自身的开销。所以单台物理机分配executor时要把这层“看不见的内存”算进去否则物理内存会被悄悄吃满出现上一节说的“被杀”现象。我通常给executor内存设置时遵循一个经验单Executor内存不要超过物理机内存的四分之一到三分之一。比如64G的机器单个executor最多设16~20G含overhead宁可多开几个小executor也好过一个巨大的executor把机器内存全占完。Executor核数控制在3~5个。核数太多时一个executor上多个并发task同时做shuffle聚合内存压力是叠加的GC也会变得激烈反而不稳。在大集群里优先用中小内存、中核数比如8~12G堆、4核配合spark.dynamicAllocation弹性扩缩容稳定性通常都优于“大内存executor”。3.2 read端与write端关键参数表下面是我在实际调优中常动的几组Shuffle参数。不同计算引擎或部署形态可能默认值有差异但核心逻辑是相近的参数说明我的常用设置参考spark.sql.shuffle.partitions决定shuffle后的分区数/Reduce任务数缺省200按数据量调通常100~1000spark.reducer.maxSizeInFlight单个Reduce Task每次同时拉取的shuffle数据字节上限默认48MB内存紧张时不要动内存充足时最多拉到96MBspark.reducer.maxReqsInFlight同时发起拉取请求的上限保持默认spark.reducer.maxBlocksInFlightPerAddress从同一上游Executive同时拉取的块数上限默认5可以不变spark.shuffle.file.bufferMap端shuffle写文件时的缓冲大小默认32KB一般不动spark.shuffle.spill.compress是否压缩spill到磁盘的数据默认true保持开启spark.shuffle.sort.bypassMergeThreshold小于此分区数时shuffle走bypass路线不排序只合并默认200分区数较少时可以不开spark.shuffle.sort.spill.threshold触发spill的缓冲记录数阈值旧参数新版本不建议手动改spark.memory.fraction统一内存占堆的比例默认0.6spark.memory.storageFraction统一内存中Storage占的比例默认0.5无大量缓存时可降到0.2~0.3spark.executor.memoryOverhead堆外内存预留显式设置如2g~4g或按堆的10~20%spark.sql.autoBroadcastJoinThreshold小表自动广播的阈值默认10MB按实际可用内存调整谨慎放大spark.sql.adaptive.enabled开启AQESpark 3.x建议开启spark.sql.adaptive.skewJoin.enabledAQE自动处理倾斜JoinSpark 3.2建议开启这张表不是让你全调一遍多数时候动其中两三个就够了后面案例里你会看到选择顺序。3.3 并行度与分区数怎么定Shuffle OOM的一个隐蔽推手是Task并行度太低。Spark默认shuffle分区数是200如果数据量有几百GB200个task每个要拉取1GB以上放在8G内存的executor里不死也脱层皮。比较合理的思路是按照“单个Reduce Task的输入量约等于50~200MB”来倒推分区数。假设Stage的Shuffle Read总量是200GB想让单task拉到100MB左右那么分区数就应该设为2000左右。并行度也不是越高越好。分区数过高会带来两个新问题大量小task导致调度开销变大运行时间反而变长。下游stage的输出被切成几千个小文件影响后续读写效率和文件系统压力。所以我在调分区数时会同时看两个指标Shuffle Read Size是否回到合理区间以及最终生成的输出文件是否过多。一般有个公式参考分区数 ≥ 集群总executor核数 × 2如果数据量大再往这个基础上按数据量放大。Spark SQL作业里直接设spark.sql.shuffle.partitionsRDD作业里就是rdd.repartition(n)或coalesce(n, shuffle true)。3.4 高级手段AQE自动优化与广播阈值调整如果你的引擎还在Spark 2.xShuffle调优基本上靠手动。如果已经是Spark 3.x强烈建议开启AQEAdaptive Query Execution它能在运行时动态合并过小分区、自动感知倾斜、自动调整join策略。几个开AQE后变化巨大的场景动态合并分区。默认shuffle分区数设很大但实际大部分task数据量并不大。AQE会把这些小task合并避免调度开销所需内存也自然下降。自动处理Join倾斜。开启spark.sql.adaptive.skewJoin.enabled后遇到倾斜的join key它会把倾斜端拆分增加并发来拉平负载。这跟手动加盐的思路一致但免去了改SQL的成本。动态优化Join策略。小表小于阈值时自动从SortMergeJoin切成Broadcast Hash Join规避大Shuffle。关于broadcast阈值我见过有人为了全用broadcast join把autoBroadcastJoinThreshold开到几百MB结果Driver端或者每个executor都缓存了一份大表内存直接爆炸。广播表本质上是“以内存换Shuffle”要结合executor内存和表大小来决定。我的建议是先保证广播表序列化后的大小不超过executor堆的十分之一再考虑调阈值。4. Shuffle OOM典型调优流程实战4.1 案例背景与第一现场我之前处理过一个某业务线跑离线日志分析的场景。环境大致是20多台物理机单机64GB内存、16核CPU。任务每天处理数百GB到1~2TB的日志数据核心逻辑是先用一个大事务表和一个用户维表做join再按渠道、时间维度做指标聚合。某天开始任务在join之后的第一个聚合Stage大面积报优ExecutorLostFailure (executor 11 exited caused by Container killed by OOM killer)伴随部分FetchFailedException任务反复重试最终失败。第一轮我先加了executor内存从8G调到12G同时也把shuffle分区数从默认200调到500。结果面临的只是把失败时间往后推了半小时最终还是崩。这里其实就暴露了我自己需要反思的一点没有先观察UI就直接堆参数这是典型错误。旁边监控一打开才发现失败Stage里少数task的Shuffle Read Size高达700MB大多数task只有几十MB——典型的倾斜场景而不是单纯内存不够。4.2 逐步定位从倾斜key到参数修正确认倾斜后第一步先定位热点key写了个统计SQL把join key拿出来按count排序发现某个渠道ID的记录数至少是其他渠道的几十倍。业务上这个渠道是主推活动带来的流量数据多不奇怪但走Shuffle时全部挤到同一个task上就直接把内存打爆了。这种场景我给两个方向方向一改SQL对倾斜key单独处理。思路是先把热点key和大表分离开对热点key在map端提前过滤或广播处理不和全量数据一起走SortMergeJoin。实现上可以先取出热点key再对热点key所在的小范围单独做一次map端关键值校验或者广播join而非热点数据继续走常规join最后用union把结果合并。这个方案改动稍大但效果最可控。方向二代码成语。在join key上拼接一个0到N的随机前缀把之前的数据打散成N份。这个方法实现简单但要注意防“数据爆炸”——如果不拆大表对应的keyjoin会产生N倍笛卡尔积反而更爆炸。因此在加随机盐时我会对大表侧也做对应改造让两边都带上相同盐值再join得到结果后再去掉盐值聚合。实际这个案例里我对热度key做了单独处理把热点key的数据量摊到10个task上同时保持其他key不走随机逻辑这样既解决了倾斜又没有放大join量。参数上也同步做了几件具体的事分区数调到1200。因为总量有1TB以上200个分区每个task平均5GB多明显不合理1200分区后单task均值约800MB可控了不少。把sort merge join换成broadcast join那个用户维表实际只有几百MB我把它手动广播了同时将autoBroadcastJoinThreshold调大到一个相对合适的值。这一改join这关完全不做大Shuffle后续聚合的压力少了一大截。开启AQE并打开自动倾斜处理当作兜底。同时我把executor核数从6降到4让并发task数变少每个task拿到的内存资源更充沛GC压力也下来了一些。executor内存保持12Goverhead显式设到2G避免“看起来堆没满实际上进程被杀”的情况再出现。4.3 调优效果与“为什么有效”调完之后同一份作业从原先的3小时左右缩短到约1小时且不再OOM。失败率归零。回头看为什么有效简要说三点先手处理倾斜而不是硬扛内存。倾斜才是导致局部内存破口的直接原因加内存只是给“破口”变宽的墙但水压不变迟早还是漏。减少不必要的Shuffle数据量。广播维表、避免大表全量Join等于从源头把Shuffle总流量降下来内存压力自然缓解。让内存分配更匹配Task的实际规模。于是并行度高了、并发task少了、堆外预留充足了每个task能分到的内存空间处于“刚好够用但不会溢出”的区间。这里我也提醒一句加随机盐处理倾斜时盐的倍数不是越大越好。曾经有人直接随机加100个盐等于把数据量平空放大100倍不仅没有解决反而把整个作业的IO和时间拖垮。做盐值处理前最好先确认热点key的数据量和其他key差几个数量级再定加几份盐。5. 参数调优后仍然OOM的常见坑5.1 高频误区速查光套参数而不理解内存模型很容易掉进下面的坑。误区本质解决办法一直加大executor内存不解决局部倾斜物理机内存可能被吃满先查倾斜再按需加内存忘了调memoryOverhead进程被杀而非JVM OOM显式调spark.executor.memoryOverheadgroupByKey用得多同key值在内存中无法增量聚合改用reduceByKey/aggregateByKeystorageFraction过高Storage缓存挤压Execution内存无缓存时降到0.2~0.3分区数过多小文件/调度开销反而压垮任务按“单task几十~几百MB”校准广播阈值盲目调大大表广播占满所有executor堆上限为executor堆的10%忽视spill指标已疯狂溢写还不调内存看Shuffle Spill (Memory/Disk)评估没开AQE手动优化滞后且漏掉倾斜Spark3开启adaptiveskewJoin只信报错文字不看UI拿FetchFailed当网络问题先定位ExecutorLost根因一次调多个参数无法区分是谁起效一次只改一个变量并记录5.2 针对典型场景的对症措施如果你还没理清方向可以参考下面这套选择逻辑现象是某个executor直接被杀且JVM没报OOM堆栈 → 优先调memoryOverhead检查单机总内存分配。现象是整个Stage所有task都报heap space → 优先并行度/分区数再看executor内存是否真的过小。现象是一部分task报OOM另一部分跑得很快 → 数据倾斜优先加盐或拆分热点key同时配上AQE skewJoin。现象是Shuffle Spill (Disk)巨大作业极慢但未必OOM → 说明内存已经严重不足调高内存或降低storageFraction减少spill。现象是代码里用了groupByKey做求和/计数 → 用它改成reduceByKey或直接用SQL聚合内存立省。很多人在最后一步卡住往往不是因为知识不够而是参数与代码夹杂着同时调整出了问题难定位。我现在的习惯是一次改动只围绕一个假设展开改完跑一小批数据验证记录前后差异。反复几次后哪个变量起了决定性作用心里非常清楚。6. 写在最后调优的边界和我的体会Shuffle阶段的OOM和数据量、资源规格、代码质量、引擎版本全都相关没有一组“万能参数”能覆盖所有情况。我必须承认最难的步骤其实是识别出瓶颈到底在哪儿而不是执行调整动作本身。先看UI、再抓GC、再定位热点key这套流程走下来大部分Shuffle OOM都能被拆解成普通问题。我个人的经验是在调优之前先把作业本身的Shuffle数据总量、task分布、缓存用量打底理解透。数据总量都不知道参数改来改去就是盲人摸象。另外稳定调优之后一定要把参数固化到作业配置或团队规范里否则下一次作业重提可能又回到老路。给作业留一个必要的运行基线把GC时间、耗时、资源使用率记录清楚对以后每次变更做对比都很有价值。最后分享一个我反复踩过的坑遇到OOM先冷静别急着在群里喊加内存。加内存只解决了“资源不够”的表象却经常掩盖了“数据不平衡”的实质。与其给某个task准备足够吞下800MB数据的堆不如改掉那个让数据全挤到一个task里的逻辑。这一层想通了Shuffle相关的问题基本就成功了大半。