HBase实战系列1—压缩与编码技术

1、hbase压缩与编码的配置 安装LZO 解决方案： 1）apt-get install liblzo2-dev 2)hadoop-gpl-compression-0.2.0-dev.jar 放入classpath 把libgpl下的共享库文件放入/opt/hbase/hbase/lib/native/Linux-amd64-64/ libgplcompression.a libgplcompression.la

1、hbase压缩与编码的配置

安装LZO

解决方案：
1）apt-get install liblzo2-dev
2)hadoop-gpl-compression-0.2.0-dev.jar　放入classpath
把libgpl下的共享库文件放入/opt/hbase/hbase/lib/native/Linux-amd64-64/
libgplcompression.a libgplcompression.la libgplcompression.so libgplcompression.so.0 libgplcompression.so.0.0.0
3)配置：

io.compression.codecs
com.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec


io.compression.codec.lzo.class
com.hadoop.compression.lzo.LzoCodec

4）测试：
hbase org.apache.hadoop.hbase.util.CompressionTest hdfs:///user.dat lzo

创建表格时，针对ColumnFamily设置压缩和编码方式。

HColumnDescriptor.setCompressionType(Compression.Algorithm.NONE);

HColumnDescriptor.setDataBlockEncoding(DataBlockEncoding.NONE);

使用FAST_DIFF 与 LZO之后的压缩情况：

hbase@GS-WDE-SEV0151:/opt/hbase/hbase$ hadoop fs -dus /hbase-weibo/weibo_test
hdfs://hbase-hdfs.goso.cn:9000/hbase-weibo/weibo_test???? 1021877013
hbase@GS-WDE-SEV0151:/opt/hbase/hbase$ hadoop fs -dus /hbase-weibo/weibo_lzo
hdfs://hbase-hdfs.goso.cn:9000/hbase-weibo/weibo_lzo???? 1179175365
hbase@GS-WDE-SEV0151:/opt/hbase/ops$ hadoop fs -dus /hbase-weibo/weibo_diff
hdfs://hbase-hdfs.goso.cn:9000/hbase-weibo/weibo_diff???? 2754679243

hbase@GS-WDE-SEV0151:/opt/hbase/hbase$ hadoop fs -dus /hbase-weibo/weibo-new
hdfs://hbase-hdfs.goso.cn:9000/hbase-weibo/weibo-new???? 5270708315

忽略数据中出现的Delete的数据、多个版本、以及超时的数据，压缩比达到1：5。

单独使用LZO的配置的压缩可接近也接近5：1的压缩比。

单独使用FAST_DIFF编码可以接近5：2的压缩比。

HBase操作过程：

Finish DataBlock–>Encoding DataBlock(FAST_DIFF\PREFIX\PREFIX_TRIE\DIFF)—>Compression DataBlock(LZO\GZ) —>Flush到磁盘。

如果Encoding和Compression的方式都设置NONE，中间的过程即可忽略。

2、相关测试

weibo-new使用的NONE、NONE

weibo_test使用的LZO、FAST_DIFF

weibo_diff使用了FAST_DIFF

weibo_lzo使用了LZO压缩

1、测试 扫描的效率:

结果分析：

使用LZO压缩或者FAST_DIFF的编码，扫描时造成大概一倍的开销

这个原因在于：在当前存储容量下，网络IO不是瓶颈，使用基本配置weibo-new吞吐量达到了45.68MB/s，而使用LZO压缩，显然经过一次或者两次解码之后，消耗了一些CPU时间片，从而耗时较长。

2、随机读的效率，采用单条随机的办法

首先scan出所有的Row，然后，使用shuf -n1000000 /tmp/row 随机取出1000000个row，然后按照单线程随机读的方式获取。

ps：每个Record有3个ColumnFamily，共有31个Column。

结果分析：

1）LZO解压缩的效率低于反解码的效率，在不以存储代价为第一考虑的情况下，优先选择FAST_DIFF编码方式。

2）LZO随机读会引起 hbase内部更多的读开销。下图在读取同样数据过程中，通过对于RegionServer上scanner采集到的读取个数，lzo明显代价较大。

3）在数据量不超过1T，并且HBase集群内存可以完全cover住整个Cache的情况下，可以不做压缩或者编码的设置，一般带有ROWCOL的bloomfilter基本就可以达到系统最佳的状态。如果数据远远大于Cache总量的10倍以上，优先使用编码方案(FAST_DIFF或者0.96引入的PREFIX_TRIE)

3、随机写的效率，采用批量写。批量个数为100

lz vs diff 写操作的集群吞吐图(两者开始执行的时间起点不同， 绿线代表weibo_diff、红线是weibo_lzo)

?

结论分析:

1）批量写操作，使用FAST_DIFF编码的开销最小，性能比不做任何配置(weibo-new)有24%提升。

2）使用diff，lzo双重配置，批量写操作有较大开销，并且压缩没有比单独使用LZO压缩有明显提升，所以不建议同时使用。

3、总体结论分析

1）在column较多、并且value较短的情况下，使用FAST_DIFF可以获得较好的压缩空间以及较优的读写延迟。推荐使用。

2）在对于存储空间比较紧缺的应用，单独使用LZO压缩，可以在牺牲一些随机读的前提下获得较高的空间压缩率(5：1)。

备注：本系列文章属于Binos_ICT在Binospace个人技术博客原创，原文链接为http://www.binospace.com/index.php/hbase-combat-series-1-compression-and-coding-techniques/?，未经允许，不得在网上转载。

From Binospace, post HBase实战系列1—压缩与编码技术

文章的脚注信息由WordPress的wp-posturl插件自动生成