Support Ukrain
Adaltas logoAdaltasAdaltas logoAdaltas
Stockage HDFS et Hive - comparaison des formats de fichiers et compressions

Stockage HDFS et Hive - comparaison des formats de fichiers et compressions

WORMS David

By WORMS David

13 mars 2012

Catégories
Data Engineering
Tags
Hive
ORC
Business Intelligence
Parquet
Format de fichier
[plus][moins]

Ne ratez pas nos articles et rejoignez la newsletter Adaltas sur l'open source, le big data et les systèmes distribués. Nous maintenons une fréquence faible avec un email tous les deux mois.

Il y a quelques jours, nous avons conduit un test dans le but de comparer différents format de fichiers et méthodes de compression disponibles dans Hive. Parmi ces formats, certains sont natifs à HDFS et s’appliquent à tous les utilisateurs d’Hadoop. La suite de tests est composée de requête Hive toutes similaires qui créent une table, éventuellement définissent une méthode de compression et chargent un jeu de données dans cette table nouvellement créée. Parmi les requêtes écrites sont testés les formats “sequence file”, “text file” et “RCFILE” ainsi que les codecs de compression “default”, “bz”, “gz”, “LZO” et “Snappy”.

N.B., cet article est la traduction d’un article précédent publié en anglais en mars dernier. Sa traduction est justifiée par la popularité de celui-ci.

Mise à jour, le 4 avril 2012 : réponse au commentaire de Huchev relatif au codec LZ4.

Mise en place

L’environnement sur lequel ont été lancés ces tests est un cluster de 20 noeuds comprenant 120 To de stockage et fonctionnant sous Cloudera CDH3U3. Le jeu de données original est un répertoire de 1.33 Go composé de 80 fichiers non divisibles compressés en “bz2”. Les données à l’intérieur sont structurées au format CSV pour un total de 125.000.000 lignes.

Ci-dessous, voici un exemple de requête Hive qui importe les données en utilisant le format “RCFILE” et le codec de compression “LZO”.

-- Prepare
CREATE TABLE rc_lzo (
    client BIGINT, ctime INT, mtime INT,
    code STRING, value_1 INT, value_2 INT
) STORED AS RCFILE;
-- Compression
SET hive.exec.compress.output=true;
SET mapred.output.compression.codec=com.hadoop.compression.lzo.LzoCodec;
-- Import
INSERT OVERWRITE TABLE rc_lzo
SELECT * FROM (
    SELECT
        client, round(ctime / 1000), round(mtime / 1000),
        code, value_1, value_2
    FROM staging
) T;

Résultats

Le tableau ci-dessous rapporte les résultats obtenus. La colonne intitulée “query” décrit le type de requête testée. Le nom commence par le format de fichier et est suivi par le type de compression. Les types de compression “block” et “record” sont rapportés pour le format “sequence file” et le codec de compression par défaut.

La famille de requêtes “serdesf” correspond à un mode de sérialisation SerDe que nous avons créé sur mesure et qui encode chacune des colonnes de notre jeu de données dans un format binaire aussi approprié que possible. Dans notre cas, le champ code peut être stocké comme un caractère (soit 1 byte), le champ value_2 peut être stocké comme la différence entre sa valeur réelle et celle du champs value_1 (soit 2 bytes). Au total, une ligne est stockée sous 16 bytes contre 65 bytes à l’origine.

Les requêtes “bss” utilisent la sérialisation BinarySortableSerDe qui est un Hive SerDe personnalisé et qui s’associe au format “sequence file”.

La famille de requêtes “b64” utilise le paquet “base64” présent dans les contributions de Hive.

