凌晨两点被电话叫醒，睡眼惺忪地打开监控面板，Driver 日志里赫然躺着那一行红字：org.apache.spark.SparkException: Job aborted due to stage failure: Task 1 in stage 0.0 failed 4 times。如果你正在数据平台、离线数仓或者实时链路里做 Spark 开发，这行报错大概率是你见到的第一个、也是见得最多的一个。它像一扇门，门后面可能是数据倾斜、可能是内存溢出、可能是序列化炸了、也可能是容器被系统直接干掉。麻烦的地方在于，这句话本身什么都没告诉你——它只说"任务失败了四次，作业中止了"，至于为什么失败，被埋在几百兆日志的某个角落里。
这篇内容就是从这行报错出发，把从定位、诊断到修复的整条链路讲透。适合刚接手 Spark 作业的同学，也适合已经能跑通作业但一遇到报错就抓瞎的同学。不讲虚的，全是排查顺序、日志捞法、参数计算和踩坑记录。核心关键词org.apache.spark.SparkException、Job aborted、stage failure、Task failed会自然出现在各个排查环节里，不堆砌，按实际语境来。
1. 报错信息到底在说什么：从 Stage 与 Task 的层级关系拆解
很多人看到这行异常的直觉反应是"去搜一下怎么解决"，结果搜出来一堆抄来抄去的答案，让加内存、让调并行度，改完还是报。根本原因是没有真正读懂这句话在描述什么。Spark 的异常信息是有结构的，读懂结构比记住结论重要得多。
1.1 一行异常背后的三层嵌套：Job、Stage 与 Task
Spark 的执行模型是三层嵌套的：一个 action（比如count、collect、saveAsTextFile）触发一个Job；Job 会按照宽依赖（也就是发生 shuffle 的地方）切分成若干个Stage；Stage 内部再按照 RDD 的分区数拆成若干个Task，一个分区对应一个 Task。这三层的关系就像公司、部门和员工：Job 是项目，Stage 是部门，Task 是真正干活的员工。现在报错说的是"某个员工失败了四次"，于是部门没法交付，整个项目被中止。
Job aborted due to stage failure这句话的因果关系很明确：先有 stage failure，才有 job aborted。而 stage failure 的直接原因，是它下面某个 Task 连续失败并超过了重试上限。所以真正的病灶永远在 Task 层面，Job 和 Stage 只是被牵连的受害者。诊断的时候，务必把注意力放在那条被反复重试的 Task 上，而不是去研究 Job 为什么被中止。
另外，Stage 会因为某个"决定性"的 Task 失败而整体失败，但同一 Stage 里其他 Task 可能是成功的。这就解释了为什么你在 Spark UI 上经常看到"绝大多数 Task 都绿了，只有一两个红着"，然后整个作业挂掉。这不是调度器抽风，而是设计如此——Stage 的输出必须完整，缺一个分区就没法往下走。
1.2 为什么是 "failed 4 times"：重试机制与失败计数规则
这个 "4 times" 不是随便写的一个数字，它来自配置项spark.task.maxFailures，默认值就是 4。也就是说，同一个 Task 会被尝试执行 4 次，如果第 4 次仍然失败，Spark 才放弃并抛出这个异常。这里有个非常关键的推论：报错现场那次失败，只是压垮骆驼的最后一根稻草，前三次失败的日志才是真正的线索。很多人只看最后一条堆栈，结果看到的是FetchFailedException或者笼统的Exception，真正的Caused by反而在前面几次的日志里。
需要区分的是，spark.task.maxFailures统计的是任务本身执行失败，而因为拉取 shuffle 数据失败（fetch failure）触发的失败，受另一个配置spark.shuffle.maxFetchFailures影响，默认值在较新版本里是 10。这两个计数是分开的，如果你在日志里看到failed 4 times但spark.shuffle.maxFetchFailures设成了 10，那说明这几次失败不是 fetch failure 引起的，而是实打实的计算异常，这个区分在排查时能帮你砍掉一半的猜测方向。
还有一个容易被忽略的机制是推测执行（speculation）。开启spark.speculation=true之后，Spark 会对那些明显比其他 Task 慢的"拖后腿"任务启动一个副本同时跑。这样一来，你可能会在日志里看到同一个 Task 出现多次启动记录，但它们不一定是失败重试，也可能是在跑副本。区分方法看日志里的attempt编号，Task 1 in stage 0.0 failed 4 times中的 attempt 编号会递增，而推测执行的副本通常出现在不同 executor 上、且原始 attempt 还没被标记失败。
1.3 "stage 0.0" 这个编号透露的隐藏信息
不同 Spark 版本里，Stage 编号的格式略有差异。较早版本常见stage 0.0这种写法，含义是"第 0 个 Stage 的第 0 次尝试"；Spark 3.x 里更常见的是stage 0.0同样表示 stageId 加点号加 attemptId。理解这个编号的意义在于：它能告诉你失败发生在整个 DAG 的哪个位置。
如果失败的是 stage 0，那通常意味着问题出在数据读取阶段——读文件、读数据库、读 Kafka，或者作用在源数据上的第一个 map/UDF。这一阶段出问题的高频原因是：源文件格式与解析方式不匹配（比如把损坏的 Parquet 当正常文件读）、UDF 里对空值没做保护、读取的数据里有脏行导致反序列化炸掉。这类问题的特点是数据驱动，同样的代码换一批数据可能就正常了，所以千万不要只盯着代码改，要先看数据。
如果失败的是比较靠后的 stage，尤其是中间那些带shuffle的，那问题大概率集中在数据倾斜、shuffle 落盘、内存不足这几个方向。还有一种情况是 DAG 里 stage 数量不多、但每个 stage 都很大，失败往往发生在聚合或 join 环节，这就要往数据分布和 key 的基数上想。判断 stage 位置这件事，花两分钟看 Spark UI 的 DAG 可视化，比翻半小时日志效率高得多。
2. 定位真凶的正确姿势：把根因从几百兆日志里捞出来
知道异常结构之后，下一个动作就是找根因。这一步的难点不在技术，而在耐心和方法——日志量动辄几百兆到几个 G，靠肉眼翻是自虐。我自己的习惯是先建立一套固定的检索流程，用几个 grep 把范围迅速收窄，然后再精读。
2.1 先捞 Root Cause：从 Driver 日志入手的关键字序列
Driver 日志里那段以Task 1 in stage 0.0 failed 4 times, most recent failure:开头的段落，是整份日志里信息密度最高的地方。它后面通常会跟着一个完整的堆栈，堆栈最底部的Caused by就是根因。如果Caused by有多层，看最内层那个——它才是最初抛出的异常。
实际操作里，我一般按这个顺序 grep：
# 1. 找出所有失败任务的标记行，拿到 task 编号、executor 主机和异常类名 grep -n "Lost task" application_xxx.log | head -50 # 2. 找出所有根因，统计出现频次，频次最高的那个基本就是主因 grep -n "Caused by" application_xxx.log | sort | uniq -c | sort -rn | head -20 # 3. 如果是内存问题，直接搜 OOM 关键字 grep -n "OutOfMemoryError\|GC overhead limit\|Direct buffer memory" application_xxx.log # 4. 如果是容器被杀，搜退出码 grep -n "Container killed\|exit code 137\|exit code 143" application_xxx.log这几条命令下来，方向基本就定了。我要强调的是第 2 条——统计频次这个动作非常重要。如果Caused by里出现最多的是某个NullPointerException，那它是主因；如果出现最多的是OutOfMemoryError，那方向就完全不同。不要被最后一条堆栈带偏，要看统计结果。
2.2 从 YARN / 容器日志里找第二现场
Driver 日志只记录了失败的"结论"，真正的事故现场在 Executor 那侧。如果是跑在 YARN 上，用yarn logs -applicationId <appId>可以拉到全部容器日志，或者直接去 ResourceManager 的 Web UI 里按 container 下载。如果是跑在 K8s 上，kubectl logs配合kubectl describe pod是标配，后者能看到容器是不是被 OOMKilled 或者被驱逐。
这里就不得不提一类很典型的场景：Executor 容器根本没起来，或者刚起来就被系统干掉。这时候 Driver 侧看到的仍然是 Task failed，但真实原因在容器层面，比如容器运行时返回了error response from daemon: failed to create task for container: failed to create containerd task这种错误。这类信息 Driver 日志里不会有，必须去节点上的容器运行时日志或者 K8s 事件里找。遇到"改代码怎么改都没用"的情况，先确认容器是不是稳定，往往能省下大量时间。
如果把 Spark 用在有状态存储的场景（比如结构化流用了 RocksDB 作为状态后端），还会遇到error running remote compact task: connection failed: error sending request这类报错。它的表现也是任务失败、作业中止，但病根在状态存储的远程连接上，跟计算逻辑没关系。这类问题的排查入口是状态存储服务本身的健康状态和网络连通性，不是 Spark 参数。
2.3 一张速查表：不同根因对应的病灶与优先动作
把常见根因整理成表格，方便对号入座。这张表是我自己排错时随手记下来的，实测能覆盖八成以上的情况。
| 日志关键特征 | 大概率根因 | 优先动作 |
|---|---|---|
java.lang.OutOfMemoryError: Java heap space | 单 Task 处理数据量过大，堆内存不足 | 看数据倾斜、调大 executor 内存或降低单分区数据量 |
GC overhead limit exceeded | 垃圾回收占满 CPU，内存濒临耗尽 | 减少缓存、降低对象创建、调大堆内存 |
java.lang.OutOfMemoryError: Direct buffer memory | 堆外内存不足，常见于大量 shuffle 或网络传输 | 调大memoryOverhead，检查网络缓冲区设置 |
Container killed by YARN for exceeding memory limits | 物理内存超限被外部杀掉 | 计算 overhead，调整executor-memory与memoryOverhead |
NotSerializableException | 闭包里引用了不可序列化的对象 | 检查 UDF 和闭包捕获的变量 |
FetchFailedException/Failed to connect | shuffle 数据拉取失败，executor 挂或磁盘满 | 查 executor 存活与磁盘用量 |
Task failed while writing rows/ 文件写入异常 | 输出路径冲突或权限问题 | 检查输出目录与权限 |
容器层failed to create task for container | 容器运行时或节点资源问题 | 查节点事件与运行时日志 |
有这张表打底，绝大多数报错都能在几分钟内锁定范围。剩下的就是针对性的修复，而不是盲目调参。
3. 数据倾斜：Stage 失败最常见的那只黑手
如果让我给"Stage 失败"的原因排个序，数据倾斜稳定排第一。它的迷惑性在于：代码看起来完全正确，逻辑上也没毛病，但就是某些 Task 死活跑不完。更气人的是，同一个作业换一批数据可能就好了，让人误以为是"偶发"，实际上是数据分布变了。
3.1 怎么确认是倾斜，而不是别的
判断倾斜最直接的地方是 Spark UI 的 Stage 详情页。点进失败的 Stage，看两个东西：Task 的执行时间分布和Shuffle Read Size 分布。健康的 Stage 里，Task 耗时的中位数和最大值差距通常在一两倍以内；倾斜严重时，你会看到绝大多数 Task 几秒到几十秒就结束了，而个别 Task 跑了十几分钟甚至几十分钟，最后 OOM 挂掉。Shuffle Read Size 也是同样的分布形态，个别 Task 读了几百兆甚至几个 G，其他 Task 只有几兆。
还有一个辅助判断方法：看失败 Task 是否总是落在同一个 key 上。如果你在代码里加了一点日志，把当前处理的分区里数据量最大的 key 打出来，倾斜的时候往往能看到某个 key 的数据量比第二名高两三个数量级。这种情况几乎可以确定是热点 key 导致的。我在实际项目里见过最夸张的一次，某个用户 ID 占了整张表 40% 的数据量，因为它是个爬虫账号，日志被打爆了。
3.2 加盐打散：最简单的倾斜解法与它的代价
最通用的倾斜处理手段是给 key 加随机前缀，也就是俗称的"加盐"。核心思路是把一个热点 key 人为拆成 N 份，让它们分散到不同 Task 上去，最后再做一次合并。代码大概长这样：
import pyspark.sql.functions as F # 第一步：对待聚合表加上随机盐值，盐的粒度决定打散程度 salt_range = 16 df_salted = df.withColumn( "salted_key", F.concat(F.col("user_id"), F.lit("_"), (F.rand() * salt_range).cast("int")) ) # 第二步：按 salted_key 做第一次聚合，热点被拆成 16 份并行处理 partial = df_salted.groupBy("salted_key").agg(F.sum("amount").alias("partial_amount")) # 第三步：去掉盐，做第二次聚合得到最终结果 final = partial.withColumn( "user_id", F.split(F.col("salted_key"), "_")[0] ).groupBy("user_id").agg(F.sum("partial_amount").alias("total_amount"))这个方案的好处是简单、见效快，缺点是多了一次 shuffle。盐的粒度salt_range是个需要权衡的参数：太小打散不彻底，太大第二次聚合的压力反而上来了。我的经验是先用 16 试，看 UI 上 Task 耗时分布是否均匀了，如果最大的还是明显偏大，再往上加到 32 或者 64。另一个经验是不要给所有 key 都加盐，只给热点 key 加，否则全量数据都要多走一轮 shuffle，成本不划算。识别热点 key 的方法是先做一次count排序，把 top 几百个 key 拿出来单独处理。
3.3 两阶段聚合与 map 端预聚合的取舍
除了加盐，还有两个思路可以组合使用。一个是map 端预聚合，也就是依赖reduceByKey而不是groupByKey。前者会在 map 端先把相同 key 的数据做一次局部合并再发送，能显著减少 shuffle 数据量；后者会把所有原始数据全量搬到 reduce 端，倾斜时几乎必炸。这个选择应该是习惯性的，看到groupByKey就条件反射地换成reduceByKey或者aggregateByKey。
另一个是两阶段聚合，本质上和加盐是一回事，但更强调"分而治之"：第一阶段按(key, 随机前缀)聚合，第二阶段去掉随机前缀再聚合。它和加盐的区别主要在抽象层次——加盐是在数据上做手脚，两阶段聚合是在逻辑上做拆分。实际写代码时，用 DataFrame API 的withColumn加盐、再groupBy两轮，就是最常见的落地方式。
需要提醒一个坑：加盐之后，如果 final 阶段的结果要 join 回原始表，一定要记得去掉盐值再做匹配，否则会大面积匹配不上，出现"结果莫名其妙变少"的问题。这个我踩过，当时排查了半天以为是数据丢了，结果是自己忘了split去盐。
4. 内存与资源配置：Executor OOM 的几种典型形态
内存问题排在倾斜之后，但有时候它俩是因果链——倾斜导致单 Task 数据量暴涨，进而内存溢出。所以排查时经常要一起看。内存类报错的难点在于，"内存不够"有好几种完全不同的形态，用错了解决方案反而会更糟。
4.1 堆内溢出、堆外溢出与容器被杀的区别
第一种是java.lang.OutOfMemoryError: Java heap space，这是堆内内存不够，说明 JVM 里存活的对象太多，垃圾回收收不回来。常见于大宽表 join、collect到 Driver、或者一个分区里数据量确实太大。应对方式是减少单次处理的数据量（提高并行度、拆分区）、或者适度调大spark.executor.memory。
第二种是java.lang.OutOfMemoryError: Direct buffer memory或者GC overhead limit exceeded。前者是堆外内存紧张，通常和网络传输、NIO 缓冲区有关，光调executor-memory没用，得调spark.executor.memoryOverhead；后者说明 GC 已经把大部分 CPU 时间吃掉了，程序还活着但基本没在干活，这时候要看的不是"内存够不够"，而是"对象是不是创建得太频繁"。
第三种最隐蔽：日志里根本没有 OOM 字样，但 executor 容器被外部杀掉了。YARN 上会看到Container killed by YARN for exceeding memory limits，K8s 上 Pod 状态是OOMKilled。这种"物理内存超限"的判定标准是 executor 总内存（堆内加堆外）超过了容器配额。堆外内存的默认配额由spark.executor.memoryOverhead控制，默认是max(384MB, 0.1 * executorMemory)。很多人只调executor-memory，忘了 overhead 会跟着涨，结果容器配额没同步调，还是被杀。
4.2 关键参数的计算过程与设置建议
配置内存不能拍脑袋，得算。假设集群单节点是 64G 内存、16 核，我打算开 4 个 executor，每个 executor 分配 4 核，那么每个 executor 的容器总内存配额大约是64G / 4 = 16G。这 16G 里要包含堆内存、堆外内存、以及容器本身的元数据开销，所以经验上堆内存给到12G左右比较稳妥：
executor-memory = 12G memoryOverhead = max(384MB, 0.1 * 12G) = 1.2G 容器总需求 ≈ 12G + 1.2G + 少量常量开销 ≈ 13.5G留出约 2.5G 的余量给系统和其他进程，这样不容易被节点上的其他东西挤爆。如果作业里有大量 shuffle 或者用了 off-heap 缓存，overhead 建议单独调大，比如直接设成2G，不要依赖默认比例。
还有一个关键参数是spark.executor.cores。它决定了单个 executor 里能并行跑几个 Task，进而决定了每个 Task 能分到多少内存。分配公式可以粗略理解为：
单个 Task 可用内存 ≈ executor-memory / (executor-cores + 1)那个 "+1" 是留给执行线程之外的内存使用（比如缓存、外部调用）。假设executor-memory=12G、executor-cores=4，那每个 Task 大约能用到 2.4G 堆内存。如果你的 Task 需要处理几百兆的分区数据，这个额度很可能不够，要么调大 executor 内存，要么提高并行度把分区切小。不要试图用"开很多 core"来解决内存问题，cores 越多，单个 Task 分到的内存越少，反而更容易 OOM，这是我见过最多的反面案例。
4.3 并行度、分区数与内存的联动关系
并行度这个参数经常被当成"越大越快"，实际上它和内存是一对跷跷板。spark.sql.shuffle.partitions默认是 200，意味着 shuffle 之后产生 200 个分区。如果你的数据量只有几百兆，200 个分区里每个分区没多少数据，Task 调度开销反而占了主导；如果数据量是几百 G，200 个分区每个分区就有几个 G，单个 Task 必然 OOM。合理的分区数应该让每个分区处理的数据量落在100MB 到 200MB这个量级，太少调度开销大，太多单 Task 压力大。
实测下来，一个比较实用的调整方式是：先按数据总量估算。假设 shuffle 后数据量是 100G，每个分区目标 128MB，那分区数大概是100 * 1024 / 128 ≈ 800。设置spark.sql.shuffle.partitions=800之后再看 UI，如果 Task 耗时分布均匀且没有 OOM，就说明合适；如果还有个别 Task 明显偏慢，说明是倾斜而不是并行度问题，得回到第 3 节的方法。
对于输入数据，尤其是小文件很多的场景，还要在读取时做合并。spark.sql.files.maxPartitionBytes默认 128MB，控制单个读分区的大小；spark.sql.files.openCostInBytes会估算打开文件的成本，把小文件合并进同一个分区。这两个参数配合好，能避免"一个分区里挂了几万个小文件"这种读都读不完的情况。
5. 序列化、Shuffle 与容易被忽略的隐藏坑
前面三节讲的是大类问题，这一节讲那些"看起来不像问题、实际上很要命"的细节。它们往往出现在代码写得很规范、参数也调了、但就是失败的场景里。
5.1 序列化异常：闭包到底抓了什么
NotSerializableException是 Task 失败的常客，在stage 0.0这种早期 stage 里尤其常见。它的根源是：你在算子（map、filter、foreach）里引用了不可序列化的对象。Spark 会把整个闭包序列化后分发到各个 executor，如果闭包里藏着数据库连接、文件句柄、或者某个没实现Serializable接口的自定义类，序列化就会在分发阶段炸掉。
一个经典场景是在foreachPartition里使用了 Driver 侧创建的单例对象。另一个场景是 UDF 里引用了外部的SparkSession或者某个配置对象。排查方法很简单：看堆栈里NotSerializableException后面跟的类名是什么，那个类就是罪魁祸首。解决方案通常是两种：把对象在 executor 内按需创建（用mapPartitions而不是引用外部实例），或者把它声明成transient并配合@transient lazy val做延迟初始化。
序列化性能本身也值得优化。Spark 默认用 Java 序列化，慢且体积大，换成 Kryo 通常能省 30% 到 50% 的序列化开销：
val conf = new SparkConf() conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer") conf.set("spark.kryo.registrationRequired", "false") conf.registerKryoClasses(Array(classOf[MyCustomClass], classOf[MyAnotherClass]))注意 Kryo 有一个registrationRequired选项，如果设成true，所有没注册的类都会报错。好处是能提前发现"序列化悄悄走了慢路径"的问题，坏处是第三方库的类特别多、注册起来很烦。我一般在开发阶段用true把该注册的类找齐，上线前根据不同版本的稳定性决定是否保留。
5.2 Shuffle 失败：拉不到数据的那些原因
FetchFailedException在stage failure里出现频率极高，它的意思是下游 Task 去上游拉 shuffle 数据时失败了。原因主要有三类：一是上游 executor 挂了，数据随之丢失；二是磁盘满了，shuffle 数据写不下去或者读不出来；三是网络或临时目录异常。
排查这类问题的顺序是：先看上游 executor 为什么挂（如果是 OOM，回到第 4 节），再看 shuffle 临时目录所在的磁盘使用率。spark.local.dir在多磁盘机器上可以配置成多个目录，用逗号分隔，Spark 会轮询写入，能显著缓解单盘压力。另外，如果作业规模大、executor 频繁上下线，可以考虑开启外部 shuffle 服务，让 shuffle 数据不随 executor 生命周期消失：
# 在 spark-defaults.conf 里开启外部 shuffle 服务 spark.shuffle.service.enabled true spark.dynamicAllocation.enabled true spark.dynamicAllocation.minExecutors 2 spark.dynamicAllocation.maxExecutors 50动态资源分配配合外部 shuffle 服务，是我认为在现代集群上跑 Spark 的"基本礼仪"。前者让 executor 按需增删，后者保证 executor 被回收时 shuffle 数据仍然可用。少了任何一环，在大作业里都容易出现"跑着跑着资源被回收，然后 fetch 失败"的诡异现象。
5.3 和容器、状态存储相关的失败：别只盯着 Spark 自己
现在越来越多 Spark 跑在 K8s 或者托管平台上，报错来源就超出了 Spark 自己的范围。前面提到的error response from daemon: failed to create task for container: failed to create containerd task，本质是节点上的容器运行时没能把 Pod 拉起来，可能是镜像拉取失败、可能是节点资源碎片化、也可能是安全策略拦截。这种情况下 Spark 侧只会告诉你"Task 失败了"，但你去改代码毫无意义。
判断方法是看失败的规律：如果失败总是集中在某几个节点，或者总是在作业刚启动、executor 还没跑热的时候，那大概率是资源调度或容器层面的事。kubectl describe pod看 Events，kubectl get events --sort-by=.lastTimestamp看时间线，往往比 Spark 日志更接近真相。我遇到过一次，节点本地磁盘被之前的容器日志塞满，新的 executor pod 起不来，Spark 侧表现就是规律性的 Task 失败，清完磁盘立刻恢复。
6. 常见问题与排查技巧实录
前面几节是"分类讲解"，这一节是我在实际排错中攒下来的一些零散经验。它们不一定成体系，但每一条都对应过具体的故障现场，实用性比较强。
6.1 排查顺序速查表
遇到Job aborted due to stage failure，我现在的固定动作是这样的，顺序不轻易变：
- 在 Driver 日志里 grep
Lost task，拿到失败的 task 编号、executor 主机、异常类名。 - grep
Caused by并统计频次，确定根因类型。 - 如果根因是 OOM，去 Spark UI 看 Stage 的 Task 耗时分布和 Shuffle Read Size 分布，判断有没有倾斜。
- 如果根因是 FetchFailure，去查上游 executor 的存活记录和磁盘使用率。
- 如果根因是序列化，看
NotSerializableException后面的类名，定位闭包引用。 - 如果根因是容器层错误，跳出 Spark，去 K8s 事件或 YARN 容器日志里找。
- 修复之后，用同一批数据复跑，并在 Spark UI 上确认 Task 分布已经均匀。
这个顺序的逻辑是"从 Spark 内部往外部走"：先确认是不是计算逻辑或数据的问题，再确认资源问题，最后才怀疑平台层。因为大多数故障确实发生在前三步，跳过它们直接怀疑平台，容易白折腾。
6.2 几个能救命的日志与配置开关
有几个配置项我几乎在每个生产作业里都会打开，它们能让出事时的日志信息量翻好几倍：
# 让 Spark 在任务失败时保留更多信息 spark.task.maxFailures=4 # 把事件日志记到 HDFS 上，History Server 能看完整过程 spark.eventLog.enabled=true spark.eventLog.dir=hdfs:///spark-logs # 加大 Driver 和 Executor 日志级别，便于排查 spark.driver.extraJavaOptions=-Dlog4j.configuration=file:/path/to/log4j.properties # 开启 GC 日志，OOM 的时候能看清回收过程 spark.executor.extraJavaOptions=-XX:+PrintGCDetails -XX:+PrintGCDateStamps其中spark.eventLog.enabled是性价比最高的一个。很多故障发生在凌晨，等人醒了作业早结束了，如果没有事件日志，只能靠残留的容器日志拼凑现场，非常痛苦。开了事件日志之后，用 History Server 能看到完整的 Stage、Task、Executor 时间线，甚至能看到每个 Task 的输入输出大小。GC 日志同理，OOM 时如果看不到回收曲线，只能猜"内存是不是够"，能看到之后就是"哪一段对象分配最猛"，效率完全不同。
还有一个技巧是临时把spark.task.maxFailures从 4 调大到比如 10。这不解决问题，但能让同一批数据多跑几次，方便观察失败是不是稳定复现、是不是固定在某个 task 上。这个手段只适合排查期使用，生产环境不要留着，否则一个真正的死循环会拖很久才暴露。
6.3 我个人踩过的坑与经验小结
第一个坑是只看最后一次失败。刚开始做 Spark 的时候，我总习惯看日志末尾那一条，结果每次都看到类似FetchFailedException这种"间接原因"，改了半天 shuffle 参数没用。后来才养成习惯，把四次失败全看一遍，并且找Caused by里最内层的那个异常。这个习惯帮我省下的时间，加起来大概够我看完两季美剧。
第二个坑是盲目调大executor-memory。曾经有个作业一直 OOM，我一路把内存从 8G 调到 24G，还是 OOM，还差点把集群内存吃满。后来一看 UI，发现是数据倾斜，单个 key 有几十 G 的数据，内存再大也没用，必须打散。所以遇到 OOM 的第一反应现在变成了"先看分布，再动内存"，顺序反了就是浪费集群资源。
第三个坑是忽略分区数对 OOM 的影响。有一次我调大并行度，OOM 反而消失了，但作业变得特别慢。原因是分区切得太碎，每个 Task 处理的数据量虽然小，但调度和序列化开销占了主导。后来把分区数调回到合理区间，速度和内存同时改善了。这件事让我明白，参数调优不是单调的，存在一个"甜点区"，得靠 UI 上的数据去定位，而不是凭感觉。
第四个坑是在容器环境里只盯着 Spark 日志。有一次作业在 K8s 上规律性失败，Spark 日志里是千篇一律的 Task 失败，改代码、调参数全都没用。最后去查节点事件，发现是某个节点的本地磁盘满了，新起的 executor pod 死活起不来。从那以后，我在文档里给团队加了一条：Spark 报错先分两类，能修的上限是 Spark 参数，不能修的下限是基础设施，先把范围判对。
最后再分享一个小习惯：每次解决完一个 Stage 失败问题，我会把当时的报错关键字、根因和修复方式记在一个表格里。时间久了，这张表就成了自己的"排错字典"。再遇到Job aborted due to stage failure，基本能在五分钟内给出方向判断。这个习惯看着笨，但在 Spark 这种报错信息高度同质化、真正原因又千差万别的场景里，是效率最高的办法。
