`
shenchunhui
  • 浏览: 145916 次
  • 来自: 杭州
社区版块
存档分类
最新评论

HBase上关于CMS、GC碎片、大缓存的一种解决方案:Bucket Cache

阅读更多

介绍BucketCache前,先对HBase的Cache做个介绍:
一.HBase在读取时,会以Block为单位进行cache,用来提升读的性能;


二.Block可以分类为DataBlock(默认大小64K,存储KV)、BloomBlock(默认大小128K,存储BloomFilter数据)、IndexBlock(默认大小128K,索引数据,用来加快Row所在DataBlock的定位)




三.对于一次随机读,Block的访问顺序为BloomBlock、IndexBlock、DataBlock,如果Region下面的StoreFile数目为2个,那么一次随机读至少访问2次BloomBlock+1次IndexBlock+1次DataBlock


四.我们通常将BloomBlock和IndexBlock统称为MetaBlock,MetaBlock线上系统中基本命中率都是100%


五.Block的cache命中率对HBase的读性能影响十分大,所以DataBlockEncoding将KV在内存中进行压缩,对于单行多列和Row相似的场景,可以提高内存使用率,增加读性能


六.HBase中管理缓存的Block的类为BlockCache,其实现目前主要是下面三种:



6.1 LruBlockCache,默认的BlockCache实现,也是目前使用的BlockCache,使用一个HashMap维护Block Key到Block的映射,采用严格的LRU算法来淘汰Block,初始化时会指定容量大小,当使用量达到85%的时候开始淘汰block至75%的比例。
优点:直接采用jvm提供的HashMap来管理Cache,简单可依赖;内存用多少占多少,JVM会帮你回收淘汰的BlOCK占用的内存
缺点:
1.一个Block从被缓存至被淘汰,基本就伴随着Heap中的位置从New区晋升到Old区
2.晋升在Old区的Block被淘汰后,最终由CMS进行垃圾回收,随之带来的是Heap碎片
3.因为碎片问题,随之而来的是GC时晋升失败的FullGC,我们的线上系统根据不同的业务特点,因为这个而发生FullGC的频率,有1天的,1周的,1月半年的都有。对于高频率的,

在运维上通过在半夜手工触发FullGC来缓解
4.如果缓存的速度比淘汰的速度快,很不幸,现在的代码有OOM的风险(这个可以修改下代码避免)



6.2 SlabCache,针对LruBlockCache的碎片问题一种解决方案,使用堆外内存,处于实验性质,真实测试后,我们定位为不可用。说下它的原理:它由多个SingleSizeCache组成(所谓SingleSizeCache,就是只缓存固定大小的block,其内部维护一个ByteBuffer List,每个ByteBuffer的空间都是一样的,比如64K的SingleSizeCache,ByteBuffer的空间都是64K,cache Block时把Block的内容复制到ByteBuffer中,所以block的大小必须小于等于64K才能被这个SingleSizeCache缓存;淘汰block的时候只需要将相应的ByteBuffer标记为

空闲,下次cache的时候对其上的内存直接进行覆盖就行了),cache Block的时候,选择一个小于且最接近的SingleSizeCache进行缓存,淘汰block亦此。由于SingleSize的局限性,其使用上和LruBlockCache搭配使用,叫做DoubleBlockCache,cache block的时候LruBlockCache和SlabCache都缓存一份,get block的时候顺序为LruBlockCache、SlabCache,如果只有SlabCache命中,那么再将block缓存到LruBlockCache中(本人觉得它的这个设计很费,你觉得呢)

优点:其思想:申请固定内存空间,Block的读写都在这片区域中进行
缺点:
1.cache block和 get block的时候,需要内存复制
2.SingleSizeCache的设计,导致内存使用率很低
3.与LruBlockCache搭配使用不合理,导致所有的block都会去LruBlockCache中逗留一下,结果是CMS和碎片都不能有所改善


6.3 BucketCache,可以看成是对SlabCache思想在实现上的一种改进及功能扩展,其优点是解决LruBlockCache的缺点及支持面向高性能读的大缓存空间.



1.何谓大缓存?缓存Block的存储介质不再仅仅依赖在内存上,而是可以选择为Fusion-io、SSD等高速磁盘,我们称之为二级缓存



2.何谓Bucket?我们将缓存空间划分为一个个的Bucket,每个Bucket都贴上一个size标签,将Block缓存在最接近且小于size的bucket中(和SingleSizeCache很相似)



3.怎么解决CMS 碎片问题?Block存储在Bucket中,而每个Bucket的物理存储是不变的,也就是说系统刚启动的时候,我们就申请了一堆Bucket内存空间,而这些内存空间是一直在Old区,block的Get/Cache动作只是对这片空间的访问/覆写,CMS/碎片自然大大减少



4.怎么使用?上面的描述指出BucketCache可以有两种用法:
4.1 与LruBlockCache搭配,作为主要的内存cache方案使用




 


4.2 作为二级缓存使用,将Block缓存在我们的高速盘(Fusion-IO)中




 


5.BucketCache中的Cache/Get Block逻辑?



 



 



简单地描述下:
CacheBlock的时候,将Block放在一个RAMMap和一个Queue中,然后WriterThread异步从Queue中remove Block写入到IOEngine(内存或高速盘)中,并将BlockKey及其位置、长度等信息记录在backingMap
GetBlock的时候,先访问RAMMap,然后访问backingMap获取block的位置及长度,从IOEngine读取数据


6.Block在IOEngine中的位置是怎么分配的?




 


我们将物理空间划分为一堆等大的Bucket,每一个Bucket有一个序号及一个size标签,于是Block所在bucket的序号及其在bucket中的offset与block在物理空间的offset就形成了一一对应。我们通过BucketAllocator为指定大小的Block寻找一个Bucket进行存放,于是就得到了其在物理空间上的位置。



上图描述了BucketAllocator对于Bucket的组织管理:

6.1 每个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


6.2 相同size标签的Bucket由同一个BucketSizeInfo管理


6.3 Bucket的size标签可以动态调整,比如64K的block数目比较多,65K的bucket被用完了以后,其他size标签的完全空闲的bucket可以转换成为65K的bucket,但是至少保留一个该size的bucket




6.4 如果最大size的bucket为513K,那么超过这个大小的block无法存储,直接拒绝


6.5 如果某个size的bucket用完了,那么会依照LRU算法触发block淘汰



问题:

6.6.如果系统一开始都是某个size的block,突然变成另外个size的block(不能存在同个size的bucket中),根据6.5不是会不停地进行淘汰算法?
是的,但是由于淘汰是异步的,影响不大,而且随着淘汰进行,bucket的大小会逐渐向那个block size大小bucket转移,最终稳定



6.7 BucketAllocator中allocate block的流程?



 





 



6.8 BucketAllocator中free block的流程?



 


6.9 第一种使用的测试结果



 


6.10 第二种使用的测试结果




 


6.11 更多细节,尽在代码中

https://issues.apache.org/jira/browse/HBASE-7404

 

  • 大小: 79.3 KB
  • 大小: 81.9 KB
  • 大小: 128.5 KB
  • 大小: 90.5 KB
  • 大小: 142.8 KB
  • 大小: 150.6 KB
  • 大小: 184.5 KB
  • 大小: 138.7 KB
  • 大小: 128.8 KB
  • 大小: 105.2 KB
分享到:
评论
7 楼 blackproof 2015-03-17  
RAMQueueEntry的writeToCache这个方法,看得我都蛋疼
感觉就是把数据写到了bytebufferarray里面,获取个bytebufferarray里的索引,就完了;那里有高速磁盘啥啥的事
6 楼 SMCwwh 2014-12-17  
BucketCache的实现,和memcache对内存的管理很像啊
5 楼 qiuboboy 2013-03-17  
但是由于淘汰是异步的,影响不大
这个结论怎么得出的
4 楼 qiuboboy 2013-03-17  
但是由于淘汰是异步的,影响不大
3 楼 lc_koven 2012-12-21  
panfeng412 写道
为什么第二种用法中,before和after相差这么大呢?

Using fusionio
2 楼 panfeng412 2012-12-21  
为什么第二种用法中,before和after相差这么大呢?
1 楼 jitabc 2012-12-21  
这个很给力。

相关推荐

    hbase bucket cache

    hbase bucket cache 作者的设计文档

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》part1

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案.part1.rar

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案.part2.rar

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案.pdf

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    HBase常见热点问题及几种解决方案.docx

    HBase常见热点问题及几种解决方案.docx

    Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案.part4.rar

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案.part3.rar

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    PentahoKettle解决方案:使用PDI构建开源ETL解决方案.part1.rar

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    PentahoKettle解决方案:使用PDI构建开源ETL解决方案.part2.rar

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案 part2

    《Pentaho Kettle解决方案:使用PDI构建开源ETL解决方案》介绍的PDI(Kettle)是一种开源的 ETL 解决方案,书中介绍了如何使用PDI来实现数据的剖析、清洗、校验、抽取、转换、加载等各类常见的ETL类工作。 除了ODS/DW...

    Hbase权威指南(HBase: The Definitive Guide)

    如果你正在寻找一种具备可伸缩性的存储解决方案来适应几乎没有穷尽的数据的话,这本书将可以向你表明apache hbase完全能够满足你的需求。作为google bigtable架构的开源实现,hbase能够支持数以十亿计的记录数和数以...

    Hbase 二级索引方案

    们更加希望像 Sql 一样快速检索数据,可是,Hbase 之前定位的是大表的存储,要进行这样 的查询,往往是要通过类似 Hive、Pig 等系统进行全表的 MapReduce 计算,这种方式既浪费 了机器的计算资源,又因高延迟使得...

    GC优化利器HBase2.0全链路offheap.pdf

    讲师:林明--阿里巴巴-云hbase内核开发 高级工程师 内容概要: gc问题会带来访问毛刺,回顾一下读写链路,然后看看全链路offheap怎么减少gc停顿、减低p999延迟的。

    HBase学习利器:HBase实战

    HBase开发实战,HBase学习利器:HBase实战

    实验三:熟悉常用的HBase操作

    A.3实验三:熟悉常用的HBase操作 本实验对应第5章的内容。 A.3.1 实验目的 (1)理解HBase在Hadoop体系结构中的角色。(2)熟练使用HBase操作常用的 Shell命令。(3)熟悉HBase操作常用的 Java API。 A.3.2 实验平台 (1...

    HBASERegion数量增多问题描述及解决方案.docx

    HBASERegion数量增多问题描述及解决方案.docx

    hbase的Rowkey设计方案.pdf

    HBase中设计有MemStore和BlockCache,分别对应列族/Store级别的写⼊缓存,和RegionServer级别的读取缓存。如果RowKey过 长,缓存中存储数据的密度就会降低,影响数据落地或查询效率。 1.2 hbase的设计原则以及解决...

    HBase(hbase-2.4.9-bin.tar.gz)

    HBase(hbase-2.4.9-bin.tar.gz)是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System...

    FlinkSQL实战:HBase的结合应用

    HBase作为Google发表BigTable论文的开源实现版本,是一种分布式列式存储的数据库,构建在HDFS之上的NoSQL数据库,非常适合大规模实时查询,因此HBase在实时计算领域使用非常广泛。可以实时写HBase,也可以利用...

Global site tag (gtag.js) - Google Analytics