[Binospace] 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 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、测试 扫描的效率:

	个数	耗时
weibo_test	2314054	3m49.661s
weibo-new	2314054	1m55.349s
weibo_lzo	2314054	3m24.378s
weibo_diff	2314054	4m41.792s

 

结果分析：

使用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。

 

	个数	耗时
weibo_test	100,0000	122min12s, 平均7.3ms/Record
weibo-new	100,0000	68min40s， 平均3.99ms/Record
weibo_lzo	100,0000	83m26.539s， 平均5.00ms/Record
weibo_diff	100,0000	58m5.915s,  平均3.48ms/Record

 

结果分析：

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

	个数	耗时
weibo_test	8640447	571670ms， 66µs/Put, 6.61ms/batch
weibo-new	8640447	329694ms，38.12µs/Put,  3.81ms/batch
weibo_lzo	8640447	295770ms, 34.23µs/Put, 3.42ms/batch
weibo_diff	8640447	250399ms, 28.97µs/Put,2.90ms/batch

 

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插件自动生成