HBase1.x精通:详解HBase读缓存BlockCache(一、概述及策略)

概述:

缓存对于任何一个数据库都非常重要,如果有条件允许,我们更愿意把所有的数据都缓存到内存中,就不存在任何的磁盘IO,但对于大数据来说缓存所有数据几乎是不可能的,基于二八法则,我们80%的业务请求都集中在20%的数据里面,如果把这20%的数据缓存到内存中,数据库的性能将会有极大的提升。

    HBase上Regionserver的内存分为两个部分:一部分作为Memstore,主要用来写; 另外一部分作为BlockCache,主要用于读。

1). 写请求会先写入Memstore ,Regionserver会给每个region提供一个Memstore,当Memstore满128MB以后,此时当前的HRegion中所有的MemStore会Flush到HDFS中。

当一个HRegion中的所有MemStore的大小总和超过了hbase.regionserver.global.memstore.upperLimit的大小,默认40%的内存使用量。此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中,Flush顺序是MemStore大小的倒序,直到总体的MemStore使用量低于hbase.regionserver.global.memstore.lowerLimit,默认38%的内存使用量。

     2). 读请求先到Memstore中查数据,查不到就到BlockCache中查,再查不到就会到磁盘上读,并把读的结果放入BlockCache 。由于BlockCache采用的是LRU策略,因此BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)后,会启动淘汰机制,淘汰掉最老的一批数据。

一个Regionserver上有一个BlockCache和N个Memstore,它们的大小之和不能大于等于heapsize * 0.8,否则HBase不能正常启动。

BlockCache机制

为了高效获取数据,HBase设置了BlockCache机制,内存中缓存block,Block大体来分为两类,一类是JVM的heap内存,一类是heap off内存;第一类的cache策略叫做LRUCache,第二类Cache策略有SlabCache以及BucketCache两类;

BlockCache是Region Server级别的,一个Region Server只有一个Block Cache,在Region Server启动的时候完成Block Cache的初始化工作。到目前为止,HBase先后实现了3种Block Cache方案, LRUBlockCache是最初的实现方案,也是默认的实现方案 ;HBase 0.92版本实现了第二种方案SlabCache,见HBASE-4027;HBase 0.96之后官方提供了另一种可选方案BucketCache,见HBASE-7404。

BlockCache在HBase中所处的位置如下图中所示:

三种策略:

1).LRUBlockCache

Least-Recently-Used, HBase默认的BlockCache实现方案, LRU缓存把最近最少使用的数据移除,让给最新读取的数据。而往往最常读取的,也是读取次数最多的,所以,利用LRU缓存,我们能够提高系统的性能。

LRUBlockCache将缓存分为三块:single-access区、mutil-access区、in-memory区,分别占到整个BlockCache大小的25%、50%、25%。

  1. single-access 优先级 :当一个数据块第一次从HDFS读取时,它会具有这种优先级,并且在缓存空间需要被回收(置换)时,它属于优先被考虑范围内。它的优点在于:一般被扫描(scanned)读取的数据块,相较于之后会被用到的数据块,更应该被优先清除

  2. mutil-access优先级 :如果一个数据块,属于Single Access优先级,但是之后被再次访问,则它会升级为Multi Access优先级。在缓存里的内容需要被清除(置换)时,这部分内容属于次要被考虑的范围

  3. in-memory-access优先级 :表示数据可以常驻内存,一般用来存放访问频繁、数据量小的数据,比如元数据,用户也可以在建表的时候通过设置列族属性IN-MEMORY= true将此列族放入in-memory区,两种具体实现方式如下:

    a.在Java中可以调用: HColumnDescriptor.setInMemory(true);

  4. b.在hbase shell 中创建或修改一个表时,可以使用 IN_MEMORY => true,例如:create ‘t’, {NANME => ‘f’, IN_MEMORY => ‘true’}

    弊端: 使用LRUBlockCache缓存机制会因为CMS GC策略导致内存碎片过多,从而可能引发臭名昭著的Full GC,触发可怕的’stop-the-world’暂停;尤其在大内存条件下,一次Full GC很可能会持续较长时间,甚至达到分钟级别。大家知道Full GC是会将整个进程暂停的(称为stop-the-wold暂停),因此长时间Full GC必然会极大影响业务的正常读写请求。

2).SlabCache 

在1.0版本后被废弃了(HBASE-11307);内部结构是划分为两块,80%和20%;缓存的数据如小于等于blocksize,则放在在前面的区域(80%区域);如果block大于1x但是小于2x将会放置到后面区域(20%区域);如果大于2x则不进行缓存。

和LRUBlockCache相同,SlabCache也使用Least-Recently-Used算法对过期Block进行淘汰。

和LRUBlockCache不同的是,SlabCache淘汰Block的时候只需要将对应的bufferbyte标记为空闲,后续cache对其上的内存直接进行覆盖即可。

线上集群环境中,不同表不同列族设置的BlockSize都可能不同,很显然,默认只能存储两种固定大小Block的SlabCache方案不能满足部分用户场景,比如用户设置BlockSize = 256K,简单使用SlabCache方案就不能达到这部分Block缓存的目的。因此HBase实际实现中将SlabCache和LRUBlockCache搭配使用,称为DoubleBlockCache。一次随机读中,一个Block块从HDFS中加载出来之后会在两个Cache中分别存储一份;缓存读时首先在LRUBlockCache中查找,如果Cache Miss再在SlabCache中查找,此时如果命中再将该Block放入LRUBlockCache中。

弊端 :经过实际测试,DoubleBlockCache方案有很多弊端。比如SlabCache设计中固定大小内存设置会导致实际内存使用率比较低,而且使用LRUBlockCache缓存Block依然会因为JVM GC产生大量内存碎片。因此在HBase 0.98版本之后,该方案已经被不建议使用。

3).BucketCache 

这种策略是阿里设计出来的  CDH集群用的这种策略,BucketCache通过配置可以工作在三种模式下:heap,offheap和file。无论工作在那种模式下,BucketCache都会申请许多带有固定大小标签的Bucket,和SlabCache一样,一种Bucket存储一种指定BlockSize的数据块,但和SlabCache不同的是,BucketCache会在初始化的时候申请14个不同大小的Bucket,而且即使在某一种Bucket空间不足的情况下,系统也会从其他Bucket空间借用内存使用,不会出现内存使用率低的情况。接下来再来看看不同工作模式,heap模式表示这些Bucket是从JVM Heap中申请,offheap模式使用DirectByteBuffer技术实现堆外内存存储管理,而file模式使用类似SSD的高速缓存文件存储数据块。

弊端 :实际实现中,HBase将BucketCache和LRUBlockCache搭配使用,称为CombinedBlockCache。和DoubleBlockCache不同,系统在LRUBlockCache中主要存储Index Block和Bloom Block,而将Data Block存储在BucketCache中。因此一次随机读需要首先在LRUBlockCache中查到对应的Index Block,然后再到BucketCache查找对应数据块。BucketCache通过更加合理的设计修正了SlabCache的弊端,极大降低了JVM GC对业务请求的实际影响,但也存在一些问题,比如使用堆外内存会存在拷贝内存的问题,一定程度上会影响读写性能。当然,在后来的版本中这个问题也得到了解决,见HBASE-11425。

    文章不错? 点个【 在看 】吧!   :point_down:

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章