Meilleure compression séparable pour Hadoop input = bz2?
nous avons réalisé un peu trop tard que l'archivage de nos fichiers au format GZip pour le traitement Hadoop n'est pas une si bonne idée. GZip n'est pas splittable, et pour référence, voici les problèmes que je ne vais pas le répéter:
- question très basique sur Hadoop et les fichiers d'entrée compressés
- Hadoop gzip fichiers compressés
- Hadoop gzip fichier d'entrée en utilisant seulement un mappeur
- pourquoi ne peut pas hadoop fractionner un gros fichier texte et compresser les séparations à l'aide de gzip?
ma question Est: Est-ce que BZip2 est la meilleure compression d'archives qui permettra à un seul fichier d'archives d'être traité en parallèle par Hadoop? Gzip ne l'est certainement pas, et D'après ce que J'ai lu, LZO a des problèmes.
4 réponses
BZIP2 est séparable en hadoop - il fournit un très bon taux de compression, mais à partir du temps CPU et des performances ne fournit pas des résultats optimaux, car la compression est très consommatrice de CPU.
IZO est splittable dans hadoop - en s'appuyant sur hadoop-lzo vous avez des fichiers LZO compressés. Vous avez besoin d'avoir à l'externe .lzo.index des fichiers à traiter en parallèle. La bibliothèque fournit tous les moyens de générer ces les index en local ou distribué de manière.
LZ4 est splittable dans hadoop - en s'appuyant sur hadoop-4mc vous avez des fichiers compressés 4MC. Vous n'avez pas besoin d'indexation externe, et vous pouvez générer des archives avec l'outil en ligne de commande fourni ou par code Java/C, à l'intérieur/à l'extérieur de hadoop. 4mc rend disponible sur hadoop LZ4 à tout niveau de vitesse / rapport de compression: du mode rapide jusqu'à 500 MB / s vitesse de compression jusqu'aux modes high / ultra fournissant un taux de compression accru, presque comparable à GZIP one.
je ne considère pas l'autre réponse correcte, bzip2 selon ceci:
est splittable. LZO est trop!--9-->si indexé.
Donc la réponse est oui, si vous voulez utiliser plus d'utilisateurs que vous avez des fichiers, alors vous aurez envie d'utiliser bzip2.
Pour ce faire, vous pouvez écrire une simple M. d'emploi pour lire les données, puis l'écrire à nouveau, vous devez vous assurer que vous définissez mapred.output.compression.codec pour org.apache.hadoop.io.compress.BZip2Codec
voici cinq façons avec gzip, trois nécessitant un index, deux pas.
il est possible de créer un index pour n'importe quel fichier gzip, c'est-à-dire NON spécialement construit, comme fait par zran.c. Ensuite, vous pouvez commencer la décompression aux limites du bloc. L'indice comprend les 32K de données historiques non compressées à chaque point d'entrée.
si vous construisez le fichier gzip, alors il peut être fait avec des points d'entrée périodiques dont l'index n'a pas besoin d'histoire non compressée à ces points d'entrée, ce qui fait un indice plus petit. Cela se fait avec l' Z_FULL_FLUSH option deflate() zlib.
Vous pouvez aussi faire un Z_SYNC_FLUSH suivi de Z_FULL_FLUSH à chacun de ces points, ce qui insérerait deux marqueurs. Ensuite, vous pouvez rechercher le modèle de neuf octets 00 00 ff ff 00 00 00 ff ff pour trouver ces. Ce n'est pas différent de chercher le marqueur de six octets dans les fichiers bzip2, sauf qu'un faux positif est beaucoup moins probable avec neuf octets. Alors vous n'avez pas besoin d'un autre indice fichier.
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 réussite de la comparaison.
vous pouvez alors simplement compresser des morceaux de la taille désirée et concaténer les résultats. Enregistrez un index des offsets du début de chaque flux gzip. Décompresse de ces décalages. Vous pouvez choisir la taille des blocs à votre goût, en fonction de votre application. Si vous les faites trop petites, la compression sera impacté.
avec la concaténation simple des fichiers gzip, vous pouvez également renoncer à l'index si vous faites à chaque morceau une taille fixe non compressé. Puis chaque morceau se termine avec les mêmes quatre octets, la longueur non compressée dans l'ordre de little-endian, par exemple 00 00 10 00 pour des morceaux de 1 MiB, suivi de 1f 8b 08 dans la partie suivante, qui est le début d'un en-tête gzip. Ce marqueur de sept octets peut alors être recherché comme le marqueur bzip2, mais encore une fois avec une plus faible probabilité de faux positifs.
la même chose pourrait être faite avec des fichiers XZ concaténés, dont l'en-tête est les sept octets:fd 37 7a 58 5a 00 00.
mes 2cents, bzip est très lent à écrire. Testé avec Apache Spark 1.6.2, Hadoop 2.7, compresse un simple fichier JSON de 50Go, il prend 2 fois plus de temps avec bzip que gzip.
mais avec bzip, 50Go = = > 4 Go!