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

六月 9th, 2013 by klose | Posted under 互联网应用, 海量数据存储与处理.

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)配置:
<property>
<name>io.compression.codecs</name>
<value>com.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec</value>
</property>
<property>
<name>io.compression.codec.lzo.class</name>
<value>com.hadoop.compression.lzo.LzoCodec</value>
</property>
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_ICTBinospace个人技术博客原创,原文链接为http://www.binospace.com/index.php/hbase-combat-series-1-compression-and-coding-techniques/ ,未经允许,不得在网上转载。

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

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





Tags: , , ,

Do you have any comments on HBase实战系列1—压缩与编码技术 ?