提高Apache引发性能与S3神奇的提交者

大多数Apache引发用户忽略S3提交者的选择(协议引发写作时所使用的输出结果S3),因为它是相当复杂和文档是稀缺。这个选择对性能有重大影响时写入数据到S3。平均而言,大部分火花工作写入S3,所以选择合适的S3 AWS引发用户提交者是很重要的。

与2021年10月Apache火花3.2版本,一种特殊类型的S3提交者称为神奇的提交者已经显著提高,使它更好的性能,更稳定,更容易使用。

NetApp以现货,我们测试了S3与实际客户提交者的管道和加速引发就业65%等客户Weather20/20。我们建议使用这个所有AWS引发用户提交者。

在这篇文章里我们将介绍:

• S3提交者是什么?我为什么要使用魔法提交者吗?
• 性能优势可以使吗?
• 我如何打开神奇的提交者?
• 在火花3.2发生了什么事?期待未来的火花释放什么?

S3提交者是什么?我为什么要使用魔法提交者吗?

Apache火花,就像之前Hadoop MapReduce,工作在一个文件系统的输出。更准确地说,许多火花任务并行运行,每个火花任务写到输出文件。系统必须产生一个一致的输出即使:

• 一些任务可以被打断,同时他们在进步(例如点杀、遗嘱执行人的内存错误),在另一个执行人重试
• 相同的多个副本任务可以并行执行在不同的执行者(一种称为投机的机制,这有助于性能)

为了解决这个问题,Hadoop MapReduce使用一种技术称为提交协议,列出中间输出目录,重命名文件的最终位置。这工作好Hadoop分布式文件系统(HDFS)因为清单目录产生一致的结果,和重命名一个文件是一个快速“O(1)”操作。

虽然这是对HDFS, S3的情况并非如此。重命名一个文件在S3不是* *一个原子操作,它实现为一个复制和删除操作,这需要大约6 mb /秒。

的默认工作提交者(称为火花FileOutputCommmitter使用S3)因此不是安全的。例如,如果发生故障而重命名操作正在进行中,数据输出可以破坏。除了安全,它也可以非常缓慢。

要修复这个问题,社区开发了特殊的提交者S3称为S3A提交者:

• 阶段提交者,由Netflix。它工作很好,但它需要有一个集群级别共享存储HDFS或NFS来存储中间输出文件,设置不是很方便,尤其是Spark-on-Kubernetes用户。
• 神奇的提交者,这是社区和新Hadoop违约。

最初,神奇的提交者有一个很大的缺点:它需要安装一个Dynamodb数据库启用一个S3端机制称为S3Guard(“看守”你对不一致的结果)。

2020年12月以来,S3提供强大read-after-write全球一致性,这意味着你能看到一个文件当你列出一个目录后的书面文件(就像你在你的笔记本电脑的硬盘)。因此没有必要安装S3Guard了,让神奇的提交者更容易使用。

去更深的关于这个主题,请参阅官方Hadoop文档这研究论文“zero-rename提交者”由史蒂夫Loughran和其他Apache贡献者。

请注意:如果您使用的是pure-manifest表格格式像三角洲。io、Apache冰山或Apache Hudi, S3提交者不像这些表的格式与您相关处理提交进程不同。

性能优势S3提交者可以启用?

精确的性能优势取决于工作负载,但作为一个经验法则,收益是重要的如果火花的工作很大一部分花在了写数据S3(这是一种非常常见的情况)。除了性能优势,使用魔法提交者而不是默认的FileOutputCommitter也将保护你免受恶劣的数据损坏缺陷在边界情况的情况下(执行人损失、投机等)。

让我们评估实际的性能优势引发管道由我们的一个客户Weather20/20天气分析平台。在使用魔法之前提交者,他们的管道将许多火花的工作和任务一小时,然后“打破”了近一个小时,在这期间似乎火花空闲不执行任务,最后退出。

通过观察这个问题非常明显高兴的是,我们的免费火花监控工具:

48-min打破的火花引发司机日志中应用也清晰可见:

21/11/08 20:52:11信息DAGScheduler:工作完成7:insertInto NativeMethodAccessorImpl。java: 0,花了3495.605049秒

