Sur un projet récent, je travaillais sur la conception et l’implémentation de pipelines pour ingérer des données dans un cluster Hadoop. L’emplacement cible typique des données ingérées est une table Hive. Même si Hadoop peut traiter des données volumineuses, il est préférable de compresser vos données et d’utiliser un format de fichier plus avancé tel que ORC ou Parquet. Comme le cadre d’ingestion est Apache Spark, Parquet est mieux adapté à la lecture et à l’écriture des cadres de données Spark. En termes de compression, il existe de nombreuses options telles que Bzip, LZO et SNAPPY. En pratique, SNAPPY est un bon choix par défaut car il compresse bien mais est aussi relativement rapide.
Avec le format de fichier sélectionné (Parquet) et la compression (SNAPPY), je voulais créer des tables Hive appropriées pour tirer parti de ces options. Hive est assez robuste et celles-ci sont nativement disponibles ce qui rend l’utilisation de ces options aussi simple que de définir les bons paramètres dans la DDL de la table.
J’ai créé les DDL et j’ai juste supposé que les données étaient correctement compressées. Après avoir exécuté les pipelines sur de grands ensembles de données, j’ai remarqué que l’utilisation du disque était beaucoup plus élevée que prévu. Après une recherche et des tests assez exhaustifs, j’ai réalisé quelque chose d’intéressant avec Hive et Spark:
- Les propriétés des tables Hive sont sensibles à la casse. « PARQUET.COMPRESS » n’est pas la même chose que « parquet.compress » dans le Metastore de Hive.
- Utiliser tblproperties(« parquet.compression »= »SNAPPY ») puis décrire la table vous donne des informations mitigées. Il dira que la table n’est pas compressée (ce qui est vrai) mais il compresse le contenu dans les fichiers (que Hive Metastore ne suit pas).
- Spark n’utilise pas les mêmes bibliothèques que hive donc les tblproperties ne sont pas toujours alignées. Cela signifie que ce que nous voyons dans le Metastore de Hive et ce que nous écrivons en utilisant Spark peut ne pas être le même.
Avec toutes ces informations nouvellement découvertes, j’ai découvert que la bonne façon de définir une table Hive pour qu’elle soit compressée en utilisant Parquet et SNAPPY indépendamment de l’application qui fait l’écriture (Spark ou Hive) est de définir les propriétés de la table comme suit:
TBLPROPERTIES (« parquet.compression »= »SNAPPY »)
Notez le nom et la casse.
En plus de cette découverte, j’ai appris comment vérifier si un fichier Parquet est compressé. La plupart des distributions Hadoop sont livrées avec un outil appelé parquet-tools. Si vous ne l’avez pas, vous pouvez le télécharger ici : https://github.com/apache/parquet-mr/tree/master/parquet-tools. En tirant parti de cet outil, faites ce qui suit :
- Copier votre parquet depuis HDFS vers le nœud périphérique en utilisant hdfs dfs -get <path/to/file>
- Utiliser le parquet-tools pour regarder le fichier. Utilisez cette commande : /usr/bin/parquet-tools meta < nom du fichier>
La sortie contiendra des lignes comme celle-ci si les données sont décompressées:
mon_col : BINARY UNCOMPRESSED DO:0 FPO:4 SZ:793/793/1.00 VC:100 ENC:BIT_PACKED,PLAIN_DICTIONARY,RLE
et si elles sont compressées:
my_col : BINARY SNAPPY DO:0 FPO:4 SZ:757/793/1,05 VC:100 ENC:BIT_PACKED,RLE,PLAIN_DICTIONARY
En clair, si vous voulez qu’il soit compressé, vous voulez vous assurer que la compression correcte est indiquée pour chaque colonne.
0 commentaire