Lêerformate in groot data: 'n kort opvoedkundige program

Weer Godheid deur Remarin

Span Mail.ru Wolkoplossings bied artikel vertaling ingenieur Rahul Bhatia van Clairvoyant oor watter lêerformate daar in groot data is, wat die mees algemene kenmerke van Hadoop-formate is en watter formaat beter is om te gebruik.

Hoekom is verskillende lêerformate nodig?

'n Groot prestasie-knelpunt vir HDFS-geaktiveerde toepassings soos MapReduce en Spark is die tyd wat dit neem om data te soek, lees en skryf. Hierdie probleme word vererger deur die moeilikheid om groot datastelle te bestuur as ons 'n ontwikkelende skema eerder as 'n vaste een het, of as daar bergingbeperkings is.

Die verwerking van groot data verhoog die las op die bergingsubstelsel - Hadoop stoor data oortollig om fouttoleransie te bereik. Benewens skywe word die verwerker, netwerk, invoer/afvoerstelsel, ensovoorts gelaai. Soos die volume data groei, neem die koste om dit te verwerk en te berg ook toe.

Verskeie lêerformate in Hadoop uitgevind om presies hierdie probleme op te los. Die keuse van die toepaslike lêerformaat kan 'n paar belangrike voordele bied:

1. Vinniger leestyd.
2. Vinniger opname tyd.
3. Gedeelde lêers.
4. Ondersteuning vir skema-evolusie.
5. Uitgebreide kompressie-ondersteuning.

Sommige lêerformate is bedoel vir algemene gebruik, ander vir meer spesifieke gebruike, en sommige is ontwerp om aan spesifieke data-eienskappe te voldoen. Die keuse is dus eintlik redelik groot.

Avro lêer formaat

Vir data serialisering Avro word wyd gebruik - dit string gebaseer, dit wil sê 'n string data stoor formaat in Hadoop. Dit stoor die skema in JSON-formaat, wat dit maklik maak om deur enige program te lees en te interpreteer. Die data self is in binêre formaat, kompak en doeltreffend.

Avro se serialiseringstelsel is taalneutraal. Lêers kan in 'n verskeidenheid tale verwerk word, tans C, C++, C#, Java, Python en Ruby.

'n Sleutelkenmerk van Avro is sy robuuste ondersteuning vir dataskemas wat oor tyd verander, dit wil sê, ontwikkel. Avro verstaan ​​skemaveranderinge—vee uit, voeg by of verander velde.

Avro ondersteun 'n verskeidenheid datastrukture. Byvoorbeeld, jy kan 'n rekord skep wat 'n skikking, 'n opgesomde tipe en 'n subrekord bevat.

Hierdie formaat is ideaal om na die landings (oorgangs) sone van 'n datameer (data meer, of datameer - 'n versameling gevalle vir die stoor van verskeie tipes data bykomend tot databronne direk).

Dus, hierdie formaat is die beste geskik om na die landingsone van 'n datameer te skryf om die volgende redes:

1. Data uit hierdie sone word gewoonlik in sy geheel gelees vir verdere verwerking deur stroomafstelsels - en 'n ry-gebaseerde formaat is meer doeltreffend in hierdie geval.
2. Stroomafstelsels kan skematabelle maklik van lêers af haal - dit is nie nodig om skemas apart in eksterne metaberging te stoor nie.
3. Enige verandering aan die oorspronklike skema word maklik verwerk (skema-evolusie).

Parket lêerformaat

Parket is 'n oopbron-lêerformaat vir Hadoop wat stoor geneste datastrukture in plat kolomformaat.

In vergelyking met die tradisionele rybenadering, is Parket meer doeltreffend in terme van berging en werkverrigting.

Dit is veral nuttig vir navrae wat spesifieke kolomme van 'n wye (baie kolomme) tabel lees. Danksy die lêerformaat word slegs die nodige kolomme gelees, dus word I/O tot die minimum beperk.

'n Klein afwyking en verduideliking: Om die Parket-lêerformaat in Hadoop beter te verstaan, kom ons kyk wat 'n kolom-gebaseerde - dit wil sê kolom-formaat is. Hierdie formaat stoor soortgelyke waardes vir elke kolom saam.

Byvoorbeeld, sluit die rekord die ID-, Naam- en Departement-velde in. In hierdie geval sal al die ID-kolomwaardes saam gestoor word, asook die Naam-kolomwaardes, ensovoorts. Die tabel sal iets soos volg lyk:

ID
Naam
Departement

1
emp1
d1

2
emp2
d2

3
emp3
d3

In string-formaat sal die data soos volg gestoor word:

1
emp1
d1
2
emp2
d2
3
emp3
d3

In 'n kolomlêerformaat sal dieselfde data soos volg gestoor word:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Die kolomformaat is meer doeltreffend wanneer jy verskeie kolomme uit 'n tabel moet navraag doen. Dit sal slegs die vereiste kolomme lees omdat hulle aangrensend is. Op hierdie manier word I/O-bewerkings tot 'n minimum beperk.

Byvoorbeeld, jy het net die NAAM-kolom nodig. IN string formaat Elke rekord in die datastel moet gelaai word, volgens veld ontleed word en dan die NAAM-data onttrek word. Die kolomformaat laat jou toe om direk na die Naam-kolom te drill omdat al die waardes vir daardie kolom saam gestoor word. Jy hoef nie die hele opname te skandeer nie.

