Spark任务Executor心跳超时问题排查求助

看起来你碰到的问题虽然表面是Executor心跳超时，但结合之前单行数据超2GB导致OOM的历史，核心大概率还是单条数据过大的问题——哪怕转成RDD处理后，最终写回DataFrame时还是没避开这个坑。下面给你几个针对性的排查和解决方向：

1. 先确认最终DataFrame里的单条数据大小 #

虽然你用RDD做了reduceByKey和合并操作，但还是要检查转成DataFrame后有没有残留的超大行。可以临时加一段代码计算每条数据的大小：

from pyspark.sql.functions import length, col, concat_ws

# 替换成你的DataFrame名称，这里用拼接所有字段的方式估算行大小（根据实际字段类型调整）
df_with_size = df.withColumn("row_size", length(concat_ws("", *df.columns)))
# 查看最大的10条数据大小
df_with_size.orderBy(col("row_size").desc()).show(10, truncate=False)

如果发现仍然有接近或超过2GB的行，那这就是问题根源——哪怕数据总量不大，单条数据超过Executor内存阈值或者Parquet的处理上限，就会导致Executor崩溃、心跳超时。

2. 调整Spark内存与序列化配置 #

针对超大行场景，需要给Executor足够的内存缓冲，同时优化序列化策略：

• 增大Executor内存（根据你的集群资源调整，至少要比最大行的大小多留冗余）：
  在提交任务时添加参数：--executor-memory 32G
• 调整Spark内存分配占比，让更多内存用于数据存储：

  spark.conf.set("spark.memory.fraction", "0.8")
  

• 使用Kryo序列化（比默认的Java序列化更高效，且支持更大的对象）：

  spark.conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
  spark.conf.set("spark.kryoserializer.buffer.max", "2048m")  # 设置足够大的序列化缓冲区
  

3. 拆分超大行再写入（业务允许的情况下） #

如果无法避免超大行的存在，可以考虑把单条数据拆分成多条小数据，写入后再按需合并：

• 比如把一个超大的数组字段拆分成多个小批次的数组行，给每条数据标记序号；
• 或者把大文本字段拆分成固定长度的片段，后续读取时再拼接还原。

4. 优化S3写入的相关配置 #

S3的网络延迟或写入超时也可能触发Executor心跳异常，可以调整以下Hadoop S3客户端参数：

# 增大S3连接超时时间（5分钟）
spark.conf.set("spark.hadoop.fs.s3a.connection.timeout", "300000")
# 增加重试次数
spark.conf.set("spark.hadoop.fs.s3a.retry.max", "10")
# 使用S3专属的Parquet提交器，减少写入阶段的延迟
spark.conf.set("spark.sql.parquet.output.committer.class", "org.apache.spark.sql.execution.datasources.parquet.ParquetOutputCommitter")

5. 查看Executor的详细日志 #

Driver日志只显示了心跳超时，但Executor（比如你日志里的26号Executor）的日志里应该有更具体的错误信息（比如OOM的完整堆栈）。在Databricks控制台找到对应Executor的日志，能直接定位是处理哪条数据时出现了内存溢出，帮你快速确认问题。

最后提醒下：之前直接用DataFrame出现OOM，转RDD处理只是把问题延后到了写入阶段，核心还是超大行的问题，优先解决这个最关键。

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