HBase(八): 表结构设计优化

在 HBase(六): HBase体系结构剖析（上) 介绍过，Hbase创建表时，只需指定表名和至少一个列族，基于HBase表结构的设计优化主要是基于列族级别的属性配置，如下图：

目录：

BLOOMFILTER
BLOCKSIZE
IN_MEMORY
COMPRESSION/ENCODING
VERSIONS
TTL

BLOOMFILTER：

Bloom Filter是由Bloom在1970年提出的一种多哈希函数映射的快速查找算法。通常应用在一些需要快速判断某个元素是否属于集合，但是并不严格要求100%正确的场合
bloom filter的数据存在StoreFile的meta中，一旦写入无法更新，因为StoreFile是不可变的。Bloomfilter是一个列族（cf）级别的配置属性，如果在表中设置了Bloomfilter，那么HBase会在生成StoreFile时包含一份bloomfilter结构的数据，称其为MetaBlock；MetaBlock与DataBlock（真实的KeyValue数据）一起由LRUBlockCache维护。所以，开启bloomfilter会有一定的存储及内存cache开销
对于已经存在的表，可以使用alter表的方式修改表结构，但这种修改对于之前的数据不会生效，只针对修改后插入的数据
包含三种类型：NONE、ROW、ROWCOL

1. ROW：根据KeyValue中的row来过滤storefile，举例如下：假设有2个storefile文件sf1和sf2
  - sf1包含kv1（r1 cf:q1 v）、kv2（r2 cf:q1 v）
  - sf2包含kv3（r3 cf:q1 v）、kv4（r4 cf:q1 v）
  - 如果设置了CF属性中的bloomfilter为ROW，那么get(r1)时就会过滤sf2，get(r3)就会过滤sf1
2. ROWCOL：根据KeyValue中的row+qualifier来过滤storefile
  - 如上例：若设置了CF属性中的bloomfilter为ROW，无论get(r1,q1)还是get(r1,q2)，都会读取sf1+sf2；
  - 而如果设置了CF属性中的bloomfilter为ROWCOL，那么get(r1,q1)就会过滤sf2，get(r1,q2)就会过滤sf1

region下的storefile数目越多，bloomfilter的效果越好
region下的storefile数目越少，HBase读性能越好

BLOCKSIZE：

从上图可发现，默认的BlockSize 为 65536B （64KB），在 HBase(七): HBase体系结构剖析（下) 介绍HBase读原理，如果在blaock cache 、memostore中都没查到符合条件的数据，则循环遍历 storeFile 文件，而hbase读取磁盘文件是按其基本I/O单元(即 hbase block)读数据的，因此HFile块大小是影响性能的重要参数
参见Get\Scan场景下测试不同BlockSize大小（16K，64K，128K）对性能的影响，如下图：对比结果参考：http://hbasefly.com/2016/07/02/hbase-pracise-cfsetting/
可见，如果业务请求以Get请求为主，可以考虑将块大小设置较小；如果以Scan请求为主，可以将块大小调大；默认的64K块大小是在Scan和Get之间取得的一个平衡

平均键值对规划，如下

[root@HDP0 bin]# hbase hfile -m -f /apps/hbase/data/data/default/PerTest/7685e6c39d1394d94e26cf5ddafb7f9f/d/3ef195ca65044eca93cfa147414b56c2SLF4J: Class path contains multiple SLF4J bindings.SLF4J: Found binding in [jar:file:/usr/hdp/2.4.2.0-258/hadoop/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]SLF4J: Found binding in [jar:file:/usr/hdp/2.4.2.0-258/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]2016-09-11 12:54:40,514 INFO [main] hfile.CacheConfig: CacheConfig:disabledBlock index size as per heapsize: 6520reader=/apps/hbase/data/data/default/PerTest/7685e6c39d1394d94e26cf5ddafb7f9f/d/3ef195ca65044eca93cfa147414b56c2,  compression=none,  cacheConf=CacheConfig:disabled,  firstKey=00123ed7-5af8-49b1-bd13-9e086a5bd5f2/d:Action/1471406616120/Put,  lastKey=fffbc8f7-55f2-4c49-804f-444f6ccbc903/d:UserID/1471406614464/Put,  avgKeyLen=55,  avgValueLen=10,  entries=54180,  length=4070738

