我们已经意识到将GZip格式的文件归档用于Hadoop处理并不是一个好主意。 GZip不可拆分，以供参考，以下是我不会重复的问题：
我的问题是：BZip2是最好的归档压缩，它允许Hadoop并行处理单个归档文件吗？ Gzip肯定不是，从我的阅读LZO有一些问题。
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相媲美。
我不认为其他答案是正确的，bzip2根据这个：
是可拆分的。如果编入索引，LZO也是如此。
所以答案是肯定的，如果你想使用比你有文件更多的映射器，那么你将需要使用bzip2。
要做到这一点，你可以编写一个简单的MR作业来读取数据，然后再将其写出来，然后你需要确保将mapred.output.compression.codec设置为org.apache.hadoop.io.compress.BZip2Codec
以下是gzip的五种方式，三种需要索引，两种不需要。
可以为任何gzip文件创建索引，即不是由zran.c完成的特殊构造。然后，您可以在块边界处开始解压缩。索引包括每个入口点处的32K未压缩数据历史记录。
如果您正在构建gzip文件，那么可以使用其索引在这些入口点处不需要未压缩历史记录的周期性入口点，从而形成较小的索引。这是通过zlib中的Z_FULL_FLUSH的deflate()选项完成的。
你也可以在每个这样的点做一个Z_SYNC_FLUSH，接着是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 00为1 MiB块，然后是来自下一个块的1f 8b 08，这是gzip头的开始。然后可以像bzip2标记一样搜索该七字节标记，尽管再次使用较小的误报概率。
对于连接的xz文件也可以这样做，其头部是七个字节：fd 37 7a 58 5a 00 00。
我的2cents，bzip写作速度很慢。使用Apache Spark 1.6.2，Hadoop 2.7进行测试，压缩50Go的简单JSON文件，使用bzip比gzip需要2倍的时间。
但是用bzip，50Go ==> 4 Go！