21/11/08 21:40:13信息FileFormatWriter:写工作13 ca8cb6-5fc0-4fe9-9fd0-bba5cf9e2f7f承诺。

最后一行给出了一个暗示20:52和21:40之间引发运行作业提交一步的FileOutputCommitter协议。如前所述,S3重命名操作非常慢(用于大型数据集)。除了慢S3电话,提交者使成千上万的S3调用,这在某些情况下可以扼杀了S3(你可以证实这一点通过启用S3日志和寻找503 API响应)。

通过切换到神奇的提交者,这就是应用程序图高兴的样子。

现在管道运行在40分钟,而之前1小时48分钟。这是一个63%改进!这个管道可能特别极端的例子的一个改进,但我们经常看到改善的15 - 50%范围管道写大量的数据上传到S3。你应该试试这个。

我如何打开神奇的提交者?

你可以打开它国旗sparkConf中插入一个单独的配置:“spark.hadoop.fs.s3a.bucket.all.committer.magic.enabled”:“真正的”

请注意:之前需要提供bucket名称在你的火花配置的关键spark.hadoop.fs.s3a.bucket。<桶> .committer.magic.enabled。T他最初是因为你必须安装S3Guard一桶。现在S3强烈一致的,这是没有必要的了。如果你通过国旗spark.hadoop.fs.s3a.bucket.all.committer.magic.enabled,神奇的提交者将被用于所有桶。

您还需要包括spark-hadoop-cloud图书馆在你的码头工人形象或依赖,因为它提供了S3A提交者所使用的类。如果你缺少这种依赖性,你会得到一个错误:java.lang.ClassNotFoundException:org.apache.spark.internal.io.cloud.PathOutputCommitProtocol

来验证是否使用魔法提交者,最简单的方法是寻找“提交者”这个词引发司机日志。

如果你看到这样的日志:

21/11/08 19:53:54信息ParquetFileFormat:使用用户定义的输出为拼花提交者:org.apache.spark.internal.io.cloud.BindingParquetOutputCommitter

21/11/08 19:53:54警告AbstractS3ACommitterFactory:使用标准FileOutputCommitter提交工作。这是缓慢的和潜在的不安全。

21/11/08 19:53:54信息FileOutputCommitter:文件输出提交者算法版本是1

还有一个问题——使用标准FileOutputCommitter。警告说,它是缓慢的和潜在的不安全。

但是如果你看到下面的日志,那么你知道所使用的魔法提交者是正确的:

AbstractS3ACommitterFactory 21/11/14 00:05:11信息:提交者使用魔法输出数据s3a: / /…

在火花3.2发生了什么事?期待未来的火花释放什么?

3.2使魔术火花提交者更容易使用(火星- 35383),你可以通过插入一个打开配置国旗(之前您必须通过4个不同的标志)。火花3.2还构建Hadoop 3.3.1之上,包括bug修复和性能改进的神奇的提交者。请阅读我们的文章引发3.2想要了解更多关于这个版本的主要特性和改进。

注意:另一个不相关的Hadoop 3.3改进。如果你通过配置标志“spark.hadoop.fs.s3a.directory.marker。保留”:“保持”,Hadoop将停止不必要的删除目录标记。你需要选择这种行为(你需要通过标志)因为它不是向后兼容的。你应该只通过这个标志如果你所有的火花应用程序使用Hadoop 3.3 +。

有正在进行的工作由史蒂夫Loughran(一个Apache软件基金会成员自2000年以来)建立类似task-manifest提交对象存储Azure和GCP的算法(mapreduce - 7341),并提高魔法提交者的性能(hadoop - 17833)。这是一个巨大的工作量(谢谢史蒂夫!),首先需要将导致Hadoop,然后被一个新的火花。

结论

从火花3.2开始,我们强烈推荐的魔法提交者AWS引发用户写入数据S3的管道(除非他们已经使用表格格式像三角洲,Hudi,或冰山)。通过切换一个配置国旗,你可能获得高达60%的性能提升管道,以及避免严重的数据损坏造成的违约FileOutputCommitter的bug。