从上面输出的信息可以看出，该HFile的平均键值对规模为55B + 10B = 65B，相对较小，在这种情况下可以适当将块大小调小（例如8KB或16KB）。这样可以使得一个block内不会有太多kv，kv太多会增大块内寻址的延迟时间，因为HBase在读数据时，一个block内部的查找是顺序查找
选择较小块的大小的目的是使随机读取更快，而付出的代价是块索引变大，会消耗更多的内存。相反，如果平均键值对规模很大，或者磁盘速度慢造成了性能瓶颈，那就应该选择一个较大的块大小，以便使一次磁盘IO能够读取更多的数据
思考：实际场景大部分是Scan读，但平均键值规划较小，如何设置BlockSize?

IN_MEMORY:

Block Cache 包含三个级别的优先级队列：

1. Single: 如果一个Block被第一次访问，则放在这一级的队列中
2. Multi: 如果一个Block被多次访问，则从Single队列移动Multi队列
3. In Memory: 它是静态指定的（在column family上设置），不会像其他两种cache会因访问频率而发生改变，这就决定了它的独立性，另外两种block访问次数再多也不会被放到in-memory的区段里去，in-memory的block不管是第几次访问，总是被放置到in-memory的区段中

LRU(Least Recently Used)淘汰数据时，Single会被优先淘汰，其次是Multi, 最后是In Memory, 这三个队列分别占用 BlockCache的 25%、50%、25%
每load一个block到cache时，都会检查当前cache的size是否已经超过了“警戒线”，这个“警戒线”是一个规定的当前block cache总体积占额定体积的安全比例，默认该值是0.85，即当加载了一个block到cache后总大小超过了既定的85%就开始触发异步的evict操作了
evict的逻辑是这样的：遍历cache中的所有block,根据它们所属的级别(single,multi,in-memory)分拨到三个优先级队列中，队头元素是最旧（最近访问日间值最小）的那个block。对这个三队列依次驱逐头元素，释放空间
注意：标记 IN_MEMORY=>'true' 的column family的总体积最好不要超过in-memory cache的大小（in-memory cache = heap size * hfile.block.cache.size * 0.85 * 0.25），特别是当总体积远远大于了in-memory cache时，会在in-memory cache上发生严重的颠簸
换个角度再看，普遍提到的使用in-memory cache的场景是把元数据表的column family声明为IN_MEMORY=>'true。实际上这里的潜台词是：元数据表都很小。其时我们也可以大胆地把一些需要经常访问的，总体积不会超过in-memory cache的column family都设为IN_MEMORY=>'true'从而更加充分地利用cache空间。普通的block永远是不会被放入in-memory cache的，只存放少量metadata是对in-memory cache资源的浪费

操作命令如下（建表时或alter已创建的表）：

hbase(main):002:0> create 'Test',{NAME=>'d',IN_MEMORY=>'true'}0 row(s) in 4.4970 seconds=> Hbase::Table - Test
hbase(main):003:0> describe 'Test'Table Test is ENABLED                                                                                      Test                                                                                               COLUMN FAMILIES DESCRIPTION                                                                                   {NAME => 'd', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'true', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}                                                            1 row(s) in 0.2530 secondshbase(main):004:0> create 'Test1','d'0 row(s) in 2.2400 seconds=> Hbase::Table - Test1hbase(main):005:0> disable 'Test1'0 row(s) in 2.2730 secondshbase(main):006:0> alter 'Test1',{NAME=>'d',IN_MEMORY=>'true'}Updating all regions with the new schema...1/1 regions updated.Done.0 row(s) in 2.4610 secondshbase(main):007:0> enable 'Test1'0 row(s) in 1.3370 secondshbase(main):008:0> describe 'Test1'Table Test1 is ENABLED                                                                                      Test1                                                                                              COLUMN FAMILIES DESCRIPTION                                                                                   {NAME => 'd', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'true', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}                                                            1 row(s) in 0.0330 secondshbase(main):009:0>

