如果我有一个1gb的压缩文件，它是可拆分的，默认情况下块大小和输入拆分大小是128mb，那么就创建了8个块和8个输入拆分。当压缩块被map reduce读取时，它被解压，解压后块的大小变为200mb。但是这个分配的输入分割是128mb，那么剩余的82mb是如何处理的呢。是否由下一个输入拆分处理？是否增加了相同的输入拆分大小？
igsr9ssn1#
我在这里指的是压缩文件，它可以像bzip2一样拆分成表，bzip2是可拆分的。如果为bzip2的128mb块创建了一个输入分割，并且在map reduce处理过程中，当该块解压缩到200mb时，会发生什么情况？
agxfikkp2#
我的理解是：假设1 gb压缩数据=2 gb解压缩数据，因此有16个数据块，bzip2知道块边界，因为bzip2文件在块之间提供同步标记。因此bzip2将数据分成16个块，并将数据发送给16个Map器。每个Map器得到的解压数据大小为1，输入拆分大小为128 mb(当然，如果数据不是128 mb的整数倍，则最后一个Map器将获得较少的数据）
gev0vcfq3#
总文件大小：1 gb块大小：128 mb分割数：8为每个块创建一个分割将不起作用，因为不可能在gzip流中的任意点开始读取，因此map任务不可能独立于其他块读取其分割。gzip格式使用deflate存储压缩数据，deflate将数据存储为一系列压缩块。问题是，每个块的开头没有任何区别。因此，gzip不支持拆分。mapreduce不会分割gzip文件，因为它知道输入是gzip压缩的（通过查看文件扩展名），并且gzip不支持分割。这将起作用，但以牺牲位置为代价：单个Map将处理8个hdfs块，其中大多数块不是Map的本地块。请看一下：本文和小节名称：关于压缩和输入拆分的问题编辑：（用于可拆分的解压缩）bzip2是一种压缩/反压缩算法，它对数据块进行压缩，然后这些压缩块可以相互独立地进行解压缩。这确实是一个机会，我们可以并行处理文件块，而不是将一个bzip2压缩文件传递给一个Map器。这种处理的正确性标准是，对于bzip2压缩文件，每个压缩块只应由一个Map器处理，并且最终应处理文件的所有块(我们所说的处理是指Map器中未压缩数据（来自编解码器）的实际利用率资料来源：https://issues.apache.org/jira/browse/hadoop-4012
3条答案
按热度按时间igsr9ssn1#
我在这里指的是压缩文件，它可以像bzip2一样拆分成表，bzip2是可拆分的。如果为bzip2的128mb块创建了一个输入分割，并且在map reduce处理过程中，当该块解压缩到200mb时，会发生什么情况？
agxfikkp2#
我的理解是：
假设1 gb压缩数据=2 gb解压缩数据，因此有16个数据块，bzip2知道块边界，因为bzip2文件在块之间提供同步标记。因此bzip2将数据分成16个块，并将数据发送给16个Map器。每个Map器得到的解压数据大小为1，输入拆分大小为128 mb(当然，如果数据不是128 mb的整数倍，则最后一个Map器将获得较少的数据）
gev0vcfq3#
总文件大小：1 gb
块大小：128 mb
分割数：8
为每个块创建一个分割将不起作用，因为不可能在gzip流中的任意点开始读取，因此map任务不可能独立于其他块读取其分割。gzip格式使用deflate存储压缩数据，deflate将数据存储为一系列压缩块。问题是，每个块的开头没有任何区别。因此，gzip不支持拆分。
mapreduce不会分割gzip文件，因为它知道输入是gzip压缩的（通过查看文件扩展名），并且gzip不支持分割。这将起作用，但以牺牲位置为代价：单个Map将处理8个hdfs块，其中大多数块不是Map的本地块。
请看一下：本文和小节名称：关于压缩和输入拆分的问题
编辑：（用于可拆分的解压缩）
bzip2是一种压缩/反压缩算法，它对数据块进行压缩，然后这些压缩块可以相互独立地进行解压缩。这确实是一个机会，我们可以并行处理文件块，而不是将一个bzip2压缩文件传递给一个Map器。这种处理的正确性标准是，对于bzip2压缩文件，每个压缩块只应由一个Map器处理，并且最终应处理文件的所有块(我们所说的处理是指Map器中未压缩数据（来自编解码器）的实际利用率
资料来源：https://issues.apache.org/jira/browse/hadoop-4012