hbase之BlockCache优化

最新推荐文章于 2020-12-20 14:30:44 发布

L13763338360

最新推荐文章于 2020-12-20 14:30:44 发布

阅读量684

点赞数

分类专栏： hbase

本文链接：https://blog.csdn.net/L13763338360/article/details/106901058

版权

4 篇文章 0 订阅

订阅专栏

读请求到HBase之后先尝试查询BlockCache，如果获取不到就去HFile（StoreFile）和Memstore中去获取。如果获取到了则在返回数据的同时把Block块缓存到BlockCache中。它默认是开启的，一个RegionServer只有一个BlockCache。

BlockCache默认开启，如果关闭BlockCache：

alter 'testTable', CONFIGURATION=>{NAME => 'cf',BLOCKCACHE=>'false'}

在0.92版本之前只有这种BlockCache的实现方案。LRU就是Least Recently Used，即近期最少使用算法的缩写。读出来的block会被放到BlockCache中待下次查询使用。当缓存满了的时候，会根据LRU的算法来淘汰block。 LRUBlockCache被分为三个区域

SlabCache实际测试起来对Full GC的改善很小，所以这个方案最后被废弃了。不过它被废弃还有一个更大的原因，这就是有另一个更好的Cache方案产生了，也用到了堆外内存，它就是BucketCache。

相比起只有2个区域的SlabeCache，BucketCache一上来就分配了 14种区域。注意：我这里说的是14种区域，并不是14块区域。这 14种区域分别放的是大小为4KB、8KB、16KB、32KB、40KB、 48KB、56KB、64KB、96KB、128KB、192KB、256KB、384KB、 512KB的Block。而且这个种类列表还是可以手动通过设置 hbase.bucketcache.bucket.sizes属性来定义（种类之间用逗号分隔，想配几个配几个，不一定是14个！），这14种类型可以分配出很多个Bucket。
BucketCache的存储不一定要使用堆外内存，是可以自由在3种存储介质直接选择：堆（heap）、堆外（offheap）、文件（file,这里的文件可以理解成SSD硬盘）。通过设置hbase.bucketcache.ioengine为heap、 offfheap或者file来配置。
每个Bucket的大小上限为最大尺寸的block 4，比如可以容纳的最大的Block类型是512KB，那么每个Bucket的大小就是512KB 4 = 2048KB。
系统一启动BucketCache就会把可用的存储空间按照每个Bucket 的大小上限均分为多个Bucket。如果划分完的数量比你的种类还少，比如比14（默认的种类数量）少，就会直接报错，因为每一种类型的Bucket至少要有一个Bucket。

Bucket Cache默认是开启的，如果要关闭的话

alter 'testTable', CONFIGURATION=>{CACHE_DATA_IN_L1 => 'true'}

在SlabCache的时代，SlabCache，是跟LRUCache一起使用的，每一个Block被加载出来都是缓存两份，一份在SlabCache一份在LRUCache，这种模式称之为DoubleBlockCache。读取的时候LRUCache作为L1层缓存（一级缓存），把SlabCache作为L2层缓存（二级缓存）。
在BucketCache的时代，也不是单纯地使用BucketCache，但是这回不是一二级缓存的结合；而是另一种模式，叫组合模式（CombinedBlockCahce）。具体地说就是把不同类型的Block分别放到 LRUCache和BucketCache中。
Index Block和Bloom Block会被放到LRUCache中。Data Block被直接放到BucketCache中，所以数据会去LRUCache查询一下，然后再去 BucketCache中查询真正的数据。其实这种实现是一种更合理的二级缓存，数据从一级缓存到二级缓存最后到硬盘，数据是从小到大，存储介质也是由快到慢。考虑到成本和性能的组合，比较合理的介质是： LRUCache使用内存->BuckectCache使用SSD->HFile使用机械硬盘。

参考

关注