hadoop中使用lzo压缩格式支持笔记

通常hadoop中的mapreduce作业都会产生大量都中间 文 件  ，当要处理当原始 数 据  非常大，并且在一定大map处理逻辑的情况下，这些中间文件会非常的大，hadoop mapreduce的中间文件是通过slave上hadoop-site.xml配置文件中的mapred.local.dir 配置选项来指定的。

  <property>
    <name>mapred.local.dir</name>
    <value>/disk1/mapred/local,/disk2/mapred/local</value>
  </property>

     虽然这个配置选项能够支持用逗号分隔的多个写入点，增加mapreduce程序的吞吐率，但是大量的中间文件，仍然是影响性能的一个因素，常常在 slave节点上用top查看进程性能或者iostat时，看到许多task进程的 iowait 非常的高，通常这样的作业的性能就是受到了类似的影响。由于mapreduce计算模型本身的特点，中间文件势必会有非常大的时候，解决 这个问题，对于性能的影响就至关重要。  
     几乎所有会产生大量map output的hadoop作业，都能够通过将中间文件用Lzo进行压缩来提升性能。尽管lzo会使得cpu的load有所增高，但是reduce在 shuffle阶段的disk IO通常都能节省不少时间，对job的性能有好处。
     当一个job需要产生大量的输出时，lzo压缩同时还可以在输出端提升job的性能。由于write操作通常默认都是要写3个副本，对每个文件的输出，就 能节省3倍的写入时间。
     为了能够在hadoop系统中使用lzo分布式压缩，需要做一些事情，具体怎么弄写到另一篇里去好了，不过首先要注意的是，要将提交端的jobconf中 的 mapred.compress.map.output参数设 置 成true。

  <property>
    <name> mapred.compress.map.output  </name>
    <value>true</value>
  </property>


测试对比：

     根据cloudera的测试数据，在disable lzo 压缩的情况下运行的wordcount作业会比使用lzo压缩的情况要长一些，在job中加入的FILE_BYTES_WRITTEN counter变量显示该数据从3.5GB上升到9.2GB，这表示，使用了lzo压缩的情况下，能够节省62% 的磁盘 IO，由于该实验是在集群上单独的跑这个job，没有跟其他job竞争计算资源，并且每个slave上的task/disk的比例都比较高，就是说并没有 多少task在竞争disk，所以性能的提升并不是非常明显。在disk相对紧缺，多个task竞争disk的情况下，能够节省约60%的磁盘io，从而 大大的提升job的效率。

Ref: http://blog.csdn.net/ae86_fc/article/details/5284230