为什么火花的读写速度如此之快S3

我明白spark在处理并行和in-mem大规模数据方面的优势。为什么火花的读写速度如此之快S3

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

来源

2016-11-05 Dnaiel

好笑的是，我总是问自己，为什么他们这么慢:) – 2016-11-05 14:09:33

笑。我的意思是与非分布式存储系统相比，硬盘的I/O速率是一个巨大的瓶颈。 – Dnaiel

内AWS唯一的瓶颈是：

甲network bandwidth limitation在Amazon EC2实例，基于实例类型（基本上，较大的情况下，有更多的网络带宽）
的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传输数据。

来源

2016-11-05 06:42:18

@jrotenstein谢谢！更具体地说，让我们说我在S3中保存了X TB/PB的教科书数据，并且我在火花集群中执行了典型的字数映射减少示例。让我们还假设一半的数据可以适用于公羊（按照所有火花工人的公羊总和定义）。什么时候将数据存入内存的时间百分比与执行映射的时间相比，减少步骤与将（字，数）元组写回到磁盘的时间相比较。至于每个工人的CPU速度，我会假设一个标准的EC2实例（即r3.2xlarge或sthg）。 – Dnaiel

你必须运行一个spark工作，并查看统计数据来弄清楚。第一次运行数据总是最慢的，当它被加载到Spark和（可能）被缓存。随后访问该数据的速度会更快。因此，Spark适用于多次处理相同数据的情况（例如机器学习）。如果您只访问一次数据，与非内存驻留查询引擎相比，您看不到什么好处。 –

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

我们一直在做很多工作以加快速度，请参阅HADOOP-11694。

性能杀手已被证明是制定文件时，HEAD请求

过度数字存在（太在代码中的许多检查）。修复：减少这些
关闭并重新打开连接寻求。修正：（a）懒寻找（只有在read（）上进行查找，而不是seek（）调用），（b）通过正向查找并丢弃数据。高效的甚至达几百KB （YMMV等）
对于二进制ORC /镶文件，加入了特殊fadvise =随机模式，不尝试源文件的完整GET，而不是读以块为单位。如果我们需要寻求回退或长途前行，则丢弃该块的其余和重新使用HTTP 1.1连接：不需要来中止连接并重新协商新连接。

一些细节是从上个月这次谈话：Spark and Object Stores，虽然它并没有进入新的东西（在Hadoop中2.8（即将出版），HDP 2.5（运费），也许在CDH一些时间）深度。它会推荐各种性能设置，虽然今天有效。

而且一定要确保你使用任何压缩可分裂（LZO，活泼的，...），以及你的文件不能太小以致有在列出目录，并打开他们太多的开销。

来源

2016-11-10 13:57:35

为什么火花的读写速度如此之快S3

回答

相关问题