为什么火花从S3

Question

我理解spark在并行和内存中处理大规模数据方面的优势。

但是当从/向S3读取/写入数据时，如何在读取/写入S3方面遇到瓶颈。这是由S3存储服务以某种有效的形式处理的吗？ S3分布式存储？请提供一些解释，如果可能的话，请提供有关如何了解更多信息的链接。

Answer 1

AWS内唯一的瓶颈是：

• Amazon EC2实例上的network bandwidth limitation，基于实例类型（基本上，较大的实例具有更多的网络带宽）
• Amazon EBS storage volumes的速度（预配置IOPS支持高达20,000 IOPS）

区域内的吞吐量（例如Amazon EC2和Amazon S3之间的吞吐量）非常高，并且不太可能限制您传输数据的能力（除了上面提到的EC2网络带宽限制）。

Amazon S3分布在区域内多个可用区域的多台服务器上。在非常高的速度下，Amazon S3确实有一些推荐的Request Rate and Performance Considerations，但这只是在每秒发出超过300个PUT / LIST / DELETE请求或每秒超过800 GET请求的情况下。

Apache Spark通常部署在多个节点之间。每个节点都具有基于其实例类型的可用网络带宽。 Spark的并行性意味着它可以比单个实例更快地向/从Amazon S3传输数据。

Answer 2

Apache Spark通过EMR上的Amazon客户端库或S3其他地方的Apache Hadoop团队与S3进行通信。如果您使用s3a：// URL，则表示您使用的是最新的ASF客户端。

我们在加快工作方面做了很多工作，请参阅HADOOP-11694。

表演杀手已证明是

1. 存在处理文件时过多的HEAD请求（也是 代码中的许多检查）。修复：减少这些

2. 关闭并重新开启搜寻联系。修复：（a）懒惰寻求（仅限 对read（）进行搜索，而不是seek（）调用），（b）向前搜索 阅读和丢弃数据。高效甚至高达几百KB （YMMV等）

3. 对于二进制ORC / Parquet文件，添加一个特殊的fadvise = random模式， 它不会尝试源文件的完整GET，而是读取 在街区。如果我们需要回头或向前看，其余的则需要 丢弃的块和重用的HTTP 1.1连接：不需要 中止连接并重新协商新的连接。

上个月的讨论中有一些细节：Spark and Object Stores，虽然它没有进入新的东西（在Hadoop 2.8（即将推出），HDP 2.5（发货），也许在CDH中）深度。它会推荐各种性能设置，这些设置今天都有效。

另外请确保您使用的任何压缩都是可拆分的（LZO，snappy，...），并且您的文件不会太小，以至于列出目录并打开它们会产生太多开销。