我们已经意识到用gzip格式归档文件以进行hadoop处理并不是一个好主意，这有点太晚了。gzip是不可拆分的，为了便于参考，这里有一些问题我将不再重复：关于hadoop和压缩输入文件的基本问题hadoop gzip压缩文件只使用一个Map器的hadoop gzip输入文件为什么hadoop不能分割一个大的文本文件，然后使用gzip压缩分割？我的问题是：bzip2是允许hadoop并行处理单个归档文件的最佳归档压缩吗？gzip绝对不是，从我的阅读来看lzo有一些问题。
tktrz96b1#
我的朋友，bzip写东西很慢。使用apachespark1.6.2、hadoop2.7进行测试，压缩一个简单的json文件50go，使用bzip比gzip花费2倍的时间。但是使用bzip，50go==>4 go！
ldfqzlk82#
bzip2在hadoop中是可拆分的—它提供了非常好的压缩比，但从cpu时间和性能来看，并不能提供最佳结果，因为压缩非常消耗cpu。lzo在hadoop中是可拆分的-利用hadoop lzo，可以拆分压缩的lzo文件。您需要有外部的.lzo.index文件才能并行处理。库提供了以本地或分布式方式生成这些索引的所有方法。lz4在hadoop中是可拆分的-利用hadoop-4mc您可以拆分压缩的4mc文件。您不需要任何外部索引，您可以使用提供的命令行工具或通过java/c代码在hadoop内部/外部生成归档文件。4mc在hadoop lz4上提供了任何级别的速度/压缩比：从达到500 mb/s压缩速度的快速模式到提供更高压缩比的高/超模式，几乎与gzip模式相当。
ojsjcaue3#
gzip有五种方法，三种需要索引，两种不需要。可以为任何gzip文件创建索引，即不是像zran.c那样专门构造的。然后可以在块边界处开始解压缩。索引包括每个入口点的32k未压缩数据历史记录。如果您正在构造gzip文件，那么可以使用定期的入口点来创建它，这些入口点的索引不需要在这些入口点处进行未压缩的历史记录，从而生成较小的索引。这是通过 Z_FULL_FLUSH 选择 deflate() 在兹利布。你也可以做一个 Z_SYNC_FLUSH 接着是一个 Z_FULL_FLUSH 在每个这样的点上，插入两个标记。然后你可以搜索9字节的模式 00 00 ff ff 00 00 00 ff ff 找到那些。这与在bzip2文件中搜索6字节标记没有什么不同，只是9字节的情况下误报的可能性要小得多。那么就不需要单独的索引文件了。gzip和xz都支持简单的连接。这允许您以另一种方式轻松地为并行解压缩准备存档。简而言之：
Z_FULL_FLUSH
deflate()
Z_SYNC_FLUSH
00 00 ff ff 00 00 00 ff ff
gzip < a > a.gz gzip < b > b.gz cat a.gz b.gz > c.gz gunzip < c.gz > c cat a b | cmp - c
将导致比较成功。然后，您可以简单地压缩成所需大小的块并连接结果。将索引保存到每个gzip流开始的偏移量。从这些补偿中减压。您可以根据自己的应用程序来选择块的大小。但是，如果使它们太小，则会影响压缩。通过gzip文件的简单连接，如果使每个块具有固定的未压缩大小，也可以放弃索引。然后每个块以相同的四个字节结束，未压缩的长度以小端顺序排列。 00 00 10 00 对于1个mib块，后跟 1f 8b 08 从下一个块开始，这是gzip头的开始。然后可以像bzip2标记一样搜索这个7字节的标记，尽管误报的概率更小。对于连接的xz文件也可以这样做，其头是七个字节： fd 37 7a 58 5a 00 00 .
00 00 10 00
1f 8b 08
fd 37 7a 58 5a 00 00
d6kp6zgx4#
我不认为另一个答案是正确的，根据这个：http://comphadoop.weebly.com/是可拆分的。如果索引，lzo也是。所以答案是肯定的，如果你想使用比你有文件更多的Map器，那么你会想使用bzip2。要做到这一点，你可以写一个简单的mr作业来读取数据，然后再写出来，然后你需要确保你设置了 mapred.output.compression.codec 至 org.apache.hadoop.io.compress.BZip2Codec
mapred.output.compression.codec
org.apache.hadoop.io.compress.BZip2Codec
4条答案
按热度按时间tktrz96b1#
我的朋友，bzip写东西很慢。使用apachespark1.6.2、hadoop2.7进行测试，压缩一个简单的json文件50go，使用bzip比gzip花费2倍的时间。
但是使用bzip，50go==>4 go！
ldfqzlk82#
bzip2在hadoop中是可拆分的—它提供了非常好的压缩比，但从cpu时间和性能来看，并不能提供最佳结果，因为压缩非常消耗cpu。
lzo在hadoop中是可拆分的-利用hadoop lzo，可以拆分压缩的lzo文件。您需要有外部的.lzo.index文件才能并行处理。库提供了以本地或分布式方式生成这些索引的所有方法。
lz4在hadoop中是可拆分的-利用hadoop-4mc您可以拆分压缩的4mc文件。您不需要任何外部索引，您可以使用提供的命令行工具或通过java/c代码在hadoop内部/外部生成归档文件。4mc在hadoop lz4上提供了任何级别的速度/压缩比：从达到500 mb/s压缩速度的快速模式到提供更高压缩比的高/超模式，几乎与gzip模式相当。
ojsjcaue3#
gzip有五种方法，三种需要索引，两种不需要。
可以为任何gzip文件创建索引，即不是像zran.c那样专门构造的。然后可以在块边界处开始解压缩。索引包括每个入口点的32k未压缩数据历史记录。
如果您正在构造gzip文件，那么可以使用定期的入口点来创建它，这些入口点的索引不需要在这些入口点处进行未压缩的历史记录，从而生成较小的索引。这是通过
Z_FULL_FLUSH选择deflate()在兹利布。你也可以做一个
Z_SYNC_FLUSH接着是一个Z_FULL_FLUSH在每个这样的点上，插入两个标记。然后你可以搜索9字节的模式00 00 ff ff 00 00 00 ff ff找到那些。这与在bzip2文件中搜索6字节标记没有什么不同，只是9字节的情况下误报的可能性要小得多。那么就不需要单独的索引文件了。gzip和xz都支持简单的连接。这允许您以另一种方式轻松地为并行解压缩准备存档。简而言之：
将导致比较成功。
然后，您可以简单地压缩成所需大小的块并连接结果。将索引保存到每个gzip流开始的偏移量。从这些补偿中减压。您可以根据自己的应用程序来选择块的大小。但是，如果使它们太小，则会影响压缩。
通过gzip文件的简单连接，如果使每个块具有固定的未压缩大小，也可以放弃索引。然后每个块以相同的四个字节结束，未压缩的长度以小端顺序排列。
00 00 10 00对于1个mib块，后跟1f 8b 08从下一个块开始，这是gzip头的开始。然后可以像bzip2标记一样搜索这个7字节的标记，尽管误报的概率更小。对于连接的xz文件也可以这样做，其头是七个字节：
fd 37 7a 58 5a 00 00.d6kp6zgx4#
我不认为另一个答案是正确的，根据这个：
http://comphadoop.weebly.com/
是可拆分的。如果索引，lzo也是。
所以答案是肯定的，如果你想使用比你有文件更多的Map器，那么你会想使用bzip2。
要做到这一点，你可以写一个简单的mr作业来读取数据，然后再写出来，然后你需要确保你设置了
mapred.output.compression.codec至org.apache.hadoop.io.compress.BZip2Codec