HBase实战：压缩与编码技术

问题导读

1.如何配置lzo?
2.如何测试lzo是否成功？
3.使用lzo后有什么缺点？






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)

file:///C:/Users/JIANGB~1/AppData/Local/Temp/enhtmlclip/lzo_diff_write.png
结论分析:
1）批量写操作，使用FAST_DIFF编码的开销最小，性能比不做任何配置(weibo-new)有24%提升。
2）使用diff，lzo双重配置，批量写操作有较大开销，并且压缩没有比单独使用LZO压缩有明显提升，所以不建议同时使用。

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

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