Hadoop输入的最佳可拆分压缩= bz2？

Question

我们已经意识到将GZip格式的文件归档用于Hadoop处理并不是一个好主意.GZip不可拆分,以供参考,以下是我不会重复的问题:

• 关于Hadoop和压缩输入文件的基本问题
• Hadoop gzip压缩文件
• Hadoop gzip输入文件只使用一个映射器
• 为什么hadoop不能拆分大文本文件,然后使用gzip压缩拆分？

我的问题是:BZip2是最好的归档压缩,它允许Hadoop并行处理单个归档文件吗？Gzip肯定不是,从我的阅读LZO有一些问题.

Answer 1

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相媲美.

Answer 2

这里有五种使用 gzip 的方法，三种需要索引，两种不需要。

可以为任何 gzip 文件创建索引，即不是专门构造的，如zran.c所做的那样。然后您可以在块边界处开始解压缩。该索引包括每个入口点的 32K 未压缩数据历史记录。

如果您正在构建 gzip 文件，则可以使用周期性入口点来制作它，这些入口点的索引不需要在这些入口点处的未压缩历史记录，从而形成较小的索引。这是通过zlib 中的Z_FULL_FLUSH选项完成的deflate()。

您还可以在每个这样的点执行 aZ_SYNC_FLUSH后跟 a Z_FULL_FLUSH，这将插入两个标记。然后你可以搜索九字节模式00 00 ff ff 00 00 00 ff ff来找到这些。这与在 bzip2 文件中搜索六字节标记没有什么不同，除了九个字节的误报可能性要小得多。那么你不需要单独的索引文件。

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 001 MiB 块，然后1f 8b 08是下一个块，它是 gzip 标头的开始。然后可以像搜索 bzip2 标记一样搜索该七字节标记，但再次出现误报的可能性较小。

对连接的 xz 文件也可以这样做，其标头是七个字节：fd 37 7a 58 5a 00 00.

Answer 3

我不认为其他答案是正确的,bzip2根据这个:

http://comphadoop.weebly.com/

是可拆分的.如果编入索引, LZO也是如此.

所以答案是肯定的,如果你想使用比你有文件更多的映射器,那么你将需要使用bzip2.

要做到这一点,你可以编写一个简单的MR作业来读取数据,然后再将其写出来,然后你需要确保设置mapred.output.compression.codec为org.apache.hadoop.io.compress.BZip2Codec