Formate de fișiere în date mari: un scurt program educațional

Zeitatea vremii de Remarin

Echipă Mail.ru Cloud Solutions ofertele traducerea articolului inginer Rahul Bhatia de la Clairvoyant despre ce formate de fișiere există în big data, care sunt cele mai comune caracteristici ale formatelor Hadoop și ce format este mai bine de utilizat.

De ce sunt necesare formate de fișiere diferite?

Un blocaj major de performanță pentru aplicațiile compatibile HDFS, cum ar fi MapReduce și Spark, este timpul necesar pentru a căuta, citi și scrie date. Aceste probleme sunt agravate de dificultatea de a gestiona seturi mari de date dacă avem o schemă în evoluție mai degrabă decât una fixă, sau dacă există anumite constrângeri de stocare.

Prelucrarea datelor mari crește încărcarea subsistemului de stocare - Hadoop stochează datele redundant pentru a obține toleranța la erori. Pe lângă discuri, sunt încărcate procesorul, rețeaua, sistemul de intrare/ieșire și așa mai departe. Pe măsură ce volumul de date crește, crește și costul procesării și stocării acestora.

Diverse formate de fișiere în Hadoop inventat pentru a rezolva tocmai aceste probleme. Selectarea formatului de fișier adecvat poate oferi câteva beneficii semnificative:

1. Timp de citire mai rapid.
2. Timp de înregistrare mai rapid.
3. Fișiere partajate.
4. Suport pentru evoluția schemei.
5. Suport de compresie extins.

Unele formate de fișiere sunt destinate utilizării generale, altele pentru utilizări mai specifice, iar unele sunt concepute pentru a îndeplini anumite caracteristici de date. Deci, alegerea este într-adevăr destul de mare.

Format de fișier Avro

Pentru serializarea datelor Avro este utilizat pe scară largă - acesta bazat pe șiruri, adică un format de stocare a datelor șir în Hadoop. Stochează schema în format JSON, făcându-l ușor de citit și interpretat de către orice program. Datele în sine sunt în format binar, compacte și eficiente.

Sistemul de serializare al lui Avro este neutru în limbaj. Fișierele pot fi procesate într-o varietate de limbi, în prezent C, C++, C#, Java, Python și Ruby.

O caracteristică cheie a Avro este suportul robust pentru schemele de date care se schimbă în timp, adică evoluează. Avro înțelege modificările schemei - ștergerea, adăugarea sau modificarea câmpurilor.

Avro acceptă o varietate de structuri de date. De exemplu, puteți crea o înregistrare care conține o matrice, un tip enumerat și o subînregistrare.

Acest format este ideal pentru scrierea în zona de aterizare (de tranziție) a unui lac de date (lacul de date, sau data lake - o colecție de instanțe pentru stocarea diferitelor tipuri de date în plus față de sursele de date direct).

Deci, acest format este cel mai potrivit pentru scrierea în zona de aterizare a unui lac de date din următoarele motive:

1. Datele din această zonă sunt de obicei citite în întregime pentru procesarea ulterioară de către sistemele din aval - iar un format bazat pe rând este mai eficient în acest caz.
2. Sistemele din aval pot prelua cu ușurință tabelele de schemă din fișiere - nu este nevoie să stocați schemele separat în meta-stocare externă.
3. Orice modificare a schemei originale este ușor de procesat (evoluția schemei).

Format de fișier parchet

Parquet este un format de fișier open source pentru Hadoop care stochează structuri de date imbricate în format coloană plat.

În comparație cu abordarea tradițională în rânduri, parchetul este mai eficient în ceea ce privește depozitarea și performanța.

Acest lucru este util în special pentru interogările care citesc anumite coloane dintr-un tabel larg (multe coloane). Datorită formatului de fișier, sunt citite doar coloanele necesare, astfel încât I/O este menținut la minimum.

O mică digresiune și explicație: Pentru a înțelege mai bine formatul de fișier Parquet în Hadoop, să vedem ce este un format bazat pe coloane - adică coloane. Acest format stochează valori similare pentru fiecare coloană împreună.

De exemplu, înregistrarea include câmpurile ID, Nume și Departament. În acest caz, toate valorile coloanei ID vor fi stocate împreună, la fel ca și valorile coloanei Nume și așa mai departe. Tabelul va arăta cam așa:

ID
Nume si Prenume
Departament

1
emp1
d1

2
emp2
d2

3
emp3
d3

În format șir, datele vor fi salvate după cum urmează:

1
emp1
d1
2
emp2
d2
3
emp3
d3

Într-un format de fișier coloană, aceleași date vor fi salvate astfel:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Formatul coloanei este mai eficient atunci când trebuie să interogați mai multe coloane dintr-un tabel. Va citi doar coloanele necesare deoarece sunt adiacente. În acest fel, operațiunile I/O sunt reduse la minimum.

De exemplu, aveți nevoie doar de coloana NUME. ÎN format șir Fiecare înregistrare din setul de date trebuie să fie încărcată, analizată după câmp și apoi extrasă datele NAME. Formatul coloanei vă permite să detaliați direct la coloana Nume, deoarece toate valorile pentru acea coloană sunt stocate împreună. Nu trebuie să scanați întreaga înregistrare.

Astfel, formatul de coloană îmbunătățește performanța interogării deoarece necesită mai puțin timp de căutare pentru a ajunge la coloanele necesare și reduce numărul de operațiuni I/O deoarece sunt citite doar coloanele dorite.

