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请求的
• 延迟，尤其是在工作中用于使对象存储区使用的所有请求看起来像是带有目录的文件系统。当列出了所有源文件并标识了要实际读取的源文件时，这尤其会损害查询的分区阶段。
• 如果读取的HTTP连接被中止并且重新协商了新的HTTP连接，则seek()的成本将很糟糕。如果没有为此优化了seek（）的连接器，ORC和Parquet输入将遭受严重损失。如果将fs.s3a.experimental.fadvise设置为random，则Hadoop 2.8+中的s3a连接器可以做到这一点。

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

写性能

写入性能受到影响

• 在上传之前以块为单位缓存一些/很多MB数据，直到写入完成才开始上传。 Hadoop 2.8+上的S3A：设置fs.s3a.fast.upload = true。
• 网络上传带宽，也是您要付费的VM类型的功能。

承诺表现和正确性

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

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

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

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