本文共 5258 字，大约阅读时间需要 17 分钟。

转 ： https://blog.csdn.net/bigdatahappy/article/details/42087317  

我们hadoop2,4集群默认不支持snappy压缩，但是最近有业务方说他们的部分数据是snappy压缩的（这部分数据由另外一个集群提供给他们时就是snappy压缩格式的）想迁移到到我们集群上面来进行计算，但是直接运行时报错：

根据报错信息显示snappy本地库不可用，同时似乎在编译libhadoop的时候需要特别指定以支持snappy，这一点不同于hadoop1.0，hadoop1.0只需要将snappy的本地库文件往指定目录一拷贝就行，不需要重新编译libhadoop本地库文件。

由于snappy压缩算法压缩比不是很高，虽然在解压缩效率上又一点优势，所以我们集群默认没有支持snappy，我们集群的数据要求是RCFile+Gzip，以下是几种压缩格式在hadoop中的优缺点对比：

参考地址：

目前在Hadoop中用得比较多的有lzo，gzip，snappy，bzip2这4种压缩格式，笔者根据实践经验介绍一下这4种压缩格式的优缺点和应用场景，以便大家在实践中根据实际情况选择不同的压缩格式。

1、gzip压缩

优点：压缩率比较高，而且压缩/解压速度也比较快；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分linux系统都自带gzip命令，使用方便。

缺点：不支持split。

应用场景：当每个文件压缩之后在130M以内的（1个块大小内），都可以考虑用gzip压缩格式。譬如说一天或者一个小时的日志压缩成一个gzip文件，运行mapreduce程序的时候通过多个gzip文件达到并发。hive程序，streaming程序，和java写的mapreduce程序完全和文本处理一样，压缩之后原来的程序不需要做任何修改。

2、lzo压缩

优点：压缩/解压速度也比较快，合理的压缩率；支持split，是hadoop中最流行的压缩格式；支持hadoop native库；可以在linux系统下安装lzop命令，使用方便。

缺点：压缩率比gzip要低一些；hadoop本身不支持，需要安装；在应用中对lzo格式的文件需要做一些特殊处理（为了支持split需要建索引，还需要指定inputformat为lzo格式）。

应用场景：一个很大的文本文件，压缩之后还大于200M以上的可以考虑，而且单个文件越大，lzo优点越越明显。

3、snappy压缩

优点：高速压缩速度和合理的压缩率；支持hadoop native库。

缺点：不支持split；压缩率比gzip要低；hadoop本身不支持，需要安装；linux系统下没有对应的命令。

应用场景：当mapreduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；或者作为一个mapreduce作业的输出和另外一个mapreduce作业的输入。

4、bzip2压缩

优点：支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便。

缺点：压缩/解压速度慢；不支持native。

应用场景：适合对速度要求不高，但需要较高的压缩率的时候，可以作为mapreduce作业的输出格式；或者输出之后的数据比较大，处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持split，而且兼容之前的应用程序（即应用程序不需要修改）的情况。

最后用一个表格比较上述4种压缩格式的特征（优缺点）：

4种压缩格式的特征的比较

压缩格式	split	native	压缩率	速度	是否hadoop自带	linux命令	换成压缩格式后，原来的应用程序是否要修改
gzip	否	是	很高	比较快	是，直接使用	有	和文本处理一样，不需要修改
lzo	是	是	比较高	很快	否，需要安装	有	需要建索引，还需要指定输入格式
snappy	否	是	比较高	很快	否，需要安装	没有	和文本处理一样，不需要修改
bzip2	是	否	最高	慢	是，直接使用	有	和文本处理一样，不需要修改

注意：以上几种压缩算法都是在压缩普通文本的前提下来说的是否支持split，如果是RCFile、Sequence Files等，本身就支持split，经过压缩之后一样是支持split的。

综上，我们hadoop2.4集群要求RCFile+gzip是有一定道理的，首先RCFile格式的文件支持按列存储，同时支持split，而gzip的压缩率比较高，而且压缩/解压速度也比较快，所以RCFile格式的文件经过gzip压缩后既能保证文件能split，还能保证很高压缩/解压速度和压缩比。

以上说了半天题外话，以下来进入主题来说一下怎样在不替换集群本地库文件，不重启hadoop进程，也即在hadoop的客户端就能解决支持snappy压缩的问题的方法：

1、编译snappy本地库，编译之后snappy本地库文件地址：/data0/liangjun/snappy/

参考地址：

2、重新编译libhadoop.so文件，编译时通过-Dsnappy.prefix指定snappy本地库文件地址编译：

 mvn clean package -Pdist -Dtar -Pnative -Dsnappy.prefix=/data0/liangjun/snappy/ -DskipTests

注：我测试了一下，通过-Drequire.snappy编译的libhadoop.so也是可行的：

3、执行完上面两步之后，最终只需要拿到libhadoop.so和libsnappy.so.1两个文件（只需要这两个文件，其他得经过我测试都过滤掉了），以下是MapReduce和hive的使用snappy压缩的例子：

(1)、MapReduce，将编译好的本地库加到DistributedCache中就可以：

在测试环境的客户端mapred-site.xml文件添加以下两个配置项以支持map端数据的时候按snappy压缩：

上传libhadoop.so和libhadoop.so到指定hdfs目录/test/snappy/下，通过-files指定文件：

(2)、hive，通过add file指定文件：

表ct_tmp_objrec的数据是文本文件经过snappy压缩的数据，ct_tmp_objrec存储格式是普通的文本格式。

运行hql之后，发现snappy格式的数据能够正常处理计算了，但是200+M的文件只能由一个map任务处理，既不支持split。

==========================================================

以下部分是就RCFile+snappy的数据是否支持split的测试：

1、创建测试表snappy_test，该表和前面的ct_tmp_objrec列完全相同，只是hive表存储格式换成了RCFile：

2、将ct_tmp_objrec中plain text+snappy压缩的数据转成snappy_test中RCFile+gzip压缩的数据：

3、查询snappy_test中的RCFile+snappy数据看是否能split

运行hql之后，发现RCFile+snappy的数据能够正常处理计算，同时200+M的文件split成两个map任务处理，测试完成。

参考地址：