hadoop input=bz2的最佳可拆分压缩?

6ljaweal  于 2021-06-04  发布在  Hadoop
关注(0)|答案(4)|浏览(535)

我们已经意识到用gzip格式归档文件以进行hadoop处理并不是一个好主意,这有点太晚了。gzip是不可拆分的,为了便于参考,这里有一些问题我将不再重复:
关于hadoop和压缩输入文件的基本问题
hadoop gzip压缩文件
只使用一个Map器的hadoop gzip输入文件
为什么hadoop不能分割一个大的文本文件,然后使用gzip压缩分割?
我的问题是:bzip2是允许hadoop并行处理单个归档文件的最佳归档压缩吗?gzip绝对不是,从我的阅读来看lzo有一些问题。

tktrz96b

tktrz96b1#

我的朋友,bzip写东西很慢。使用apachespark1.6.2、hadoop2.7进行测试,压缩一个简单的json文件50go,使用bzip比gzip花费2倍的时间。
但是使用bzip,50go==>4 go!

ldfqzlk8

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模式相当。

ojsjcaue

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 < 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 .

d6kp6zgx

d6kp6zgx4#

我不认为另一个答案是正确的,根据这个:
http://comphadoop.weebly.com/
是可拆分的。如果索引,lzo也是。
所以答案是肯定的,如果你想使用比你有文件更多的Map器,那么你会想使用bzip2。
要做到这一点,你可以写一个简单的mr作业来读取数据,然后再写出来,然后你需要确保你设置了 mapred.output.compression.codecorg.apache.hadoop.io.compress.BZip2Codec

相关问题