【问题标题】:Differences between Amazon S3 and S3n in HadoopHadoop 中 Amazon S3 和 S3n 的区别
【发布时间】:2018-03-16 16:51:33
【问题描述】:

当我将 Hadoop 集群连接到 Amazon 存储并将文件下载到 HDFS 时,我发现 s3:// 不起作用。在 Internet 上寻求帮助时,我发现我可以使用 S3n。当我使用S3n 时,它起作用了。我不明白在我的 Hadoop 集群中使用 S3S3n 之间的区别,有人可以解释一下吗?

【问题讨论】:

  • 这怎么跑题了!?

标签: hadoop amazon-s3 hdfs


【解决方案1】:

使用Amazon S3 的两个文件系统记录在各自的Hadoop wiki page addressing Amazon S3 中:

  • S3 原生文件系统(URI 方案:s3n)
    用于在 S3 上读取和写入常规文件的本机文件系统。这样做的好处 文件系统是您可以访问 S3 上使用 其他工具。 相反,其他工具可以访问使用 Hadoop。缺点是 S3 对文件大小施加了 5GB 的限制。 由于这个原因它不适合作为 HDFS 的替代品(它 支持非常大的文件)。

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

有两种方式可以将 S3 与 Hadoop 的 Map/Reduce 一起使用, 使用 S3 块文件系统替代 HDFS(即 将其用作可靠的分布式文件系统,支持非常 大文件)或作为数据输入的便捷存储库 MapReduce 的输出,使用任一 S3 文件系统。在第二种情况下 HDFS 仍然用于 Map/Reduce 阶段。 [...]

[强调我的]

所以区别主要与 5GB 限制的处理方式有关(可以在单个 PUT 中上传的最大对象,即使 对象的大小范围可以从 1字节到 5 TB,请参阅 How much data can I store?):使用 S3 块文件系统(URI 方案:s3) 可以弥补 5GB 限制并将文件存储到 5TB,它取代了 HDFS依次。

【讨论】:

  • 我的示例文件大约 60MB,在这种情况下,我可以使用 s3 或 s3n,但只有 s3n 有效。如果唯一的区别是 5GB 文件大小限制,那么 s3 和 s3n 都必须工作,但没有..
  • S3 每个对象最多支持 5 TB,只需要分多个部分上传,请参阅:aws.amazon.com/s3/faqs/#How_much_data_can_I_store
  • @LaurenceRowe:这实际上是在引用中暗示的,有点(可以大于 5GB),但感谢您指出此后可能令人困惑的措辞 - 我试过了合并您的评论以澄清这一点。
  • 我有一个问题,Steffen,我通常在 S3 上创建带有位置的 HIVE 外部表,它运行良好。该文件是 BSON 并使用 mongo-hadoop 连接器。但大多数时候我的 BSON 文件超过 5 GB,比如 18 GB。如何使用这么多文件创建外部表?我已经将我的文件放在存储桶中,不介意它是否仅被 hadoop 锁定,但它说如果您选择 S3 阻塞文件系统,则不应使用包含文件的现有存储桶。如何从 S3 上超过 5GB 的文件创建外部表?谢谢史蒂芬。
  • 5Gb 限制was lifted in 2010
【解决方案2】:

我认为您的主要问题与将 S3S3n 作为 Hadoop 的两个独立连接点有关。 s3n:// 的意思是“一个常规文件,可以从外部世界读取,位于这个 S3 url”。 s3:// 指的是映射到位于 AWS 存储集群上的 S3 存储桶的 HDFS 文件系统。因此,当您使用 Amazon 存储桶中的文件时,您必须使用 S3N,这就是您的问题得到解决的原因。 @Steffen 添加的信息也很棒!!

【讨论】:

  • 我知道为什么会出现问题。谢谢。
  • 我相信在 AWS EMR 中,s3: 和 s3n: 方案是相同的。 Hadoop 2.x+ 建议使用 s3a:无论如何。
  • 对于现在遇到这个问题的任何人,aws docs 现在建议使用 s3:// 前缀而不是 s3n://
【解决方案3】:

这里有一个解释:https://notes.mindprince.in/2014/08/01/difference-between-s3-block-and-s3-native-filesystem-on-hadoop.html

第一个支持 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://,但只需确保您创建的所有文件在浏览器的存储桶资源管理器中可见即可。

另见http://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-plan-file-systems.html

以前,Amazon EMR 使用带有 URI 方案 s3n 的 S3 Native FileSystem。虽然这仍然有效,但我们建议您使用 s3 URI 方案以获得最佳性能、安全性和可靠性。

它还说您可以使用s3bfs:// 访问旧的块文件系统,以前称为s3://

【讨论】:

  • 更新:考虑改用s3a://
猜你喜欢
  • 1970-01-01
  • 2016-01-26
  • 1970-01-01
  • 2013-01-01
  • 2016-02-23
  • 1970-01-01
  • 2012-06-18
  • 1970-01-01
  • 2011-12-10
相关资源
最近更新 更多