S3并行读写性能如何？

Question

考虑一个场景，Spark（或任何其他Hadoop框架）从S3读取大文件（例如1 TB）。多个Spark执行程序如何从S3并行读取非常大的文件。在HDFS中，这个非常大的文件将分布在多个节点上，每个节点都有一个数据块。在对象存储中，我认为整个文件将位于单个节点中（忽略副本）。这将大大降低读取吞吐量/性能。

同样，在HDFS中，大型文件的写入也应该比S3快得多，因为HDFS中的写入将分散在多个主机上，而所有数据都必须通过S3中的一台主机（忽略复制）。

因此，这是否意味着与大数据世界中的HDFS相比，S3的性能明显较差。

Answer 1

是的，S3比HDFS慢。但是看看为什么以及如何减轻影响很有趣。关键：如果您要读取的数据多于写入的数据，则读取性能至关重要。Hadoop 2.8+中的S3A连接器确实为您提供了帮助，因为它已针对基于真实基准的痕迹进行了调整，可读取Parquet / ORC文件。写入性能也会受到影响，生成的数据越多，获得的性能越差。人们抱怨说，当他们真的应该担心以下事实时，如果不付出特殊的努力，您实际上可能最终得到无效的输出。通常这是更重要的问题-不太明显。

阅读表现

来自S3的读取因

• S3和您的VM之间的带宽。您为EC2 VM支付的费用越多，获得的网络带宽就越好。
• HEAD / GET / LIST请求的等待时间，特别是在工作中用于使对象存储看起来像带有目录的文件系统的所有请求。当列出了所有源文件并标识了要实际读取的源文件时，这尤其会损害查询的分区阶段。
• seek()如果读取的HTTP连接被中止并且重新协商了新的HTTP连接，那么这会带来可怕的代价。如果没有为此优化了seek（）的连接器，ORC和Parquet输入将遭受严重损失。如果将设置fs.s3a.experimental.fadvise为，则Hadoop 2.8+中的s3a连接器将精确地执行此操作random。

如果格式是可拆分的，Spark将拆分文件上的工作，并且使用的任何压缩格式也都可以拆分（gz不是，snappy是）。它将按块大小进行操作，您可以针对特定作业（fs.s3a.block.size）进行配置/调整。如果> 1个客户端读取相同的文件，则是的，您将磁盘IO过载到该文件，但与其他磁盘相比，它通常较小。一个小秘密：对于分段上传的文件，然后阅读分开的部分似乎可以避免这种情况，因此使用相同的配置块大小进行上传和下载。

写性能

写性能受到影响

• 在上传之前以块的形式缓存一些/很多MB数据，直到写入完成才开始上传。hadoop 2.8+上的S3A：set fs.s3a.fast.upload= true。
• 网络上传带宽，这也是您要购买的VM类型的功能。

承诺表现和正确性

当通过写入临时位置的文件的rename（）提交输出时，将每个对象复制到其最终路径的时间为6-10 MB / S。

更大的问题是，在提交过程中，处理不一致的目录列表或任务失败非常不好。如果没有某种东西可以给您商店的一致视图（一致的emrfs，s3mper，s3guard），就无法安全地将S3用作普通的按提交重命名算法的直接工作目标。

为了获得最佳性能和安全的工作提交，您需要一个针对S3优化的输出提交器。数据块在那里有自己的东西，Apache Hadoop 3.1添加了“ S3A输出提交器”。EMR现在显然也有一些东西。

有关该问题的详细信息，请参见零重命名提交者。之后，希望您可以使用安全的提交机制，也可以将HDFS用作工作目标。