team oanbiedingen yngenieur Rahul Bhatia fan Clairvoyant oer hokker bestânsformaten d'r binne yn grutte gegevens, wat binne de meast foarkommende funksjes fan Hadoop-formaten en hokker formaat better is om te brûken.
Wêrom binne ferskillende bestânsformaten nedich?
In wichtige knelpunt foar prestaasjes foar HDFS-ynskeakele applikaasjes lykas MapReduce en Spark is de tiid dy't it nimt om gegevens te sykjen, te lêzen en te skriuwen. Dizze problemen wurde fersterke troch de muoite by it behearen fan grutte datasets as wy in skema hawwe yn stee fan in fêste, of as d'r wat opslachbeheiningen binne.
It ferwurkjen fan grutte gegevens fergruttet de lading op it opslachsubsysteem - Hadoop bewarret gegevens oerstallich om fouttolerânsje te berikken. Neist skiven wurde de prosessor, netwurk, ynfier-/útfiersysteem, ensfh. As it folume fan gegevens groeit, groeie ek de kosten foar it ferwurkjen en opslaan.
Ferskate bestânsformaten yn útfûn om krekt dizze problemen op te lossen. It selektearjen fan it passende bestânsformaat kin inkele wichtige foardielen leverje:
- Snellere lêstiid.
- Snellere opname tiid.
- Dielde triemmen.
- Stipe foar skema-evolúsje.
- Utwreide kompresje-stipe.
Guon bestânsformaten binne bedoeld foar algemien gebrûk, oaren foar mear spesifyk gebrûk, en guon binne ûntworpen om te foldwaan oan spesifike gegevenskarakteristiken. Dus de kar is echt frij grut.
Avro triemformaat
foar data serialization Avro wurdt in soad brûkt - it string basearre, dat is, in string gegevens opslachformaat yn Hadoop. It bewarret it skema yn JSON-formaat, wêrtroch it maklik te lêzen en ynterpretearje troch elk programma. De gegevens sels binne yn binêre formaat, kompakt en effisjint.
Avro's serialisaasjesysteem is taalneutraal. Bestannen kinne wurde ferwurke yn in ferskaat oan talen, op it stuit C, C++, C#, Java, Python en Ruby.
In wichtich skaaimerk fan Avro is har robúste stipe foar gegevensskema's dy't oer de tiid feroarje, dat is, evoluearje. Avro begrypt skemawizigingen - fjilden wiskje, tafoegje of feroarje.
Avro stipet in ferskaat oan gegevensstruktueren. Jo kinne bygelyks in record oanmeitsje dy't in array, in opnomd type en in subrecord befettet.
Dit formaat is ideaal foar skriuwen nei de lâningssône (oergong) fan in gegevensmar (, of gegevensmar - in kolleksje fan eksimplaren foar it bewarjen fan ferskate soarten gegevens neist gegevensboarnen direkt).
Dat, dit formaat is it bêste geskikt foar it skriuwen nei de lâningsône fan in gegevensmar om de folgjende redenen:
- Gegevens út dizze sône wurde meastal lêzen yn syn gehiel foar fierdere ferwurking troch downstream systemen - en in rige-basearre opmaak is effisjinter yn dit gefal.
- Downstream-systemen kinne skematabellen maklik ophelje út bestannen - gjin needsaak om skema's apart op te slaan yn eksterne meta-opslach.
- Elke feroaring oan it orizjinele skema wurdt maklik ferwurke (skema-evolúsje).
Parket triemformaat
Parquet is in iepen boarne bestânsformaat foar Hadoop dat opslaat geneste gegevensstruktueren yn platte kolomfoarm.
Yn ferliking mei de tradisjonele rige oanpak, Parket is effisjinter yn termen fan opslach en prestaasjes.
Dit is benammen nuttich foar fragen dy't spesifike kolommen lêze fan in brede (in protte kolommen) tabel. Mei tank oan it bestânsformaat wurde allinich de nedige kolommen lêzen, sadat I/O op in minimum wurdt hâlden.
In lytse digresje en útlis: Om it Parquet-bestânsformaat yn Hadoop better te begripen, litte wy sjen wat in kolom-basearre - dus kolumner - formaat is. Dit formaat bewarret ferlykbere wearden foar elke kolom tegearre.
, it rekord omfettet de ID-, Namme- en ôfdielingsfjilden. Yn dit gefal sille alle ID-kolomwearden tegearre wurde opslein, lykas de Name-kolomwearden, ensafuorthinne. De tabel sil der sa útsjen:
ID
namme
Departemint
1
emp1
d1
2
emp2
d2
3
emp3
d3
Yn stringformaat wurde de gegevens as folget bewarre:
1
emp1
d1
2
emp2
d2
3
emp3
d3
Yn in kolombestânsformaat wurde deselde gegevens sa opslein:
1
2
3
emp1
emp2
emp3
d1
d2
d3
It kolomformaat is effisjinter as jo meardere kolommen út in tabel moatte freegje. It sil allinich de fereaske kolommen lêze om't se neistlizze. Op dizze manier wurde I/O-operaasjes op in minimum hâlden.
Jo hawwe bygelyks allinich de kolom NAME nedich. YN Elke record yn 'e dataset moat wurde laden, parseard troch fjild, en dan de NAME-gegevens ekstrahearre. It kolomformaat lit jo direkt nei de kolom Namme boarje, om't alle wearden foar dy kolom tegearre wurde opslein. Jo hoege net de hiele opname te scannen.
Sa ferbettert it kolomformaat query-prestaasjes om't it minder opsyktiid nedich is om nei de fereaske kolommen te kommen en it oantal I/O-operaasjes fermindert, om't allinich de fereaske kolommen lêzen wurde.
Ien fan 'e unike skaaimerken is dat yn dit formaat it kin bewarje gegevens mei nestele struktueren. Dit betsjut dat yn in Parquet-bestân sels nêste fjilden yndividueel lêzen wurde kinne sûnder alle fjilden yn 'e nêste struktuer te lêzen. Parket brûkt in shredding- en assemblagealgoritme foar it bewarjen fan nestede struktueren.
Om it Parquet-bestânsformaat yn Hadoop te begripen, moatte jo de folgjende termen witte:
- Groep fan snaren (rige groep): logyske horizontale ferdieling fan gegevens yn rigen. In rige groep bestiet út in fragmint fan elke kolom yn de gegevens set.
- Kolomfragmint (column chunk): In fragmint fan in spesifike kolom. Dizze kolomfragminten libje yn in spesifike groep rigen en wurde garandearre oanienwei yn 'e triem.
- Side (side): Kolomfragminten wurde ferdield yn siden skreaun ien nei de oare. De siden hawwe in mienskiplike titel, sadat jo ûnnedige oerslaan kinne by it lêzen.
Hjir befettet de titel gewoan it magyske nûmer PAR1 (4 bytes) dy't identifisearret de triem as in Parket triem.
De foettekst seit it folgjende:
- Bestânsmetadata dy't de startkoordinaten fan de metadata fan elke kolom befettet. By it lêzen moatte jo earst de metadata fan it bestân lêze om alle ynteressante kolomfragminten te finen. De kolompartijen moatte dan opfolgjend lêzen wurde. Oare metadata omfetsje de opmaakferzje, skema, en alle ekstra kaai-wearde-pearen.
- Metadata lingte (4 bytes).
- magysk getal PAR1 (4 bytes).
ORC triemformaat
Optimalisearre rige-kolom bestânsformaat (Optimized Row Column, ) biedt in heul effisjinte manier om gegevens op te slaan en is ûntworpen om de beheiningen fan oare formaten te oerwinnen. Bewarret gegevens yn in perfekt kompakte foarm, wêrtroch jo ûnnedige details kinne oerslaan - sûnder dat de oanlis fan grutte, komplekse of mei de hân ûnderhâlden yndeksen nedich is.
Foardielen fan it ORC-formaat:
- Ien bestân is de útfier fan elke taak, dy't de lading op 'e NameNode (nammeknooppunt) ferminderet.
- Stipe foar Hive-gegevenstypen, ynklusyf DateTime, desimale en komplekse gegevenstypen (struktuer, list, kaart en uny).
- Tagelyk lêzen fan itselde bestân troch ferskate RecordReader-prosessen.
- Mooglikheid om bestannen te splitsen sûnder te scannen foar markers.
- Skatting fan de maksimale mooglike heapûnthâldallokaasje foar lês- / skriuwprosessen basearre op ynformaasje yn 'e triemfoettekst.
- Metadata wurde opslein yn it Protocol Buffers binêre serialisaasjeformaat, wêrtroch fjilden kinne wurde tafoege en fuortsmiten.
ORC bewarret kolleksjes fan snaren yn ien bestân, en binnen de kolleksje wurde stringgegevens opslein yn in kolomformaat.
In ORC-bestân bewarret groepen rigels neamd stripes en stypjende ynformaasje yn 'e fuottekst fan it bestân. It Postscript oan 'e ein fan it bestân befettet kompresjeparameters en de grutte fan' e komprimearre foettekst.
De standert stripe grutte is 250 MB. Troch sokke grutte strepen wurdt it lêzen fan HDFS effisjinter útfierd: yn grutte oanienlizzende blokken.
De triemfuottekst registrearret de list mei banen yn it bestân, it oantal rigen per baan, en it gegevenstype fan elke kolom. De resultearjende wearde fan count, min, max en som foar elke kolom wurdt dêr ek skreaun.
De fuottekst fan 'e strip befettet in map mei streamlokaasjes.
Rigegegevens wurde brûkt by it scannen fan tabellen.
Yndeksgegevens omfetsje de minimale en maksimale wearden foar elke kolom en de posysje fan 'e rigen yn elke kolom. ORC-yndeksen wurde allinich brûkt foar it selektearjen fan strepen en rigegroepen, net foar it beantwurdzjen fan fragen.
Fergeliking fan ferskate bestânsformaten
Avro ferlike mei Parket
- Avro is in rige opslach formaat, wylst Parquet bewarret gegevens yn kolommen.
- Parket is better geskikt foar analytyske queries, wat betsjut dat lêzen operaasjes en querying gegevens binne folle effisjinter dan skriuwt.
- Skriuwoperaasjes yn Avro wurde effisjinter útfierd as yn Parquet.
- Avro behannelet sirkwy-evolúsje mear folwoeksener. Parket stipet allinnich skema tafoeging, wylst Avro stipet multyfunksjonele evolúsje, dat is, tafoegjen of feroarjen fan kolommen.
- Parket is ideaal foar querying in subset fan kolommen yn in multi-kolom tabel. Avro is geskikt foar ETL operaasjes dêr't wy query alle kolommen.
ORC tsjin Parket
- Parket bewarret nestele gegevens better.
- ORC is better geskikt foar predikaat pushdown.
- ORC stipet ACID eigenskippen.
- ORC komprimearret gegevens better.
Wat oars te lêzen oer it ûnderwerp:
- .
- .
- .
Boarne: www.habr.com