这里有一些不同的事情。对于强制列表一致性的问题，dataproc传统上依赖于每集群nfs挂载来在写入一致性之后应用客户端强制列表；最近，google云存储已经成功地改进了它的list-after-write一致性语义，现在list操作在所有写入操作之后立即具有很强的一致性。dataproc正在逐步淘汰客户端强制的一致性，而像dynamodb上的s3guard这样的东西在gcs中不再需要。
至于多部分上传，理论上可以使用您提到的gcs compose，但在大多数情况下，单个大文件的并行多部分上传在单流情况下最有帮助，然而，大多数hadoop/spark工作负载已经将每台机器上的不同任务并行化，这样对多线程处理每个单独的上传流是不利的；无论有无并行多部分上传，聚合吞吐量都将大致相同。
因此，剩下的问题是使用多部分api来执行条件/原子提交。用于hadoop的gcs连接器目前确实使用了一种称为“可恢复上传”的东西，理论上讲，一个节点有可能负责“提交”一个完全不同的节点上传的对象；客户机库的结构目前还不能使这一点变得非常简单。然而，同时，gcs“重命名”的“复制和删除”阶段也不同于s3，因为它作为元数据操作而不是真正的数据“复制”。这使得gcs可以使用vanilla hadoop文件提交程序，而不需要“直接”提交到最终位置并跳过“临时”机制。必须“复制/删除”每个文件的元数据而不是真正的目录重命名可能并不理想，但它也与基础数据大小不成正比，只与文件数成正比。
当然，所有这些仍然不能解决提交大量小文件效率低下的问题。然而，它确实使“直接提交”方面不像您想象的那样是一个因素；更大的问题往往是hive在完成时没有并行化文件提交，特别是在提交到许多分区目录时。spark在这方面做得更好，而且Hive应该会随着时间的推移而改进。
最近在dataproc1.2中使用本机ssl库有一个性能改进，您无需“写更少、更大的文件”，只需使用dataproc1.2开箱即用。
否则，真正的解决方案确实需要写更少、更大的文件，因为即使你修复了写端，如果你有太多的小文件，读端也会受到影响。gcs在吞吐量方面进行了大量优化，因此任何小于64mb或128mb的数据都可能花费更多的时间，而这仅仅是增加任务和打开流的开销，而不是实际的计算（应该能够在200ms-500ms左右的时间内读取那么多的数据）。
在这种情况下，你要确保你设置的东西 hive.merge.mapfiles , hive.merge.mapredfiles ，或 hive.merge.tezfiles 如果你正在使用这些，或者在保存到gcs之前重新划分你的sparkDataframe；合并到更大的分区通常是非常值得的，因为这样可以保持文件的可管理性，并从正在进行的快速读取中获益。
编辑：有一件事我忘了提，那就是我一直在松散地使用这个词 repartition ，但在这种情况下，由于我们严格地尝试将文件组合成更大的文件，因此使用 coalesce 相反；在另一个stackoverflow问题中有更多关于重分区与coalese的讨论。

s3guard，hadoop-13345通过让dynamodb存储列表来改进与s3的一致性。这使得第一次可靠地使用s3a作为工作的直接目的地成为可能。否则，执行时间似乎是个问题，但真正的问题是基于重命名的提交者可能会得到一个不一致的列表，甚至看不到需要重命名的文件。
s3guard提交者工作hadoop-13786将在完成时（截至2017年8月，仍在进行中）提供两个提交者。

暂存提交人

工人写入本地文件系统
任务提交者上载到s3，但未完成操作。相反，它将commit metainfo保存到hdfs。
此提交元信息在hdfs中作为普通任务/作业数据提交。
在job commit中，提交者从hdfs读取未决提交的数据并完成它们，然后清除任何未完成的提交。
任务提交是所有数据的上传，时间是 O(data/bandwidth ).
这是基于ryan在netflix的s3committer，是一个将是最安全的一开始玩。

魔术师

调用它是因为它在文件系统中具有“魔力”。
文件系统本身识别如下路径 s3a://dest/__magic/job044/task001/__base/part-000.orc.snappy 将写入重定向到 s3a://dest/__magic/job044/task001/__base/part-000.orc.snappy ; 未完成流中的写入 close() 打电话。
将提交metainfo保存到s3a，如下所示 s3a://dest/__magic/job044/task001/__base/part-000.orc.snappy.pending 任务提交：从该目录加载所有.pending文件，聚合并保存到其他地方。时间是 O(files) ; 数据大小不重要。
任务中止：加载所有挂起的文件，中止提交
作业提交：从提交的任务加载所有挂起的文件，完成。
因为它在s3中列出文件，所以需要s3guard在awss3上提供一致性（其他s3实现都是现成的，所以不需要它）。
两个提交者共享相同的代码库，两个提交者的作业提交都将是 O(files/threads) ，因为它们都是不占用带宽或大量时间的短post请求。
在测试中，对于小规模的测试文件，staging committer比magic committer要快，因为magic committer与s3的对话更多，这很慢……尽管s3guard加快了listing/getfilestatus调用的速度。写的数据越多，staging committer上的任务提交时间就越长，而magic commit的任务提交对于相同数量的文件是恒定的。两者都比使用rename（）快，这是因为list，copy模仿了rename（）

gcs和hadoop/spark提交算法

（我没有看过这里的gcs代码，所以保留出错的权利。将丹尼斯•霍的陈述视为权威）
如果gcs确实rename（）比s3a copy-then delete更有效，那么它应该更快，比o（data）更快，这取决于代码中的并行化。
我不知道他们能不能找一个0-重命名的提交人。mapreduce代码中的更改 FileOutputFormat 是为支持不同文件系统的不同/可插入提交程序而设计的，因此他们有机会在这里做一些事情。
现在，请确保您使用的是v2mr提交算法，该算法虽然对失败的适应性较差，但至少会将重命名推入任务提交，而不是作业提交。
请参见spark和对象存储。