COMPRESSION/ENCODING：

Compression就是在用CPU资源换取磁盘空间资源，对读写性能并不会有太大影响，HBase目前提供了三种常用的压缩方式：GZip | LZO | Snappy
HBase在写入数据块到HDFS之前会首先对数据块进行压缩，再落盘，从而可以减少磁盘空间使用量
读数据的时候首先从HDFS中加载出block块之后进行解压缩，然后再缓存到BlockCache，最后返回给用户。写路径和读路径分别如下
结合上图，来看看数据压缩对资源使用情况以及读写性能的影响：

1. 资源使用情况：压缩最直接、最重要的作用即是减少数据硬盘容量，理论上snappy压缩率可以达到5:1，但是根据测试数据不同，压缩率可能并没有理论上理想；压缩/解压缩无疑需要大量计算，需要大量CPU资源；根据读路径来看，数据读取到缓存之前block块会先被解压，缓存到内存中的block是解压后的，因此和不压缩情况相比，内存前后基本没有任何影响
2. 读写性能：因为数据写入是先将kv数据值写到缓存，最后再统一flush的硬盘，而压缩是在flush这个阶段执行的，因此会影响flush的操作，对写性能本身并不会有太大影响；而数据读取如果是从HDFS中读取的话，首先需要解压缩，因此理论上读性能会有所下降；如果数据是从缓存中读取，因为缓存中的block块已经是解压后的，因此性能不会有任何影响；一般情况下大多数读都是热点读，缓存读占大部分比例，压缩并不会对读有太大影响

官方分别从压缩率，编解码速率三个方面对其进行对比如下图：
综合来看，Snappy的压缩率最低，但是编解码速率最高，对CPU的消耗也最小，目前一般建议使用Snappy
从上图看数据编码对资源使用情况以及读写性能的影响：

1. 资源使用情况：和压缩一样，编码最直接、最重要的作用也是减少数据硬盘容量，但是数据编码压缩率一般没有数据压缩的压缩率高，理论上只有5:2；编码/解码一般也需要大量计算，需要大量CPU资源；根据读路径来看，数据读取到缓存之前block块并没有被解码，缓存到内存中的block是编码后的，因此和不编码情况相比，相同数据block快占用内存更少，即内存利用率更高
2. 读写性能：和数据压缩相同，数据编码也是在数据flush到hdfs阶段执行的，因此并不会直接影响写入过程；前面讲到，数据块是以编码形式缓存到blockcache中的，因此同样大小的blockcache可以缓存更多的数据块，这有利于读性能。另一方面，用户从缓存中加载出来数据块之后并不能直接获取KV，而需要先解码，这却不利于读性能。可见，数据编码在内存充足的情况下会降低读性能，而在内存不足的情况下需要经过测试才能得出具体结论

HBase目前提供了四种常用的编码方式：Prefix | Diff | Fast_Diff | Prefix_Tree。
压缩与编码使用测试结果示例，来源于：http://hbasefly.com/2016/07/02/hbase-pracise-cfsetting/
结果分析：

1. 数据压缩率并没有理论上0.2那么高，只有0.7左右，这和数据结构有关系。其中压缩、编码、压缩+编码三种方式的压缩率基本相当
2. 随机读场景：和默认配置相比，snappy压缩在性能上没有提升，CPU开销却上升了38%；prefix_tree性能上没有提升，CPU利用率也基本相当；snappy+prefix_tree性能没有提升，CPU开销上升了38%
3. 区间扫描场景：和默认配置相比，snappy压缩在性能上略有10%的提升，但是CPU开销却上升了23%；prefix_tree性能上略有4%左右的下降，但是CPU开销也下降了5%，snappy+prefix_tree在性能上基本没有提升，CPU开销却上升了23%