Qual è tecnicamente la differenza tra s3n, s3a e s3?

Sono a conoscenza dell'esistenza di https://wiki.apache.org/hadoop/AmazonS3 e delle seguenti parole:

S3 Native FileSystem (schema URI: s3n) Un filesystem nativo per la lettura e la scrittura di file regolari su S3. Il vantaggio di questo filesystem è che puoi accedere ai file su S3 che sono stati scritti con altri strumenti. Al contrario, altri strumenti possono accedere ai file scritti utilizzando Hadoop. Lo svantaggio è il limite di 5 GB sulla dimensione del file imposto da S3.

S3A (schema URI: s3a) Successore di S3 Native, s3n fs, il sistema S3a: utilizza le librerie di Amazon per interagire con S3. Ciò consente a S3a di supportare file più grandi (nessun limite di 5 GB), operazioni con prestazioni più elevate e altro ancora. Il filesystem vuole essere un sostituto di / successore di S3 Native: tutti gli oggetti accessibili da s3n: // Gli URL dovrebbero essere accessibili anche da s3a semplicemente sostituendo lo schema URL.

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

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

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

per

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

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

Il cambio di lettera nello schema URI fa una grande differenza perché fa sì che venga utilizzato un software diverso per interfacciarsi a S3. Un po 'come la differenza tra http e https: è solo una modifica di una 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 non lo sono (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 perché utilizza il caricamento in più parti). s3a è il successore di s3n.

Se sei qui perché vuoi capire quale file system S3 dovresti usare con Amazon EMR, leggi questo articolo di Amazon (disponibile solo su wayback machine). La rete è: usa s3: // perché s3: // e s3n: // sono funzionalmente intercambiabili nel contesto di EMR, mentre s3a: // non è compatibile con EMR.

Per ulteriori consigli, leggi Lavorare con archiviazione e file system .

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

s3n è il suo successore, che utilizzava nomi di percorso diretti agli oggetti, in modo da poter leggere e scrivere dati con altre applicazioni. Come s3: //, utilizza 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'SDK AWS di Amazon. Perché il nuovo nome? così potremmo spedirlo fianco a fianco con quello che era stabile. S3A è dove va tutto il lavoro in corso su scalabilità, prestazioni, sicurezza, ecc. S3N viene lasciato solo, quindi non lo interrompiamo. S3A è stato distribuito in Hadoop 2.6, ma si è ancora stabilizzato fino al 2.7, principalmente con alcuni problemi di scala minori che sono emersi.

Se stai usando Hadoop 2.7 o successivo, usa s3a. Se utilizzi Hadoop 2.5 o versioni precedenti. s3n, se stai usando Hadoop 2.6, è una scelta più difficile. -Proverei s3a e tornerei a s3n se ci fossero problemi-

Per ulteriori informazioni sulla cronologia, vedere http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/

2017-03-14 Aggiornamento in realtà, il partizionamento è interrotto su S3a in Hadoop 2.6, poiché la dimensione del blocco restituita in una listFiles()chiamata è 0: cose come Spark e pig partizionano il lavoro in un'attività / byte. Non è possibile utilizzare S3a per il lavoro di analisi in Hadoop 2.6, anche se le operazioni di base del file system e la generazione di dati sono soddisfatte. Hadoop 2.7 lo risolve.

10/01/2018 Aggiornamento Hadoop 3.0 ha tagliato le sue implementazioni s3: e s3n: s3a è tutto ciò che ottieni. Ora è significativamente migliore del suo predecessore e funziona almeno tanto quanto l'implementazione di Amazon. "S3:" di Amazon è ancora offerto da EMR, che è il loro client closed source. Consulta i documenti EMR per maggiori informazioni.