Hadoop Compression学习及实践应用

Hadoop Compression学习及实践应用

       Hadoop的Compressor解压缩模块是Hadoop Common IO模块中一个重要模块。使用压缩能帮助我们减少储存文件所需要的磁盘空间，并加速数据在网络和磁盘上的传输。在Hadoop系统中目前支持多种压缩算法，下面我们先来看看几种常用的压缩算法比较。

1. Hadoop压缩算法比较 压缩格式工具算法扩展名native可分割性是否hadoop自带DEFLATE无DEFLATE.deflate是否是GZIPgzipDEFLATE.gz是否是BZIP2bzip2bzip2.bz2否是是LZOlzopLZO.lzo是是否SNAPPY无Snappy.snappy是否否

部分比较项说明

是否hadoop自带：如果压缩格式不是hadoop自带，则需要我们额外安装，比如常用的snappy压缩。

native: 是否支持Hadoop native库。Hadoop是使用Java语言开发的，鉴于性能问题以及某些Java类库的缺失，对于某些组件，hadoop引入了native库（即本地库）的概念提供了自己的本地实现。这些组件保存在hadoop的一个独立的动态链接的库里（这个库在*nix平台上叫libhadoop.so）。通过使用本地库，hadoop可以更高效的执行某些 *** 作。

默认情况下，Hadoop会自动在本地库路径（java.library.path）下查询并加载合适的本地库实现，我们可以通过设置属性io.native.lib.available为false禁用本地库，此时内建的Java实现将被使用。

想要验证各种算法的本地库情况，可以执行命令 hadoop checknative 进行查看。

可分割性：对应的压缩算法是否可以搜索数据流的任意位置并进一步往下读取数据。可否分割，对于我们执行大文件的并行处理是一个要重点关注的点。怎么理解呢？举个例子，我们有一个经过gzip压缩后大小为1G的HDFS文件，那么HDFS会将这个文件存储成多个数据块。由于gzip不具备分割性，只有将该文件的所有HDFS的数据块都传输到一个map/task任务来进行处理，但是大多数数据块都没有存储在这个任务的节点上，所以需要跨节点传输，且不能并行处理，因此运行的时间可能变得很长。

2. 压缩性能测试

      上文对hadoop中不同压缩算法，从可分割性、是否native等方面进行了综合比较。但在实际应用中，我们还要从另外两个重要的指标考虑来决定我们最后采用哪种算法，这两个指标就是压缩比和压缩速率。笔者曾经做过hadoop的多种压缩算法的性能测试，下面贴出测试结果让大家对不同的压缩算法的压缩比和压缩速度有一个感观性的认识。

 snappyLz4ZlibBzip2原始大小(MB)1024102410241024压缩后(MB)427553288212压缩比42%54%28%21%压缩速度(s)331368299306

       从结果中我们看出来，测试中的4中压缩算法，压缩比： LZ4 < Snappy < Zlib < Bzip2，在压缩速度这个方面比较：LZ4 < Snappy < BZIP2 < Zlib