teamo ofertas inĝeniero Rahul Bhatia de Clairvoyant pri kiaj dosierformatoj estas en grandaj datumoj, kiuj estas la plej oftaj trajtoj de Hadoop-formatoj kaj kiu formato estas pli bone uzi.
Kial necesas malsamaj dosierformatoj?
Grava rendimenta proplemkolo por HDFS-ebligitaj aplikoj kiel MapReduce kaj Spark estas la tempo necesa por serĉi, legi kaj skribi datumojn. Ĉi tiuj problemoj estas kunmetitaj de la malfacileco en administrado de grandaj datumserioj se ni havas evoluantan skemon prefere ol fiksan, aŭ se ekzistas iuj stokadlimoj.
Prilaborado de grandaj datumoj pliigas la ŝarĝon sur la stokadsubsistemo - Hadoop stokas datumojn redunde por atingi misfunkciadon. Krom diskoj estas ŝarĝitaj la procesoro, reto, enigo/eliga sistemo ktp. Dum la volumo de datumoj kreskas, ankaŭ la kosto de prilaborado kaj stokado de ĝi.
Diversaj dosierformatoj en inventita por solvi ĝuste tiujn problemojn. Elekti la taŭgan dosierformaton povas doni iujn signifajn avantaĝojn:
- Pli rapida tempo de legado.
- Pli rapida registra tempo.
- Komunaj dosieroj.
- Subteno por skemo-evoluo.
- Pligrandigita kunprema subteno.
Kelkaj dosierformatoj estas destinitaj por ĝenerala uzo, aliaj por pli specifaj uzoj, kaj kelkaj estas dizajnitaj por renkonti specifajn datenkarakterizaĵojn. Do la elekto estas vere sufiĉe granda.
Avro-dosierformato
Por serialigo de datumoj Avro estas vaste uzata - ĝi kordo bazita, tio estas, ŝnuro datumstokado formato en Hadoop. Ĝi stokas la skemon en JSON-formato, faciligante ĝin legi kaj interpreti per iu ajn programo. La datumoj mem estas en binara formato, kompakta kaj efika.
La seriigsistemo de Avro estas lingvoneŭtrala. Dosieroj povas esti prilaboritaj en diversaj lingvoj, nuntempe C, C++, C#, Java, Python kaj Ruby.
Ĉefa trajto de Avro estas ĝia fortika subteno por datumskemoj kiuj ŝanĝiĝas laŭlonge de la tempo, tio estas, evoluas. Avro komprenas skemajn ŝanĝojn—forigante, aldoni aŭ ŝanĝi kampojn.
Avro subtenas diversajn datumstrukturojn. Ekzemple, vi povas krei rekordon kiu enhavas tabelon, listigitan tipon kaj subrekordon.
Ĉi tiu formato estas ideala por skribi al la surteriĝo (transira) zono de datuma lago (, aŭ datenlago - kolekto de petskriboj por stoki diversajn specojn de datumoj krom datumfontoj rekte).
Do, ĉi tiu formato plej taŭgas por skribi al la surteriĝozono de datuma lago pro la sekvaj kialoj:
- Datenoj de ĉi tiu zono estas kutime legitaj en sia tuteco por plia prilaborado de kontraŭfluaj sistemoj - kaj vic-bazita formato estas pli efika en ĉi tiu kazo.
- Laŭfluaj sistemoj povas facile preni skemajn tabelojn el dosieroj—ne necesas konservi skemojn aparte en ekstera metastokado.
- Ajna ŝanĝo al la origina skemo estas facile prilaborita (skemo-evoluo).
Parquet Dosierformato
Parquet estas malfermfonta dosierformato por Hadoop kiu stokas nestitaj datumstrukturoj en plata kolumna formato.
Kompare kun la tradicia vica aliro, Parquet estas pli efika laŭ stokado kaj rendimento.
Ĉi tio estas precipe utila por demandoj, kiuj legas specifajn kolumnojn de larĝa (multaj kolumnoj) tabelo. Danke al la dosierformato, nur la necesaj kolumnoj estas legitaj, do I/O estas minimume.
Eta digresio kaj klarigo: Por pli bone kompreni la Parquet-dosierformaton en Hadoop, ni vidu kio estas kolumna - t.e. kolumna - formato. Ĉi tiu formato stokas similajn valorojn por ĉiu kolumno kune.
, la rekordo inkluzivas la ID, Nomo, kaj Fako kampoj. En ĉi tiu kazo, ĉiuj ID-kolumnaj valoroj estos stokitaj kune, same kiel la Nomaj kolumnaj valoroj, ktp. La tablo aspektos kiel ĉi tio:
ID
Nomo
Fako
1
emp1
d1
2
emp2
d2
3
emp3
d3
En ĉenformato, la datumoj estos konservitaj jene:
1
emp1
d1
2
emp2
d2
3
emp3
d3
En kolona dosierformato, la samaj datumoj estos konservitaj jene:
1
2
3
emp1
emp2
emp3
d1
d2
d3
La kolumna formato estas pli efika kiam vi bezonas pridemandi plurajn kolumnojn de tabelo. Ĝi nur legos la postulatajn kolumnojn ĉar ili estas apudaj. Tiamaniere, I/O operacioj estas konservitaj al minimumo.
Ekzemple, vi bezonas nur la NOMO-kolumnon. EN Ĉiu rekordo en la datumaro devas esti ŝarĝita, analizita laŭ kampo, kaj poste ĉerpi la NAME-datumojn. La kolumna formato ebligas al vi bori rekte al la Nomo-kolumno ĉar ĉiuj valoroj por tiu kolumno estas stokitaj kune. Vi ne devas skani la tutan registradon.
Tiel, la kolumna formato plibonigas demandan rendimenton ĉar ĝi postulas malpli da serĉtempo por atingi la postulatajn kolumnojn kaj reduktas la nombron da I/O-operacioj ĉar nur la dezirataj kolumnoj estas legitaj.
Unu el la unikaj trajtoj estas ke en ĉi tiu formato ĝi povas stoki datumojn kun nestitaj strukturoj. Ĉi tio signifas, ke en Parquet-dosiero, eĉ nestitaj kampoj povas esti legitaj individue sen devi legi ĉiujn kampojn en la nestita strukturo. Parquet uzas disrompadon kaj kunig-algoritmon por stoki nestitajn strukturojn.
Por kompreni la Parquet-dosierformaton en Hadoop, vi devas scii la jenajn terminojn:
- Vicogrupo (vicgrupo): logika horizontala divido de datumoj en vicojn. Vicgrupo konsistas el fragmento de ĉiu kolumno en la datumaro.
- Kolumna fragmento (kolumnpeco): Fragmento de specifa kolono. Ĉi tiuj kolumpecoj vivas en specifa grupo de vicoj kaj estas garantiitaj esti apudaj en la dosiero.
- Paĝo (paĝo): Kolumnfragmentoj estas dividitaj en paĝojn skribitajn unu post la alia. La paĝoj havas komunan titolon, do vi povas preterlasi nenecesajn dum legado.
Ĉi tie la titolo nur enhavas la magian nombron PAR1 (4 bajtoj) kiu identigas la dosieron kiel Parquet dosiero.
La piedlinio diras la jenon:
- Dosiero metadatenoj kiu enhavas la komencajn koordinatojn de la metadatenoj de ĉiu kolumno. Legante, vi unue devas legi la metadatumojn de la dosiero por trovi ĉiujn kolumnajn fragmentojn de intereso. La kolonpartoj tiam devus esti legitaj sinsekve. Aliaj metadatenoj inkluzivas la formatversion, skemon kaj iujn ajn kromajn ŝlosilvalorajn parojn.
- Longo de metadatumoj (4 bajtoj).
- magia nombro PAR1 (4 bajtoj).
ORC Dosierformato
Optimumigita vico-kolumna dosierformato (Optimigita Vico-Kolumno, ) ofertas tre efikan manieron stoki datumojn kaj estis dizajnita por venki la limojn de aliaj formatoj. Stokas datumojn en perfekte kompakta formo, ebligante vin salti nenecesajn detalojn - sen postuli la konstruadon de grandaj, kompleksaj aŭ mane konservitaj indeksoj.
Avantaĝoj de la ORC-formato:
- Unu dosiero estas la eligo de ĉiu tasko, kiu reduktas la ŝarĝon sur la NameNode (nomnodo).
- Subteno por Hive-datumtipoj, inkluzive de DateTime, decimalaj kaj kompleksaj datumtipoj (strukturo, listo, mapo kaj unio).
- Samtempa legado de la sama dosiero per malsamaj RecordReader-procezoj.
- Kapablo dividi dosierojn sen skanado por markiloj.
- Taksado de la maksimuma ebla amasmemoro-atribuo por legado/skribaj procezoj bazitaj sur informoj en la dosierpiedo.
- Metadatenoj estas stokitaj en la Protocol Buffers binara seriigformato, kiu permesas al kampoj esti aldonitaj kaj forigitaj.
ORC stokas kolektojn de ŝnuroj en ununura dosiero, kaj ene de la kolekto, ŝnuroj estas stokitaj en kolonformato.
ORC-dosiero stokas grupojn de linioj nomataj strioj kaj subtenajn informojn en la piedlinio de la dosiero. La Postskribo ĉe la fino de la dosiero enhavas kunpremajn parametrojn kaj la grandecon de la kunpremita piedlinio.
La defaŭlta striograndeco estas 250 MB. Pro tiaj grandaj strioj, legado de HDFS estas farita pli efike: en grandaj apudaj blokoj.
La dosierpiedo registras la liston de lenoj en la dosiero, la nombron da vicoj per leno, kaj la datumtipo de ĉiu kolumno. La rezulta valoro de kalkulo, min, max kaj sumo por ĉiu kolumno ankaŭ estas skribita tie.
La piedlinio de la strio enhavas dosierujon de riveretolokoj.
Vicdatenoj estas uzataj dum skanado de tabeloj.
Indeksaj datumoj inkluzivas la minimumajn kaj maksimumajn valorojn por ĉiu kolumno kaj la pozicion de la vicoj en ĉiu kolumno. ORC-indeksoj estas uzataj nur por elekti striojn kaj vicgrupojn, ne por respondi demandojn.
Komparo de malsamaj dosierformatoj
Avro kompare kun Parquet
- Avro estas vica stokado formato, dum Parquet stokas datumojn en kolumnoj.
- Parquet pli taŭgas por analizaj demandoj, tio signifas, ke legaj operacioj kaj pridemandado de datumoj estas multe pli efikaj ol skribado.
- Skribaj operacioj en Avro estas faritaj pli efike ol en Parquet.
- Avro traktas cirkvitenvolucion pli mature. Parquet nur subtenas skeman aldonon, dum Avro subtenas multfunkcian evoluon, tio estas, aldoni aŭ ŝanĝi kolumnojn.
- Parquet estas ideala por pridemandi subaron de kolumnoj en plurkolumna tabelo. Avro taŭgas por ETL-operacioj, kie ni pridemandas ĉiujn kolumnojn.
ORC vs Parquet
- Parquet stokas nestitajn datumojn pli bone.
- ORC pli bone taŭgas por predikativo-puŝmalsupren.
- ORC subtenas ACID-propraĵojn.
- ORC pli bone kunpremas datumojn.
Kion alian legi pri la temo:
- .
- .
- .
fonto: www.habr.com