Meilleur splittable compression pour Hadoop entrée = bz2?
Nous avons réalisé un peu trop tard que l'archivage de nos fichiers en format GZip pour Hadoop traitement n'est pas une 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 simple sur Hadoop et la compression des fichiers d'entrée
- Hadoop gzip fichiers compressés
- Hadoop gzip fichier d'entrée en utilisant seulement un mappeur
- Pourquoi ne peut-hadoop diviser un grand fichier texte, puis de les compresser le divise en utilisant gzip?
Ma question est: est-BZip2 le meilleur d'archives compression qui permettent à un seul fichier d'archive à être traitées en parallèle par Hadoop? Gzip est certainement pas, et à partir de ma lecture LZO a quelques problèmes.
Snappy est l'algorithme de compression par défaut utilisé par Étincelle pour Parquet fichiers et est une autre grande option.
OriginalL'auteur Suman | 2013-02-11
Vous devez vous connecter pour publier un commentaire.
BZIP2 est splittable dans hadoop - il fournit un très bon taux de compression, mais de temps PROCESSEUR et des performances n'est pas de fournir des résultats optimaux, comme la compression est très consommation PROCESSEUR.
LZO est splittable dans hadoop en tirant parti de hadoop-lzo vous avez splittable comprimé LZO fichiers. Vous avez besoin d'avoir à l'externe .lzo.les fichiers d'index pour être en mesure de traiter en parallèle. La bibliothèque fournit tous les moyens de génération de ces indices dans le local ou distribué de manière.
LZ4 est splittable dans hadoop en tirant parti de hadoop-4mc vous avez splittable comprimé 4mc fichiers. Vous n'avez pas besoin d'une personne extérieure à l'indexation, et vous pouvez générer des archives avec l'outil de ligne de commande ou en Java/C code, à l'intérieur/à l'extérieur de hadoop. 4mc met à disposition sur hadoop LZ4 à n'importe quel niveau de vitesse/de compression ratio: de mode rapide pour atteindre 500 MO/s vitesse de compression jusqu'à high/ultra modes de fournir le taux de compression accru, presque comparable avec GZIP.
qui vous a surpris à gauche en sortant de Zlib.
OriginalL'auteur Carlo Medas
Je ne considère pas l'autre réponse correcte, bzip2 selon cette:
http://comphadoop.weebly.com/
est splittable. LZO est trop 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
àorg.apache.hadoop.io.compress.BZip2Codec
Je ne sais pas comment faire pour créer des indexé LZO, mais je vais mettre à jour ma réponse à expliquer brièvement comment les compresser pour bzip2.
(Eh bien, j'écris ma sortie via la compression gzip, parce que c'est ce Décalage peut lire), mais tout corriger bzip2 fichier comme entrée, ou dois-je besoin d'en passer un paramètre spécial pour avoir les blocs / index?
Vous n'avez pas besoin de l'indexation avec bzip2, juste LZO. La plupart des Grandes les Données des outils de gérer toutes sortes de compression automatiquement en regardant le fichier qui se termine.
OriginalL'auteur samthebest
Voici cinq façons à l'aide de gzip, trois dans le besoin d'un indice, à deux pas de.
Il est possible de créer un index pour n'importe quel fichier gzip, c'est à dire pas spécialement construits, comme le fait par zran.c. Ensuite, vous pouvez commencer la décompression à bloquer les frontières. L'indice comprend les 32 ko de données non compressées de l'histoire à chaque point d'entrée.
Si vous êtes en train de construire le fichier gzip, alors il peut être fait avec des points d'entrée dont l'index n'a pas besoin de décompressé l'histoire à ces points d'entrée, ce qui pour un plus petit indice. Cela se fait avec la
Z_FULL_FLUSH
option pourdeflate()
dans zlib.Vous pouvez également faire une
Z_SYNC_FLUSH
suivie par unZ_FULL_FLUSH
à chaque point de ce type, qui vise à insérer deux marqueurs. Ensuite, vous pouvez effectuer une recherche pour la période de neuf-modèle d'octet00 00 ff ff 00 00 00 ff ff
pour trouver ces. Ce n'est pas différent que de chercher les six octets marqueur de bzip2 fichiers, à l'exception de faux positifs est beaucoup moins probable avec neuf octets. Alors vous n'avez pas besoin d'un fichier d'index.Les deux gzip et xz appui simple concaténation. Cela vous permet de préparer facilement une archive en parallèle de la décompression d'une autre manière. En bref:
entraînera la comparer à réussir.
Vous pouvez alors simplement de compresser en morceaux de la taille désirée et concaténer les résultats. Enregistrer un index pour les décalages de début de chaque gzip flux. Décompresser de ces décalages. Vous pouvez choisir la taille des blocs à votre goût, selon votre demande. Si vous les faites trop petites, la compression sera impacté.
Avec une simple concaténation de fichiers gzip, vous pouvez également renoncer à l'index si vous faites chaque bloc fixe la taille non compressée. Ensuite, chaque morceau se termine avec la même période de quatre octets, la non compressé longueur en little-endian ordre, par exemple
00 00 10 00
pour 1 MiB morceaux, suivie par1f 8b 08
de la partie suivante, qui est le début d'un en-tête gzip. Que sept octets marqueur peut alors être recherchées comme le bzip2 marqueur, bien qu'encore une fois avec une plus petite probabilité de faux positifs.La même chose pourrait être fait avec concaténées xz fichiers, dont la tête est le sept octets:
fd 37 7a 58 5a 00 00
.Voir mise à jour de réponse.
Astuce: puisque je n'ai pas trouver hadoop fs -bzcat , au lieu d'utilisation: hadoop fs -chat /nom de fichier.bz | bzcat | moins
Selon cette comphadoop.weebly.com bzip2 EST splittable mais gzip n'est pas.
Je ne pense pas que c'est en fait de répondre à la question. Splittable signifie quelque chose de très spécifique dans le monde Hadoop, et GZIP n'est PAS splittable.
OriginalL'auteur Mark Adler
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, il prend 2x plus de temps avec bzip que gzip.
Mais avec bzip, 50Go ==> 4 Go!
OriginalL'auteur Thomas Decaux