1 BlockCache 唯一性

  • 一个 RegionServer只有一个BlockCache。
  • BlockCache的诞生就是用来优化读取性能的。
  • HBase Block 目前主要有DATA，ENCODED_DATA，META，FILE_INFO，ROOT_INDEX等。
  • BlockCache 目前主要有LRUBlockCache和SlabCache，以及BucketCache等。

 

 

2 LRUBlockCache的三段缓存架构

  • hfile.block.cache.size.LRUBlockCache： 参数表示占用堆内存比例，默认是0.4，目前这是唯一的LRUBlockCache，无法被关闭。
  • BlockCache配置和Memstore配置的联动影响，即：Memstore+BlockCache的内存占比不能超过0.8（即80%），否则就会报错。注意必须留20%的机动空间：
hbase.regionserver.global.memstore.size+hfile.block.cache.size<=0.8
复制代码
  • LRUBlockCache 完全基于JVM heap的LRU的方案，当缓存写满了之后，会根据LRU的算法来淘汰block。
  • LRUBlockCache的三段缓存架构：
  • 第一段single-access占用25%的比例，也即单次读取区，block被读出后先放到这个区域，当被读到多次后会升级到下一个区域。
  • 第二段multi-acsess占用50%的比例，也即多次读取区，当一个被缓冲到单次读取区后又被访问多次，会升级到这个区。
  • in-memory占用25%的比例，这个区域跟Block被访问几次没有什么关系，它只存放那些被设置了IN-MEMORY=true的列族中读取出来的block。

3 LRUBlockCache的弊端

LRUBlockCache完全基于JVM Heap的缓存，那么势必会造成一个后果，随着内存中对象越来越多，每隔一段时间肯定会产生Full GC。

4 SlabCache 堆外内存的创意(已废弃)

4.1 堆外内存烫手山芋

  • 因为堆外内存存储的数据都是原始数据，对于一个对象，比如先序列化之后才能存储，所以不能存储大对象。
  • 堆外内存并不是JVM的管理范围，所以当内存泄露的时候非常不好排查问题。
  • 对外内存使用的是物理内存，当使用过大的时候，物理内存可能会爆掉。

5 BucketCache 应运而生

5.1 BucketCache理论基础

  • CombinedBlockCache是一个LRUBlockCache和BucketCache的混合体。BucketCache是阿里贡献的。LRUBlockCache中主要存储Index Block和Bloom Block，而将Data Block存储在BucketCache中。因此一次随机读需要首先在LRUBlockCache中查到对应的Index Block，然后再到BucketCache查找对应数据块。
  • BucketCache可以有三种工作模式：heap、offheap、file。heap模式表示这些Bucket是从JVM Heap中申请，offheap模式使用DirectByteBuffer技术实现堆外内存存储管理，而file模式使用类似SSD的高速缓存文件存储数据块。
  • 无论在哪一种工作模式下，BucketCache都会申请许多带有固定大小标签的Bucket，一种Bucket只是一种指定的BlockSize的数据块，初始化的时候申请14个不同大小的Bucket，而且即使在某一种Bucket空间不足的情况下，系统也会从其他Bucket空间借用内存使用，不会出现内存使用率低下的情况。这里每个Bucket的大小上限为最大尺寸的Block * 4,比如最大容纳Block类型为512KB,那么每个Bucket的大小就是512KB*4 =2018。若配置了4，则会有2048/4=512个4K的空间。
  • 我们将物理空间划分为一堆等大的Bucket，每一个Bucket有一个序号及一个size标签，于是Block所在bucket的序号及其在bucket中的offset与block在物理空间的offset就形成了一一对应。我们通过BucketAllocator为指定大小的Block寻找一个Bucket进行存放，于是就得到了其在物理空间上的位置。
  • 每个Bucket都有一个size标签，目前对于size的分类，是在启动时候就确定了，如默认的有(8+1)K、(16+1)K、(32+1)K、(40+1)K、(48+1)K、(56+1)K、(64+1)K、(96+1)K ... (512+1)K
  • 相同size标签的Bucket由同一个BucketSizeInfo管理
  • Bucket的size标签可以动态调整，比如64K的block数目比较多，65K的bucket被用完了以后，其他size标签的完全空闲的bucket可以转换成为65K的bucket，但是至少保留一个该size的bucket
  • 如果最大size的bucket为513K，那么超过这个大小的block无法存储，直接拒绝
  • 如果某个size的bucket用完了，那么会依照LRU算法触发block淘汰
  • hbase 表参数一览
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 seconds
复制代码

5.2 BucketCache的参数设置

  • BucketCache默认是开启的，如果不想让某个列族使用BucketCache，可以使用一下命令
alter 'mytable' , CONFIGURATION => {CACHE_DATA_IN_L1 => 'true'}
复制代码
  • BucketCache 相关的配置项如下：
  • hbase.bucketcache.ioengine :使用的存储介质，可选值为heap ,offheap,file。不设置的话，默认为offheap。
  • hbase.bucketcache.combinedcache.enabled:是否打开组合模式（combinedcache），默认是true
  • hbase.bucketcache.size:BucketCache所占的大小
如果设置为0.0-1.0 ，则代表占堆内存的百分比
如果大于1，则代表实际的BucketCache的大小，单位为MB。
默认值为0.0，即关闭BucketCache
复制代码
  • hbase.bucketcache.bucket.sizes:定义所有Block种类，默认是14中，默认值为4,8,16,32,40......
  • -XX:MaxDirectMemorySize:这是JVM启动参数，该参数定义了JVM可以获取的堆外内存上限。

5.3 BucketCache组合模式的强强合作

  • 具体解释为把不同类型的Block分别放到LRUCache和BucketCache中，如：Index Block和Bloom Block会被放到LRUCache中，Data Block 被直接放进BucketCache中，所以每次查询，都会先去LRUCache查询一下，然后再去BucketCache中查询真正的数据。
  • LRUCache使用内存，BucketCache使用SSD，HFile使用机械硬盘。

5.4 BucketCache 测试报告

  • BucketCache自己使用内存，碎片比较少，所以GC时间大部分都要比LRUBlockCache短。
  • 在缓存全部命中的情况下，LRUBlockCache是BucketCache吞吐量的两倍。在缓存基本命中的情况下，LRUBlockCache是BucketCache吞吐量相当。
  • 读写延迟，IO方面基本相当。
  • 强烈建议线上配置BucketCache模式。可能很多专家都测试过这两种模式下的GC、吞吐量、读写延迟等指标，看到测试结果都会很疑惑，BucketCache模式下的各项性能指标都比LruBlockCache差了好多，但是突然我弄明白了，测试肯定是在基本全内存场景下进行的，这种情况下确实会是如此。但是话又说回来，在大数据场景下又有多少业务会是全内存操作呢？

5.5 RegionServer内存分配

 

   RegionServer进程的内存就是JVM内存，主要分为三部分：LRUBlockCache，用于读缓存；MemStore，用于写缓存；Other，用于RS运行所必须的其他对象