Was ist technisch der Unterschied zwischen s3n, s3a und s3?

Mir ist die Existenz von https://wiki.apache.org/hadoop/AmazonS3 und die folgenden Wörter bekannt:

S3 Native FileSystem (URI-Schema: s3n) Ein natives Dateisystem zum Lesen und Schreiben regulärer Dateien in S3. Der Vorteil dieses Dateisystems besteht darin, dass Sie auf Dateien in S3 zugreifen können, die mit anderen Tools geschrieben wurden. Umgekehrt können andere Tools auf Dateien zugreifen, die mit Hadoop geschrieben wurden. Der Nachteil ist die von S3 auferlegte Beschränkung der Dateigröße auf 5 GB.

S3A (URI-Schema: s3a) Als Nachfolger des S3 Native s3n fs verwendet das S3a: -System die Bibliotheken von Amazon, um mit S3 zu interagieren. Dadurch kann S3a größere Dateien (kein Limit von mehr als 5 GB), Operationen mit höherer Leistung und mehr unterstützen. Das Dateisystem soll ein Ersatz für / Nachfolger von S3 Native sein: Alle Objekte, auf die über s3n: // URLs zugegriffen werden kann, sollten auch über s3a zugänglich sein, indem einfach das URL-Schema ersetzt wird.

S3 Block FileSystem (URI-Schema: s3) Ein blockbasiertes Dateisystem, das von S3 unterstützt wird. Dateien werden wie in HDFS als Blöcke gespeichert. Dies ermöglicht eine effiziente Implementierung von Umbenennungen. Für dieses Dateisystem müssen Sie einen Bucket für das Dateisystem reservieren. Sie sollten keinen vorhandenen Bucket mit Dateien verwenden oder andere Dateien in denselben Bucket schreiben. Die von diesem Dateisystem gespeicherten Dateien können größer als 5 GB sein, sind jedoch nicht mit anderen S3-Tools kompatibel.

Warum könnte eine Buchstabenänderung in der URI einen solchen Unterschied machen? Beispielsweise

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

zu

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

Was ist der technische Unterschied, der dieser Änderung zugrunde liegt? Gibt es gute Artikel, die ich dazu lesen kann?

Die Buchstabenänderung im URI-Schema macht einen großen Unterschied, da unterschiedliche Software für die Schnittstelle zu S3 verwendet wird. Etwas wie der Unterschied zwischen http und https - es ist nur eine Änderung mit einem Buchstaben, aber es löst einen großen Unterschied im Verhalten aus.

Der Unterschied zwischen s3 und s3n / s3a besteht darin, dass s3 eine blockbasierte Überlagerung über Amazon S3 ist, s3n / s3a jedoch nicht (sie sind objektbasiert).

Der Unterschied zwischen s3n und s3a besteht darin, dass s3n Objekte mit einer Größe von bis zu 5 GB unterstützt, während s3a Objekte mit einer Größe von bis zu 5 TB unterstützt und eine höhere Leistung aufweist (beides liegt daran, dass ein mehrteiliger Upload verwendet wird). s3a ist der Nachfolger von s3n.

Wenn Sie hier sind, um zu verstehen, welches S3-Dateisystem Sie mit Amazon EMR verwenden sollten, lesen Sie diesen Artikel von Amazon (nur auf Wayback-Computern verfügbar). Das Netz lautet: Verwenden Sie s3: //, da s3: // und s3n: // im Kontext von EMR funktional austauschbar sind, während s3a: // nicht mit EMR kompatibel ist.

Weitere Hinweise finden Sie unter Arbeiten mit Speicher- und Dateisystemen .

In Apache Hadoop bezieht sich "s3: //" auf den ursprünglichen S3-Client, der für die Skalierbarkeit eine nicht standardmäßige Struktur verwendet hat. Diese Bibliothek ist veraltet und wird bald gelöscht.

s3n ist sein Nachfolger, der direkte Pfadnamen zu Objekten verwendete, sodass Sie Daten mit anderen Anwendungen lesen und schreiben können. Wie s3: // verwendet es jets3t.jar, um mit S3 zu sprechen.

Im EMR-Dienst von Amazon bezieht sich s3: // auf den S3-Client von Amazon, der anders ist. Ein Pfad in s3: // on EMR verweist direkt auf ein Objekt im Objektspeicher.

In Apache Hadoop sind S3N und S3A beide Konnektoren zu S3, wobei S3A der Nachfolger ist, der mit dem Amazon AWS SDK erstellt wurde. Warum der neue Name? so konnten wir es Seite an Seite mit dem stabilen versenden. In S3A werden alle laufenden Arbeiten zu Skalierbarkeit, Leistung, Sicherheit usw. durchgeführt. S3N bleibt allein, damit wir es nicht kaputt machen. S3A wurde in Hadoop 2.6 ausgeliefert, stabilisierte sich jedoch noch bis 2.7, hauptsächlich mit einigen geringfügigen Problemen beim Auftauchen.

Wenn Sie Hadoop 2.7 oder höher verwenden, verwenden Sie s3a. Wenn Sie Hadoop 2.5 oder früher verwenden. s3n, Wenn Sie Hadoop 2.6 verwenden, ist dies eine schwierigere Wahl. -Ich würde s3a ausprobieren und bei Problemen wieder zu s3n wechseln-

Weitere Informationen zur Geschichte finden Sie unter http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/.

2017-03-14 Update tatsächlich, Partitionierung ist auf S3a in Hadoop 2.6 unterbrochen, da die in einem listFiles()Aufruf zurückgegebene Blockgröße 0 ist: Dinge wie Spark & ​​Pig partitionieren die Arbeit in eine Aufgabe / ein Byte. Sie können S3a nicht für die Analyse in Hadoop 2.6 verwenden, selbst wenn der Kernbetrieb des Dateisystems und die Datengenerierung zufrieden sind. Hadoop 2.7 behebt das.

2018-01-10 Update Hadoop 3.0 hat seine s3: - und s3n-Implementierungen gekürzt: s3a ist alles, was Sie bekommen. Es ist jetzt deutlich besser als sein Vorgänger und bietet mindestens die gleiche Leistung wie die Amazon-Implementierung. Amazon "s3:" wird weiterhin von EMR angeboten, dem Closed-Source-Client. Weitere Informationen finden Sie in den EMR-Dokumenten .