Hadoop中的Amazon S3和S3n之间的区别
当我将Hadoop集群连接到亚马逊存储并将文件下载到HDFS时，我发现s3：//没有工作，但是在网上寻找一些帮助，我发现我可以使用S3n，所以当我使用S3n时它工作。 我不明白使用S3或s3n与我的hadoop群集之间的不同，有人可以解释吗？
我认为你的主要问题是与S3和S3N两个独立的Hadoop连接点有关。 S3n：//的意思是“一个普通的文件，从外部世界可读，在这个S3 url”。 S3：//是指映射到坐在AWS存储集群上的S3存储桶的HDFS文件系统。 因此，当您使用Amazon存储桶中的文件时，您必须使用S3N，这就是您的问题得到解决的原因。 @Steffen添加的信息也很棒！
用于使用Amazon S3的两个文件系统logging在各自针对Amazon S3的Hadoop wiki页面中 ：
S3本地文件系统（URIscheme：s3n）
用于在S3上读取和写入常规文件的本地文件系统。 这个文件系统的优点是你可以访问S3上用其他工具编写的文件。 相反，其他工具可以访问使用Hadoop编写的文件。 缺点是由S3强加的5GB文件大小限制 。 由于这个原因， 它不适合作为HDFS的替代品 （它支持非常大的文件）。S3 Block FileSystem（URIscheme：s3）
一个由S3支持的基于块的文件系统。 文件存储为块，就像它们在HDFS中一样。 这允许有效实现重命名。 这个文件系统要求您为文件系统专用一个存储桶 – 不应该使用包含文件的现有存储桶，或者将其他文件写入同一个存储桶。 这个文件系统存储的文件可能大于5GB，但是不能与其他S3工具交互操作 。有两种方法可以将S3与Hadoop的Map / Reduce一起使用， 既可以用S3块文件系统替代HDFS （也就是将其用作支持非常大文件的可靠分布式文件系统），也可以作为数据input的便捷存储库并使用S3文件系统从MapReduce输出。 在第二种情况下，HDFS仍然用于Map / Reduce阶段。 […]
[强调我的]
所以这个区别主要与5GB限制的处理方式有关（这是可以在一个PUT中上传的最大的对象 ，即使对象的大小可以从1字节到5TB不等 ，请参阅我可以存储多less数据？ ）：虽然使用S3 Block FileSystem（URIscheme：s3）可以修复5GB的限制，并将文件存储到5TB，但它依次取代HDFS。
这是一个解释： https ： //notes.mindprince.in/2014/08/01/difference-between-s3-block-and-s3-native-filesystem-on-hadoop.html
Hadoop 0.10.0（HADOOP-574）中引入了第一个支持S3的Hadoop文件系统。 它被称为S3块文件系统，并被分配了URIschemes3：//。 在这个实现中，文件被存储为块，就像它们在HDFS中一样。 这个文件系统存储的文件与其他S3工具不能互操作 – 这意味着如果你到AWS控制台，并试图寻找由这个文件系统写的文件，你不会find它们，而是find名为像block_-1212312341234512345等等
为了克服这些限制，在Hadoop 0.18.0（HADOOP-930）中引入了另一个S3支持的文件系统。 它被称为S3本地文件系统，并被分配了URIschemes3n：//。 这个文件系统可以让你访问S3上用其他工具编写的文件。当这个文件系统被引入时，S3的文件大小限制为5GB，因此这个文件系统只能用小于5GB的文件操作。 2010年底，亚马逊将文件大小限制从5GB提高到了5TB …
不再推荐使用S3块文件系统。 像Qubole和Amazon EMR这样的各种Hadoop-as-a-service提供商可以将s3：//和s3n：// URI映射到S3本地文件系统，以确保这一点。
所以总是使用本地文件系统。 没有更多的5Gb限制。 有时你可能不得不键入s3://而不是s3n:// ，但只要确保你创build的任何文件在浏览器的bucket explorer中都可见。
另请参阅http://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-plan-file-systems.html 。
以前，Amazon EMR使用了带有URIschemes3n的S3本地文件系统。 虽然这仍然有效，但我们build议您使用s3 URIscheme以获得最佳性能，安全性和可靠性。
它还说你可以使用s3bfs://来访问旧的块文件系统，以前称为s3:// 。
