在Hadoop环境中，压缩编解码器的可拆分性是什么意思？

Question

当我遇到术语'可拆分'时，我正在学习各种压缩编解码器。现在这个术语在我看到的任何互联网资源和书籍中都没有得到很好的解释，所以我想我可能会在这里错过一些微不足道的东西。我的第一个猜测是，某些编解码器将元数据作为标题/尾部添加到压缩文件中，这意味着如果一个压缩文件被分割为多个HDFS块进行存储，除非其所有分割都是分割的合并在一起。如果是这种情况，那么不可拆分文件的拆分（块）如何发送给映射器以便输入到MR应用程序？

我知道一个事实，即Hadoop的不支持gzip（非裂开的编解码器），但我完全不明白怎么样。

有人能给出一个解释精细到什么是编解码器或非分割性的影响分享一些链接，这样做？从“Hadoop的权威指南”由汤姆·怀特，在Hadoop我的一章

Answer 1

摘录/ O，压缩和输入拆分：

让我们假设我们有1个GB大小的文件在HDFS其块大小是64 MB。这意味着文件存储在16个块中。使用此文件作为输入的MapReduce作业将创建16个输入拆分，每个输入拆分作为独立映射任务的输入单独处理。

现在想象一下，该文件是一个用gzip压缩的文件，其压缩后的大小为1 GB。和以前一样，HDFS将文件存储为16个块。但是，为每个块创建分割将不起作用，因为无法在gzip流中的任意点开始读取，因此无法使地图任务独立于其他分割地读取其分割。 gzip格式使用DEFLATE存储压缩数据，DEFLATE将数据存储为一系列压缩块。问题在于，不能以任何方式来区分每个块的开始，使得位于流中任意点的阅读器前进到下一个块的开始处，从而使其与流同步。由于这个原因，gzip不支持分割。

在这种情况下，MapReduce会做正确的事情，不会尝试拆分gzip文件，因为它知道输入是gzip压缩的（通过查看文件扩展名），并且gzip不支持拆分。这会起作用，但是以牺牲局部性为代价：单个地图将处理16个HDFS块，其中大多数块不会在地图上局部。此外，由于地图数量较少，作业的粒度较小，因此可能需要较长的时间才能运行。

如果我们假设的例子中，文件是一个LZO文件，我们也有同样的问题，因为底层的压缩格式不为读者本身与流同步，提供了一种方法。但是，可以使用Hadoop LZO库附带的索引器工具预处理LZO文件。该工具建立分割点的索引，当使用适当的MapReduce输入格式时，该分割点有效地使它们分裂。

另一方面，bzip2文件提供块之间的同步标记（pi的48位近似值），因此它支持分割。

Compression format| Algorithm | Splittable 
------------------------------------------------------------------- 
gzip    | DEFLATE | No 
bzip2    | bzip2  | Yes 
LZO    | LZO  | Yes 
Snappy   | Snappy | No 

参考this更多细节上的压缩和分裂