Squadra offre Rahul Bhatia di Clairvoyant su quali formati di file ci sono nei big data, quali sono le caratteristiche più comuni dei formati Hadoop e quale formato è meglio usare.
Perché sono necessari formati di file diversi?
Uno dei principali colli di bottiglia delle prestazioni per le applicazioni abilitate per HDFS come MapReduce e Spark è il tempo necessario per cercare, leggere e scrivere i dati. Questi problemi sono aggravati dalla difficoltà di gestire set di dati di grandi dimensioni se si dispone di uno schema in evoluzione anziché fisso o se esistono alcuni vincoli di archiviazione.
L'elaborazione dei big data aumenta il carico sul sottosistema di archiviazione: Hadoop archivia i dati in modo ridondante per raggiungere la tolleranza agli errori. Oltre ai dischi, vengono caricati il processore, la rete, il sistema di input/output e così via. Con l’aumento del volume dei dati, aumentano anche i costi di elaborazione e archiviazione degli stessi.
Vari formati di file in inventato per risolvere proprio questi problemi. La selezione del formato file appropriato può offrire alcuni vantaggi significativi:
- Tempo di lettura più veloce.
- Tempo di registrazione più veloce.
- File condivisi.
- Supporto per l'evoluzione dello schema.
- Supporto di compressione espanso.
Alcuni formati di file sono destinati a un uso generale, altri a usi più specifici e altri ancora sono progettati per soddisfare caratteristiche specifiche dei dati. Quindi la scelta è davvero piuttosto ampia.
Formato file Avro
per serializzazione dei dati Avro è ampiamente utilizzato: it basato su stringhe, ovvero un formato di archiviazione dati di tipo stringa in Hadoop. Memorizza lo schema in formato JSON, facilitandone la lettura e l'interpretazione da parte di qualsiasi programma. I dati stessi sono in formato binario, compatti ed efficienti.
Il sistema di serializzazione di Avro è neutrale rispetto al linguaggio. I file possono essere elaborati in una varietà di linguaggi, attualmente C, C++, C#, Java, Python e Ruby.
Una caratteristica chiave di Avro è il suo solido supporto per schemi di dati che cambiano nel tempo, cioè si evolvono. Avro comprende le modifiche allo schema: eliminazione, aggiunta o modifica dei campi.
Avro supporta una varietà di strutture dati. Ad esempio, puoi creare un record che contenga una matrice, un tipo enumerato e un sottorecord.
Questo formato è ideale per scrivere nella zona di atterraggio (transizione) di un data Lake (o data Lake: una raccolta di istanze per archiviare direttamente vari tipi di dati oltre alle origini dati).
Pertanto, questo formato è più adatto per scrivere nella landing zone di un data Lake per i seguenti motivi:
- I dati di questa zona vengono solitamente letti nella loro interezza per un'ulteriore elaborazione da parte dei sistemi a valle e in questo caso un formato basato su righe è più efficiente.
- I sistemi downstream possono recuperare facilmente le tabelle degli schemi dai file, senza bisogno di archiviare gli schemi separatamente in meta storage esterno.
- Qualsiasi modifica allo schema originale viene facilmente elaborata (evoluzione dello schema).
Formato file parquet
Parquet è un formato di file open source per Hadoop che memorizza strutture di dati nidificate in formato colonnare piatto.
Rispetto al tradizionale approccio in fila, il Parquet è più efficiente in termini di stoccaggio e prestazioni.
Ciò è particolarmente utile per le query che leggono colonne specifiche da una tabella ampia (con molte colonne). Grazie al formato del file, vengono lette solo le colonne necessarie, quindi l'I/O è ridotto al minimo.
Una piccola digressione e spiegazione: Per comprendere meglio il formato file Parquet in Hadoop, vediamo cos'è un formato basato su colonne, ovvero colonnare. Questo formato memorizza insieme valori simili per ciascuna colonna.
, il record include i campi ID, Nome e Dipartimento. In questo caso, tutti i valori della colonna ID verranno archiviati insieme, così come i valori della colonna Nome e così via. La tabella sarà simile a questa:
ID
Nome
Shirts Department
1
emp1
d1
2
emp2
d2
3
emp3
d3
In formato stringa, i dati verranno salvati come segue:
1
emp1
d1
2
emp2
d2
3
emp3
d3
In un formato di file a colonne, gli stessi dati verranno salvati in questo modo:
1
2
3
emp1
emp2
emp3
d1
d2
d3
Il formato colonnare è più efficiente quando è necessario eseguire query su più colonne da una tabella. Leggerà solo le colonne richieste perché sono adiacenti. In questo modo le operazioni di I/O sono ridotte al minimo.
Ad esempio, hai solo bisogno della colonna NOME. IN Ogni record nel set di dati deve essere caricato, analizzato per campo e quindi estratto i dati NAME. Il formato della colonna consente di eseguire il drill-down direttamente sulla colonna Nome perché tutti i valori per quella colonna sono archiviati insieme. Non è necessario scansionare l'intera registrazione.
Pertanto, il formato a colonne migliora le prestazioni delle query perché richiede meno tempo di ricerca per raggiungere le colonne richieste e riduce il numero di operazioni di I/O perché vengono lette solo le colonne desiderate.
Una delle caratteristiche uniche è che in questo formato è possibile memorizzare i dati con strutture nidificate. Ciò significa che in un file Parquet anche i campi nidificati possono essere letti singolarmente senza dover leggere tutti i campi nella struttura nidificata. Parquet utilizza un algoritmo di triturazione e assemblaggio per immagazzinare strutture annidate.
Per comprendere il formato file Parquet in Hadoop, è necessario conoscere i seguenti termini:
- Gruppo di righe (gruppo di righe): divisione logica orizzontale dei dati in righe. Un gruppo di righe è costituito da un frammento di ciascuna colonna nel set di dati.
- Frammento di colonna (pezzo di colonna): un frammento di una colonna specifica. Questi frammenti di colonna risiedono in un gruppo specifico di righe e sono garantiti contigui nel file.
- pagina (pagina): i frammenti di colonna sono divisi in pagine scritte una dopo l'altra. Le pagine hanno un titolo comune, quindi puoi saltare quelle non necessarie durante la lettura.
Qui il titolo contiene solo il numero magico PAR1 (4 byte) che identifica il file come file Parquet.
Il piè di pagina dice quanto segue:
- Metadati del file che contengono le coordinate iniziali dei metadati di ogni colonna. Durante la lettura, è necessario prima leggere i metadati del file per trovare tutti i frammenti di colonna di interesse. Le parti della colonna devono quindi essere lette in sequenza. Altri metadati includono la versione del formato, lo schema ed eventuali coppie chiave-valore aggiuntive.
- Lunghezza dei metadati (4 byte).
- numero magico PAR1 (4 byte).
Formato file ORC
Formato file riga-colonna ottimizzato (Colonna riga ottimizzata, ) offre un modo molto efficiente per archiviare i dati ed è stato progettato per superare le limitazioni di altri formati. Memorizza i dati in un formato perfettamente compatto, consentendoti di saltare i dettagli non necessari, senza richiedere la costruzione di indici grandi, complessi o gestiti manualmente.
Vantaggi del formato ORC:
- Un file è l'output di ciascuna attività, il che riduce il carico sul NameNode (nodo del nome).
- Supporto per tipi di dati Hive, inclusi DateTime, tipi di dati decimali e complessi (struttura, elenco, mappa e unione).
- Lettura simultanea dello stesso file da parte di diversi processi RecordReader.
- Possibilità di dividere i file senza cercare i marcatori.
- Stima della massima allocazione di memoria heap possibile per i processi di lettura/scrittura in base alle informazioni nel piè di pagina del file.
- I metadati vengono archiviati nel formato di serializzazione binaria Protocol Buffers, che consente di aggiungere e rimuovere campi.
ORC archivia raccolte di stringhe in un singolo file e all'interno della raccolta i dati delle stringhe vengono archiviati in un formato colonnare.
Un file ORC memorizza gruppi di linee chiamate strisce e informazioni di supporto nel piè di pagina del file. Il Postscript alla fine del file contiene i parametri di compressione e la dimensione del piè di pagina compresso.
La dimensione predefinita dello stripe è 250 MB. A causa di strisce così grandi, la lettura da HDFS viene eseguita in modo più efficiente: in grandi blocchi contigui.
Il piè di pagina del file registra l'elenco delle corsie nel file, il numero di righe per corsia e il tipo di dati di ciascuna colonna. Qui viene scritto anche il valore risultante di count, min, max e sum per ciascuna colonna.
Il piè di pagina della striscia contiene una directory di posizioni dei flussi.
I dati delle righe vengono utilizzati durante la scansione delle tabelle.
I dati dell'indice includono i valori minimo e massimo per ciascuna colonna e la posizione delle righe in ciascuna colonna. Gli indici ORC vengono utilizzati solo per selezionare strisce e gruppi di righe, non per rispondere alle query.
Confronto tra diversi formati di file
Avro rispetto al Parquet
- Avro è un formato di archiviazione a righe, mentre Parquet memorizza i dati in colonne.
- Parquet è più adatto per le query analitiche, il che significa che le operazioni di lettura e di interrogazione dei dati sono molto più efficienti delle scritture.
- Le operazioni di scrittura in Avro vengono eseguite in modo più efficiente rispetto a Parquet.
- Avro affronta l'evoluzione del circuito in modo più maturo. Parquet supporta solo l'aggiunta di schemi, mentre Avro supporta l'evoluzione multifunzionale, ovvero l'aggiunta o la modifica di colonne.
- Parquet è ideale per eseguire query su un sottoinsieme di colonne in una tabella a più colonne. Avro è adatto per operazioni ETL in cui interroghiamo tutte le colonne.
ORC contro Parquet
- Parquet memorizza meglio i dati annidati.
- ORC è più adatto al predicato pushdown.
- ORC supporta le proprietà ACID.
- ORC comprime meglio i dati.
Cos'altro leggere sull'argomento:
- .
- .
- .
Fonte: habr.com