Techniquement, quelle est la différence entre s3n, s3a et s3?

Je connais l'existence de https://wiki.apache.org/hadoop/AmazonS3 et les mots suivants:

S3 Native FileSystem (schéma 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. À l'inverse, d'autres outils peuvent accéder aux fichiers écrits avec Hadoop. L'inconvénient est la limite de 5 Go de taille de fichier imposée par S3.

S3A (schéma URI: s3a) Successeur du S3 Native, s3n fs, le système S3a: utilise les bibliothèques d'Amazon pour interagir avec S3. Cela permet à S3a de prendre en charge des fichiers plus volumineux (plus de limite de 5 Go), des opérations plus performantes, etc. Le système de fichiers est destiné à remplacer / successeur de S3 Native: tous les objets accessibles depuis les URL s3n: // doivent également être accessibles depuis s3a simplement en remplaçant le schéma d'URL.

S3 Block FileSystem (schéma 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 renommés. Ce système de fichiers nécessite que vous dédiez un compartiment pour le 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.

Pourquoi un changement de lettre sur l'URI pourrait faire une telle différence? Par exemple

val data = sc.textFile("s3n://bucket-name/key")

à

val data = sc.textFile("s3a://bucket-name/key")

Quelle est la différence technique sous-jacente à ce changement? Y a-t-il de bons articles que je peux lire à ce sujet?

Le changement de lettre sur le schéma URI fait une grande différence car il entraîne l'utilisation de différents logiciels pour s'interfacer avec S3. Un peu comme la différence entre http et https - ce n'est qu'un changement d'une lettre, mais cela déclenche une grande différence de comportement.

La différence entre s3 et s3n / s3a est que s3 est une superposition basée sur des blocs au-dessus d'Amazon S3, tandis que s3n / s3a ne le sont pas (ils sont basés sur des objets).

La différence entre s3n et s3a est que s3n prend en charge des objets d'une taille maximale de 5 Go, tandis que s3a prend en charge des objets jusqu'à 5 To et offre des performances plus élevées (les deux sont dus au téléchargement en plusieurs parties). s3a est le successeur de s3n.

Si vous êtes ici parce que vous souhaitez comprendre quel système de fichiers S3 vous devez utiliser avec Amazon EMR, lisez cet article d'Amazon (disponible uniquement sur la machine de retour). Le réseau est: use s3: // car s3: // et s3n: // sont fonctionnellement interchangeables dans le contexte de l'EMR, tandis que s3a: // n'est pas compatible avec l'EMR.

Pour obtenir des conseils supplémentaires, lisez Utilisation des systèmes de stockage et de fichiers .

dans Apache Hadoop, "s3: //" fait référence au client S3 d'origine, qui utilisait une structure non standard pour l'évolutivité. Cette bibliothèque est obsolète et sera bientôt supprimée,

s3n est son successeur, qui utilisait des noms de chemin directs vers les objets, afin que vous puissiez lire et écrire des données avec d'autres applications. Comme s3: //, il utilise jets3t.jar pour parler à S3.

Sur le service EMR d'Amazon, s3: // fait référence au propre client S3 d'Amazon, ce qui est différent. Un chemin dans s3: // sur EMR fait directement référence à un objet dans le magasin d'objets.

Dans Apache Hadoop, S3N et S3A sont tous deux des connecteurs vers S3, avec S3A le successeur construit à l'aide du propre AWS SDK d'Amazon. Pourquoi le nouveau nom? afin que nous puissions l'expédier côte à côte avec celui qui était stable. S3A est l'endroit où va tout le travail en cours sur l'évolutivité, les performances, la sécurité, etc. S3N est laissé seul pour ne pas le casser. S3A a été livré dans Hadoop 2.6, mais se stabilisait encore jusqu'en 2.7, principalement avec quelques problèmes d'échelle mineurs.

Si vous utilisez Hadoop 2.7 ou version ultérieure, utilisez s3a. Si vous utilisez Hadoop 2.5 ou une version antérieure. s3n, si vous utilisez Hadoop 2.6, c'est un choix plus difficile. -J'essaierais s3a et reviendrais à s3n s'il y avait des problèmes-

Pour plus d'informations sur l'historique, voir http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/

2017-03-14 Mise à jour en fait, le partitionnement est interrompu sur S3a dans Hadoop 2.6, car la taille de bloc retournée dans un listFiles()appel est 0: des choses comme Spark & ​​pig partitionnent le travail en une tâche / octet. Vous ne pouvez pas utiliser S3a pour le travail d'analyse dans Hadoop 2.6, même si les opérations de base du système de fichiers et la génération de données sont satisfaisantes. Hadoop 2.7 corrige cela.

Mise à jour du 10/01/2018 Hadoop 3.0 a réduit ses implémentations s3: et s3n: s3a est tout ce que vous obtenez. Il est désormais nettement meilleur que son prédécesseur et fonctionne au moins aussi bien que l'implémentation Amazon. "S3:" d'Amazon est toujours proposé par EMR, qui est leur client source fermée. Consultez la documentation EMR pour plus d'informations.