squadra offerte l'ingegnere Rahul Bhatia da Clairvoyant nantu à quali furmati di schedari ci sò in big data, quali sò e caratteristiche più cumuni di i formati Hadoop è chì formate hè megliu aduprà.
Perchè sò necessarii diversi formati di fugliale?
Un collu di buttiglia di rendiment maiò per l'applicazioni abilitate HDFS cum'è MapReduce è Spark hè u tempu chì ci vole à circà, leghje è scrive dati. Questi prublemi sò aggravati da a difficultà in a gestione di grande setti di dati se avemu un schema in evoluzione piuttostu cà un fissu, o s'ellu ci sò qualchì limitazione di almacenamento.
Trattamentu di big data aumenta a carica nantu à u sottosistema di almacenamiento - Hadoop almacena dati in modu ridondante per ottene a tolleranza di difetti. In più di i dischi, u processatore, a rete, u sistema di input / output, è cusì sò caricati. Cum'è u voluminu di dati cresce, cusì u costu di trasfurmazioni è di almacenamentu.
Diversi formati di schedari in inventatu per risolve precisamente questi prublemi. A selezzione di u formatu di fugliale adattatu pò furnisce alcuni benefici significativi:
- Tempu di lettura più veloce.
- Tempu di registrazione più veloce.
- I schedarii spartuti.
- Supportu per l'evoluzione di schema.
- Supportu di compressione allargatu.
Certi furmati di schedari sò destinati à l'usu generale, altri per usi più specifichi, è certi sò pensati per risponde à e caratteristiche specifiche di dati. Allora a scelta hè veramente abbastanza grande.
Format di schedariu Avro
di serializazione di dati Avro hè largamente utilizatu - hè string basatu, vale à dì, un furmatu di almacenamentu di dati di stringa in Hadoop. Guarda u schema in formatu JSON, facendu faciule di leghje è interpretate da qualsiasi prugramma. I dati stessi sò in formatu binariu, compactu è efficiente.
U sistema di serializazione di Avro hè lingua neutrale. I schedari ponu esse processati in una varietà di lingue, attualmente C, C++, C#, Java, Python è Ruby.
Una caratteristica chjave di Avro hè u so supportu robustu per i schemi di dati chì cambianu cù u tempu, vale à dì, evoluzione. Avro capisce i cambiamenti di schema - sguassà, aghjunghje o cambià campi.
Avro supporta una varietà di strutture di dati. Per esempiu, pudete creà un registru chì cuntene un array, un tipu enumeratu è un subrecord.
Stu formatu hè ideale per scrive à a zona di sbarcu (transizione) di un lacu di dati (, o data lake - una cullizzioni di casi per almacenà diversi tipi di dati in più di e fonti di dati direttamente).
Dunque, stu formatu hè megliu adattatu per scrive à a zona di sbarcu di un lacu di dati per i seguenti motivi:
- I dati da questa zona sò generalmente letti in a so intera per un ulteriore prucessu da i sistemi downstream - è un furmatu basatu in fila hè più efficau in questu casu.
- I sistemi downstream ponu facilmente ricuperà e tabelle di schema da i schedari - ùn hè micca bisognu di almacenà schemi separatamente in meta storage esternu.
- Ogni cambiamentu di u schema originale hè facilmente processatu (evoluzione di schema).
Format di File Parquet
Parquet hè un furmatu di fugliale open source per Hadoop chì almacena strutture di dati nidificate in formatu colonnare flat.
Paragunatu à l'approcciu tradiziunale di fila, Parquet hè più efficaci in quantu à u almacenamentu è a prestazione.
Questu hè particularmente utile per e dumande chì leghjenu colonne specifiche da una tavola larga (assai colonne). Grazie à u furmatu di u schedariu, solu i culonni necessarii sò leghjiti, cusì I / O hè guardatu à u minimu.
Una piccula digressione è spiegazione: Per capisce megliu u furmatu di u schedariu Parquet in Hadoop, vedemu ciò chì hè un formatu basatu in colonna - vale à dì columnar. Stu formatu guarda valori simili per ogni colonna inseme.
, u registru include i campi ID, Nome è Dipartimentu. In questu casu, tutti i valori di a colonna ID seranu guardati inseme, cum'è i valori di a colonna di Nome, è cusì. A tavula serà simile à questu:
ID
nomu
Dipartimentu
1
emp1
d1
2
emp2
d2
3
emp3
d3
In u formatu di stringa, i dati seranu salvati cum'è seguente:
1
emp1
d1
2
emp2
d2
3
emp3
d3
In un furmatu di u schedariu columnar, i stessi dati seranu salvati cusì:
1
2
3
emp1
emp2
emp3
d1
d2
d3
U formatu di columnare hè più efficau quandu avete bisognu di dumandà parechje colonne da una tavula. Leghjirà solu e culonni necessarii perchè sò adiacenti. In questu modu, l'operazioni I / O sò mantinuti à u minimu.
Per esempiu, avete solu bisognu di a colonna NOME. IN Ogni registru in u dataset deve esse caricatu, parsed by field, and then extracted the NAME data. U formatu di a colonna permette di drill down direttamente à a colonna Nome perchè tutti i valori per quella colonna sò almacenati inseme. Ùn avete micca scansà tutta a registrazione.
Cusì, u formatu di columnare migliurà a prestazione di a dumanda perchè esige menu tempu di ricerca per ghjunghje à e culonni necessarii è riduce u numeru di operazioni I/O perchè solu e colonne desiderate sò leghjite.
Una di e caratteristiche uniche hè chì in stu formatu pò almacenà dati cù strutture nidificate. Questu significa chì in un schedariu Parquet, ancu i campi nidificati ponu esse leghje individualmente senza avè da leghje tutti i campi in a struttura nidificatu. Parquet usa un algoritmu di triturazione è assemblea per almacenà strutture nidificate.
Per capisce u furmatu di u schedariu Parquet in Hadoop, avete bisognu di cunnosce i seguenti termini:
- Gruppu di fila (gruppu di fila): divisione horizontale logica di dati in fila. Un gruppu di fila hè custituitu da un fragmentu di ogni colonna in u settore di dati.
- Frammentu di colonna (column chunk): Un fragmentu di una colonna specifica. Questi frammenti di colonna vivenu in un gruppu specificu di fila è sò garantiti per esse cuntigui in u schedariu.
- Pagina (pagina): Frammenti di culonna sò spartuti in pagine scritte una dopu à l'altru. E pagine anu un titulu cumunu, cusì pudete saltà quelli innecessarii quandu leghje.
Quì u titulu cuntene solu u numeru magicu PAR1 (4 bytes) chì identificanu u schedariu cum'è un schedariu Parquet.
U footer dice u seguente:
- Metadata di u schedariu chì cuntene e coordenate di partenza di i metadata di ogni colonna. Quandu leghje, prima deve leghje i metadati di u schedariu per truvà tutti i frammenti di colonna d'interessu. E porzioni di colonna devenu esse leghjite in sequenza. L'altri metadati includenu a versione di furmatu, schema, è qualsiasi coppie chjave-valore supplementari.
- Lunghezza di metadata (4 bytes).
- numeru magicu PAR1 (4 bytes).
Formatu di u schedariu ORC
Formatu di file-colonna ottimizatu (Colonna di fila ottimizzata, ) offre un modu assai efficace per almacenà e dati è hè statu cuncepitu per superà e limitazioni di altri formati. Almacene e dati in una forma perfettamente compatta, chì vi permette di saltà i dettagli inutili - senza bisognu di a custruzzione di indici grandi, cumplessi o mantinuti manualmente.
Vantaghji di u formatu ORC:
- Un schedariu hè l'output di ogni compitu, chì riduce a carica nantu à u NameNode (node di nome).
- Supportu per i tipi di dati Hive, cumprese DateTime, dati decimali è cumplessi (struct, list, map and union).
- Lettura simultanea di u stessu schedariu da diversi prucessi RecordReader.
- Capacità di split files senza scanning per marcatori.
- Stima di l'allocazione massima di memoria heap pussibule per i prucessi di lettura / scrittura basatu annantu à l'infurmazioni in u piè di pagina di u schedariu.
- I metadati sò guardati in u furmatu di serializazione binariu Protocol Buffers, chì permette à i campi per esse aghjuntu è eliminati.
ORC guarda e cullezzione di stringhe in un unicu schedariu, è in a cullizzioni, i dati di stringa sò almacenati in un formatu di colonna.
Un schedariu ORC guarda gruppi di linii chjamati strisce è informazioni di supportu in u footer di u schedariu. U Postscript à a fine di u schedariu cuntene paràmetri di compressione è a dimensione di u footer compressatu.
A taglia di striscia predefinita hè 250 MB. A causa di tali strisce grandi, a lettura da HDFS hè realizatu più efficacemente: in grandi blocchi contigu.
U piè di pagina di u schedariu registra a lista di corsi in u schedariu, u numeru di fila per via, è u tipu di dati di ogni colonna. U valore resultanti di count, min, max è summa per ogni colonna hè ancu scrittu quì.
U piè di pagina di a striscia cuntene un repertoriu di locu di flussu.
I dati di fila sò usati quandu scanning tables.
I dati di l'indice includenu i valori minimi è massimi per ogni colonna è a pusizione di e fila in ogni colonna. L'indici ORC sò usati solu per selezziunà strisce è gruppi di fila, micca per risponde à e dumande.
Paragone di diversi furmati di schedari
Avro paragunatu à Parquet
- Avro hè un formatu di almacenamentu di fila, mentri Parquet guarda dati in colonne.
- Parquet hè megliu adattatu per e dumande analitiche, vale à dì chì l'operazioni di lettura è l'interrogazione di dati sò assai più efficaci cà i scrittura.
- L'operazioni di scrittura in Avro sò realizate più efficaci chè in Parquet.
- Avro tratta di l'evoluzione di u circuitu più maturu. Parquet supporta solu l'aghjunzione di schema, mentri Avro sustene l'evoluzione multifunzionale, vale à dì, aghjunghje o mudificà e colonne.
- Parquet hè l'ideale per dumandà un subset di colonne in una tavola multi-colonna. Avro hè adattatu per l'operazioni ETL induve dumandemu tutte e colonne.
ORC vs Parquet
- Parquet guarda megliu i dati nidificati.
- ORC hè megliu adattatu per u predicatu pushdown.
- ORC supporta proprietà ACID.
- ORC compresses data megliu.
Chì altru à leghje nantu à u tema:
- .
- .
- .
Source: www.habr.com