我理解spark在并行和内存中处理大规模数据方面的优势。但是，在从S3读取数据/向S3写入数据时，它如何避免遇到读取/写入S3的瓶颈。S3存储服务是否以某种有效的形式处理了这一问题？S3是否为分布式存储？请提供一些说明，如果可能，请提供有关如何了解更多信息的链接。
w8rqjzmb1#
AWS中的唯一瓶颈是：
区域内（例如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之间的数据传输速度比单个示例快得多。
6ie5vjzr2#
Apache Spark通过EMR上Amazon的客户端库或其他地方的Apache Hadoop团队的客户端库与S3通信。如果您使用s3 a：//URL，则您使用的是最新的ASF客户端。我们已经做了很多工作来加快速度，请参见HADOOP-11694。性能杀手已被证明是1.当工作文件存在过多的HEAD请求（代码中有太多的检查）。修复：减少这些1.查找时关闭和重新打开连接。修复：（a）惰性寻道（只在read（）调用时执行寻道，而不在seek（）调用时执行寻道），（B）通过阅读和丢弃数据执行正向寻道。甚至在几百KB（YMMV等）的情况下也是有效的1.对于二进制ORC/Parquet文件，添加一个特殊的fadvise=random模式，它不尝试对源文件执行完整的GET操作，而是读取块。如果我们需要向后查找或向前查找，则丢弃块的其余部分，并重用HTTP 1.1连接：不需要中止连接并重新协商新的连接。一些细节是在这个演讲从上个月：Spark and Object Stores，虽然它没有深入到新的东西（在Hadoop 2.8（即将推出），HDP 2.5（即将推出），也许在CDH的某个时候）。它会建议各种性能设置，虽然这是今天有效的。同时确保你使用的任何压缩都是可拆分的（LZO，snappy，...），并且你的文件不会太小，以至于在列出目录和打开它们时有太多的开销。
2条答案
按热度按时间w8rqjzmb1#
AWS中的唯一瓶颈是：
区域内（例如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之间的数据传输速度比单个示例快得多。
6ie5vjzr2#
Apache Spark通过EMR上Amazon的客户端库或其他地方的Apache Hadoop团队的客户端库与S3通信。如果您使用s3 a：//URL，则您使用的是最新的ASF客户端。
我们已经做了很多工作来加快速度，请参见HADOOP-11694。
性能杀手已被证明是
1.当工作文件存在过多的HEAD请求（代码中有太多的检查）。修复：减少这些
1.查找时关闭和重新打开连接。修复：（a）惰性寻道（只在read（）调用时执行寻道，而不在seek（）调用时执行寻道），（B）通过阅读和丢弃数据执行正向寻道。甚至在几百KB（YMMV等）的情况下也是有效的
1.对于二进制ORC/Parquet文件，添加一个特殊的fadvise=random模式，它不尝试对源文件执行完整的GET操作，而是读取块。如果我们需要向后查找或向前查找，则丢弃块的其余部分，并重用HTTP 1.1连接：不需要中止连接并重新协商新的连接。
一些细节是在这个演讲从上个月：Spark and Object Stores，虽然它没有深入到新的东西（在Hadoop 2.8（即将推出），HDP 2.5（即将推出），也许在CDH的某个时候）。它会建议各种性能设置，虽然这是今天有效的。
同时确保你使用的任何压缩都是可拆分的（LZO，snappy，...），并且你的文件不会太小，以至于在列出目录和打开它们时有太多的开销。