首页 > 代码库 > HBase(八): 表结构设计优化

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 TestTable 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,d0 row(s) in 2.2400 seconds=> Hbase::Table - Test1hbase(main):005:0> disable Test10 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 Test10 row(s) in 1.3370 secondshbase(main):008:0> describe Test1Table 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%
  • 设计原则:
    1. 在任何场景下开启prefix_tree编码都是安全的
    2. 在任何场景下都不要同时开启snappy压缩和prefix_tree编码
    3. 通常情况下snappy压缩并不能比prefix_tree编码获得更好的优化结果,如果需要使用snappy需要针对业务数据进行实际测试

 VERSIONS


  •  用于定义某列族所能记录的最多的版本数量,默认值是3,即每个单元格的最大版本数量是3
  • 对于更新频繁的应用,建设设置为1,可以快速淘汰无用的数据,节省存储空间同时还能提升查询效率
  • 同样道理,可在建表时指定或通过alter修改表结构实现

TTL


  • TTL:Time To Live 用于定义列族中单元格存活时间,过期数据自动删除
  • TTL属性特性:
    1. 单位是秒,默认值:FOREVEN (永不过期)
    2. 当一行所有列都过期后,RowKey也会被删除
    3. 若TTL设置为两个月,则时间戮为2个月之前的数据不能插入
  • 同理,在建表时指定或通过alter修改表结构设置

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