如果我有一个可拆分的 1GB 压缩文件，并且默认情况下块大小和输入拆分大小为 128MB，则创建了 8 个块和 8 个输入拆分。当 map reduce 读取压缩块时，它是未压缩的，解压缩后块的大小变为 200MB。但是这个分配的输入分割是 128MB，那么剩下的 82MB 是如何处理的。
- 它是否由下一个输入拆分处理？
- 相同的输入拆分大小是否增加？
1079 次
3 回答
1
以下是我的理解：
假设 1 GB 压缩数据 = 2 GB 解压缩数据，因此您有 16 个数据块，Bzip2 知道块边界，因为 bzip2 文件提供块之间的同步标记。所以 bzip2 将数据拆分为 16 个块，并将数据发送到 16 个映射器。每个映射器获得 1 个输入拆分大小 = 128 MB 的解压缩数据大小。（当然，如果数据不完全是 128 MB 的倍数，最后一个映射器将获得更少的数据）
于 2015-11-01T08:16:25.210 回答
0
总文件大小：1 GB
块大小：128 MB
分割数：8
为每个块创建一个拆分将不起作用，因为不可能从 gzip 流中的任意点开始读取，因此地图任务不可能独立于其他任务读取其拆分。gzip 格式使用 DEFLATE 来存储压缩数据，而 DEFLATE 将数据存储为一系列压缩块。问题是每个块的开始都没有以任何方式区分。因此，gzip 不支持拆分。
MapReduce 不会拆分 gzip 文件，因为它知道输入是 gzip 压缩的（通过查看文件扩展名）并且 gzip 不支持拆分。这将起作用，但会牺牲局部性：单个地图将处理 8 个 HDFS 块，其中大部分不会是地图的本地块。
看看：这篇文章和部分名称：关于压缩和输入拆分的问题
编辑：（用于可拆分解压缩）
BZip2 是一种压缩/解压缩算法，它对数据块进行压缩，然后这些压缩块可以相互独立地解压缩。这确实是一个机会，我们可以并行处理文件块，而不是一个 BZip2 压缩文件转到一个映射器。这种处理的正确性标准是，对于一个bzip2压缩文件，每个压缩块应该只被一个mapper处理，最终文件的所有块都应该被处理。（通过处理，我们指的是映射器中未压缩数据（来自编解码器）的实际利用）
于 2015-10-25T16:07:47.493 回答
0
我在这里指的是可以拆分表的压缩文件，例如可拆分的 bzip2。如果为 128MB 的 bzip2 块创建输入拆分，并且在 map reduce 处理过程中将其解压缩到 200MB，会发生什么情况？
于 2015-10-25T17:05:27.450 回答