HBase集群配置Snappy压缩算法

Posted 2023-04-17

参考技术A      在生产环境搭建了Hadoop HA集群（Hadoop2.7.7+HBase1.4.10）。根据官方文档，Snappy 压缩算法在Hadoop 1.0.2中即可使用。

1、首先通过命令查看Hadoop是否支持Snappy。

2、已知Hadoop支持Snappy算法，配置hbase-env.sh，使得HBase能够支持Snappy算法。

3、在HBase中新建压缩算法为Snappy的表。

4、至此，HBase配置Snappy成功。

hadoop2.4 支持snappy

       我们hadoop2,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	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的client就能解决支持snappy压缩的问题的方法：

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

參考地址：http://www.tuicool.com/articles/yiiiY3R

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中就能够：

在測试环境的clientmapred-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任务处理。測试完毕。

參考地址：

http://blog.cloudera.com/blog/2011/09/snappy-and-hadoop/

http://blog.csdn.net/czw698/article/details/38387657

http://www.linuxidc.com/Linux/2014-05/101230.htm

http://book.2cto.com/201305/21922.html

http://blog.csdn.net/czw698/article/details/38387657

http://blog.csdn.net/czw698/article/details/38398399

http://www.tuicool.com/articles/yiiiY3R