Spark超大Shuffle运行失败：大DataFrame Join报shuffle文件缺失错误

你当前遇到的报错和内存使用率不足没有直接关联。从错误栈的调用链路看，当前是在创建文件输出流写入shuffle数据时触发的路径不存在错误，说明存放shuffle文件的上层临时目录已经被整体删除，并非单文件损坏。哪怕集群RAM剩余充足，只要shuffle文件/目录丢失就会触发该类任务崩溃。

• 排查默认临时目录的磁盘与清理策略
  Spark默认将shuffle临时文件写入系统的/tmp路径，该路径通常挂载在系统根分区，存在两个极易触发该报错的隐患：
  • Linux系统自带的定时清理机制（如tmpwatch）会定期删除/tmp路径下超过存活时长的文件，你当前任务运行时长达到2小时，存在shuffle文件被系统定时任务误删的概率
  • GCP n1-highmem系列节点默认的根分区磁盘容量有限，两个总规模超400GB的表做Join产生的shuffle数据量很容易占满根分区磁盘，空间不足时系统或Spark自身会自动清理早期写入的临时文件，导致后续写入/读取时报文件不存在的错误
    对应调整方式：将spark.local.dir配置为集群节点挂载的专用大存储路径（如各节点独立的本地SSD挂载路径），避免使用系统默认/tmp目录，同时确保该路径不被系统定时清理任务覆盖。
• 校验Executor稳定性配置
  若Executor因为网络抖动、心跳超时被Driver判定为失效，其节点上存储的shuffle文件会被自动标记为可清理，后续依赖这些shuffle文件的Task重新调度时就会报文件不存在的错误。对应调整：
  • 将spark.network.timeout从默认的120秒调整为600秒，适配长任务的网络波动场景
  • 合理设置spark.executor.heartbeatInterval，避免Executor因为心跳间隔过长被误判为离线
• 优化大Join的shuffle负载
  两个超200GB量级的表做Join若未做倾斜优化，极易出现单分区shuffle文件过大、单节点磁盘负载过高的问题：
  • 若其中一个表的实际规模满足广播阈值要求，可适当调大spark.sql.autoBroadcastJoinThreshold参数值，让小表直接通过广播方式完成Join，从根源上减少shuffle磁盘IO
  • 根据整体shuffle数据量调整spark.sql.shuffle.partitions参数值，将单分区的shuffle文件大小控制在128MB-1GB区间，避免单分区文件过大撑爆节点磁盘
  • 提前排查Join key的数据分布，对存在数据倾斜的key做打散处理，避免单个Task生成超大shuffle文件
• 补充监控校验
  不要仅通过RAM使用率判断任务健康度，需要额外核对每台从节点的本地磁盘剩余空间、系统日志中关于/tmp目录清理的相关记录、Executor的存活时长日志，确认是否存在文件被误删、磁盘占满的情况。

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