从技术上说,s3n,s3a和s3有什么区别?

我知道https://wiki.apache.org/hadoop/AmazonS3的存在和下面的字眼:

S3本地文件系统(URI scheme:s3n)在S3上读取和写入常规文件的本机文件系统。 这个文件系统的优点是你可以访问S3上用其他工具编写的文件。 相反,其他工具可以访问使用Hadoop编写的文件。 缺点是由S3强加的5GB文件大小限制。

S3A(URIscheme:s3a)S3 Native,s3n fs的后继者,S3a:系统使用Amazon的库与S3进行交互。 这允许S3a支持更大的文件(不超过5GB的限制),更高的性能操作等等。 这个文件系统的目的是成为S3 Native的替代品/inheritance者:从s3n:// URL访问的所有对象也应该可以通过简单地replaceURL模式从s3a访问。

S3块文件系统(URI scheme:s3)S3支持的基于块的文件系统。 文件存储为块,就像它们在HDFS中一样。 这允许有效实现重命名。 这个文件系统要求您为文件系统专用一个存储桶 – 不应该使用包含文件的现有存储桶,或者将其他文件写入同一个存储桶。 这个文件系统存储的文件可能大于5GB,但是不能与其他S3工具交互操作。

为什么URI上的一个字母改变会使这样的区别? 例如

val data = sc.textFile("s3n://bucket-name/key") 

 val data = sc.textFile("s3a://bucket-name/key") 

这种变化背后的技术差异是什么? 有什么好的文章可以阅读吗?

URIscheme中的字母更改会产生很大的差异,因为它会导致使用不同的软件来连接到S3。 有点像http和https之间的区别 – 它只是一个字母的变化,但是它触发了一个很大的行为差异。

s3和s3n / s3a之间的区别在于s3是基于块的覆盖在Amazon S3之上,而s3n / s3a不是(它们是基于对象的)。

s3n和s3a的区别在于s3n支持最大5GB的对象,而s3a支持最大5TB的对象,性能更高(都是因为它使用多部分上传)。 s3a是s3n的inheritance者。

如果您在这里是因为您想了解您应该使用哪个S3文件系统与Amazon EMR,那么请阅读Amazon的这篇文章 (url是:使用s3://因为s3://和s3n://在function上是可以互换的在EMR的情况下,而s3a://与EMR不兼容)。

在Apache Hadoop中,“s3://”是指原来的S3客户端,它使用非标准结构来实现可伸缩性。 该图书馆已被弃用,即将被删除,

s3n是它的后继者,它使用直接path名称到对象,所以你可以读取和写入其他应用程序的数据。 像s3://一样,它使用jets3t.jar与S3交谈。

在亚马逊的EMR服务上,s3://指的是亚马逊自己的S3客户端,这是不同的。 EMR中的s3://中的path直接指向对象存储中的对象。

在Apache Hadoop中,S3N和S3A都是S3的连接器,S3A是使用Amazon自己的AWS SDK构build的后继者。 为什么新的名字? 所以我们可以把它与稳定的那个并排运输。 S3A是所有正在进行的可伸缩性,性能,安全性等方面的工作。 S3N是孤立的,所以我们不打破它。 S3A在Hadoop 2.6中发布,但直到2.7才稳定下来,主要是出现一些小规模问题。

如果您使用的是Hadoop 2.7或更高版本,请使用s3a。 如果您使用的是Hadoop 2.5或更早的版本。 s3n,如果你使用的是Hadoop 2.6,这是一个更难的select。 – 如果出现问题,我试试s3a并切换回s3n,

有关更多的历史,请参阅http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/

实际上,在Hadoop 2.6中S3a的分区被破坏了,因为在listFiles()调用中返回的块大小是0:像Spark和listFiles()这样的东西把工作划分成一个任务/字节。 即使核心文件系统操作和数据生成很快,您也不能在Hadoop 2.6中使用S3a进行分析工作。 Hadoop 2.7修复了这个问题。