写入对象存储的建议设置为：对于一致性模型意味着基于重命名的提交是安全的对象存储，请使用 FileOutputCommitter v2算法性能；为了安全。使用v2算法写入google云存储安全吗？算法“不安全”到底意味着什么？有什么具体的标准来决定我是否处于v2不安全的情况下？
FileOutputCommitter
8yparm6h1#
https://databricks.com/blog/2017/05/31/transactional-writes-cloud-storage.html我们从经验上看到，尽管v2速度更快，但它也会留下部分工作失败的结果，从而打破事务性要求。实际上，这意味着使用链式etl作业时，作业失败（即使重试成功）可能会复制下游作业的一些输入数据。这需要在使用链式etl作业时进行仔细的管理。它是安全的，只要你管理部分写入失败。更详细地说，他们的意思是安全，就你引用的部分的安全而言。在azure、aws和gcp中，只有awss3最终与v2算法一致，即使没有作业失败发生，也不安全。但是gcp（也不是azure或aws）对于部分写入是不安全的。
jaql4c8m2#
1.mapreduce.fileoutputcommitter.algorithm.version=1am将在所有还原程序完成后最终执行mergepaths（）。如果这个mr作业有许多reducer，am将首先等待所有reducer完成，然后使用单个线程合并输出文件。因此，该算法对大型作业有一定的性能要求。2.mapreduce.fileoutputcommitter.algorithm.version=2每个reducer都将执行mergepaths（）操作，将其输出文件同时移动到最终的输出目录中。因此，该算法在任务提交时为am节省了大量的时间。http://www.openkb.info/2019/04/what-is-difference-between.html如果你能看到apachespark文档，googlecloud在v1版本中标记为safe，那么在v2版本中也是如此算法“不安全”到底意味着什么？s3没有重命名的概念，所以一旦数据写入s3临时位置，它就会再次将数据复制到新的s3位置，但是azure和google云商店确实有目录重命名awss3具有最终一致性的含义如果删除一个bucket并立即列出所有bucket，则删除的bucket可能仍会出现在列表中，最终一致性会导致在部分写入期间找不到预期的文件，并且不安全。有什么具体的标准来决定我是否处于v2不安全的情况下？使用spark将大量文件写入s3的最佳实践是什么https://docs.aws.amazon.com/amazons3/latest/userguide/welcome.html#consistencymodelhttps://spark.apache.org/docs/3.1.1/cloud-integration.html#recommended-写入对象存储的设置https://databricks.com/blog/2017/05/31/transactional-writes-cloud-storage.htmlhttps://github.com/steveloughran/zero-rename-committer/files/1604894/a_zero_rename_committer.pdf
iszxjhcz3#
啊。我写了一些文件。还有你引用的一篇论文。gcp以非原子方式实现rename（），因此v1实际上并不比v2更健壮。v2可以更快。azure“abfs”连接器有o（1）个原子重命名，一切正常。s3的性能和安全性都受到了影响。由于它现在是一致的，所以风险较小，但在生产数据集上仍然非常缓慢。使用更高性能的committer（emr spark committer、s3a committer）或者先看看云的格式，比如：冰山，湖底，三角洲湖。这就是现在的焦点所在。
3条答案
按热度按时间8yparm6h1#
https://databricks.com/blog/2017/05/31/transactional-writes-cloud-storage.html
我们从经验上看到，尽管v2速度更快，但它也会留下部分工作失败的结果，从而打破事务性要求。实际上，这意味着使用链式etl作业时，作业失败（即使重试成功）可能会复制下游作业的一些输入数据。这需要在使用链式etl作业时进行仔细的管理。
它是安全的，只要你管理部分写入失败。更详细地说，他们的意思是安全，就你引用的部分的安全而言。在azure、aws和gcp中，只有awss3最终与v2算法一致，即使没有作业失败发生，也不安全。但是gcp（也不是azure或aws）对于部分写入是不安全的。
jaql4c8m2#
fileoutputcommitter v1与v2
1.mapreduce.fileoutputcommitter.algorithm.version=1
am将在所有还原程序完成后最终执行mergepaths（）。如果这个mr作业有许多reducer，am将首先等待所有reducer完成，然后使用单个线程合并输出文件。因此，该算法对大型作业有一定的性能要求。
2.mapreduce.fileoutputcommitter.algorithm.version=2
每个reducer都将执行mergepaths（）操作，将其输出文件同时移动到最终的输出目录中。因此，该算法在任务提交时为am节省了大量的时间。
http://www.openkb.info/2019/04/what-is-difference-between.html
如果你能看到apachespark文档，googlecloud在v1版本中标记为safe，那么在v2版本中也是如此
算法“不安全”到底意味着什么？
s3没有重命名的概念，所以一旦数据写入s3临时位置，它就会再次将数据复制到新的s3位置，但是azure和google云商店确实有目录重命名
awss3具有最终一致性的含义如果删除一个bucket并立即列出所有bucket，则删除的bucket可能仍会出现在列表中，最终一致性会导致在部分写入期间找不到预期的文件，并且不安全。
有什么具体的标准来决定我是否处于v2不安全的情况下？
使用spark将大量文件写入s3的最佳实践是什么
https://docs.aws.amazon.com/amazons3/latest/userguide/welcome.html#consistencymodel
https://spark.apache.org/docs/3.1.1/cloud-integration.html#recommended-写入对象存储的设置
https://databricks.com/blog/2017/05/31/transactional-writes-cloud-storage.html
https://github.com/steveloughran/zero-rename-committer/files/1604894/a_zero_rename_committer.pdf
iszxjhcz3#
啊。我写了一些文件。还有你引用的一篇论文。
gcp以非原子方式实现rename（），因此v1实际上并不比v2更健壮。v2可以更快。
azure“abfs”连接器有o（1）个原子重命名，一切正常。
s3的性能和安全性都受到了影响。由于它现在是一致的，所以风险较小，但在生产数据集上仍然非常缓慢。使用更高性能的committer（emr spark committer、s3a committer）
或者先看看云的格式，比如：冰山，湖底，三角洲湖。这就是现在的焦点所在。