HadoopでのAmazon S3とS3nの違い
HadoopクラスターをAmazonストレージに接続し、ファイルをHDFSにダウンロードしたとき、s3://が機能しないことがわかりました。インターネットでヘルプを探しているときに、S3nを使用できることがわかりました。 S3nを使用すると、うまくいきました。 HadoopクラスターでS3とS3nを使用することの違いがわかりません。誰か説明できますか？
あなたの主な問題は、S3およびS3n Hadoopの2つの個別の接続ポイントとして。 s3n://は、「このS3 URLで、外部から読み取り可能な通常のファイル」を意味します。 s3://は、AWSストレージクラスターにあるS3バケットにマッピングされたHDFSファイルシステムを指します。したがって、Amazonストレージバケットのファイルを使用しているときは、S3Nを使用している必要があり、それが問題を解決する理由です。 @Steffenによって追加された情報も素晴らしいです!!
Amazon S を使用するための2つのファイルシステムは、それぞれの Amazon S3に対応するHadoop wikiページ に記載されています。
S3 Native FileSystem（URIスキーム：s3n）
S3で通常のファイルを読み書きするためのネイティブファイルシステム。このファイルシステムの利点は、他のツールで作成されたS3上のファイルにアクセスできることです。 逆に、他のツールはHadoopを使用して記述されたファイルにアクセスできます。欠点は、S3によって課されるファイルサイズの5GB制限です。このため、HDFS（非常に大きなファイルをサポート）の代替としては適していません。S3 Block FileSystem（URIスキーム：s3）
S3が支援するブロックベースのファイルシステム。ファイルは、HDFSと同様にブロックとして保存されます。これにより、名前の変更を効率的に実装できます。このファイルシステムでは、ファイルシステム専用のバケットを用意する必要があります。ファイルを含む既存のバケットを使用したり、同じバケットに他のファイルを書き込んだりしないでください。 このファイルシステムに保存されるファイルは5GBを超えることがありますが、他のS3ツールとの相互運用性はありません。S3をHadoopのMap/Reduceで使用するには、2つの方法があります。S3ブロックファイルシステムを使用するHDFSの代替として（つまり、非常に大きなファイルをサポートする信頼性の高い分散ファイルシステム）、またはいずれかのS3ファイルシステムを使用したMapReduceのデータ入出力の便利なリポジトリとして。 2番目のケースでは、HDFSが引き続きMap/Reduceフェーズに使用されます。 [...]
[エンファシス鉱山]
そのため、違いは主に5GBの制限の処理方法に関連しています（これは、オブジェクトであっても、単一のPUTでアップロードできる最大オブジェクトです）サイズは1バイトから5テラバイトまでの範囲で指定できます、 どれだけのデータを保存できますか？ ）：S3 Block FileSystem（URIスキーム： s3）は、5GBの制限を修正し、最大5TBのファイルを保存することを可能にし、HDFSを順番に置き換えます。
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年後半、Amazonはファイルサイズの制限を5GBから5TBに引き上げました...
S3ブロックファイルシステムの使用は推奨されなくなりました。QuboleやAmazon EMRなどのさまざまなHadoop-as-a-serviceプロバイダーは、これを保証するために、s3：//およびS3ネイティブファイルシステムへのs3n：// 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://と呼ばれていた古いブロックファイルシステムにアクセスできるとしています。