🥇Formati dei file nei big data: breve guida

Deità del Tempo di Remarin

Team Mail.ru Cloud Solutions offre la traduzione di un articolo ingegnere Rahul Bhatia di Clairvoyant sui diversi formati di file nei big data, le funzioni più comuni dei formati Hadoop e quale formato sia meglio utilizzare.

Perché sono necessari diversi formati di file

Un serio collo di bottiglia nelle prestazioni delle applicazioni che supportano HDFS, come MapReduce e Spark, è il tempo di ricerca, lettura e scrittura dei dati. Questi problemi si complicano ulteriormente dalla gestione di grandi set di dati, specialmente se abbiamo uno schema evolutivo piuttosto che fisso, o se ci sono limitazioni nella memorizzazione.

L'elaborazione dei big data aumenta il carico sul sottosistema di memorizzazione: Hadoop memorizza i dati in modo ridondante per garantire la resilienza. Oltre ai dischi, sono sotto pressione anche 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 memorizzazione.

Diverse formati di file in Hadoop sono stati ideati per affrontare proprio questi problemi. Scegliere il formato di file giusto può portare a vantaggi sostanziali:

Tempi di lettura più rapidi.
Tempi di scrittura più rapidi.
File condivisibili.
Supporto per l'evoluzione degli schemi.
Supporto esteso per la compressione.

Alcuni formati di file sono destinati a usi generali, altri a opzioni più specifiche, e alcuni sono progettati per caratteristiche di dati specifiche. Quindi, la scelta è davvero piuttosto ampia.

Formato file Avro

Per serializzazione dei dati Avro è ampiamente utilizzato — è un formato di archiviazione dei dati basato su righe, ovvero basato su stringhe, in Hadoop. Memorizza lo schema in formato JSON, facilitando la lettura e l'interpretazione da parte di qualsiasi programma. I dati stessi sono memorizzati in formato binario, in modo compatto ed efficiente.

Il sistema di serializzazione Avro è neutro rispetto al linguaggio. I file possono essere elaborati in diversi linguaggi, attualmente C, C++, C#, Java, Python e Ruby.

Una caratteristica chiave di Avro è il supporto robusto per gli schemi di dati che cambiano nel tempo, ovvero evolvono. Avro comprende le modifiche dello schema — eliminazione, aggiunta o modifica dei campi.

Avro supporta una varietà di strutture dati. Ad esempio, è possibile creare un record che contiene un array, un tipo enumerativo e un sotto-record.

Questo formato è ideale per la registrazione nella zona di ingresso del lago dati (lago dati, o data lake — una collezione di istanze per la memorizzazione di vari tipi di dati in aggiunta alle fonti di dati).

Quindi, per la registrazione nella zona di ingresso del lago dati, questo formato è il più adatto per i seguenti motivi:

I dati in questa zona vengono generalmente letti per intero per ulteriore elaborazione da parte dei sistemi sottostanti — e un formato basato su righe in questo caso è più efficiente.
I sistemi sottostanti possono facilmente estrarre le tabelle di schema dai file — non è necessario conservare gli schemi separatamente in un meta-storage esterno.
Qualsiasi cambiamento nello schema originale viene elaborato facilmente (evoluzione dello schema).

Il formato file Parquet

Parquet è un formato file open source per Hadoop che memorizza strutture dati annidate in formato flat columnar.

Rispetto all'approccio tradizionale basato su righe, Parquet è più efficiente in termini di spazio e prestazioni.

Questo è particolarmente utile per le query che leggono determinate colonne da una tabella ampia (con molte colonne). Grazie a questo formato, vengono letti solo i colonne necessari, riducendo al minimo l'input e l'output.

Una piccola digressione esplicativa: per capire meglio il formato del file Parquet in Hadoop, vediamo cos'è un formato basato su colonne, ovvero un formato colonne. In questo tipo di formato, i valori simili di ogni colonna vengono memorizzati insieme.

Ad esempio, la registrazione comprende i campi ID, Name e Department. In questo caso, tutti i valori della colonna ID saranno memorizzati insieme, così come i valori della colonna Name e così via. La tabella avrà all'incirca questo aspetto:

ID
Name
Department

1
emp1
d1

2
emp2
d2

3
emp3
d3

Nel formato a righe, i dati saranno memorizzati nel seguente modo:

1
emp1
d1
2
emp2
d2
3
emp3
d3

Nel formato a colonne, gli stessi dati saranno memorizzati in questo modo:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Il formato colonne è più efficiente quando è necessario interrogare più colonne da una tabella. Leggerà solo le colonne necessarie, poiché sono vicine. In questo modo, le operazioni di input e output sono ridotte al minimo.

Ad esempio, hai bisogno solo della colonna NAME. In formato a righe è necessario caricare ogni record nel set di dati, analizzarlo nei campi e poi estrarre i dati NAME. Il formato colonnare consente di accedere direttamente alla colonna Name, poiché tutti i valori per questa colonna sono memorizzati insieme. Non è necessario scandagliare l'intero record.

