Formats de Stockage de Fichiers
1. FICHIER TEXTE
Format par défaut lors de la création de tables dans Hadoop, où les données sont stockées sous forme de texte. Les fichiers texte peuvent être divisés et traités en parallèle, et peuvent également être compressés à l'aide de méthodes telles que GZip, LZO ou Snappy. Cependant, la plupart des fichiers compressés ne supportent pas la division et le traitement parallèle, ce qui entraîne l'utilisation d'un seul mapper pour traiter les données. Lors de l'utilisation de fichiers texte compressés, il convient de s'assurer qu'ils ne sont pas trop volumineux, généralement proches de la taille de deux blocs HDFS.
2. FICHIER SÉQUENTIEL
Format de stockage binaire pour paires clé-valeur. L'avantage des fichiers séquentiels est qu'ils offrent une meilleure compression que le format texte. Les fichiers séquentiels peuvent être compressés au niveau des blocs, ce qui permet d'obtenir un excellent ratio de compression. Si vous utilisez la compression par blocs, vous devez configurer les paramètres suivants :
set hive.exec.compress.output=true ;
set io.seqfile.compression.type=BLOCK<br></br><br></br>Prend en charge trois options de compression : NONE, RECORD, BLOCK. La compression RECORD offre un faible taux de compression, il est donc recommandé d'utiliser la compression BLOCK.
3. AVRO
Format de fichier binaire qui est également un cadre de sérialisation et de désérialisation. Avro fournit un schéma de données spécifique.
4. FICHIER RC (RECORD COLUMNAR)
Abréviation de Record Columnar File. Ce format divise d'abord la table en plusieurs groupes de lignes, puis stocke les données de chaque groupe de lignes par colonne. Chaque colonne est stockée séparément, ce qui correspond à une division horizontale suivie d'une division verticale.
5. FICHIER ORC (OPTIMIZED ROW COLUMNAR)
Abréviation de Optimized Row Columnar, pris en charge à partir de la version Hive 0.11. Le format ORC est une version optimisée du format RCFILE, avec des blocs par défaut plus grands (256M)<br></br><br></br>Prend en charge trois options de compression : NONE, ZLIB, SNAPPY.
Le format de compression par défaut d'ORC produit des fichiers plus petits qu'avec Snappy, car le format ZLIB par défaut utilise l'algorithme de compression deflate, qui offre un ratio de compression supérieur à celui de l'algorithme Snappy.
Après pluiseurs tests, on constate que les trois méthodes de compression offrent des vitesses d'exécution similaires. Par conséquent, il est recommandé d'utiliser le mode de stockage par défaut d'ORC.
6. FICHIER PARQUET
Un autre format de stockage columnaire, très similaire à ORC. Comparé à ORC, le format Parquet bénéficie d'un écosystème plus étendu, par exemple, les versions antérieures d'Impala ne prennent pas en charge le format ORC. Prend en charge des méthodes de compression telles que Snappy et LZO.
Exemples de création de tables dans Hive :
1. Stockage au format ORC avec compression Snappy
create table etudiants_orc(id int,nom string)
stored as orc
tblproperties ('orc.compress'='snappy');
2. Compression Snappy simple (création directe de table en texte)
create table etudiants_snappy(id int,nom string);
3. Stockage au format Parquet avec compression Lzo
create table etudiants_par(id int,nom string)
stored as parquet
tblproperties ('parquet.compression'='lzo');
4. Stockage au format Parquet avec compression Snappy
create table etudiants_par(id int,nom string)
stored as parquet
tblproperties ('parquet.compression'='snappy');
5. Compression Lzo (nécessite de spécifier InputFormat)
CREATE EXTERNAL TABLE `evenements`(
`donnees` string)
PARTITIONED BY (
`date` string,
`heure` string)
stored as
INPUTFORMAT'com.hadoop.mapred.DeprecatedLzoTextInputFormat'
OUTPUTFORMAT'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
'hdfs://moncluster/utilisateur/pirate/flume/log/Test' ;
Compression dans Hadoop : Comparaison et Cas d'Usage
Lors de l'utilisation des systèmes de stockage de l'écosystème Hadoop, les opérations de stockage, de transfert et de lecture de fichiers sont très courantes. La taille des fichiers influence directement la vitesse de ces opérations ainsi que la consommation d'espace disque.
Une méthode courante pour optimiser ces aspects consiste à compresser les fichiers. Cependant, les fichiers compressés nécessitent une décompression lors de la lecture, ce qui consomme des ressources CPU.
Dans un environnement de prodduction, il est donc essentiel de décider si et comment compresser les données, en tenant compte des ressources nécessaires pour la compression et la décompression, de l'E/S disque, de la bande passante requise pour le transfert réseau, ainsi que des performances du cluster et des caractéristiques des fichiers.
Avantages de la compression :
1. Réduction de l'espace de stockage disque
2. Diminution de l'E/S (disque et réseau), accélération de la transmission des données et amélioration des performances
Voici un aperçu des formats de compression courants dans Hadoop, avec leurs détails :
Compression Snappy :
Avantages : Vitesse de compression élevée et ratio de compression raisonnable ; support des bibliothèques natives Hadoop.
Inconvénients : Ne supporte pas la division (split) ; ratio de compression inférieur à gzip ; inclus par défaut dans Hadoop 2.x.
Cas d'usage : Lorsque les données de sortie des tâches Map sont volumineuses, comme format de données intermédiaires entre les étapes map et reduce ; ou comme format de sortie d'une tâche MapReduce servant d'entrée à une autre tâche MapReduce.
Compression LZO :
Avantages : Vitesse de compression/décompression rapide avec un ratio de compression raisonnable ; support de la division, ce qui en fait le format de compression le plus populaire dans Hadoop ; support des bibliothèques natives Hadoop ; installation possible de la commande lzop sous Linux pour une utilisation pratique.
Inconvénients : Ratio de compression légèrement inférieur à gzip ; non supporté nativement par Hadoop, nécessite une installation ; dans les applications, les fichiers LZO nécessitent un traitement spécial (création d'index pour supporter la division, spécification du InputFormat au format LZO).
Cas d'usage : Idéal pour les très grands fichiers texte qui, après compression, dépassent 200M ; l'avantage du LZO est d'autant plus marqué que le fichier est volumineux.
Compression Gzip :
Avantages : Ratio de compression élevé, vitesse de compression/décompression rapide ; support natif par Hadoop, traitement identique aux fichiers texte ; présence de bibliothèques natives Hadoop ; commande gzip intégrée à la plupart des systèmes Linux.
Inconvénients : Ne supporte pas la division.
Cas d'usage : Pour les fichiers dont la taille compressée reste inférieure à 130M. Par exemple, compression des journaux quotidiens en un seul fichier gzip, avec traitement parallèle par MapReduce via plusieurs fichiers. Les programmes traitant ces fichiers (Hive, streaming, MapReduce) fonctionnent de la même manière qu'avec des fichiers texte, sans nécessiter de modification.
Compression Bzip2 :
Avantages : Supporte la division ; très haut ratio de compression, supérieur à gzip ; support natif par Hadoop (mais sans bibliothèques natives) ; commande bzip2 intégrée à la plupart des systèmes Linux.
Inconvénients : Vitesse de compression/décompression lente ; pas de support des bibliothèques natives.
Cas d'usage : Adapté aux scénarios où la vitesse n'est pas critique mais où un ratio de compression élevé est nécessaire. Comme format de sortie pour les tâches MapReduce ; pour les données importantes après traitement qui nécessitent un stockage compressé pour économiser de l'espace disque et qui seront peu utilisées par la suite ; pour la compression de très gros fichiers texte nécessitant la division et la compatibilité avec les applications existantes (sans modification nécessaire).
Remarque : Lors de la présentation des formats de compressoin ci-dessus, nous avons souligné leur support des bibliothèques natives Hadoop, car ce support a un impact considérable sur les performances.
Hadoop est développé en Java, mais certaines opérations ne sont pas toujours optimales avec Java, d'où l'introduction du concept de bibliothèques natives. Grâce à ces bibliothèques, Hadoop peut exécuter certaines opérations de manière plus efficace.