Hadoop压缩之MapReduce中使用压缩

1.压缩和输入分片

Hadoop中文件是以块的形式存储在各个DataNode节点中，假如有一个文件A要做为输入数据，给MapReduce处理，系统要做的，首先从NameNode中找到文件A存储在哪些DataNode中，然后，在这些DataNode中，找到相应的数据块，作为一个单独的数据分块，作为map任务的输入，这就是mapreduce处理的数据的粗略过程！但是，我们都知道，对于一些大型的数据，压缩是很有用的，不仅能够节省存储空间，而且还能够加快传输速率。把文件压缩后再存入数据节点中，这个很常见。那么压缩的数据作为MapReduce的输入数据处理，这个可以不？

假如现在有一个压缩文件B，存储在16个数据块中，但是，将每个数据块作为单独的输入分片是无法实现工作的，因为无法实现从gzip压缩数据流的任意位置读取数据，所以，让多个map任务多里运行是无法实现的。在这种情况下，MapReduce不会去切分gzip压缩文件，而是由一个map任务去处理所有的数据块。因为它知道输入的是gzip（文件扩展名）且不支持切分。那么这么做，带来的缺点很明显了：首先是牺牲了数据的本地性，一个map处理16个数据块，而其中大多数块并没有存储在执行map任务的节点。其次，map任务少了，作业的粒度就较大，运行的时间可能会更长！

对于大文件来说，不应该使用不支持切分整个文件的压缩格式，否则将失去数据的本地性，进而造成MapReduce应用效率低下！

2.数据本地性

Hadoop中有几样东西比较珍贵，不是存储硬盘，不是cpu，而是内存和带宽！为什么是内存和带宽呢？NameNode中存储的是目录元数据，不懂的可以查看我的博客《Hadoop中的namenode、辅助namenode、jobtracker、datenode等作用》,http://blog.sina.com.cn/s/blog_c09822a40102v9fp.html，而NameNode把这些存放在内存当中，所以，内存的大小也决定着DataNode中存放的数据多少，就算DataNode再多，NameNode的内存上不去，也存储不了多少数据。还有网络带宽，带宽很贵，数据本地化就能够节省网络带宽。因为我们把数据是在本地处理的。处理完后，然后，再把处理后的结果，通过网络传送个reduce所在的节点。而上面的经过gzip压缩的数据，是把数据块全部传送到map所在的节点，就丧失了数据本地化的优势，占用网络带宽。尤其是对于大点的数据！统一时间要占用多少带宽。

3.在MapReduce中使用压缩

如果想对MapReduce作业的输出进行压缩操作，应在作业配置过程中，将mapred.output.compress属性设置为true和mapred.output.compression.codec属性设置为打算使用的压缩codec的类名。

由于map任务的输出需要写到磁盘并通过网络传输到reducer节点，所以如果使用LZO这样的快速压缩方式，是可以获得性能提升的，因为需要传输的数据减少了。

属性名称	类型	默认值	描述
mapred.compress.map.out	boolean	false	对map任务输出进行压缩
mapred.map.output.compression.codec	Class	org.apache.hadoop.io.compress.DefaultCodec	map输出所用的压缩codec