写入s3时在Spark 2.1.0中设置spark.speculation

Question

我正在运行一个大型Spark 2.1.0,最后将结果写入s3.它运行在30节点集群上,大部分工作正常.但是,偶尔我必须停止工作并再次运行它,因为即使在完成所有计算之后,单个节点也会在写入时卡住.我想知道我是否可以通过改变猜测来缓解这个问题.我在另一篇文章中读到这可能有害并导致重复结果或数据损坏.任何人都可以建议吗？我还被建议通过在我的指定中指定以下设置来使用hadoop默认提交者spark-defaults.conf.我正在运行Spark standalone.

 spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version 2

对此问题的任何澄清将不胜感激.

Answer 1

在提交到对象存储库时运行Spark猜测通常是一个非常糟糕的主意,这取决于查看下游数据和一致性模型的内容.

来自Netflix的Ryan Blue有一个很好的(而且很有趣)的话题,它解释了原因:https://www.youtube.com/watch？v = BBHrff5yAQo

根据你的描述判断,我怀疑你正在写Parquet.

TL; dr版本是在S3中,重命名操作实际上是副本和删除,这具有一致性含义.通常在Spark中,输出数据将写入临时文件位置,并在计算完成时重命名.这意味着如果推测执行已启用,则多个执行程序可以处理相同的结果,然后通过将临时文件重命名为最终结果而首先完成"获胜"而另一个任务被取消.这个重命名操作发生在一个任务上,以确保只有一个推测任务获胜,这在HDFS上不是问题,因为重命名是一个廉价的元数据操作,其中几千或几百万只需要很少的时间.

但是当使用S3时,重命名不是原子操作,它实际上是一个需要时间的副本.因此,您可能会遇到这样的情况,即您必须在S3中再次复制一大堆文件以进行重命名,这是一个同步操作,这会导致您的速度减慢.如果你的执行者有多个核心,你实际上可能有一个任务破坏了另一个核心的结果,这在理论上应该没问题,因为一个文件最终获胜,但是你无法控制那时发生的事情.

这个问题是,如果最终重命名任务失败会发生什么？您最终会将一些文件提交给S3而不是所有文件,这意味着部分/重复数据以及下游的许多问题,具体取决于您的应用程序.

虽然我不喜欢它,但目前流行的智慧是在本地写入HDFS,然后使用像S3Distcp这样的工具上传数据.

看看HADOOP-13786吧.Steve Loughran是这个问题的最佳人选.

如果您不想等待Ryan Blue有一个repo"rdblue/s3committer",它允许您为除镶木地板文件之外的所有输出修复此问题,但看起来有点像正确集成和子类的工作.

更新: SaveMode.Overwrite现已修复并发布到Hadoop 3.1库中.目前,Steven Loughran正在努力获得基于Hadoop 3.1的修复程序,并将其合并到apache/spark中,(SaveMode.Append)但最新的票评论线程是在Spark 2.4发布之前修复程序不会合并,所以我们可能正在等待有点长,这成为主流.