HBase 0.94版本新特性、性能优化详解及使用（一）之数据压缩（DataBlock compression,HLog compression）

众所周知，HBase 0.94对性能做了很多优化，记录一下个人对其实现细节及如何更好应用的理解。


0.94引入了两个在HBase层的数据压缩：

一.DataBlock compression

1.1 作用
DataBlock compression指的是对HFile v2中的Data Block进行压缩，Data Block既存储在Disk上（HDFS中），也会存在于LRU Cache中，所以此压缩特性支持：
a)Disk、Cache上都不开启
b)Disk、Cache上都开启
c)Cache上开启,Disk上开启
但不支持
d)Cache上不开启,Disk开启

由此可见，此压缩特性的作用是：
a)节省LRU Cache的空间使用,提升cache命中率,优化读性能
b)节省Disk空间使用

当然，前者是主要目的，后者我们有对HFile的全局压缩算法,如LZO

1.2 副作用
目前，DataBlock压缩特性默认是关闭的，显然，其能优化某些业务场景，但盲然使用肯定会带来副作用：
a)Data Block解压缩，（如果一个Block（默认64KB）中包含很多KV，这个开销会比较大）
b)某些场景，压缩后数据更大

1.3 压缩算法
a)PREFIX
向Block中写入KV时，和前一条KV比较Key（这里的Key=Row+Family+Qualifier+Timestamp+Type，具体可见附件），对于相同的前缀byte， 则不再重复写入
根据KeyValue结构（见附件），某KV具体压缩后的内容：
*KeyLength压缩为1~5个字节（使用7-bit encoding，见附注）
*ValueLength压缩为1~5个字节
*和上个KV比较Key的内容，写入相同的前缀byte的长度，1~5个字节
*除相同前缀部分，剩余的Key内容
*Value内容

在最坏情况下，一条KV经过此算法压缩后会大小会增加3个字节

b)DIFF
向Block中写入KV时，会和前一条KV进行全面比较（如Key长度，value长度，Row，timestamp，type），对于相同的信息则不再写入，同时KV中的family内容只写一次（因为同个Block中，他们的family肯定是相同的）
某KV具体压缩后的内容：
*一个字节的flag（这个flag的作用后面解释）
*如果和上个KV的Key长度不一样，则写入1~5个字节的KeyLength
*如果和上个KV的Value长度不一样，则写入1~5个字节的KeyLength
*和上个KV比较Key的内容，写入相同的前缀byte的长度，1~5个字节（此比较不包含timestamp和type，而PREFIX算法中是包含的）
*剩余的Row内容(如果相同前缀比较少)
*如果是第一条KV,写入family内容
*剩余的qualifier内容
*写入1~8字节的timestamp或者与上个KV的timestamp的差(是原值还是写与上个KV的差，取决于哪个字节更小)
*如果和上个KV的type不一样，则写入1字节的type
*Value内容

在解压缩时，怎么判断和上个KV的Key长度是否一样，Value长度是否一样，写入的timestamp是原值还是差呢等等，这些都是通过最早写入的1个字节的flag来实现的，
这个字节中的8位bit，含义是：
第0位，如果为1，Key长度一样
第1位，如果为1，Value长度一样
第2位，如果为1，type一样
第3位，如果为1，则写入的timestamp是差值
第4，5,6位，这3位组合起来的值（能表示0~7），表示写入的timestamp或差值的字节数
第7位，如果为1，表示写入的timestamp或差值取反了（比如timestamp差值为负数，为了节省空间，会写入绝对值）

由此可见，DIFF算法是针对KeyValue的结构而量身设计的

c)FAST_DIFF
FAST_DIFF与DIFF的原理一样，只是减小了压缩量，提升了压缩速度，
某KV具体压缩后的内容：
*一个字节的flag
*如果和上个KV的Key长度不一样，则写入1~5个字节的KeyLength
*如果和上个KV的Value长度不一样，则写入1~5个字节的KeyLength
*和上个KV比较Key的内容，写入相同的前缀byte的长度，1~5个字节（此比较不包含timestamp和type，而PREFIX算法中是包含的）
*剩余的Row内容(如果相同前缀比较少)
*如果是第一条KV,写入family内容
*剩余的qualifier内容
*写入1~8字节的timestamp
*如果和上个KV的type不一样，则写入1字节的type
*如果和上个KV的Value内容不一样，则写入Value内容

