Compression de données dans Hadoop - mannequins

Les volumes de données énormes qui sont des réalités dans un déploiement Hadoop typique font de la compression une nécessité. La compression des données vous permet d'économiser beaucoup d'espace de stockage et d'accélérer le mouvement de ces données dans votre cluster. Sans surprise, un certain nombre de schémas de compression disponibles, appelés codecs, sont là pour vous.

Dans un déploiement Hadoop, vous traitez (potentiellement) un nombre assez important de nœuds esclaves individuels, chacun d'entre eux ayant un nombre important de disques durs. Il n'est pas rare qu'un nœud esclave individuel dispose de plus de 45 To d'espace de stockage brut disponible pour HDFS.

Même si les noeuds esclaves Hadoop sont conçus pour être peu coûteux, ils ne sont pas gratuits, et avec de gros volumes de données qui ont tendance à augmenter à des taux croissants, la compression est un outil évident pour contrôler les extrêmes. volumes de données

Tout d'abord, certains termes de base: A codec, qui est une forme abrégée de co mpressor / dec ompressor, est la technologie (logiciel ou matériel, à la fois) pour compresser et décompresser des données; c'est l'implémentation d'un algorithme de compression / décompression.

Vous devez savoir que certains codecs prennent en charge ce que l'on appelle la compression divisible et que les codecs diffèrent à la fois par la vitesse de compression et de décompression des données et par le degré de compression.

La compression divisible est un concept important dans un contexte Hadoop. La façon dont Hadoop fonctionne est que les fichiers sont divisés s'ils sont plus grands que le paramètre de taille de bloc du fichier, et les séparations de fichiers individuelles peuvent être traitées en parallèle par différents mappeurs.

Avec la plupart des codecs, les fichiers texte ne peuvent pas être décompressés indépendamment des autres fichiers du même fichier. Ces codecs sont donc non divisibles, donc le traitement MapReduce est limité à un seul mappeur.

Comme le fichier ne peut être décompressé que dans son ensemble, et non en tant que parties individuelles basées sur des séparations, il ne peut y avoir de traitement parallèle d'un tel fichier, et les performances risquent d'être considérablement affectées. traiter plusieurs blocs de données qui ne peuvent pas être décompressés indépendamment.

La compression séparable n'est qu'un facteur pour les fichiers texte. Pour les fichiers binaires, les codecs de compression Hadoop compressent les données dans un conteneur codé en binaire, en fonction du type de fichier (par exemple, un fichier SequenceFile, Avro ou ProtocolBuffer).

En parlant de performance, il y a un coût (en termes de ressources de traitement et de temps) associé à la compression des données qui sont écrites dans votre cluster Hadoop.

Avec les ordinateurs, comme avec la vie, rien n'est gratuit. Lorsque vous compressez des données, vous échangez des cycles de traitement pour l'espace disque. Et lorsque ces données sont lues, il y a un coût associé à la décompression des données. Assurez-vous de peser les avantages des économies de stockage par rapport aux frais généraux de performance supplémentaires.

Si le fichier d'entrée d'un travail MapReduce contient des données compressées, le temps nécessaire pour lire ces données à partir de HDFS est réduit et les performances du travail sont améliorées. Les données d'entrée sont décompressées automatiquement lors de leur lecture par MapReduce.

L'extension du nom de fichier d'entrée détermine quel codec pris en charge est utilisé pour décompresser automatiquement les données. Par exemple, a. L'extension gz identifie le fichier comme un fichier compressé par gzip.

Il peut également être utile de compresser la sortie intermédiaire de la phase de la carte dans le flux de traitement MapReduce. Étant donné que la sortie de la fonction de carte est écrite sur le disque et envoyée sur le réseau aux tâches de réduction, la compression de la sortie peut entraîner des améliorations significatives des performances.

Et si vous souhaitez stocker la sortie MapReduce en tant que fichiers d'historique pour une utilisation future, la compression de ces données peut réduire considérablement la quantité d'espace nécessaire dans HDFS.

Il existe de nombreux algorithmes et outils de compression, dont les caractéristiques et les forces varient. Le compromis le plus courant est entre les taux de compression (le degré de compression d'un fichier) et les vitesses de compression / décompression. Le framework Hadoop supporte plusieurs codecs. Le cadre compresse et décompresse de manière transparente la plupart des formats de fichiers d'entrée et de sortie.

La liste suivante identifie certains codecs courants pris en charge par le framework Hadoop. Assurez-vous de choisir le codec le plus proche des exigences de votre cas d'utilisation (par exemple, avec des charges de travail où la vitesse de traitement est importante, choisissez un codec avec des vitesses de décompression élevées):

• Gzip: utilitaire qui a été adopté par le projet GNU, Gzip (abréviation de GNU zip) génère des fichiers compressés qui ont un. extension gz. Vous pouvez utiliser la commande gunzip pour décompresser les fichiers créés par un certain nombre d'utilitaires de compression, notamment Gzip.

• Bzip2: Du point de vue de l'ergonomie, Bzip2 et Gzip sont similaires. Bzip2 génère un meilleur taux de compression que Gzip, mais il est beaucoup plus lent. En fait, de tous les codecs de compression disponibles dans Hadoop, Bzip2 est de loin le plus lent.

  Si vous configurez une archive que vous aurez rarement besoin d'interroger et que l'espace est très cher, Bzip2 sera peut-être utile.

• Snappy: Le codec Snappy de Google fournit des taux de compression modestes, mais des vitesses de compression et de décompression rapides. (En fait, il a les vitesses de décompression les plus rapides, ce qui le rend très souhaitable pour les fichiers susceptibles d'être souvent interrogés.)

  Le codec Snappy est intégré dans Hadoop Common, un ensemble d'utilitaires communs prenant en charge d'autres sous-projets Hadoop. Vous pouvez utiliser Snappy en tant que module complémentaire pour les versions plus récentes de Hadoop qui ne fournissent pas encore de support de codec Snappy.

• LZO: Semblable à Snappy, LZO (abréviation de Lempel-Ziv-Oberhumer, le trio d'informaticiens qui a inventé l'algorithme) fournit des taux de compression modestes, mais des vitesses de compression et de décompression rapides. LZO est sous licence GNU Public License (GPL).

  LZO prend en charge la compression séparable, ce qui permet le traitement parallèle des fragments de fichiers texte compressés par vos travaux MapReduce. LZO doit créer un index lorsqu'il compresse un fichier, car avec les blocs de compression de longueur variable, un index est requis pour indiquer au mappeur où il peut diviser le fichier compressé en toute sécurité. LZO n'est vraiment souhaitable que si vous avez besoin de compresser des fichiers texte.

Codecs Hadoop

Codec	Extension de fichier	Séparable?	Degré de compression	Vitesse de compression
Gzip	. gz	Non	Moyen	Moyen
Bzip2	. bz2	Oui	Haut	Lent
Snappy	. Snappy	Non	Moyen	Rapide
LZO	. lzo	Non, sauf indexé	Moyen	Rapide

Tous les algorithmes de compression doivent faire des compromis entre le degré de compression et la vitesse de compression qu'ils peuvent atteindre. Les codecs répertoriés vous permettent de contrôler l'équilibre entre le taux de compression et la vitesse au moment de la compression.

Par exemple, Gzip vous permet de réguler la vitesse de compression en spécifiant un entier négatif (ou un mot-clé), où -1 indique le niveau de compression le plus rapide et -9 le niveau de compression le plus lent. Le niveau de compression par défaut est -6.