In questo modo, il formato colonnare migliora le prestazioni delle query, poiché è richiesto meno tempo di ricerca per accedere alle colonne richieste e si riducono le operazioni di input/output, poiché si leggono solo le colonne necessarie.

Una delle caratteristiche uniche Parquet è che in questo formato può memorizzare dati con strutture annidate. Ciò significa che nel file Parquet è possibile leggere anche i campi annidati singolarmente senza dover leggere tutti i campi nella struttura annidate. Per memorizzare strutture annidate, Parquet utilizza l'algoritmo di frantumazione e assemblaggio.

Per comprendere il formato del file Parquet in Hadoop, è necessario conoscere i seguenti termini:

Gruppo di righe (row group): partizione logica orizzontale dei dati in righe. Un gruppo di righe è composto da un frammento di ogni colonna nel set di dati.
Frammento di colonna (column chunk): frammento di una specifica colonna. Questi frammenti di colonna vivono in un certo gruppo di righe e saranno sicuramente contigui nel file.
Pagina (page): i frammenti di colonna sono suddivisi in pagine, registrate una dopo l'altra. Le pagine condividono un'intestazione comune, quindi durante la lettura è possibile saltare parti non necessarie.

Qui l'intestazione contiene semplicemente un numero magico PAR1 (4 byte), che identifica il file come un file del formato Parquet.

Nel footer è scritto quanto segue:

Metadati del file, che contengono le coordinate di partenza dei metadati di ciascuna colonna. Durante la lettura, è necessario prima leggere i metadati del file per trovare tutti i frammenti di colonna di interesse. Successivamente, i frammenti di colonna devono essere letti in sequenza. Inoltre, i metadati includono la versione del formato, lo schema e eventuali coppie chiave-valore aggiuntive.
Lunghezza dei metadati (4 byte).
Numero magico PAR1 (4 byte).

Formato file ORC

Formato file a colonne ottimizzato (Optimized Row Columnar, ORC) offre un modo molto efficiente di archiviazione dei dati ed è stato progettato per superare le limitazioni di altri formati. Memorizza i dati in una forma perfettamente compatta, consentendo di omettere dettagli non necessari, senza richiedere la costruzione di indici complessi o di difficile manutenzione.

Vantaggi del formato ORC:

Un file in uscita per ogni attività, il che riduce il carico sul NameNode (nodo dei nomi).
Supporto per i tipi di dati Hive, inclusi DateTime, numeri decimali e tipi di dati complessi (struct, list, map e union).
Lettura simultanea dello stesso file da parte di diversi processi RecordReader.
Possibilità di dividere i file senza scansionare alla ricerca di marcatori.
Valutazione della massima allocazione di memoria heap per i processi di lettura/scrittura basata sulle informazioni nel footer del file.
I metadati sono memorizzati in formato binario di serializzazione Protocol Buffers, che consente di aggiungere e rimuovere campi.

ORC memorizza collezioni di righe in un unico file, e all'interno della collezione i dati di riga sono archiviati in formato colonnare.

Il file ORC contiene gruppi di righe chiamate stripe e informazioni ausiliarie nel footer del file. Il postscript alla fine del file include parametri di compressione e la dimensione del footer compresso.

Per impostazione predefinita, la dimensione delle stripe è di 250 MB. Grazie a stripe di tali grandi dimensioni, la lettura da HDFS avviene in modo molto più efficiente: in blocchi continui di grande dimensione.

Nel footer del file è registrata una lista delle stripe nel file, il numero di righe per stripe e il tipo di dati di ciascuna colonna. Sono riportati anche i valori risultanti di count, min, max e sum per ciascuna colonna.

Il footer della stripe contiene un catalogo delle posizioni delle righe.

I dati riga vengono utilizzati durante la scansione delle tabelle.

I dati di indice includono i valori minimi e massimi per ogni colonna e le posizioni delle righe in ciascuna colonna. Gli indici ORC vengono utilizzati solo per selezionare le stripe e i gruppi di righe, non per rispondere a query.

Confronto tra diversi formati di file

Avro rispetto a Parquet

Avro è un formato di memorizzazione a righe, mentre Parquet memorizza i dati a colonne.
Parquet è più adatto per le query analitiche, cioè le operazioni di lettura e richiesta di dati sono molto più efficienti rispetto alla scrittura.
Le operazioni di scrittura in Avro sono più efficienti rispetto a quelle in Parquet.
Avro gestisce in modo più maturo l'evoluzione degli schemi. Parquet supporta solo l'aggiunta di schemi, mentre Avro implementa un'evoluzione multifunzionale, che consente l'aggiunta o la modifica delle colonne.
Parquet è ideale per interrogare sottoinsiemi di colonne in una tabella a più colonne. Avro è adatto per operazioni ETL, dove richiediamo tutte le colonne.