hadoop - Hadoop MR：更好的压缩输入文件或原始文件？

除非您正在进行开发，并且需要经常将数据从HDFS读取到本地文件系统以进行处理，否则以压缩格式输入文件是有意义的。

压缩格式提供了显着的优势。除非您另外设置，否则数据已在Hadoop集群中复制。复制数据是良好的冗余，但消耗更多空间。如果所有数据的复制系数均为3，那么您将消耗3倍于存储数据所需的容量。

对日志数据等文本数据进行压缩非常有效，因为它可以产生高压缩率。这也是您在Hadoop集群中经常发现的那种数据。

我没有基准测试，但我没有看到对我们拥有的合适大小的群集和数据有任何重大损失。

然而，暂时选择LZO而不是gzip。

请参阅：LZO compression and it's significance over gzip

Gzip压缩效果优于LZO。 LZO在压缩和解压缩方面更快。有可能拆分Lzo文件，可拆分Gzip不可用，但我已经看到了相同的Jira任务。（也适用于bzip2）

让我们说明压缩的理由与不压缩的理由。

对于：

a）数据主要是存储的，而不是经常处理的。这是通常的DWH场景。在这种情况下，节省空间可能比处理开销更重要 b）压缩系数非常高，因此我们节省了大量的IO。
c）减压速度非常快（如Snappy），我们有一些收益，价格很低 d）数据已经压缩

<强>反对：

a）压缩数据不可拆分。必须注意的是，许多现代格式都是使用块级压缩构建的，以实现文件的拆分和其他部分处理。 b）在集群中创建数据，压缩需要很长时间。必须注意的是，压缩通常比CPU密集更多，然后解压缩。
c）数据几乎没有冗余，压缩几乎没有增益。

1）压缩输入文件如果输入文件被压缩，则从HDFS读入的字节减少，这意味着读取数据的时间减少。这段时间的保护有利于执行作业。

如果输入文件被压缩，它们将在MapReduce读取时自动解压缩，使用文件扩展名确定要使用的编解码器。例如，以.gz结尾的文件可以标识为gzip压缩文件，因此可以使用GzipCodec进行读取。

2）压缩输出文件我们经常需要将输出存储为历史文件。如果每天的输出量很大，并且我们经常需要存储历史结果以供将来使用，那么这些累积的结果将占用大量的HDFS空间。但是，这些历史文件可能不会经常使用，从而导致浪费HDFS空间。因此，有必要在存储在HDFS上之前压缩输出。

3）压缩地图输出即使您的MapReduce应用程序读取和写入未压缩的数据，它也可能受益于压缩映射阶段的中间输出。由于地图输出被写入磁盘并通过网络传输到reducer节点，因此通过使用LZO或Snappy等快速压缩器，您可以获得性能提升，因为传输的数据量会减少。 2.通用输入格式

gzip的： gzip自然是由Hadoop支持的。 gzip基于DEFLATE算法，它是LZ77和霍夫曼编码的组合。

的bzip2： bzip2是一款免费提供的，无专利（见下文）的高质量数据压缩器。它通常将文件压缩到最佳可用技术（统计压缩器的PPM系列）的10％到15％之内，同时压缩速度提高一倍，解压缩速度提高六倍。

LZO： LZO压缩格式由许多较小（~256K）的压缩数据块组成，允许作业沿块边界分割。此外，它的设计考虑了速度：它的解压缩速度是gzip的两倍，这意味着它的速度足以跟上硬盘读取速度。它的压缩效果不如gzip - 期望文件比gzip压缩版大50％。但这仍然是没有任何压缩的文件大小的20-50％，这意味着IO绑定作业完成地图阶段的速度提高了大约四倍。

的Snappy： Snappy是一个压缩/解压缩库。它的目标不是最大压缩，也不与任何其他压缩库兼容;相反，它的目标是非常高的速度和合理的压缩。例如，与最快的zlib模式相比，对于大多数输入，Snappy的速度要快一个数量级，但生成的压缩文件大小要高20％到100％。在64位模式的Core i7处理器的单核上，Snappy压缩大约250 MB /秒或更高，并以大约500 MB /秒或更高的速度进行解压缩。 Snappy广泛应用于Google内部，从BigTable和MapReduce到我们的内部RPC系统。

