Spark GraphX缓存与Checkpoint相关问题咨询及报错排查

问题1：Checkpoint写入分区器警告的修复方案 #

处理2亿顶点、3.5亿边的大图时，定期对中间图执行Checkpoint，偶尔出现以下警告：

22/08/04 03:25:48 [WARN] o.a.s.r.ReliableCheckpointRDD - Error writing partitioner org.apache.spark.HashPartitioner@e10 to file:/mnts/nfsvol/AML/tmp/checkpoint/a153fc7b-1be7-460d-a41b-f17c820c3bf1/rdd-496

22/08/04 03:29:35 [WARN] o.a.s.r.ReliableCheckpointRDD - Error writing partitioner org.apache.spark.HashPartitioner@e10 to file:/mnts/nfsvol/AML/tmp/checkpoint/a153fc7b-1be7-460d-a41b-f17c820c3bf1/rdd-482

修复方案：

• 替换分布式文件系统：当前使用本地NFS作为Checkpoint目录，多节点并发写入时易出现一致性、锁冲突或IO性能问题，建议替换为HDFS、S3等分布式存储系统，原生支持Spark分布式读写，稳定性更高。
• 检查目录权限：确保Spark executor进程对Checkpoint目录/mnts/nfsvol/AML/tmp/checkpoint有完整读写权限，包括父目录的执行权限，避免权限不足导致写入失败。
• 调整Checkpoint配置：增加Checkpoint重试次数和超时时间，通过以下配置调整：

  spark.hadoop.fs.file.impl.disable.cache=true
  spark.checkpoint.retryInterval=10s
  spark.checkpoint.maxRetries=3
  

• 验证分区器序列化：如果自定义了分区逻辑，需确保分区器实现Serializable接口；HashPartitioner为Spark内置可序列化类，但若存在自定义扩展需确认序列化正常。
• 清理旧Checkpoint目录：每次任务启动前清理旧的Checkpoint目录，避免残留损坏文件干扰新任务的Checkpoint过程。

问题2：Checkpoint完成后立即unpersist是否安全？ #

安全，且是推荐操作。

• Checkpoint完成后，Spark会切断RDD的依赖链，后续计算直接从Checkpoint的磁盘文件读取数据，此时unpersist仅释放内存中的缓存数据，不会影响后续任务执行。
• Spark UI显示以ReliableCheckpointRDD启动阶段，说明Spark已成功切换到Checkpoint数据源，内存缓存不再被依赖，释放内存反而能避免内存溢出，提升集群资源利用率。
• 两种方式性能无差异是正常现象，因为后续计算均从磁盘读取Checkpoint数据，内存缓存已无作用。

问题3：警告的风险与任务失败原因分析 #

警告的风险 #

写入分区器的警告本身不会直接导致任务失败，但它是Checkpoint过程异常的信号，说明Checkpoint目录的写入稳定性存在问题，可能引发后续更严重的错误（如分区文件写入不全）。

任务失败的原因 #

你遇到的FileNotFoundException核心原因是Checkpoint的分区文件未成功写入或被意外删除，结合场景分析：

1. NFS存储的不稳定性：本地NFS作为Checkpoint目录，多节点并发写入时可能出现文件写入不完整、缓存一致性问题，导致部分分区文件实际不存在，但Spark认为Checkpoint已完成。
2. Checkpoint未完全完成就执行unpersist：Checkpoint方法是异步的，如果在Checkpoint Job未完全结束时调用unpersist，可能导致内存数据被提前释放，而磁盘文件还未写完，后续读取时就会出现文件不存在的错误。正确做法是在Checkpoint后触发一个action（如count()）确保Checkpoint Job完成，再执行unpersist：

   graph.checkpoint()
   graph.vertices.count() // 触发Checkpoint执行
   graph.unpersist(blocking = true)
   

3. Checkpoint目录被意外清理：若有外部进程定期清理临时目录，可能误删未过期的Checkpoint文件，导致后续读取失败。

集群配置：32个executor，每个4核、24GB内存。

内容的提问来源于stack exchange，提问作者I M TEN