Différences entre Amazon S3 et S3n dans Hadoop
Lorsque j'ai connecté mon cluster Hadoop au stockage Amazon et téléchargé des fichiers sur HDFS, j'ai trouvé s3:// n'a pas fonctionné. Lorsque j'ai cherché de l'aide sur Internet, j'ai trouvé que je pouvais utiliser S3n. Quand j'ai utilisé S3n ça a marché. Je ne comprends pas les différences entre l'utilisation de S3 et S3n avec mon cluster Hadoop, quelqu'un peut-il expliquer?
Je pense que votre principal problème était lié au fait d'avoir S3 et S3n comme deux points de connexion distincts pour Hadoop. s3n:// signifie "Un fichier régulier, lisible depuis le monde extérieur, à cette URL S3". s3:// fait référence à un système de fichiers HDFS mappé dans un compartiment S3 qui se trouve sur un cluster de stockage AWS. Donc, lorsque vous utilisiez un fichier du compartiment de stockage Amazon, vous devez utiliser S3N et c'est pourquoi votre problème est résolu. Les informations ajoutées par @Steffen sont également excellentes !!
Les deux systèmes de fichiers pour utiliser Amazon S sont documentés dans les page wiki Hadoop traitant d'Amazon S :
S3 Native FileSystem (schéma d'URI: s3n)
Un système de fichiers natif pour lire et écrire des fichiers normaux sur S3. L'avantage de ce système de fichiers est que vous pouvez accéder aux fichiers sur S3 qui ont été écrits avec d'autres outils. Inversement, d'autres outils peuvent accéder aux fichiers écrits à l'aide de Hadoop. L'inconvénient est la limite de 5 Go sur la taille de fichier imposée par S3 . Pour cette raison , il ne convient pas en remplacement de HDFS (qui prend en charge les très gros fichiers).S3 Block FileSystem (schéma d'URI: s3)
Un système de fichiers basé sur des blocs soutenu par S3. Les fichiers sont stockés sous forme de blocs, tout comme ils le sont dans HDFS. Cela permet une implémentation efficace des renommages. Ce système de fichiers nécessite que vous dédiez un compartiment au système de fichiers - vous ne devez pas utiliser un compartiment existant contenant des fichiers, ni écrire d'autres fichiers dans le même compartiment. Les fichiers stockés par ce système de fichiers peuvent dépasser 5 Go, mais ils ne sont pas interopérables avec d'autres outils S3 .Il existe deux façons d'utiliser S3 avec Hadoop Map/Reduce, soit en remplacement de HDFS en utilisant le système de fichiers de bloc S3 (c'est-à-dire en l'utilisant comme système de fichiers distribué fiable avec prise en charge de très gros fichiers) ou comme référentiel pratique pour l'entrée et la sortie de données depuis MapReduce, en utilisant l'un ou l'autre système de fichiers S3. Dans le second cas, HDFS est toujours utilisé pour la phase Map/Reduce. [...]
[c'est moi qui souligne]
La différence est donc principalement liée à la façon dont la limite de 5 Go est gérée (qui est le plus grand objet qui peut être téléchargé en un seul PUT, même si les objets peuvent varier en taille de 1 octet à 5 téraoctets, voir Combien de données puis-je stocker? ): lors de l'utilisation du S3 Block FileSystem (schéma URI: s3) permet de remédier à la limite de 5 Go et stocker des fichiers jusqu'à 5 To, il remplace à son tour HDFS.
Voici une explication: https://notes.mindprince.in/2014/08/01/difference-between-s3-block-and-s3-native-filesystem-on-hadoop.html
Le premier système de fichiers Hadoop soutenu par S3 a été introduit dans Hadoop 0.10.0 (HADOOP-574). Il a été appelé le système de fichiers de blocs S3 et le schéma d'URI s3: // lui a été attribué. Dans cette implémentation, les fichiers sont stockés sous forme de blocs, tout comme ils le sont dans HDFS. Les fichiers stockés par ce système de fichiers ne sont pas interopérables avec d'autres outils S3 - cela signifie que si vous allez sur la console AWS et essayez de rechercher des fichiers écrits par ce système de fichiers, vous ne le ferez pas les trouver - à la place, vous trouverez des fichiers nommés quelque chose comme block_-1212312341234512345 etc.
Pour surmonter ces limitations, un autre système de fichiers soutenu par S3 a été introduit dans Hadoop 0.18.0 (HADOOP-930). On l'appelait le système de fichiers natif S3 et on lui a attribué le schéma d'URI s3n: //. Ce système de fichiers vous permet d'accéder à des fichiers sur S3 qui ont été écrits avec d'autres outils ... Lorsque ce système de fichiers a été introduit, S3 avait une limite de taille de 5 Go et donc ce système de fichiers ne pouvait fonctionner qu'avec des fichiers de moins de 5 Go. Fin 2010, Amazon ... a augmenté la limite de taille de fichier de 5 Go à 5 To ...
L'utilisation du système de fichiers de blocs S3 n'est plus recommandée. Divers fournisseurs Hadoop-as-a-service comme Qubole et Amazon EMR vont jusqu'à mapper les deux s3: // et les URI s3n: // vers le système de fichiers natif S3 pour garantir cela.
Utilisez donc toujours le système de fichiers natif. Il n'y a plus de limite de 5 Go. Parfois, vous devrez peut-être taper s3:// au lieu de s3n://, mais assurez-vous simplement que tous les fichiers que vous créez sont visibles dans l'explorateur de compartiments du navigateur.
Voir également http://docs.aws.Amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-plan-file-systems.html .
Auparavant, Amazon EMR utilisait le système de fichiers natif S3 avec le schéma d'URI, s3n. Bien que cela fonctionne toujours, nous vous recommandons d'utiliser le schéma d'URI s3 pour les meilleures performances, sécurité et fiabilité.
Il indique également que vous pouvez utiliser s3bfs:// pour accéder à l'ancien système de fichiers de blocs, précédemment appelé s3://.