Una dintre caracteristicile unice parchet este că în acest format se poate stocarea datelor cu structuri imbricate. Aceasta înseamnă că într-un fișier Parquet, chiar și câmpurile imbricate pot fi citite individual, fără a fi nevoie să citiți toate câmpurile din structura imbricată. Parchetul folosește un algoritm de mărunțire și asamblare pentru a stoca structuri imbricate.

Pentru a înțelege formatul fișierului Parquet în Hadoop, trebuie să cunoașteți următorii termeni:

1. Grup de șiruri (grup de rânduri): împărțirea orizontală logică a datelor în rânduri. Un grup de rânduri constă dintr-un fragment din fiecare coloană din setul de date.
2. Fragment de coloană (column chunk): Un fragment dintr-o coloană specifică. Aceste fragmente de coloană trăiesc într-un anumit grup de rânduri și sunt garantate a fi învecinate în fișier.
3. Page (pagina): Fragmentele de coloane sunt împărțite în pagini scrise una după alta. Paginile au un titlu comun, așa că puteți sări peste cele inutile atunci când citiți.

Aici titlul conține doar numărul magic PAR1 (4 octeți) care identifică fișierul ca fișier Parquet.

Subsolul spune următoarele:

1. Fișier metadate care conține coordonatele de început ale metadatelor fiecărei coloane. Când citiți, trebuie mai întâi să citiți metadatele fișierului pentru a găsi toate fragmentele de coloană de interes. Porțiunile coloanei ar trebui apoi citite secvenţial. Alte metadate includ versiunea formatului, schema și orice pereche cheie-valoare suplimentară.
2. Lungimea metadatelor (4 octeți).
3. Număr magic PAR1 (4 octeți).

Format de fișier ORC

Format de fișier rând-coloană optimizat (Coloană Rând optimizată, CRO) oferă o modalitate foarte eficientă de stocare a datelor și a fost conceput pentru a depăși limitările altor formate. Stochează datele într-o formă perfect compactă, permițându-vă să săriți peste detalii inutile - fără a necesita construirea de indici mari, complexi sau întreținute manual.

Avantajele formatului ORC:

1. Un fișier este rezultatul fiecărei sarcini, ceea ce reduce sarcina pe NameNode (nodul nume).
2. Suport pentru tipuri de date Hive, inclusiv DateTime, zecimale și tipuri de date complexe (struct, list, map și union).
3. Citirea simultană a aceluiași fișier de către diferite procese RecordReader.
4. Abilitatea de a împărți fișierele fără a scana pentru markeri.
5. Estimarea alocării maxime posibile de memorie heap pentru procesele de citire/scriere pe baza informațiilor din subsolul fișierului.
6. Metadatele sunt stocate în formatul de serializare binar Protocol Buffers, care permite adăugarea și eliminarea câmpurilor.

ORC stochează colecții de șiruri într-un singur fișier, iar în cadrul colecției, datele șirurilor sunt stocate într-un format de coloană.

Un fișier ORC stochează grupuri de linii numite dungi și informații de sprijin în subsolul fișierului. Postscriptul de la sfârșitul fișierului conține parametrii de compresie și dimensiunea subsolului comprimat.

Dimensiunea implicită a benzii este de 250 MB. Datorită dungilor atât de mari, citirea din HDFS se realizează mai eficient: în blocuri mari învecinate.

Subsolul fișierului înregistrează lista benzilor din fișier, numărul de rânduri pe bandă și tipul de date al fiecărei coloane. Valoarea rezultată a numărului, minului, maximului și sumei pentru fiecare coloană este de asemenea scrisă acolo.

Subsolul benzii conține un director de locații ale fluxului.

Datele de rând sunt utilizate la scanarea tabelelor.

Datele index includ valorile minime și maxime pentru fiecare coloană și poziția rândurilor din fiecare coloană. Indicii ORC sunt utilizați numai pentru selectarea benzilor și a grupurilor de rânduri, nu pentru a răspunde la întrebări.

Compararea diferitelor formate de fișiere

Avro comparativ cu Parchet

1. Avro este un format de stocare pe rând, în timp ce Parquet stochează datele în coloane.
2. Parchetul este mai potrivit pentru interogări analitice, ceea ce înseamnă că operațiunile de citire și interogarea datelor sunt mult mai eficiente decât scrierile.
3. Operațiile de scriere în Avro sunt efectuate mai eficient decât în ​​Parchet.
4. Avro se ocupă de evoluția circuitului mai matur. Parquet acceptă doar adăugarea de schemă, în timp ce Avro acceptă evoluția multifuncțională, adică adăugarea sau schimbarea coloanelor.
5. Parchetul este ideal pentru interogarea unui subset de coloane dintr-un tabel cu mai multe coloane. Avro este potrivit pentru operațiunile ETL în care interogăm toate coloanele.

ORC vs Parchet

1. Parchetul stochează mai bine datele imbricate.
2. ORC este mai potrivit pentru pushdown predicat.
3. ORC acceptă proprietățile ACID.
4. ORC comprimă mai bine datele.

Ce să mai citești pe subiect:

1. Analiza datelor mari în cloud: cum poate o companie să devină orientată către date.
2. Un ghid umil pentru schemele bazelor de date.
3. Canalul nostru de telegrame despre transformarea digitală.

Sursa: www.habr.com