Compressione Parquet in Apache Hive

In un progetto recente, stavo lavorando alla progettazione e all’implementazione di pipeline per ingerire i dati in un cluster Hadoop. La tipica posizione di destinazione dei dati ingestiti è una tabella Hive. Anche se Hadoop può gestire grandi dati, è una buona pratica comprimere i dati e utilizzare un formato di file più avanzato come ORC o Parquet. Poiché il framework di ingestione è Apache Spark, Parquet è più adatto per leggere e scrivere Spark Dataframes. In termini di compressione, ci sono molte opzioni come Bzip, LZO e SNAPPY. In pratica, SNAPPY è una buona scelta predefinita in quanto comprime bene ma è anche relativamente veloce.

Con il formato di file selezionato (Parquet) e la compressione (SNAPPY), ho voluto creare tabelle Hive appropriate per sfruttare queste opzioni. Hive è abbastanza robusto e queste sono disponibili nativamente, il che rende l’uso di queste opzioni semplice come la definizione dei parametri corretti nel DDL della tabella.

Ho creato i DDL e ho dato per scontato che i dati fossero stati correttamente compressi. Dopo aver eseguito le pipeline su grandi set di dati, ho notato che l’utilizzo del disco era molto più alto del previsto. Dopo una ricerca e un test piuttosto esaustivi, ho capito qualcosa di interessante con Hive e Spark:

1. Le proprietà delle tabelle Hive sono sensibili alle maiuscole e alle minuscole. “PARQUET.COMPRESS” non è la stessa cosa di “parquet.compress” nel metastore Hive.
2. Utilizzando tblproperties(“parquet.compression”=”SNAPPY”) e poi descrivendo la tabella si ottengono informazioni contrastanti. Si dirà che la tabella non è compressa (il che è vero) ma sta comprimendo il contenuto all’interno dei file (che Hive Metastore non traccia).
3. Spark non usa le stesse librerie di hive quindi le tblproperties non sono sempre allineate. Questo significa che quello che vediamo nel Metastore di Hive e quello che stiamo scrivendo usando Spark potrebbe non essere lo stesso.

Con tutte queste nuove informazioni scoperte, ho scoperto che il modo corretto per definire una tabella Hive in modo che sia compressa usando Parquet e SNAPPY indipendentemente dall’applicazione che sta facendo la scrittura (Spark o Hive) è quello di impostare le proprietà della tabella come segue:

TBLPROPERTIES (“parquet.compression”=”SNAPPY”)

Nota il nome e il caso.

In aggiunta a questa scoperta, ho imparato come controllare se un file Parquet è compresso. La maggior parte delle distribuzioni Hadoop sono dotate di uno strumento chiamato parquet-tools. Se non lo avete, potete scaricarlo da qui: https://github.com/apache/parquet-mr/tree/master/parquet-tools. Sfruttando questo strumento, fate quanto segue:

1. Copiate il vostro parquet da HDFS al nodo edge usando hdfs dfs -get <path/to/file>
2. Utilizzate parquet-tools per guardare il file. Utilizzare questo comando: /usr/bin/parquet-tools meta < nome del file>

L’output conterrà righe come questa se i dati non sono compressi:

my_col: BINARY UNCOMPRESSED DO:0 FPO:4 SZ:793/793/1.00 VC:100 ENC:BIT_PACKED,PLAIN_DICTIONARY,RLE

e se è compresso:

my_col: BINARY SNAPPY DO:0 FPO:4 SZ:757/793/1.05 VC:100 ENC:BIT_PACKED,RLE,PLAIN_DICTIONARY

E’ chiaro che se si vuole comprimere, bisogna assicurarsi che sia indicata la compressione corretta per ogni colonna.