🥇Formati di file nei big data: breve introduzione

Divinità del Meteo di Remarin

Team Mail.ru Cloud Solutions offre la traduzione di un articolo ingegnere Rahul Bhatia della compagnia Clairvoyant su quali formati di file esistano nei big data, quali siano le funzioni più comuni dei formati Hadoop e quale formato sia migliore da utilizzare.

Perché servono 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 sono aggravati dalle difficoltà nella gestione di grandi set di dati, se abbiamo uno schema che non è fisso, ma evolutivo, o ci sono alcune limitazioni nello stoccaggio.

L'elaborazione dei big data aumenta il carico sul sottosistema di archiviazione: Hadoop memorizza i dati in modo ridondante per garantire la resilienza. Oltre ai dischi, vengono sollecitati anche il processore, la rete, il sistema di input-output e così via. Con l'aumentare del volume dei dati, aumentano anche i costi per l'elaborazione e la memorizzazione.

Diversi formati di file in Hadoop sono stati pensati per affrontare proprio questi problemi. La scelta del formato di file appropriato può portare a vantaggi significativi:

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

Alcuni formati di file sono progettati per un uso generale, altri per varianti più specifiche e alcuni sono stati sviluppati tenendo conto delle caratteristiche specifiche dei dati. Quindi, la scelta è davvero ampia.

Formato file Avro

Per serializzazione dei dati è ampiamente utilizzato da Avro: questo è un formato di archiviazione dei dati basato su righe, cioè a righe, nel Hadoop. Memorizza lo schema in formato JSON, facilitandone 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 è neutrale rispetto al linguaggio. I file possono essere elaborati in vari linguaggi, attualmente sono C, C++, C#, Java, Python e Ruby.

Una caratteristica chiave di Avro è il supporto affidabile per gli schemi di dati che cambiano nel tempo, cioè evolvono. Avro comprende le modifiche allo schema: rimozione, aggiunta o modifica dei campi.

Avro supporta diverse strutture di dati. Ad esempio, è possibile creare un record che contiene un array, un tipo enumerabile e un sottoregistro.

Questo formato è perfetto per la scrittura nella zona di atterraggio (transitoria) di un lago dati (lago di dati, o data lake—una collezione di istanze per la memorizzazione di vari tipi di dati in aggiunta alle fonti di dati dirette).

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

I dati di questa zona vengono generalmente letti per intero per ulteriori elaborazioni da parte dei sistemi sottostanti, e il formato basato su righe è più efficiente in questo caso.
I sistemi sottostanti possono facilmente estrarre le tabelle degli schemi dai file—non è necessario memorizzare gli schemi separatamente in un meta-magazzino esterno.
Qualsiasi modifica allo schema di origine viene elaborata facilmente (evoluzione dello schema).

Formato file Parquet

Parquet è un formato di file open-source per Hadoop che memorizza strutture di dati nidificate in un formato colonnare piatto.

Rispetto all'approccio tradizionale basato su righe, Parquet è più efficiente dal punto di vista della memorizzazione e delle prestazioni.

Questo è particolarmente utile per le query che leggono colonne specifiche da una tabella ampia (con molte colonne). Grazie al formato dei file, vengono letti solo le colonne necessarie, riducendo al minimo le operazioni di input/output.

Una piccola digressione-spiegazione: per comprendere meglio il formato dei file Parquet in Hadoop, diamo un'occhiata a cosa significa un formato basato su colonne—cioè colonnare. In questo formato, vengono memorizzati insieme valori dello stesso tipo per ogni colonna.

Ad esempio, la registrazione include i campi ID, Nome e Dipartimento. In questo caso, tutti i valori della colonna ID saranno memorizzati insieme, così come i valori della colonna Nome e così via. La tabella avrà un aspetto simile a questo:

ID
Name
Dipartimento

1
emp1
d1

2
emp2
d2

3
emp3
d3

In formato righe, i dati verranno memorizzati nel seguente modo:

1
emp1
d1
2
emp2
d2
3
emp3
d3

In formato colonnare, gli stessi dati verranno memorizzati in questo modo:

