首页 > 解决方案 > [随机出现][Spark ML ALS][AWS EMR] Checkpoint 文件夹中的 FileNotFoundException 但文件存在

问题描述

我在 AWS EMR 上运行一个计划的(每天一次)火花应用程序,该应用程序是基于 spark.ml.recommendation.ALS 的推荐算法,数据位于 AWS S3 上,应用程序向一组用户输出推荐。

为了保证迭代算法稳健运行,我使用了 spark 的 checkpoint 功能。我在 AWS S3 上设置了检查点文件夹。

有时一切正常。但有时,即使该文件实际存在,spark 应用程序也无法在检查点文件夹中找到该文件。我不知道为什么。

这是一个典型的错误日志:

19/10/30 13:46:01 WARN TaskSetManager:在阶段 873.0 中丢失任务 5.0(TID 12169,ip-10-79-9-182.us-west-2.compute.internal,执行程序 5):java.io .FileNotFoundException:没有这样的文件或目录:s3a://bucket-name/checkpoint/8f63442c-dd06-45d8-8e3a-ec30634b1a2f/rdd-2166/part-00005 at org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus (S3AFileSystem.java:1642) 在 org.apache.hadoop.fs.s3a.S3AFileSystem.open(S3AFileSystem.java:521) 在 org.apache.spark.rdd.ReliableCheckpointRDD$.readCheckpointFile(ReliableCheckpointRDD.scala:292) 在 org .apache.spark.rdd.ReliableCheckpointRDD.compute(ReliableCheckpointRDD.scala:100) at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:324)

我检查s3a://bucket-name/checkpoint/8f63442c-dd06-45d8-8e3a-ec30634b1a2f/rdd-2166/part-00005了 S3 存储上确实存在。

我的详细步骤如下:

  1. 在 s3 上创建一个检查点文件夹;
  2. 将 spark 的 CheckpointDir 设置为刚刚创建的文件夹;
  3. 运行算法;
  4. 删除检查点文件夹进行清理。

这是我的斯卡拉代码:

//step 1
val pathString = "s3a://bucket-name/checkpoint"
val path = new Path(pathString)
val fileSystem = FileSystem.get(path.toUri, sparkContext.hadoopConfiguration)
fileSystem.mkdirs(path)

//step 2
sparkContext.setCheckpointDir(pathString)

//step 3
//... lots of data that not so relevant
val als = new ALS()
      .setRank(10)
      .setMaxIter(20)
      .setUserCol("userId")
      .setItemCol("clubId")
      .setRatingCol("rating")
      .setCheckpointInterval(10)
      .setColdStartStrategy("drop")
      .setPredictionCol("prediction")
//... another lots of data that not so relevant

//step 4
fileSystem.delete(path, recursive = true)

标签: scalaapache-spark-mlcheckpoint

解决方案


S3 最终是一致的——如果客户端在创建文件之前执行 HEAD,有时 404 可以缓存在负载均衡器中——然后在随后的 HEAD/GET 请求中(a)返回 404(b)刷新缓存条目,使其保持不变大约

S3A 连接器最近做了很多工作来尝试消除这个问题HADOOP-16490及相关),但这还没有发货。虽然它在消除 s3a 连接器中的问题方面做了很多工作,但它仍然可能容易受到 spark 使用代码的怪癖的影响。有人应该检查检查点以确保它创建的文件具有 overwrite=true。

同时:如果您使用 hadoop 3.2.x 二进制文件并使用 S3Guard 来获得一致的列表,它应该知道足以在这里重试 - 您可能需要将重试间隔调大一点,以便 URL 长时间保持不变足以清除缓存。

否则,请尝试在创建文件和尝试重命名或打开文件之间的工作流程中添加一些 30 到 60 秒的睡眠,看看是否有帮助。


推荐阅读