当我将Hadoop集群连接到Amazon存储并将文件下载到HDFS时，我发现s3://无效。在互联网上寻求帮助时，我发现我可以使用S3n。当我使用S3n时它起作用了。我不理解在我的Hadoop集群中使用S3和S3n之间的区别，有人可以解释一下吗？
答案 0 :(得分：65)
使用Amazon S3的两个文件系统记录在相应的Hadoop wiki page addressing Amazon S3：
中
S3 Native FileSystem（URI scheme：s3n）
用于在S3上读取和写入常规文件的本机文件系统。这样做的好处 filesystem是你可以访问S3上写的文件 其他工具。 相反，其他工具可以访问使用的文件 Hadoop的。缺点是S3强加的文件大小限制为5GB 。 出于这个原因它不适合作为HDFS的替代品（其中 支持非常大的文件。）S3 Block FileSystem（URI scheme：s3）
由S3支持的基于块的文件系统。文件存储为块，就像它们一样 在HDFS中。这允许有效地实现重命名。这个 filesystem要求你为文件系统专用一个桶 - 你 不应使用包含文件的现有存储桶，也不应写入其他存储桶 文件到同一个桶。 此文件系统存储的文件可以是 大于5GB，但它们不能与其他S3工具互操作。S3可以通过两种方式与Hadoop的Map / Reduce一起使用， 使用S3块文件系统替代HDFS （即 使用它作为一个可靠的分布式文件系统，支持非常 大文件）或作为数据输入和方便的存储库 使用S3文件系统从MapReduce输出。在第二种情况下 HDFS仍用于Map / Reduce阶段。 [...]
[强调我的]
所以差异主要与5GB限制的处理方式有关（即可以在单个PUT 中上传的最大对象，即使对象的大小可以从1开始）字节到5太字节，请参阅How much data can I store?）：使用 S3 Block FileSystem（URI方案：s3）允许修复5GB限制并存储高达5TB的文件，它依次替换HDFS。
答案 1 :(得分：38)
我认为您的主要问题与将S3和S3n作为Hadoop的两个独立连接点相关。 s3n://表示“在这个S3网址上可以从外部世界读取的常规文件”。 s3://是指映射到位于AWS存储集群上的S3存储桶的HDFS文件系统。因此，当您使用Amazon存储桶中的文件时，您必须使用S3N，这就是您的问题得到解决的原因。 @Steffen添加的信息也很棒!!
答案 2 :(得分：6)
第一个S3支持的Hadoop文件系统是在Hadoop 0.10.0（HADOOP-574）中引入的。它被称为S3块文件系统，它被分配了URI方案s3：//。在此实现中，文件存储为块，就像它们在HDFS中一样。此文件系统存储的文件无法与其他S3工具互操作 - 这意味着如果您转到AWS控制台并尝试查找由此文件系统编写的文件，您将无法找到它们 - 而是你会找到像block_-1212312341234512345 等名称的文件。
为了克服这些限制，在Hadoop 0.18.0（HADOOP-930）中引入了另一个S3支持的文件系统。它被称为S3本机文件系统，它被分配了URI方案s3n：//。此文件系统允许您访问使用其他工具编写的S3上的文件...当引入此文件系统时，S3的文件大小限制为5GB，因此该文件系统只能使用小于5GB的文件。在2010年底，亚马逊......将文件大小限制从5GB增加到5TB ......
不再推荐使用S3阻止文件系统。各种Hadoop即服务提供商（如Qubole和Amazon EMR）都可以映射s3：//和s3n： //确保这一点的S3本机文件系统的URI。
因此始终使用本机文件系统。没有更多的5Gb限制。有时您可能必须键入s3://而不是s3n://，但只需确保您创建的所有文件都在浏览器的bucket explorer中可见。
另见http://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-plan-file-systems.html。
以前，Amazon EMR使用带有URI方案的S3 Native FileSystem，s3n。虽然这仍然有效，但我们建议您使用s3 URI方案以获得最佳性能，安全性和可靠性。
它还说您可以使用s3bfs://来访问旧的块文件系统，以前称为s3://。