Die kolomformaat verbeter dus navraagwerkverrigting omdat dit minder soektyd verg om by die vereiste kolomme uit te kom en verminder die aantal I/O-bewerkings omdat slegs die verlangde kolomme gelees word.

Een van die unieke kenmerke parket is dat dit in hierdie formaat kan stoor data met geneste strukture. Dit beteken dat in 'n Parket-lêer selfs geneste velde individueel gelees kan word sonder om al die velde in die geneste struktuur te lees. Parket gebruik 'n versnippering en samestelling algoritme om geneste strukture te stoor.

Om die Parket-lêerformaat in Hadoop te verstaan, moet jy die volgende terme ken:

1. Groep snare (rygroep): logiese horisontale verdeling van data in rye. 'n Rygroep bestaan ​​uit 'n fragment van elke kolom in die datastel.
2. Kolomfragment (kolom stuk): 'n Fragment van 'n spesifieke kolom. Hierdie kolomfragmente woon in 'n spesifieke groep rye en is gewaarborg om aaneenlopend in die lêer te wees.
3. bladsy (bladsy): Kolomfragmente word verdeel in bladsye wat een na die ander geskryf is. Die bladsye het 'n gemeenskaplike titel, so jy kan onnodiges oorslaan wanneer jy lees.

Hier bevat die titel net die towernommer PAR1 (4 grepe) wat die lêer as 'n Parket-lêer identifiseer.

Die voetskrif sê die volgende:

1. Lêer metadata wat die beginkoördinate van elke kolom se metadata bevat. Wanneer jy lees, moet jy eers die lêer se metadata lees om al die kolomfragmente van belang te vind. Die kolomgedeeltes moet dan opeenvolgend gelees word. Ander metadata sluit die formaatweergawe, skema en enige bykomende sleutel-waarde-pare in.
2. Metadata lengte (4 grepe).
3. magiese nommer PAR1 (4 grepe).

ORC-lêerformaat

Geoptimaliseerde ry-kolom lêer formaat (Geoptimaliseerde rykolom, CRO) bied 'n baie doeltreffende manier om data te stoor en is ontwerp om die beperkings van ander formate te oorkom. Stoor data in 'n perfek kompakte vorm, wat jou toelaat om onnodige besonderhede oor te slaan - sonder om die konstruksie van groot, komplekse of met die hand onderhou indekse te vereis.

Voordele van die ORC-formaat:

1. Een lêer is die uitvoer van elke taak, wat die las op die NameNode (naamnode) verminder.
2. Ondersteuning vir Hive-datatipes, insluitend DateTime, desimale en komplekse datatipes (struktuur, lys, kaart en unie).
3. Gelyktydige lees van dieselfde lêer deur verskillende RecordReader-prosesse.
4. Vermoë om lêers te verdeel sonder om vir merkers te skandeer.
5. Beraming van die maksimum moontlike hoopgeheuetoewysing vir lees/skryfprosesse gebaseer op inligting in die lêervoetskrif.
6. Metadata word gestoor in die Protocol Buffers binêre serialisering formaat, wat toelaat dat velde bygevoeg en verwyder kan word.

ORC stoor versamelings stringe in 'n enkele lêer, en binne die versameling word stringdata in 'n kolomformaat gestoor.

'n ORC-lêer stoor groepe lyne wat strepe genoem word en ondersteunende inligting in die voetskrif van die lêer. Die Postscript aan die einde van die lêer bevat kompressieparameters en die grootte van die saamgeperste voetskrif.

Die verstek streepgrootte is 250 MB. As gevolg van sulke groot strepe word lees vanaf HDFS meer doeltreffend uitgevoer: in groot aaneenlopende blokke.

Die lêervoetskrif teken die lys bane in die lêer aan, die aantal rye per baan en die datatipe van elke kolom. Die gevolglike waarde van tel, min, maksimum en som vir elke kolom word ook daar geskryf.

Die voetskrif van die strook bevat 'n gids van stroomliggings.

Rydata word gebruik wanneer tabelle geskandeer word.

Indeksdata bevat die minimum en maksimum waardes vir elke kolom en die posisie van die rye in elke kolom. ORC-indekse word slegs gebruik om strepe en rygroepe te kies, nie om navrae te beantwoord nie.

Vergelyking van verskillende lêerformate

Avro in vergelyking met Parket

1. Avro is 'n rybergingsformaat, terwyl Parquet data in kolomme stoor.
2. Parket is beter geskik vir analitiese navrae, wat beteken dat leesbewerkings en navrae van data baie doeltreffender is as skryf.
3. Skryfbewerkings in Avro word meer doeltreffend uitgevoer as in Parket.
4. Avro hanteer kringevolusie meer volwasse. Parket ondersteun slegs skemabyvoeging, terwyl Avro multifunksionele evolusie ondersteun, dit wil sê die byvoeging of verandering van kolomme.
5. Parket is ideaal om 'n subset van kolomme in 'n multi-kolom tabel te bevraagteken. Avro is geskik vir ETL-bedrywighede waar ons alle kolomme navraag doen.

ORC vs Parket

1. Parket stoor geneste data beter.
2. ORC is beter geskik om predikasie afdruk.
3. ORC ondersteun ACID eienskappe.
4. ORC komprimeer data beter.

Wat anders om te lees oor die onderwerp:

1. Groot data-analise in die wolk: hoe 'n maatskappy data-georiënteerd kan word.
2. 'n Nederige gids tot databasisskemas.
3. Ons telegramkanaal oor digitale transformasie.

Bron: will.com