一些权衡：所有压缩算法都表现出空间/时间权衡：更快的压缩和解压缩速度通常以节省更少的空间为代价。上表中列出的工具通常通过提供九种不同的选项来控制压缩时的这种权衡：-1表示优化速度，-9表示优化空间。

不同的工具具有非常不同的压缩特性。 Gzip是一种通用压缩器，位于空间/时间折衷的中间。 Bzip2比gzip压缩效率更高，但速度更慢。 Bzip2的解压缩速度比压缩速度快，但它仍然比其他格式慢。另一方面，LZO和Snappy都优化速度，比gzip快一个数量级，但压缩效率较低。对于减压，Snappy也明显快于LZO。 3.有关压缩和输入拆分的问题在考虑如何压缩将由MapReduce处理的数据时，了解压缩格式是否支持拆分非常重要。考虑存储在HDFS中的未压缩文件，其大小为1 GB。如果HDFS块大小为64 MB，则文件将存储为16个块，使用此文件作为输入的MapReduce作业将创建16个输入拆分，每个拆分作为输入单独处理到单独的地图任务。

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

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

如果我们假设示例中的文件是LZO文件，我们就会遇到同样的问题，因为底层压缩格式没有为读者提供与流同步的方法。但是，可以使用Hadoop LZO库附带的索引器工具预处理LZO文件。该工具构建了一个分割点索引，有效地在使用适当的MapReduce输入格式时将它们分开。

另一方面，bzip2文件确实在块之间提供了同步标记（pi的48位近似值），因此它支持分割。 4. IO绑定和CPU绑定在HDFS中存储压缩数据可以使您的硬件分配更进一步，因为压缩数据通常是原始数据大小的25％。此外，由于MapReduce作业几乎总是受IO限制，因此存储压缩数据意味着要做的总体IO较少，这意味着作业运行得更快。然而，有两点需要注意：一些压缩格式不能拆分用于并行处理，而另一些压缩格式在解压缩时足够慢，以致作业变得受CPU限制，从而消除了IO上的收益。

gzip压缩格式说明了第一个警告。想象一下，你有一个1.1 GB的gzip文件，你的集群有一个128 MB的块大小。此文件将拆分为9个大小约为128 MB的块。为了在MapReduce作业中并行处理这些，不同的映射器将负责每个块。但这意味着第二个映射器将从文件大约128MB的任意字节开始。 gzip用于解压缩输入的上下文字典此时将为空，这意味着gzip解压缩程序将无法正确解释字节。结果是Hadoop中的大型gzip文件需要由单个映射器处理，这违背了并行性的目的。

Bzip2压缩格式说明了作业受CPU限制的第二个警告。 Bzip2文件压缩得很好，甚至可以拆分，但是解压缩算法很慢，无法跟上Hadoop作业中常见的流式磁盘读取。虽然Bzip2压缩具有一定的优势，因为它节省了存储空间，但现在运行的作业会花费时间等待CPU完成解压缩数据，这会减慢它们的速度并抵消其他增益。 5.总结压缩的原因： a）数据主要是存储的，而不是经常处理的。这是通常的DWH场景。在这种情况下，节省空间可能比处理开销更重要 b）压缩系数非常高，因此我们节省了大量的IO。 c）减压速度非常快（如Snappy），因此我们可以获得一些收益并且价格不高 d）数据已经压缩

不压缩的原因 a）压缩数据不可拆分。必须注意的是，许多现代格式都是使用块级压缩构建的，以实现文件的拆分和其他部分处理。 b）在集群中创建数据，压缩需要很长时间。必须注意的是，压缩通常比CPU密集更多，然后解压缩。 c）数据几乎没有冗余，压缩几乎没有增益。

Hadoop MR：更好的压缩输入文件或原始文件？

3 个答案: