Encodage, compression, Parquet et Hive
Sur CDH 5.14 cluster, je faisais une comparaison de taille pour des insertions faites en utilisant hive Vs impala vers une table avec un format de fichier parquet. J’avais l’impression, étant donné que les deux formats de fichiers sont les mêmes, il devrait avoir un comportement similaire (avec le codec de compression par défaut) pour aboutir à une taille approximativement identique. Cependant remarqué que – Le fichier parquet écrit par Impala est beaucoup plus petit que celui écrit par hive pour les mêmes données d’entrée.
Donc commencé à regarder le fichier parquet écrit par hive et tomber sur des observations qui ont effectivement aidé à comprendre le point où peut-être tous les débutants auraient dû tomber sur une sorte de confusion sur l’encodage Vs compression (ici liée aux tables hive hdfs). C’est-à-dire la différence spécifique entre l’encodage et la compression et comment hive opère sur cela.
Ce que je pense en général la différence entre l’encodage et la compression est –
- Encodage : C’est plus au niveau de l’application où la représentation des données est modifiée. L’encodage peut aussi minimiser l’utilisation de l’espace ce qui peut nous donner une sorte de compression.
- Compression : En général, c’est la technique pour réduire le stockage pour des données données données en octets indépendamment du fait que les données soulignées sont déjà encodées ou non.
Ce qui précède confirme avec l’observation ci-dessous.
- Création d’une ruche avec le format de fichier parquet.
- Insertion de certaines données qui avaient créé environ 1 Go de fichiers parquet dans le cadre de l’insertion.
- Pour avoir un aperçu du fichier parquet, j’ai copié le fichier de hdfs à local pour le vider (juste pour noter – il y a des moyens de vider de hdfs aussi). Puis validé en utilisant l’utilitaire parquet-meta qui peut vider le fichier parquet.
- …/parquet-meta <nom du fichier>
- Où l’on voit, chaque colonne est encodée avec différentes techniques d’encodage (valeur de ENC) comme la longueur de course, le nombre de bits, etc. Cependant, le fichier parquet écrit par le répertoire de stockage n’utilise pas de compression par défaut. La taille du fichier était de 1GB.
Après
- Tableau tronqué utilisé dans le test susmentionné.
- À la ligne de commande de hive(beeline), définissez les paramètres ci-dessous qui définiront explicitement le codec de compression et forceront hive à compresser le fichier parquet écrit par hive.
SET hive.exec.compress.output=true;
SET parquet.compression=SNAPPY
- Insérer la même quantité de données. Cette fois, il a créé environ 350 Mo de fichiers parquet.
- De nouveau, copié le fichier de hdfs à local pour le vider en utilisant l’utilitaire parquet-meta.
- Ici on peut voir que, il montre que le fichier est compressé avec SNAPPY en même temps que l’encodage. Lorsque nous activons explicitement la compression, il y aura une réduction substantielle de la taille du fichier parquet pour la même quantité de données comme résultat de la compression.
Donc l’observation est que l’encodage et la compression sont différents et qu’ils peuvent être utilisés séparément ou ensemble. J’ai observé dans hive ( à partir de CDH 5.14), lorsque nous écrivons dans une table parquet, par défaut, il utilise uniquement l’encodage et non la compression. Pour activer la compression sur hive, nous devons explicitement définir à hive comme ci-dessous.
SET hive.exec.compress.output=true;
SET parquet.compression=<Compression Codec>
Ce qui aboutirait alors à une taille presque identique à celle des inserts Impala (Impala par défaut fait à la fois l’encodage et la compression).