Tecnicamente qual è 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 leggere e scrivere file regolari su S3. Il vantaggio di questo filesystem è che è ansible 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?

La modifica della lettera sullo schema URI fa una grande differenza perché causa l’utilizzo di software diversi 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 è una sovrapposizione basata 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 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, leggi questo articolo da Amazon (la rete è: usa s3: // perché s3: // e s3n: // sono funzionalmente intercambiabili nel contesto di EMR, mentre s3a: // non è compatibile con EMR).

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

s3n è il suo successore, che utilizzava nomi di percorsi diretti agli oggetti, così puoi 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 object nell’archivio oggetti.

In Apache Hadoop, S3N e S3A sono entrambi connettori per S3, con S3A il successore costruito utilizzando il proprio AWK 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 stai usando Hadoop 2.7 o successivo, usa s3a. Se si utilizza Hadoop 2.5 o precedente. s3n, Se stai usando Hadoop 2.6, è una scelta più difficile. -Provare s3a e tornare a s3n se ci fossero problemi-

Per ulteriori informazioni sulla storia, consultare 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 chiamata listFiles() è 0: cose come Spark & listFiles() il lavoro in un task / byte. Non è ansible utilizzare S3a per il lavoro di analisi in Hadoop 2.6, anche se le operazioni del filesystem principale e la generazione dei dati sono felici. Hadoop 2.7 risolve questo.

2018-01-10 Aggiornamento Hadoop 3.0 ha tagliato le sue implementazioni s3: e s3n: s3a è tutto ciò che ottieni. 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 i documenti EMR per maggiori informazioni.