为什么 spark 从 S3 读写速度如此之快答案

【问题标题】：why spark reads and writes so fast from S3为什么 spark 从 S3 读写速度如此之快
【发布时间】：2016-11-05 03:37:44
【问题描述】：

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

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

【问题讨论】：

有趣，我总是问自己为什么他们这么慢:)
哈哈。我的意思是与非分布式存储系统相比，其中硬盘的 I/O 速率是一个巨大的瓶颈。

标签： amazon-web-services apache-spark amazon-s3 amazon

【解决方案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 传输数据。

【讨论】：

@jrotenstein 谢谢！更具体地说，假设我在 S3 中保存了 X TB/PB 的教科书数据，并在 spark 集群中执行了典型的 word count map reduce 示例。让我们还假设一半的数据可以放入 ram（将 ram 定义为所有 spark worker 的 ram 的总和）。将数据放入内存的时间与执行映射和减少步骤的时间与将（字，计数）元组写回磁盘的时间的百分比是多少。至于每个工人的 CPU 速度，我会假设一个标准的 EC2 实例（即 r3.2xlarge 或类似的东西）。
您必须运行 spark 作业并查看统计信息才能弄清楚。当数据加载到 Spark 并（可能）缓存时，第一次运行数据总是最慢的。随后对该数据的访问将快得多。因此，Spark 更适合您多次处理相同数据的情况（例如机器学习）。如果您只访问一次数据，与非内存驻留查询引擎相比，您不会看到太多好处。

【解决方案2】：

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

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

原来是性能杀手

处理文件时存在过多的 HEAD 请求（也代码中的许多检查）。修复：减少这些
在搜索时关闭和重新打开连接。修复：(a) 懒惰搜索（仅在 read() 上进行搜索，而不是 seek() 调用)，(b) 通过前向搜索读取和丢弃数据。高效，甚至高达几百 KB （YMMV 等）
对于二进制 ORC/Parquet 文件，添加一个特殊的 fadvise=random 模式，它不会尝试对源文件进行完整的 GET，而是读取以块为单位。如果我们需要向后寻找或向前走很长的路，剩下的丢弃的块和重用的 HTTP 1.1 连接：不需要中止连接并重新协商新的连接。

上个月的演讲中有一些细节：Spark and Object Stores，虽然它没有深入探讨新的东西（在 Hadoop 2.8（即将发布）、HDP 2.5（发货）中，也许在 CDH 中的某个时间）。它会推荐各种性能设置，但今天有效。

还要确保您使用的任何压缩都是可拆分的（LZO、snappy、...），并且您的文件不会太小以至于在列出目录和打开它们时开销太大。

【讨论】：