从技术上说，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修复了这个问题。
