QQinfo

Această structură este bine optimizată atât pentru performanța ridicată a interogărilor, cât și pentru un consum redus de I/O (minimizând cantitatea de date scanată). De exemplu, dacă ai un tabel cu 1000 de coloane, de obicei vei interoga doar un subset mic dintre acestea. Utilizarea fișierelor Parquet îți permite să preiei doar coloanele necesare și valorile lor, să le încarci în memorie și să răspunzi la interogare. Dacă s-ar fi folosit un format de fișier bazat pe rânduri, precum CSV, întregul tabel ar fi trebuit încărcat în memorie, ceea ce ar fi dus la un consum crescut de I/O și la performanțe mai slabe.

Suport pentru evoluția schemei

Atunci când utilizezi formate de fișiere coloane, precum Parquet, utilizatorii pot începe cu o schemă simplă și pot adăuga treptat mai multe coloane pe măsură ce este necesar. În acest fel, utilizatorii pot ajunge să aibă mai multe fișiere Parquet cu scheme diferite, dar compatibile între ele. În aceste cazuri, Parquet suportă fuziunea automată a schemelor între aceste fișiere.

Stocare non-proprietară, deschisă care reduce dependența de furnizor

După cum am menționat mai sus, Apache Parquet face parte din ecosistemul open-source Apache Hadoop. Eforturile de dezvoltare în jurul său sunt active, iar formatul este constant îmbunătățit și întreținut de o comunitate puternică de utilizatori și dezvoltator.
Stocarea datelor tale în formate deschise înseamnă că eviți dependența de un anumit furnizor și îți crești flexibilitatea, comparativ cu formatele proprietare de fișiere utilizate de multe depozite de date moderne de înaltă performanță. Aceasta înseamnă că poți folosi o gamă largă de motoare de interogare, în cadrul aceluiași data lake sau al unei arhitecturi lakehouse, fără a fi legat de un anumit furnizor de depozit de date.

Conceput pentru sarcini analitice moderne

Date complexe, precum logurile și fluxurile de evenimente , ar trebui reprezentate ca un tabel cu sute sau mii de coloane și milioane de rânduri. Stocarea acestui tabel într-un format bazat pe rânduri, precum CSV, ar însemna:

• Interogările vor dura mai mult, deoarece trebuie scanate mai multe date, în loc să interogăm doar subsetul de coloane necesare pentru a răspunde la o întrebare (ceea ce de obicei implică agregarea pe baza unei dimensiuni sau categorii).
• Stocarea va fi mai costisitoare, deoarece fișierele CSV nu sunt comprimate la fel de eficient ca Parquet

Parquet oferă o compresie mai bună și performanțe îmbunătățite imediat după instalare și, după cum am văzut mai sus, permite interogarea datelor vertical, coloana cu coloana.

Cazuri de utilizare Apache Parquet – Când ar trebui să îl folosești?

Deși aceasta nu este o listă completă, câteva semne clare că ar trebui să îți stochezi datele în Parquet includ:

• Când lucrezi cu cantități foarte mari de date. Parquet este conceput pentru performanță și compresie eficientă. Diverse teste de benchmark care au comparat timpii de procesare pentru interogările SQL pe Parquet versus formate precum Avro sau CSV (inclusiv cele descrise în acest articol și acesta) au arătat că interogările pe Parquet sunt semnificativ mai rapide.
• Când întregul tău set de date are multe coloane, dar ai nevoie să accesezi doar un subset. Datorită complexității crescânde a datelor de business pe care le înregistrezi, s-ar putea să descoperi că, în loc să colectezi 20 de câmpuri pentru fiecare eveniment de date, acum capturezi peste 100. Deși aceste date sunt ușor de stocat în sisteme de tip object storage, precum Amazon S3, interogarea lor va necesita scanarea unei cantități semnificative de date dacă sunt stocate în formate bazate pe rânduri. Natura coloanară și auto-descriptivă a Parquet permite preluarea doar a coloanelor necesare pentru a răspunde la o anumită interogare, reducând cantitatea de date procesată.
• Când vrei ca mai multe servicii să consume aceleași date din object storage. În timp ce furnizorii de baze de date preferă să stochezi datele într-un format proprietar, pe care doar uneltele lor îl pot citi, arhitectura modernă de date favorizează separarea stocării de procesare. Dacă vrei să lucrezi cu mai multe servicii de analiză pentru a răspunde la diferite cazuri de utilizare, ar trebui să stochezi datele în Parquet.

Parquet vs ORC

Apache Parquet și Optimized Row Columnar (ORC) sunt două formate populare pentru fișierele de tip big data. Fiecare are avantaje specifice, în funcție de cazul tău de utilizare:

