使用 v2 算法写入 Google Cloud Storage 安全吗？答案

【问题标题】：Writing to Google Cloud Storage with v2 algorithm safe?使用 v2 算法写入 Google Cloud Storage 安全吗？
【发布时间】：2021-04-05 21:23:28
【问题描述】：

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

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

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

【问题讨论】：

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

1. mapreduce.fileoutputcommitter.algorithm.version=1

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

2。 mapreduce.fileoutputcommitter.algorithm.version=2

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

如果您可以看到 Apache Spark 文档 Google Cloud 在 v1 版本中标记为安全，那么在 v2 中也是如此

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

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

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

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

【讨论】：

【解决方案3】：

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

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

【讨论】：

AWS S3 自 11 月以来已完全一致。这真的很好，但是因为重命名是非原子的，所以重命名仍然存在部分失败的风险。考虑到重命名需要多长时间，这比其他商店要大得多。