如果我有1GB的压缩文件是可拆分的，默认情况下块大小和输入分割大小为128MB，则创建8个块，分割8个输入。当通过map reduce读取压缩块时，它是未压缩的，并且在解压缩后说块的大小变为200MB。但是这个分配的输入分割是128MB，所以82MB的其余部分是如何处理的。
答案 0 :(得分：0)
文件总大小：1 GB
块大小：128 MB
分割数量：8
为每个块创建拆分将无法工作，因为无法在gzip流中的任意点开始读取，因此映射任务无法独立于其他任务读取其拆分。 gzip格式使用DEFLATE存储压缩数据，DEFLATE将数据存储为一系列压缩块。问题是每个块的开始都没有以任何方式区分。因此， gzip不支持拆分。
MapReduce不会拆分gzip压缩文件，因为它知道输入是gzip压缩的（通过查看文件扩展名）并且gzip不支持拆分。这将起作用，但是以牺牲局部性为代价：单个地图将处理8个HDFS块，其中大多数块不是地图的本地块。
查看：this article和部分名称：有关压缩和输入拆分的问题
编辑：（适用于可拆分的非压缩）
BZip2是一种压缩/解压缩算法，它对数据块进行压缩，之后这些压缩块可以相互独立地解压缩。这确实是一个机会，而不是一个BZip2压缩文件转到一个映射器，我们可以并行处理文件块。这种处理的正确性标准是对于bzip2压缩文件，每个压缩块应该只由一个映射器处理，并且最终应该处理该文件的所有块。 （通过处理，我们指的是在映射器中实际利用未压缩数据（来自编解码器））
答案 1 :(得分：0)
我在这里指的是可以拆分的压缩文件，如bzip2，可以拆分。如果为128MB的bzip2块创建输入分割，并且在未压缩到200MB的映射缩减处理期间，会发生什么？
答案 2 :(得分：0)
以下是我的理解：
假设1 GB压缩数据= 2 GB解压缩数据 所以你有16个数据块，Bzip2知道块边界，因为bzip2文件提供了块之间的同步标记。因此，bzip2将数据拆分为16个块，并将数据发送给16个映射器。每个映射器获得1个输入拆分大小= 128 MB的解压缩数据大小。 （当然，如果数据不是128 MB的完全倍数，则最后一个映射器将获得更少的数据）