1个字节的flag的8位bit含义：
第0,1,2位，这3位组合起来的值（能表示0~7），表示写入的timestamp的字节数
第3位，如果为1，Key长度一样
第4位，如果为1，Value长度一样
第5位，如果为1，type一样
第6位，如果为1，Value内容一样
第7位，闲置...

由此可见，相比DIFF，FAST_DIFF只是减少了对timestamp的压缩，但是增加了Value内容是否一样的判断，在某些情景（如value只是用来计数，或者value是一种类型选项值），那么可以大幅减少相同value内容的重复写入

1.4 应用场景及如何配置
上面介绍了3种压缩算法的原理，由此可简单分析下他们的应用场景：
1)PREFIX,这是一个比较公用的压缩算法，其压缩过程也比较简单快速，通用于存在相同的Row前缀的情景

2)DIFF, 相比于PREFIX，同样是需要应用在存在相同的Row前缀的情景，但其只写一份family内容，写入timestamp的差值，比较长度是否一样等特性，使其压缩幅度会更大，当然压缩的CPU开销也会稍大

3)FAST_DIFF,和DIFF类似，但是对于存在相同Value内容的场景,那肯定是使用它了

空口无凭，实验为据，具体场景，数据为准

如何配置？
Data Block的压缩算法选择是表中的一个列族属性，你可以通过api HColumnDescriptor#setDataBlockEncoding来开启或关闭或更改压缩算法，另外在开启压缩时，你可以通过HColumnDescriptor#setEncodeOnDisk决定是否在写入Disk时也采用压缩


二.HLog compression

2.1 为什么使用HLog压缩
为了保证数据安全性，每put一次，都会写入一条hlog记录，每一条hlog记录都会包含:table name、region name、row、family、qualifier等，如果数据写入集中在某表、某region乃至某row、某family，那么HLog的文件中就会存在大量重复的内容，压缩由此而生

2.2实现原理
HLog压缩采用的是词典压缩法，其写入一条log记录时的压缩行为：
*查找table是否在table词典中，如果不是，该table name写入到hlog 文件中，并加入到table词典中，对应一个short值；如果是，则hlog文件中写入一个short值，以代表该table name
*region family qualifier row，也是按照上述方法写入到hlog文件中
所以，写一个hlog文件时，会维护5个词典，即table词典、region词典、family词典、qualifier词典、row词典


2.3 作用
压缩的作用自然是减小hlog记录的写入大小，加快写hlog的速度，提升写性能；但是，个人认为，单条hlog记录压缩后减少几十或上百字节，对于其本身就不大而言，并不能提高多少HBase的写数据速度。
不过，其还存在着一个侧面作用，增加单个hlog文件的数据记录量，这会一定程度上提高memstore的内存使用率，从而提升全局的flush效率、compaction效率。

2.4如何配置及应用场景
Server端修改配置hbase.regionserver.wal.enablecompression为true（默认false）开启HLog压缩特性

应用场景：
*数据写入比较分散在各个表，各个region的，就不要考虑了
*数据写入比较集中的可以考虑开启，但测试数据为准，如果写性能没啥优化，那还是别尝这个鲜了，新特性免不了会有风险


以上只是个人见解，欢迎指正

附注：
7-bit 压缩法，针对Integer数据的一种压缩算法，可以将4个字节的Int型数据压缩为1~5个字节，数值越小，压缩后的字节数越少，所以对值小的Int型数据会有比较好的压缩效果，其具体压缩原理，简单介绍如下:
1.将一个Int型数据转换成32位；
2.0~7位，按原值写入
3.如果原值的第8位及以后存在1，则写入1，否则写入0，结束写入（即压缩为了1个字节）
4.如果没结束，则写入原值的第8~14位，如果原值的第15位及以后存在1，则写入1，否则写入0，结束写入
5...重复上述行为，直到写完

KV结构图：


HFileV2结构

评论

3 楼 leibnitz 2015-09-10  

怎么谈hlog配hfile图?

2 楼 bin_1715575332 2013-01-24  

楼主的系列文章不错，我想知道楼主哪里看到这些特性啊？尤其是这些算法，是发行版的信息？还是？

1 楼 david.org 2012-07-12  

支持，不过0.94似乎还有一些其他的特性，这里没看到呀