Meilleure compression séparable pour l’entrée Hadoop = bz2?
Nous avons compris un peu trop tard que l'archivage de nos fichiers au format GZip pour le traitement Hadoop n'était pas une si bonne idée. GZip n'est pas divisible, et pour référence, voici les problèmes que je ne répéterai pas:
- Question très basique sur Hadoop et les fichiers d'entrée compressés
- Fichiers compressés gzip Hadoop
- Fichier d'entrée Hadoop gzip utilisant un seul mappeur
- Pourquoi hadoop ne peut-il pas scinder un fichier texte volumineux, puis compresser les scissions à l'aide de gzip?
Ma question est la suivante: BZip2 est-il la meilleure compression d'archivage permettant à Hadoop de traiter en parallèle un seul fichier d'archive? Gzip n'est certainement pas, et d'après mes lectures, LZO a quelques problèmes.
BZIP2 est divisible en hadoop - il fournit un très bon rapport de compression, mais son temps et ses performances ne donnent pas des résultats optimaux, car la compression consomme beaucoup de temps.
LZOpeut être scindé en hadoop - en utilisanthadoop-lzovous avez des fichiers LZO compressés scindables. Vous devez disposer de fichiers .lzo.index externes pour pouvoir traiter en parallèle. La bibliothèque fournit tous les moyens de générer ces index de manière locale ou distribuée.
LZ4 est scindable en hadoop - en utilisanthadoop-4mcvous avez des fichiers compressés scindables de 4mc. Vous n'avez pas besoin d'indexation externe et vous pouvez générer des archives avec l'outil de ligne de commande fourni ou avec du code Java/C, dans/hors de hadoop. 4 mc est disponible sur l'hadoop LZ4 à n'importe quel niveau de vitesse/taux de compression: du mode rapide jusqu'à 500 Mo/s en vitesse de compression jusqu'aux modes haut/ultra offrant un taux de compression élevé, presque comparable au mode GZIP.
Je ne considère pas que l'autre réponse est correcte, bzip2, selon ceci:
est divisible. LZO est trop si indexé .
Donc, la réponse est oui, si vous voulez utiliser plus de mappeurs que de fichiers, alors vous voudrez utiliser bzip2.
Pour ce faire, vous pouvez écrire un travail MR simple pour lire les données, puis simplement les réécrire. Vous devez ensuite vous assurer que vous définissez mapred.output.compression.codec à org.Apache.hadoop.io.compress.BZip2Codec.
Voici cinq façons d'utiliser gzip, trois nécessitant un index, deux non.
Il est possible de créer un index pour n’importe quel fichier gzip, c’est-à-dire non spécialement construit, comme le fait le fichier zran.c . Ensuite, vous pouvez commencer la décompression aux limites des blocs. L'index inclut les 32 Ko d'historique de données non compressées à chaque point d'entrée.
Si vous construisez le fichier gzip, vous pouvez le créer avec des points d’entrée périodiques dont l’index n’a pas besoin d’historique non compressé, ce qui permet de créer un index plus petit. Ceci est fait avec l'option Z_FULL_FLUSH à deflate() dans zlib.
Vous pouvez également faire un Z_SYNC_FLUSH suivi d'un Z_FULL_FLUSH à chaque point, ce qui permettrait d'insérer deux marqueurs. Ensuite, vous pouvez rechercher le modèle à neuf octets 00 00 ff ff 00 00 00 ff ff pour les trouver. Ce n'est pas différent que de rechercher le marqueur de six octets dans les fichiers bzip2, sauf qu'un faux positif est beaucoup moins probable avec neuf octets. Ensuite, vous n'avez pas besoin d'un fichier d'index séparé.
Gzip et xz prennent en charge la concaténation simple. Cela vous permet de préparer facilement une archive pour une décompression parallèle d'une autre manière. En bref:
gzip < a > a.gz
gzip < b > b.gz
cat a.gz b.gz > c.gz
gunzip < c.gz > c
cat a b | cmp - c
aboutira à la comparaison réussie.
Vous pouvez ensuite simplement compresser des morceaux de la taille souhaitée et concaténer les résultats. Enregistrez un index sur les décalages du début de chaque flux gzip. Décompresser de ces décalages. Vous pouvez choisir la taille des morceaux à votre convenance, en fonction de votre application. Si vous les rendez trop petites, la compression sera affectée.
Avec la simple concaténation des fichiers gzip, vous pouvez également renoncer à l'index si vous donnez à chaque bloc une taille non compressée fixe. Ensuite, chaque bloc se termine par les mêmes quatre octets, la longueur non compressée dans l’ordre little-endian, par ex. 00 00 10 00 pour des morceaux de 1 Mo, suivis de 1f 8b 08 à partir du morceau suivant, qui correspond au début d'un en-tête gzip. Ce marqueur de sept octets peut ensuite être recherché comme le marqueur bzip2, mais avec une probabilité plus faible de faux positifs.
La même chose pourrait être faite avec des fichiers xz concaténés, dont l'en-tête est constitué des sept octets: fd 37 7a 58 5a 00 00.
Mes 2cents, bzip est très lent pour l'écriture. Testé avec Apache Spark 1.6.2, Hadoop 2.7, compresse un simple fichier JSON de 50Go, cela prend 2 fois plus de temps avec bzip que gzip.
Mais avec bzip, 50Go ==> 4 Go!