HBase讀緩存BlockCache怎么理解

本篇內容介紹了“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);

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讀緩存BlockCache怎么理解”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！