Tecnicamente qual è la differenza tra s3n, s3a e s3?

Question

Sono consapevole dell'esistenza di https://wiki.apache.org/hadoop/AmazonS3 e le seguenti parole:

S3 Native FileSystem (schema URI: S3N) Un file system nativo per la lettura e la scrittura di file regolari S3. Il vantaggio di questo filesystem è che è possibile accedere ai file su S3 scritti con altri strumenti. Viceversa, altri strumenti possono accedere ai file scritti usando Hadoop. Lo svantaggio è il limite di 5 GB per le dimensioni del file imposte da S3.

S3A (schema URI: s3a) Un successore di S3 Native, s3n fs, S3a: il sistema utilizza le librerie di Amazon per interagire con S3. Ciò consente a S3a di supportare file più grandi (non più limiti di 5 GB), operazioni con prestazioni più elevate e altro ancora. Il filesystem è destinato a sostituire/successore di S3 Native: tutti gli oggetti accessibili da s3n: // URL dovrebbero essere accessibili da s3a semplicemente sostituendo lo schema dell'URL.

S3 Block FileSystem (schema URI: s3) Un file system basato su blocchi supportato da S3. I file sono archiviati come blocchi, proprio come sono in HDFS. Ciò consente un'efficiente implementazione dei nomi. Questo file system richiede di dedicare un bucket per il filesystem: non si deve utilizzare un bucket esistente contenente file o scrivere altri file nello stesso bucket. I file archiviati da questo filesystem possono essere maggiori di 5 GB, ma non sono interoperabili con altri strumenti S3.

Perché un cambio di lettera sull'URI potrebbe fare la differenza? Per esempio

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

a

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

Qual è la differenza tecnica alla base di questo cambiamento? Ci sono dei buoni articoli che posso leggere su questo?

Answer 1

La modifica della lettera sullo schema URI fa una grande differenza perché causa l'utilizzo di software diverso per interfacciare S3. Un po 'come la differenza tra http e https - è solo una modifica di una sola lettera, ma innesca una grande differenza di comportamento.

La differenza tra s3 e s3n/s3a è che s3 è un overlay basato su blocchi su Amazon S3, mentre s3n/s3a no (sono basati su oggetti).

La differenza tra s3n e s3a è che s3n supporta oggetti fino a 5 GB di dimensione, mentre s3a supporta oggetti fino a 5 TB e ha prestazioni più elevate (entrambi sono perché utilizza il caricamento di più parti). s3a è il successore di s3n.

Se sei qui perché vuoi capire quale file system S3 dovresti usare con Amazon EMR, allora leggi this article da Amazon (la rete è: usa s3: // perché s3: // e s3n: // sono funzionalmente intercambiabili nel contesto di EMR, mentre s3a: // non è compatibile con EMR).

Answer 2

in Apache Hadoop, "s3: //" si riferisce al client S3 originale, che utilizzava una struttura non standard per la scalabilità. Quella libreria è deprecata e verrà presto eliminata,

s3n è il suo successore, che utilizzava nomi di percorsi diretti agli oggetti, così è possibile leggere e scrivere dati con altre applicazioni. Come s3: //, usa jets3t.jar per parlare con S3.

Sul servizio EMR di Amazon, s3: // si riferisce al client S3 di Amazon, che è diverso. Un percorso in s3: // su EMR fa riferimento direttamente a un oggetto nell'archivio oggetti.

In Apache Hadoop, S3N e S3A sono entrambi connettori per S3, con S3A il successore costruito utilizzando l'AWS AWS di Amazon. Perché il nuovo nome? quindi potremmo spedirlo fianco a fianco con quello che era stabile. S3A è dove tutto il lavoro in corso su scalabilità, prestazioni, sicurezza, ecc. S3N è lasciato in pace, quindi non lo infrangeremo. S3A è stato spedito in Hadoop 2.6, ma si stava ancora stabilizzando fino al 2.7, principalmente con alcuni problemi di scala minori.

Se si utilizza Hadoop 2.7 o successivo, utilizzare s3a. Se si utilizza Hadoop 2.5 o precedente. s3n, Se stai usando Hadoop 2.6, è una scelta più difficile. -Mi provare S3A e tornare a S3N se ci fossero problemi-

Per di più della storia, vedi http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/

2017-03-14 Aggiornamento in realtà, il partizionamento è rotto S3a in Hadoop 2.6 , poiché la dimensione del blocco restituita in una chiamata listFiles() è 0: cose come Spark & partiziona il lavoro in un task/byte. Non è possibile utilizzare S3a per il lavoro di analisi in Hadoop 2.6, anche se le operazioni del file system principale sono la generazione di dati & felice. Hadoop 2.7 risolve questo.

2018-01-10 Aggiornamento Hadoop 3.0 ha tagliato le sue implementazioni s3: e s3n: s3a è tutto ciò che si ottiene. Ora è significativamente migliore rispetto al suo predecessore e funziona almeno quanto l'implementazione Amazon. Amazon "s3:" è ancora offerto da EMR, che è il loro client di origine chiuso. Consulta lo EMR docs per maggiori informazioni.