Hadoop2.4 支持snappy

共计 5669 个字符，预计需要花费 15 分钟才能阅读完成。

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

Failed with exception java.io.IOException:java.lang.RuntimeException:
native snappy library not available: this version of libhadoop was built without snappy support

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

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

参考地址：http://www.linuxidc.com/Linux/2014-05/101230.htm

目前在 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，如果是 RCFile、Sequence Files 等，本身就支持 split，经过压缩之后一样是支持 split 的。

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

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

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

参考地址：http://www.linuxidc.com/Linux/2014-12/110858.htm

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

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

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

mvn clean package -Pdist,native -DskipTests -Drequire.snappy

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

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

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

<property>
    <name>mapreduce.map.output.compress</name>
    <value>true</value>
    <final>true</final>
  </property>
  <property>
    <name>mapreduce.map.output.compress.codec</name>
    <value>org.apache.hadoop.io.compress.SnappyCodec</value>
    <final>true</final>
  </property>

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

hadoop jar hadoop-mapreduce-examples-2.4.0.jar wordcount -files hdfs://ns1/test/snappy/libhadoop.so,hdfs://ns1/test/snappy/libsnappy.so.1  /test/missdisk/ /test/wordcount

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

hive >add file libhadoop.so;
hive >add file libsnappy.so.1;
hive >select count(*) from ct_tmp_objrec;

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

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

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

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

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

CREATE EXTERNAL TABLE `snappy_test`(
  `from_id` string,
  `to_id` string,
  `mention_type` bigint,
  `repost_flag` bigint,
  `weight` double,
  `confidence` double,
  `from_uid` string,
  `to_object_label` string,
  `count` bigint,
  `last_modified` string,
  `time` string,
  `mblog_spam` bigint,
  `mblog_simhash` string,
  `mblog_dupnum` bigint,
  `mblog_attribute` bigint,
  `user_quality` bigint,
  `user_type` bigint,
  `old_weight` double,
  `obj_pos` bigint,
  `quality` bigint)
ROW FORMAT SERDE
  ‘org.apache.hadoop.hive.serde2.columnar.LazyBinaryColumnarSerDe’
STORED AS INPUTFORMAT
  ‘org.apache.hadoop.hive.ql.io.RCFileInputFormat’
OUTPUTFORMAT
  ‘org.apache.hadoop.hive.ql.io.RCFileOutputFormat’
LOCATION
  ‘hdfs://ns1/user/liangjun/warehouse/tables/snappy_test’

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

hive >add file libhadoop.so;
hive >add file libsnappy.so.1;
hive >set hive.exec.compress.output=true;
hive >set mapred.output.compression.codec=org.apache.hadoop.io.compress.SnappyCodec;
hive >INSERT OVERWRITE table snappy_test select from_id,to_id,mention_type,repost_flag,weight,confidence,from_uid,to_object_label,count,last_modified,time,mblog_spam,mblog_simhash,mblog_dupnum,mblog_attribute,user_quality,user_type,old_weight,obj_pos,quality from ct_tmp_objrec;

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

hive >add file libhadoop.so;
hive >add file libsnappy.so.1;
hive >select count(*) from snappy_test;

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

Hadoop2.5.2 新特性   http://www.linuxidc.com/Linux/2014-11/109814.htm

CentOS 安装和配置 Hadoop2.2.0  http://www.linuxidc.com/Linux/2014-01/94685.htm

Ubuntu 13.04 上搭建 Hadoop 环境 http://www.linuxidc.com/Linux/2013-06/86106.htm

Ubuntu 12.10 +Hadoop 1.2.1 版本集群配置 http://www.linuxidc.com/Linux/2013-09/90600.htm

Ubuntu 上搭建 Hadoop 环境（单机模式 + 伪分布模式）http://www.linuxidc.com/Linux/2013-01/77681.htm

Ubuntu 下 Hadoop 环境的配置 http://www.linuxidc.com/Linux/2012-11/74539.htm

单机版搭建 Hadoop 环境图文教程详解 http://www.linuxidc.com/Linux/2012-02/53927.htm

搭建 Hadoop 环境（在 Winodws 环境下用虚拟机虚拟两个 Ubuntu 系统进行搭建）http://www.linuxidc.com/Linux/2011-12/48894.htm

更多 Hadoop 相关信息见 Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13