Team tilbud ingeniør Rahul Bhatia fra Clairvoyant om, hvilke filformater der er i big data, hvad der er de mest almindelige funktioner ved Hadoop-formater og hvilket format der er bedre at bruge.
Hvorfor er der brug for forskellige filformater?
En stor flaskehals i ydeevnen for HDFS-aktiverede applikationer som MapReduce og Spark er den tid, det tager at søge, læse og skrive data. Disse problemer forværres af vanskeligheden ved at administrere store datasæt, hvis vi har et udviklende skema i stedet for et fast, eller hvis der er nogle lagerbegrænsninger.
Behandling af big data øger belastningen på lagerundersystemet - Hadoop gemmer data redundant for at opnå fejltolerance. Ud over diske indlæses processoren, netværket, input/output-systemet og så videre. Efterhånden som mængden af data vokser, stiger omkostningerne ved at behandle og opbevare dem også.
Forskellige filformater i opfundet for at løse netop disse problemer. At vælge det passende filformat kan give nogle væsentlige fordele:
- Hurtigere læsetid.
- Hurtigere optagelsestid.
- Delte filer.
- Understøttelse af skemaudvikling.
- Udvidet kompressionsstøtte.
Nogle filformater er beregnet til generel brug, andre til mere specifik brug, og nogle er designet til at opfylde specifikke datakarakteristika. Så udvalget er egentlig ret stort.
Avro filformat
for dataserialisering Avro er meget brugt - det streng baseret, det vil sige et strengdatalagerformat i Hadoop. Det gemmer skemaet i JSON-format, hvilket gør det nemt at læse og fortolke af ethvert program. Selve dataene er i binært format, kompakte og effektive.
Avros serialiseringssystem er sprogneutralt. Filer kan behandles på en række forskellige sprog, i øjeblikket C, C++, C#, Java, Python og Ruby.
En nøglefunktion ved Avro er dens robuste understøttelse af dataskemaer, der ændrer sig over tid, det vil sige udvikler sig. Avro forstår skemaændringer – sletning, tilføjelse eller ændring af felter.
Avro understøtter en række datastrukturer. For eksempel kan du oprette en post, der indeholder en matrix, en optalt type og en underpost.
Dette format er ideelt til at skrive til landingszonen (overgangszonen) af en datasø (, eller datasø - en samling af instanser til lagring af forskellige typer data ud over datakilder direkte).
Så dette format er bedst egnet til at skrive til landingszonen for en datasø af følgende grunde:
- Data fra denne zone læses normalt i sin helhed til videre behandling af downstream-systemer - og et rækkebaseret format er mere effektivt i dette tilfælde.
- Downstream-systemer kan nemt hente skematabeller fra filer – det er ikke nødvendigt at gemme skemaer separat i eksternt metalager.
- Enhver ændring af det originale skema behandles let (skemaudvikling).
Parket filformat
Parket er et open source-filformat til Hadoop, der gemmer indlejrede datastrukturer i fladt søjleformat.
Sammenlignet med den traditionelle rækketilgang er Parket mere effektiv med hensyn til opbevaring og ydeevne.
Dette er især nyttigt for forespørgsler, der læser specifikke kolonner fra en bred (mange kolonner) tabel. Takket være filformatet læses kun de nødvendige kolonner, så I/O holdes på et minimum.
En lille digression og forklaring: For bedre at forstå Parquet-filformatet i Hadoop, lad os se, hvad et kolonnebaseret - dvs. kolonneformat - er. Dette format gemmer lignende værdier for hver kolonne sammen.
, inkluderer posten felterne ID, Navn og Afdeling. I dette tilfælde vil alle ID-kolonneværdierne blive gemt sammen, ligesom navnekolonnens værdier og så videre. Bordet vil se nogenlunde således ud:
ID
Navn
Afdeling
1
emp1
d1
2
emp2
d2
3
emp3
d3
I strengformat vil dataene blive gemt som følger:
1
emp1
d1
2
emp2
d2
3
emp3
d3
I et søjleformet filformat vil de samme data blive gemt som dette:
1
2
3
emp1
emp2
emp3
d1
d2
d3
Det kolonneformede format er mere effektivt, når du skal forespørge flere kolonner fra en tabel. Den vil kun læse de påkrævede kolonner, fordi de støder op til hinanden. På denne måde holdes I/O-drift på et minimum.
For eksempel behøver du kun kolonnen NAME. I Hver post i datasættet skal indlæses, parses efter felt og derefter udtrække NAME-dataene. Kolonneformatet giver dig mulighed for at gå direkte ned til kolonnen Navn, fordi alle værdierne for den kolonne er gemt sammen. Du behøver ikke at scanne hele optagelsen.
Således forbedrer det kolonneformede format forespørgselsydeevne, fordi det kræver mindre opslagstid at komme til de påkrævede kolonner og reducerer antallet af I/O-operationer, fordi kun de ønskede kolonner læses.
En af de unikke funktioner er, at i dette format kan det gemme data med indlejrede strukturer. Det betyder, at i en Parket-fil kan selv indlejrede felter læses individuelt uden at skulle læse alle felterne i den indlejrede struktur. Parket bruger en makulerings- og monteringsalgoritme til at opbevare indlejrede strukturer.
For at forstå Parket-filformatet i Hadoop skal du kende følgende udtryk:
- Gruppe af strenge (rækkegruppe): logisk vandret opdeling af data i rækker. En rækkegruppe består af et fragment af hver kolonne i datasættet.
- Søjlefragment (kolonne chunk): Et fragment af en specifik kolonne. Disse kolonnestykker lever i en bestemt gruppe rækker og er garanteret sammenhængende i filen.
- Side (side): Søjlefragmenter er opdelt i sider skrevet efter hinanden. Siderne har en fælles titel, så du kan springe unødvendige over, når du læser.
Her indeholder titlen blot det magiske tal PAR1 (4 bytes), som identificerer filen som en parketfil.
Sidefoden siger følgende:
- Filmetadata, der indeholder startkoordinaterne for hver kolonnes metadata. Når du læser, skal du først læse filens metadata for at finde alle de kolonnefragmenter af interesse. Kolonnedelene skal derefter læses sekventielt. Andre metadata inkluderer formatversionen, skemaet og eventuelle yderligere nøgleværdi-par.
- Metadata længde (4 bytes).
- magiske tal PAR1 (4 bytes).
ORC filformat
Optimeret række-kolonne filformat (Optimeret rækkekolonne, ) tilbyder en meget effektiv måde at gemme data på og er designet til at overvinde begrænsningerne ved andre formater. Gemmer data i en perfekt kompakt form, så du kan springe unødvendige detaljer over - uden at det kræver opbygning af store, komplekse eller manuelt vedligeholdte indekser.
Fordele ved ORC-formatet:
- Én fil er output fra hver opgave, hvilket reducerer belastningen på NameNode (navneknude).
- Understøttelse af Hive-datatyper, herunder DateTime, decimale og komplekse datatyper (struct, list, map og union).
- Samtidig læsning af den samme fil ved forskellige RecordReader-processer.
- Mulighed for at opdele filer uden at scanne for markører.
- Estimering af den maksimalt mulige heap-hukommelsesallokering til læse/skrive-processer baseret på information i fil-sidefoden.
- Metadata gemmes i Protocol Buffers binære serialiseringsformat, som gør det muligt at tilføje og fjerne felter.
ORC gemmer samlinger af strenge i en enkelt fil, og i samlingen gemmes strengdata i et søjleformat.
En ORC-fil gemmer grupper af linjer kaldet striber og understøttende information i filens sidefod. Postscriptet i slutningen af filen indeholder komprimeringsparametre og størrelsen på den komprimerede sidefod.
Standardstribestørrelsen er 250 MB. På grund af så store striber udføres læsning fra HDFS mere effektivt: i store sammenhængende blokke.
Filfoden registrerer listen over baner i filen, antallet af rækker pr. bane og datatypen for hver kolonne. Den resulterende værdi af count, min, max og sum for hver kolonne er også skrevet der.
Sidefoden på striben indeholder en mappe med stream-placeringer.
Rækkedata bruges ved scanning af tabeller.
Indeksdata inkluderer minimum- og maksimumværdier for hver kolonne og rækkernes position i hver kolonne. ORC-indekser bruges kun til at vælge striber og rækkegrupper, ikke til at besvare forespørgsler.
Sammenligning af forskellige filformater
Avro sammenlignet med Parket
- Avro er et rækkelagringsformat, mens Parket gemmer data i kolonner.
- Parket er bedre egnet til analytiske forespørgsler, hvilket betyder, at læseoperationer og forespørgsler på data er meget mere effektive end at skrive.
- Skriveoperationer i Avro udføres mere effektivt end i Parket.
- Avro beskæftiger sig mere modent med kredsløbsudvikling. Parket understøtter kun skematilsætning, mens Avro understøtter multifunktionel evolution, det vil sige tilføjelse eller ændring af kolonner.
- Parket er ideel til at forespørge et undersæt af kolonner i en flersøjletabel. Avro er velegnet til ETL-operationer, hvor vi forespørger på alle kolonner.
ORC vs Parket
- Parket gemmer indlejrede data bedre.
- ORC er bedre egnet til at prædikate pushdown.
- ORC understøtter ACID-egenskaber.
- ORC komprimerer data bedre.
Hvad skal man ellers læse om emnet:
- .
- .
- .
Kilde: www.habr.com