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)配置:
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插件自动生成
Copyright © 2008
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
)
上一篇: JS封装运动框架的一种写法
下一篇: eclipse建包有什么用?