• ORC oferă o eficiență mai bună la scriere: ORC este mai potrivit pentru operațiuni cu multe scrieri datorită formatului său bazat pe rânduri. Oferă viteze de scriere mai mari comparativ cu Parquet, în special atunci când se lucrează cu scheme în evoluție.
• Parquet este mai potrivit pentru citirea datelor: Parquet excelează în scenarii de tip write-once, read-many, oferind o compresie și decomprimare a datelor extrem de eficiente. Suportă data skipping, ceea ce permite ca interogările să returneze doar valorile coloanelor specifice, sărind peste rândurile întregi de date, reducând astfel I/O-ul. Aceasta face Parquet util în scenarii în care setul de date are un număr mare de coloane și este nevoie să se acceseze doar subseturi specifice de date.
• Compatibilitate: ORC este foarte compatibil cu ecosistemul Hive, oferind avantaje precum suport pentru tranzacții ACID atunci când se lucrează cu Apache Hive. Parquet, însă, oferă o accesibilitate mai largă, suportând multiple limbaje de programare precum Java, C++ și Python, fiind utilizabil aproape în orice mediu big data. De asemenea, este folosit de mai multe motoare de interogare, inclusiv opțiuni open-source precum Presto, Trino și Flink, precum și platforme moderne de date precum Amazon Athena, Snowflake, Databricks și Google BigQuery.
• Compresie: Atât ORC, cât și Parquet oferă multiple opțiuni de compresie și suport pentru evoluția schemei. Totuși, Parquet este adesea preferat în fața ORC atunci când compresia este criteriul principal, deoarece generează fișiere mai mici, cu scheme de compresie și codificare extrem de eficiente. De asemenea, Parquet poate suporta scheme de compresie specifice pentru fiecare coloană în parte, optimizând și mai mult datele stocate.

Parquet, Iceberg și Lakehouse

Parquet este un format de fișier optimizat pentru analiză, destinat stocării – dar, la final, rămân tot fișiere de date stocate în object storage. Pentru ca acestea să fie utile în sarcini analitice și de AI, organizațiile trebuie să construiască un strat de gestionare a datelor, guvernanță și indexare, care să permită accesul universal la date (asemănător cu ceea ce oferă în mod nativ un data warehouse). Aici intervin formatele de tabel precum Apache Iceberg, creând o combinație puternică care formează coloana vertebrală a arhitecturilor lakehouse.
Apache Iceberg oferă un strat de gestionare deasupra stocării în data lake sau lakehouse, adăugând capabilități asemănătoare unei baze de date, precum tranzacții ACID, evoluția schemei și time travel pentru datele stocate în object storage eficient din punct de vedere al costurilor în cloud. Stocarea de bază pentru Iceberg va fi cel mai frecvent Parquet, deși sunt suportate și formate coloane precum ORC.
Parquet și Iceberg sunt tehnologii complementare. Gândește-te la Parquet ca la componenta care se ocupă de „cum” sunt stocate datele – definind modul în care sunt organizate și comprimate octeții –, în timp ce Iceberg gestionează „ce” reprezintă organizarea datelor – urmărind schemele, partițiile și metadatele pentru colecții de fișiere Parquet. 
Atât Parquet, cât și Iceberg sunt tehnologii deschise, ceea ce le face o alegere bună pentru organizațiile care doresc să evite dependența de un anumit furnizor. Poți interoga tabele Iceberg bazate pe Parquet folosind orice motor compatibil – precum Snowflake, Apache Spark, Trino, Presto sau Amazon Athena. Această interoperabilitate permite echipelor de date să aleagă cele mai potrivite unelte pentru fiecare caz de utilizare, lucrând în același timp cu un strat de date unificat.

Împreună, Parquet și Iceberg permit organizațiilor să adopte o arhitectură open lakehouse, care reduce semnificativ costurile comparativ cu depozitele de date tradiționale, susținând în același timp atât fluxuri de date în timp real, cât și sarcini analitice pe loturi (batch). Rezultatul este o arhitectură flexibilă și performantă, care se scalează odată cu nevoile afacerii și se adaptează cerințelor în evoluție privind datele, construită pe standarde deschise ce asigură viabilitate pe termen lung și independență față de platformă.

Următorul pas: Trecerea de la stocarea Parquet la un Open Data Lakehouse cu Qlik

Qlik Open Lakehouse  este o capabilitate complet gestionată în cadrul Qlik Talend Cloud, care facilitează, fără efort și într-un mod eficient din punct de vedere al costurilor, ingestia, procesarea și optimizarea unor volume mari de date în lakehouse-uri bazate pe Apache Iceberg.

Cu Qlik Open Lakehouse, poți să ingestezi date în flux (streaming) sau pe loturi (batch) în format Apache Parquet pe Amazon S3 – și să încarci și optimizezi automat datele direct în tabele Apache Iceberg, cu doar câteva click-uri. Adaptive Iceberg Optimizer de la Qlik gestionează și optimizează continuu tabelele Iceberg pentru a asigura performanțe ridicate și costuri reduse, indiferent de motorul de interogare utilizat în aval.

Sursă articol: https://www.qlik.com/blog/