querytimesize
sf2mn 3s7.91 Go
sf_string2mn 22s8.72 Go
sf_df_block2mn 17s8.72 Go
sf_df_record2mn 12s7.32 Go
sf_bz2h 43mn 24s9.9 Go
sf_gz2mn 29s8.72 Go
sf_lzo2mn 36s8.80 Go
sf_snappy3mn 55s8.23 Go
tf1mn 45s6.44 Go
tf_bz2mn 14s1.12 Go
tf_df2mn 16s1.12 Go
tf_gz48s1.34 Go
tf_lzo1mn 28s2.41 Go
tf_snappy1mn 2s2.55 Go
rc1mn 30s5.78 Go
rc_df5mn 15s917.68 Mo
rc_gz4mn 36s917.80 Mo
rc_snappy52s1.85 Go
rc_lzo38s1.67 Go
serdesf59s3.63 Go
serdesf_df1mn 27s4.61 Go
serdesf_bz3h 6mn 9s9.63 Go
serdesf_gz1mn 51s6.02 Go
serdesf_snappy1mn 35s4.80 Go
bss1mn 25s5.73 Go
b642mn 5s9.17 Go
b64_bz21mn 15s1.14 Go
b64_df21mn 25s1.14 Go
b64_gz53s1.62 Go
b64_snappy59s2.89 Go

Quelques notes

Nous souhaitions faire tourner ces tests sur un jeu de données plus conséquent avec une structure de données plus classique mais les ressources serveurs furent très limitées à cet instant. Au final, les tailles finales des fichiers sont sans doutes représentatives mais les résultats sur les temps de création doivent être interprétés avec plus de précaution.

Les vitesses mesurées reflètent le temps nécessaire à l’importation des données seulement (avec une structure des données en entrée pas trop standard) et non comment ces formats se comportent avec des tâches map/reduce.

Nous avons aussi testé le type de représentation block contre d’autres types de codec et nous avons pu conclure que cela n’avait aucun effet et que celui-ci n’appliquait que pour des fichiers de type “sequence file”.

Finalement, nous avons essayé de faire tourner les tests serdesf en utilisant le format RCFILE au lieu de sequence file mais les résultats sont identiques à ceux de la famille de requêtes rc.

Interprétation

La requête “tf” peut être considérée comme une référence dans la mesure où le stockage est celui d’un format CSV non compressé. Il nous fut très étrange de constater que toutes les requêtes “sequence file” ont généré des fichiers plus larges que leurs amies les “Text file”. Voilà un fait que nous n’avions pas anticipé et peut-être est-ce dû à l’utilisation intensive du type “integer”.

Pour ce qui est de la taille des fichiers, le format “RCFILE” associé à la compression par défault et “gz” ont obtenu les meilleurs résultats. Le “base64” SerDe utilisant le “sequence file” avec les compressions “bz” et “default” ne sont pas si loin de ces résultats. Les résultats “base64” sont suffisamment lents pour être mis de côté.

En terme de vitesse, les formats “RCFILE” avec les compressions “lzo” et “snappy” sont très rapides tout en préservant de forts taux de compression.

A propos LZ4

Nous n’avons pas testé la compression LZ4. Le support pour LZ4 vise les versions 0.23.1 et 0.24.0 d’Hadoop et n’est pas implémenté pour notre Cloudera CDH3U3. Si vous êtes sérieusement intéressé par LZ4, je vous invite à lire l’article comparant LZ4 avec Snappy. Cet article comparant les compressions les plus rapides en mémoire est aussi intéressant. Les 2 articles précédemment cités sont en anglais.

Canada - Maroc - France

International locations

10 rue de la Kasbah
2393 Rabbat
Canada

Nous sommes une équipe passionnée par l'Open Source, le Big Data et les technologies associées telles que le Cloud, le Data Engineering, la Data Science le DevOps…

Nous fournissons à nos clients un savoir faire reconnu sur la manière d'utiliser les technologies pour convertir leurs cas d'usage en projets exploités en production, sur la façon de réduire les coûts et d'accélérer les livraisons de nouvelles fonctionnalités.

Si vous appréciez la qualité de nos publications, nous vous invitons à nous contacter en vue de coopérer ensemble.