Wat is technisch het verschil tussen s3n, s3a en s3?

Ik ben op de hoogte van het bestaan ​​van https://wiki.apache.org/hadoop/AmazonS3en de volgende woorden:

S3 Native FileSystem (URI-schema: s3n) Een native bestandssysteem voor het lezen en schrijven van reguliere bestanden op S3. Het voordeel van dit bestandssysteem is dat je toegang hebt tot bestanden op S3 die met andere tools zijn geschreven. Omgekeerd hebben andere tools toegang tot bestanden die zijn geschreven met Hadoop. Het nadeel is de door S3 opgelegde limiet van 5 GB voor de bestandsgrootte.

S3A (URI-schema: s3a) Een opvolger van de S3 Native, s3n fs, het S3a:-systeem gebruikt de bibliotheken van Amazon om met S3 te communiceren. Hierdoor kan S3a grotere bestanden ondersteunen (geen limiet van 5 GB meer), bewerkingen met hogere prestaties en meer. Het bestandssysteem is bedoeld als vervanging voor/opvolger van S3 Native: alle objecten die toegankelijk zijn vanaf s3n:// URL’s moeten ook toegankelijk zijn vanuit s3a door simpelweg het URL-schema te vervangen.

S3 Block FileSystem (URI-schema: s3) Een op blokken gebaseerd bestandssysteem ondersteund door S3. Bestanden worden opgeslagen als blokken, net zoals in HDFS. Dit maakt een efficiënte implementatie van naamsveranderingen mogelijk. Dit bestandssysteem vereist dat u een bucket voor het bestandssysteem toewijst – u mag geen bestaande bucket gebruiken die bestanden bevat, of andere bestanden naar dezelfde bucket schrijven. De bestanden die door dit bestandssysteem worden opgeslagen, kunnen groter zijn dan 5 GB, maar ze zijn niet compatibel met andere S3-tools.

Waarom zou een letterwijziging op de URI zo’n verschil kunnen maken? Bijvoorbeeld

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

naar

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

Wat is het technische verschil dat aan deze wijziging ten grondslag ligt? Zijn er goede artikelen die ik hierover kan lezen?

Antwoord 1, autoriteit 100%

De letterwijziging in het URI-schema maakt een groot verschil, omdat hierdoor andere software wordt gebruikt om te communiceren met S3. Een beetje zoals het verschil tussen http en https – het is maar een wijziging van één letter, maar het veroorzaakt een groot verschil in gedrag.

Het verschil tussen s3 en s3n/s3a is dat s3 een op blokken gebaseerde overlay is bovenop Amazon S3, terwijl s3n/s3a dat niet is (ze zijn op objecten gebaseerd).

Het verschil tussen s3n en s3a is dat s3n objecten tot 5 GB ondersteunt, terwijl s3a objecten tot 5 TB ondersteunt en hogere prestaties levert (beide omdat het gebruik maakt van meerdelige upload). s3a is de opvolger van s3n.

Als je hier bent omdat je wilt weten welk S3-bestandssysteem je moet gebruiken met Amazon EMR, lees dan dit artikelvan Amazon (alleen beschikbaar op wayback-machine). Het internet is: gebruik s3:// omdat s3:// en s3n:// functioneel uitwisselbaar zijn in de context van EMR, terwijl s3a:// niet compatibel is met EMR.

Lees voor aanvullend advies Werken met opslag en bestandssystemen.

Antwoord 2, autoriteit 40%

in Apache Hadoop verwijst “s3://” naar de oorspronkelijke S3-client, die een niet-standaard structuur gebruikte voor schaalbaarheid. Die bibliotheek is verouderd en wordt binnenkort verwijderd,

s3n is de opvolger, die directe padnamen naar objecten gebruikte, zodat je gegevens kunt lezen en schrijven met andere applicaties. Net als s3:// gebruikt het jets3t.jar om met S3 te praten.

Op de EMR-service van Amazon verwijst s3:// naar de eigen S3-client van Amazon, wat anders is. Een pad in s3:// op EMR verwijst rechtstreeks naar een object in de objectopslag.

In Apache Hadoop zijn S3N en S3A beide connectoren voor S3, waarbij S3A de opvolger is die is gebouwd met Amazon’s eigen AWS SDK.
Waarom de nieuwe naam? zodat we het naast het exemplaar konden verzenden dat stabiel was. S3A is waar al het lopende werk aan schaalbaarheid, prestaties, beveiliging, enz. naartoe gaat. S3N wordt alleen gelaten, dus we breken het niet. S3A werd verzonden in Hadoop 2.6, maar stabiliseerde nog steeds tot 2.7, voornamelijk met enkele kleine schaalproblemen.

Als je Hadoop 2.7 of hoger gebruikt, gebruik dan s3a. Als u Hadoop 2.5 of eerder gebruikt. s3n, als je Hadoop 2.6 gebruikt, is het een moeilijkere keuze. -Ik zou s3a proberen en terugschakelen naar s3n als er problemen waren-

Voor meer geschiedenis, zie http://hortonworks. com/blog/history-apache-hadoops-support-amazon-s3/

Update 2017-03-14eigenlijk, partitionering is verbroken op S3a in Hadoop 2.6, omdat de blokgrootte die wordt geretourneerd in een listFiles()-aanroep 0 is: dingen als vonk & pig verdeel het werk in één taak/byte. U kunt S3a niet gebruiken voor analysewerk in Hadoop 2.6, zelfs als kernbewerkingen van het bestandssysteem & het genereren van gegevens is gelukkig. Hadoop 2.7 lost dat op.

Update 2018-01-10Hadoop 3.0 heeft zijn s3: en s3n-implementaties verlaagd: s3a is alles wat je krijgt. Het is nu aanzienlijk beter dan zijn voorganger en presteert minstens zo goed als de Amazon-implementatie. Amazon’s “s3:” wordt nog steeds aangeboden door EMR, hun closed source-client. Raadpleeg de EMR-documentenvoor meer informatie .

Antwoord 3

TL;DR

1. AWS EMR gebruik gewoon s3://
2. Niet EMR-cluster – beperk het gebruik van S3.
   • gebruik s3of s3aniet om grote hoeveelheden gegevens rechtstreeks uit uw code te lezen/schrijven.
   • Haal gegevens op naar cluster HDFS met behulp van s3-dist-cpen stuur deze vervolgens terug naar S3
   • s3ais alleen nuttig om een ​​kleine tot gemiddelde hoeveelheid gegevens te lezen
   • s3aschrijven is onstabiel

(Praten uit ervaring tijdens het implementeren van meerdere taken op EPD en private hardwareclusters)