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

Question

写入对象存储的推荐设置如下：

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

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

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

Answer 1

啊。我写了一些文档。以及您引用的其中一篇论文。

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

2022 年 10 月更新

Apache Hadoop 3.3.5 在MAPREDUCE-7341中添加了中间清单提交者，以确保 abfs 和 gcs 的正确性、性能和可扩展性。（它也适用于 hdfs、FWIW）。它通过列出任务尝试的输出目录树来提交任务，并将要重命名的文件列表保存到清单文件中，该清单文件是原子提交的。作业提交是一系列简单的

1. 列出要提交的清单文件，在列表结果分页时加载这些文件。
2. 创建输出目录树
3. 通过线程池将所有源文件重命名为目标
4. 任务尝试清理，这也可以在线程池中完成，以提高 gcs 性能
5. 将摘要保存到 _SUCCESS json 文件，如果需要，还可以保存到另一个目录。摘要包括任务和作业提交期间完成的所有存储 IO 的统计信息。

这对于 GCS 来说是正确的，因为它依赖于单个文件重命名作为唯一的原子操作。对于 ABFS，它增加了对 IOPS 速率限制的支持，以及当您在同一秒内尝试数千次重命名时 abfs 失败的恢复能力。这些问题的例子之一只在生产中出现，而不是在基准测试中出现。

此提交程序随 Hadoop 3.3.5 一起提供，并且不会向后移植 - 如果您想使用它，请使用此版本或更高版本的 hadoop 二进制文件。