1
2
3
emp1
emp2
emp3
d1
d2
d3

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

Ad esempio, ti serve solo la colonna NOME. In formato righe ogni registrazione nel set di dati deve essere caricata, analizzata in campi e poi estratti i dati NOME. Il formato colonnare consente di accedere direttamente alla colonna Nome, poiché tutti i valori per quella colonna sono memorizzati insieme. Non sarà necessario scansionare l'intera registrazione.

In questo modo, il formato colonnare migliora l'efficienza delle query, poiché ci vuole meno tempo per cercare le colonne richieste e si riduce il numero di operazioni di input/output, poiché vengono letti solo i colonne necessarie.

Una delle caratteristiche uniche Parquet è che in questo formato può memorizzare dati con strutture annidate. Ciò significa che nel file Parquet anche i campi annidati possono essere letti separatamente senza dover leggere tutti i campi nella struttura annidata. Per memorizzare strutture annidate, Parquet utilizza un 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 gruppo di righe specifico e saranno necessariamente adiacenti nel file.
Pagina (page): i frammenti di colonna sono suddivisi in pagine, scritte una dopo l'altra. Le pagine hanno un'intestazione comune, quindi alla lettura è possibile saltare quelle non necessarie.

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

Nel footer è riportato 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 individuare tutti i frammenti di colonna di interesse. I frammenti di colonna devono quindi essere letti in sequenza. I metadati includono anche la versione del formato, lo schema e eventuali coppie chiave-valore aggiuntive.
Lunghezza dei metadati (4 byte).
Numero magico PAR1 (4 byte).

Il formato file ORC

Formato file colonnare ottimizzato (Optimized Row Columnar, ORC) offre un modo molto efficace per memorizzare i dati ed è stato sviluppato per superare le limitazioni di altri formati. Memorizza i dati in una forma idealmente compatta, consentendo di saltare dettagli non necessari — senza richiedere la costruzione di indici grandi, complessi o gestiti manualmente.

Vantaggi del formato ORC:

Un file all'uscita di ogni task, il che riduce il carico sul NameNode.
Supporto ai tipi di dati Hive, compresi DateTime, tipi decimali e tipi complessi (struct, list, map e union).
Lettura simultanea dello stesso file da diversi processi RecordReader.
Possibilità di dividere i file senza scansionare per la presenza di marcatori.
Valutazione della massima allocazione possibile della memoria heap per i processi di lettura/scrittura in base alle informazioni nel footer del file.
I metadati vengono salvati in un formato binario di serializzazione Protocol Buffers, che consente di aggiungere e rimuovere campi.

ORC memorizza collezioni di righe in un unico file, mentre all'interno della collezione i dati delle righe sono memorizzati in formato colonnare.

Il file ORC memorizza gruppi di righe, chiamati strisce (stripes), e informazioni accessorie nel footer del file. Il postscript alla fine del file contiene parametri di compressione e dimensione del footer compresso.

Per impostazione predefinita, la dimensione della striscia è di 250 MB. Grazie a strisce di tale grandezza, la lettura da HDFS è più efficiente: in blocchi grandi e continui.

Nel footer del file è registrata una lista delle strisce nel file, il numero di righe per striscia e il tipo di dati di ogni colonna. È anche registrato il valore risultante di count, min, max e sum per ogni colonna.

Il footer della striscia contiene un catalogo delle posizioni dello stream.

I dati delle righe vengono utilizzati durante la scansione delle tabelle.

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

Confronto tra diversi formati di file

Avro rispetto a Parquet

Avro è un formato di archiviazione a righe, mentre Parquet memorizza i dati a colonne.
Parquet è più adatto per le query analitiche, ovvero 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 meglio l'evoluzione degli schemi. Parquet supporta solo l'aggiunta di schemi, mentre Avro implementa un'evoluzione multifunzionale, cioè l'aggiunta o la modifica di colonne.
Parquet è ideale per la richiesta di sottoinsiemi di colonne in una tabella multicolonna. Avro è adatto per operazioni ETL, dove richiediamo tutte le colonne.