使用 v2 算法安全地写入 Google Cloud Storage？ FileOutputCommitter V1 与 V2

如何解决使用 v2 算法安全地写入 Google Cloud Storage？ FileOutputCommitter V1 与 V2

对于一致性模型意味着基于重命名的提交是安全的对象存储，使用 FileOutputCommitter v2 算法来提高性能； v1 为了安全。

使用 v2 算法写出 Google Cloud Storage 是否安全？

算法“不安全”究竟意味着什么？用于确定我是否处于 v2 不安全的情况的具体标准是什么？

解决方法

啊。我写了一点文档。还有你引用的一篇论文。

GCP 以非原子方式实现 rename()，因此 v1 实际上并不比 v2 更健壮。而且 v2 可以快得多。
Azure“abfs”连接器有 O(1) 次原子重命名，一切都很好。
S3 的性能和安全性都受到了影响。由于它现在是一致的，因此风险较小，但在生产数据集上仍然非常缓慢。使用性能更高的提交者（EMR spark 提交者、S3A 提交者）
或者查看云优先格式，例如：Iceberg、Hudi、Delta Lake。这就是如今的重点所在。

FileOutputCommitter V1 与 V2

1. mapreduce.fileoutputcommitter.algorithm.version=1

AM 将在所有 reducer 完成后最后执行 mergePaths()。如果这个 MR 作业有很多 reducer，AM 会先等待所有的 reducer 完成，然后使用单个线程合并 outout 文件。所以这个算法对于大型作业有一些性能问题。

2. mapreduce.fileoutputcommitter.algorithm.version=2

每个 Reducer 都会执行 mergePaths() 将它们的输出文件同时移动到最终输出目录中。所以这个算法在作业提交时为AM节省了大量时间。

http://www.openkb.info/2019/04/what-is-difference-between.html

如果你能看到 Apache Spark 文档谷歌云在 v1 版本中标记为安全，那么它在 v2 中是相同的

算法“不安全”究竟意味着什么？

S3 没有重命名的概念，因此一旦将数据写入 s3 临时位置，它会再次将该数据复制到新的 s3 位置，但 Azure 和谷歌云存储确实有目录重命名

AWS S3 具有最终一致性的含义如果删除一个桶并立即列出所有桶，被删除的桶可能仍会出现在列表中，最终一致性会导致部分写入时找不到预期的文件且不安全。

用于决定我是否处于 v2 不安全的情况的具体标准是什么？

What is the best practice writing massive amount of files to s3 using Spark

https://databricks.com/blog/2017/05/31/transactional-writes-cloud-storage.html

我们凭经验看到，虽然 v2 更快，但它也落后作业失败的部分结果，破坏了事务性要求。实际上，这意味着对于链式 ETL 作业，作业失败——即使重试成功——也可能重复一些下游作业的输入数据。这需要精心管理使用链式 ETL 作业时。

只要您在失败时管理部分写入，它就是安全的。并详细说明，它们的意思是在您引用的部分重命名安全方面是安全的。在 Azure、AWS 和 GCP 中，只有 AWS S3 最终与 V2 算法保持一致且不安全，即使没有发生作业失败也是如此。但是 GCP（也不是 Azure 或 AWS）在部分写入方面并不安全。