塊緩存

HBase提供了兩種不同的BlockCache實(shí)現(xiàn)，來(lái)緩存從HDFS中讀取的數(shù)據(jù)：默認(rèn)的on-heap LruBlockCache和BucketCache（通常是off-heap）。本節(jié)討論每個(gè)實(shí)現(xiàn)的優(yōu)點(diǎn)和缺點(diǎn)、如何選擇適當(dāng)?shù)倪x項(xiàng)以及每種配置選項(xiàng)。

緩存選擇

LruBlockCache是原始實(shí)現(xiàn)，完全在Java堆內(nèi)。 BucketCache是可選的，主要用于保持塊緩存數(shù)據(jù)脫離堆，盡管BucketCache也可以是文件支持的緩存。

當(dāng)您啟用BucketCache時(shí)，您將啟用兩層緩存系統(tǒng)。我們?cè)?jīng)將層描述為“L1”和“L2”，但是已經(jīng)不贊成使用hbase-2.0.0的這個(gè)術(shù)語(yǔ)?！癓1”緩存引用了LruBlockCache的一個(gè)實(shí)例，并且將“L2”引用到了堆外的BucketCache。相反，當(dāng)啟用BucketCache時(shí)，所有DATA塊都保存在BucketCache層中，元塊（INDEX和BLOOM塊）在LruBlockCache堆中。這兩個(gè)層次的管理以及控制它們之間的塊移動(dòng)的策略是由 CombinedBlockCache 完成的。

常規(guī)緩存配置

除了緩存實(shí)現(xiàn)本身之外，您可以設(shè)置一些常規(guī)配置選項(xiàng)來(lái)控制緩存的執(zhí)行方式。請(qǐng)參閱CacheConfig。設(shè)置了其中任何選項(xiàng)后，重新啟動(dòng)或滾動(dòng)重新啟動(dòng)群集以使配置生效。檢查日志以查找錯(cuò)誤或意外行為。

LruBlockCache設(shè)計(jì)

LruBlockCache是??一個(gè)LRU緩存，它包含三個(gè)塊級(jí)別的優(yōu)先級(jí)以允許掃描電阻和內(nèi)存中的ColumnFamilies：

• 單一訪問(wèn)優(yōu)先級(jí)：從HDFS首次加載塊時(shí)，它通常具有此優(yōu)先級(jí)，它將成為驅(qū)逐期間要考慮的第一個(gè)組的一部分。其優(yōu)點(diǎn)是，掃描塊比獲得更多用量的塊更有可能被驅(qū)逐。
• 多重訪問(wèn)優(yōu)先級(jí)：如果先前優(yōu)先級(jí)組中的塊再次被訪問(wèn)，則會(huì)升級(jí)到此優(yōu)先級(jí)。因此它是在驅(qū)逐期間考慮的第二組的一部分。
• 內(nèi)存訪問(wèn)優(yōu)先級(jí)：如果該塊的系列配置為“內(nèi)存中（in-memory）”，則無(wú)論訪問(wèn)次數(shù)如何，都將成為此優(yōu)先級(jí)的一部分。目錄表是這樣配置的。這個(gè)小組是在驅(qū)逐過(guò)程中考慮的最后一個(gè)小組。要將列族標(biāo)記為內(nèi)存中，請(qǐng)調(diào)用：

  HColumnDescriptor.setInMemory(true);

如果從java創(chuàng)建表，或者在shell中創(chuàng)建或更改表時(shí)設(shè)置IN_MEMORY ? true，例如：

hbase(main):003:0> create  't', {NAME => 'f', IN_MEMORY => 'true'}

LruBlockCache用法

所有用戶表默認(rèn)啟用塊緩存，這意味著任何讀取操作都會(huì)加載LRU緩存。這對(duì)于大量的用例可能是有益的，但通常需要進(jìn)一步的調(diào)整才能獲得更好的性能。一個(gè)重要的概念是工作集大小或WSS，即：“計(jì)算問(wèn)題答案所需的內(nèi)存量”。對(duì)于一個(gè)網(wǎng)站，這將是在短時(shí)間內(nèi)回答查詢所需的數(shù)據(jù)。

計(jì)算緩存中HBase有多少內(nèi)存的方法是：

number of region servers * heap size * hfile.block.cache.size * 0.99

塊緩存的默認(rèn)值為0.4，表示可用堆的40％。最后一個(gè)值（99％）是在驅(qū)逐開(kāi)始之后LRU緩存中的默認(rèn)可接受加載因子。它被包含在這個(gè)等式中的原因是，說(shuō)可以使用100％的可用內(nèi)存是不現(xiàn)實(shí)的，因?yàn)檫@會(huì)使得該過(guò)程從加載新塊的位置阻塞。下面是一些示例：

• 一個(gè)區(qū)域服務(wù)器的堆大小設(shè)置為1 GB，默認(rèn)塊高速緩存大小將具有405 MB的塊高速緩存可用。
• 20個(gè)區(qū)域服務(wù)器的堆大小設(shè)置為8 GB，并且默認(rèn)塊高速緩存大小將具有63.3個(gè)塊高速緩存。
• 堆大小設(shè)置為24 GB并且塊緩存大小為0.5的100個(gè)區(qū)域服務(wù)器將擁有大約1.16 TB的塊緩存。

您的數(shù)據(jù)不是塊緩存的唯一常駐者。以下是您可能必須考慮的其他問(wèn)題：

目錄表

該hbase:meta表被強(qiáng)制進(jìn)入塊緩存并具有內(nèi)存優(yōu)先級(jí)，這意味著它們更難以驅(qū)逐。（根據(jù)區(qū)域的數(shù)量，hbase：meta表格可以占用幾個(gè)MB。）

目前，衡量HFile索引和bloom過(guò)濾器大小的推薦方法是查看區(qū)域服務(wù)器Web UI并檢查相關(guān)度量標(biāo)準(zhǔn)。對(duì)于密鑰，可以使用HFile命令行工具完成采樣并查找平均密鑰大小度量。從HBase 0.98.3開(kāi)始，您可以在用戶界面的特殊Block Cache部分查看有關(guān)BlockCache統(tǒng)計(jì)信息和指標(biāo)的詳細(xì)信息。

當(dāng)WSS不適合內(nèi)存時(shí)，使用塊緩存通常是不好的。例如，在所有區(qū)域服務(wù)器的塊高速緩存中都有40GB可用的情況，但您需要處理1TB的數(shù)據(jù)。其中一個(gè)原因是由驅(qū)逐產(chǎn)生的流失會(huì)不必要地觸發(fā)更多的垃圾收集。這里有兩個(gè)用例：

• 完全隨機(jī)讀取模式：這種情況下，幾乎不會(huì)在短時(shí)間內(nèi)訪問(wèn)同一行兩次，從而使得緩存塊的命中率接近于0。在這樣的表上設(shè)置塊緩存會(huì)浪費(fèi)內(nèi)存和CPU周期，更多的是它會(huì)產(chǎn)生更多的垃圾來(lái)由JVM提取。
• 映射表：在典型的MapReduce作業(yè)中，每個(gè)行都只能讀取一次，因此不需要將它們放入塊緩存。Scan對(duì)象可以通過(guò)setCaching方法將其關(guān)閉（將其設(shè)置為false）。如果您需要快速隨機(jī)讀取訪問(wèn)，您仍然可以在此表上保持塊緩存打開(kāi)狀態(tài)。一個(gè)例子就是統(tǒng)計(jì)表中提供實(shí)時(shí)流量的行數(shù)，緩存該表的每個(gè)塊都會(huì)產(chǎn)生大量流失，并且肯定會(huì)驅(qū)逐當(dāng)前正在使用的數(shù)據(jù)。

僅高速緩存META塊（fscache中的數(shù)據(jù)塊）

一個(gè)有趣的設(shè)置是我們只緩存META塊，并在每個(gè)訪問(wèn)中讀取DATA塊。如果DATA塊適用于fscache，則當(dāng)訪問(wèn)在非常大的數(shù)據(jù)集中完全隨機(jī)時(shí)，此替代方法可能有意義。要啟用此設(shè)置，請(qǐng)更改您的表格和每個(gè)列族集：BLOCKCACHE ? 'false'。您只對(duì)此列族 "禁用" BlockCache。您永遠(yuǎn)不能禁用META塊的緩存。由于HBASE-4683總是緩存索引和bloom塊，所以即使BlockCache被禁用，我們也會(huì)緩存META塊。

堆外塊緩存

如何啟用BucketCache

BucketCache的通常部署是通過(guò)一個(gè)管理類來(lái)設(shè)置兩個(gè)緩存層：由LruBlockCache實(shí)現(xiàn)的堆緩存和使用BucketCache實(shí)現(xiàn)的第二個(gè)緩存。管理類默認(rèn)為CombinedBlockCache。上一個(gè)鏈接描述了CombinedBlockCache實(shí)現(xiàn)的緩存“策略”。簡(jiǎn)而言之，它的工作方式是將元塊（INDEX和BLOOM）保留在堆上的LruBlockCache層中，并將DATA塊保存在BucketCache層中。

Pre-hbase-2.0.0版本

與原生堆內(nèi)LruBlockCache相比，從hbase-2.0.0之前的BucketCache中獲取數(shù)據(jù)時(shí)，抓取總是比較慢。但是，隨著時(shí)間的推移，延遲趨于不那么不穩(wěn)定，因?yàn)槭褂肂ucketCache時(shí)垃圾收集較少，因?yàn)樗诠芾鞡lockCache分配，而不是GC。如果BucketCache部署在堆外模式下，則該內(nèi)存根本不由GC管理。這就是為什么你會(huì)在2.0.0之前使用BucketCache，所以你的延遲不那么不穩(wěn)定，為了減少GC和堆碎片，所以你可以安全地使用更多的內(nèi)存。

在2.0.0之前版本中，可以配置BucketCache，以便接收LruBlockCache驅(qū)逐的victim。所有數(shù)據(jù)和索引塊首先緩存在L1中。當(dāng)驅(qū)逐發(fā)生在 L1，塊（或victims）將移至L2。設(shè)置cacheDataInL1通過(guò)(HColumnDescriptor.setCacheDataInL1(true)或shell，設(shè)置CACHE_DATA_IN_L1為true：來(lái)創(chuàng)建或修改列族，如：

hbase(main):003:0> create 't', {NAME => 't', CONFIGURATION => {CACHE_DATA_IN_L1 => 'true'}}                

hbase-2.0.0 +版本

HBASE-11425更改了HBase讀取路徑，以便它可以將讀取數(shù)據(jù)從堆中保留，避免將緩存數(shù)據(jù)復(fù)制到j(luò)ava堆上。在hbase-2.0.0中，堆外延遲接近堆緩存延遲時(shí)間，并且不會(huì)引發(fā)GC。

從HBase 2.0.0開(kāi)始，L1和L2的概念已被棄用。當(dāng)BucketCache打開(kāi)時(shí)，DATA塊將總是進(jìn)入BucketCache，而INDEX/BLOOM塊將進(jìn)入堆LRUBlockCache。cacheDataInL1支持已被刪除。

BucketCache塊緩存可以部署為堆外（off-heap）、文件（file）或mmaped文件模式。

您可以通過(guò)hbase.bucketcache.ioengine設(shè)置來(lái)進(jìn)行設(shè)置。將它設(shè)置為offheap使BucketCache將其分配置于堆外，并且file:PATH_TO_FILE的ioengine設(shè)置將指示BucketCache使用文件緩存（特別是在您將某些快速I/O附加到SSD等盒子時(shí)有用）。從2.0.0開(kāi)始，可以有多個(gè)文件支持BucketCache。當(dāng)緩存大小要求很高時(shí)，這非常有用。對(duì)于多個(gè)備份文件，將ioengine配置為files:PATH_TO_FILE1,PATH_TO_FILE2,PATH_TO_FILE3。BucketCache也可以配置為使用mmapped文件。將 ioengine 配置為 mmap: PATH_TO_FILE。

可以在我們繞過(guò)CombinedBlockCache策略的情況下部署分層設(shè)置，并將BucketCache作為嚴(yán)格的L2緩存工作到L1 LruBlockCache。對(duì)于這樣的設(shè)置，設(shè)置hbase.bucketcache.combinedcache.enabled為false。在這種模式下，從L1中逐出時(shí)，塊將轉(zhuǎn)到L2。當(dāng)一個(gè)塊被緩存時(shí)，它會(huì)先在L1中緩存。當(dāng)我們?nèi)ふ揖彺鎵K時(shí)，我們先看看L1，如果找不到，那么搜索L2。我們稱這種部署格式為Raw L1 + L2。注意：這個(gè)L1 + L2模式從2.0.0中刪除。當(dāng)使用BucketCache時(shí)，它將嚴(yán)格地是DATA緩存，并且LruBlockCache將緩存INDEX/META塊。

其他BucketCache配置包括：指定要在重新啟動(dòng)時(shí)保持緩存的位置、使用多少線程來(lái)編寫(xiě)緩存等。

要檢查它是否啟用，請(qǐng)查找描述緩存設(shè)置的日志行，它將詳細(xì)介紹BucketCache的部署方式。另請(qǐng)參閱UI。它將詳細(xì)介紹緩存分層及其配置。

BucketCache示例配置

此示例為具有1 GB堆緩存的4 GB脫離堆BucketCache提供配置。

在RegionServer上執(zhí)行配置。

設(shè)置hbase.bucketcache.ioengine和hbase.bucketcache.size> 0啟用CombinedBlockCache。讓我們假設(shè)RegionServer已經(jīng)設(shè)置為以5G堆運(yùn)行：即HBASE_HEAPSIZE=5g。

1. 首先，編輯RegionServer的hbase-env.sh，并將HBASE_OFFHEAPSIZE設(shè)置為大于所需的堆外大小的值，在本例中為4 GB（表示為4G）。我們將其設(shè)置為5G。對(duì)于我們的堆外緩存，這將是4G，對(duì)于任何其他堆外內(nèi)存使用（除了BlockCache以外，還有其他堆外存儲(chǔ)器的用戶，例如RegionServer中的DFSClient可以使用堆外存儲(chǔ)器）。

   HBASE_OFFHEAPSIZE=5G

2. 接下來(lái)，將以下配置添加到RegionServer的hbase-site.xml。

   <property>
     <name>hbase.bucketcache.ioengine</name>
     <value>offheap</value>
   </property>
   <property>
     <name>hfile.block.cache.size</name>
     <value>0.2</value>
   </property>
   <property>
     <name>hbase.bucketcache.size</name>
     <value>4196</value>
   </property>

3. 重新啟動(dòng)或滾動(dòng)重新啟動(dòng)群集，并檢查日志是否有任何問(wèn)題。

在上面，我們將BucketCache設(shè)置為4G。我們將堆上的LruBlockCache配置為RegionServer堆大小的20％（0.2）（0.2 * 5G = 1G）。換句話說(shuō)，像通常一樣配置L1 LruBlockCache（就好像沒(méi)有L2高速緩存一樣）。

HBase-10641引入了為HBase 0.98和更高版本的BucketCache的bucket配置多種大小的功能。要配置多個(gè)存儲(chǔ)區(qū)大小，請(qǐng)將新屬性hfile.block.cache.sizes（而不是hfile.block.cache.size）配置為以逗號(hào)分隔的塊大小列表（從最小到最大排列），并且不含空格。目標(biāo)是根據(jù)您的數(shù)據(jù)訪問(wèn)模式優(yōu)化存儲(chǔ)bucket大小。以下示例配置大小為4096和8192的存儲(chǔ)bucket。

<property>
  <name>hfile.block.cache.sizes</name>
  <value>4096,8192</value>
</property>

HBase中的直接內(nèi)存使用情況

默認(rèn)的最大直接內(nèi)存因JVM而異。傳統(tǒng)上它是64M或某一關(guān)系到被分配的堆大小（-Xmx）或根本沒(méi)有限制（JDK7）。HBase服務(wù)器使用直接內(nèi)存，特別是短路讀取，承載的DFSClient將分配直接內(nèi)存緩沖區(qū)。DFSClient使用的數(shù)量不容易量化；它是打開(kāi)的HFiles*hbase.dfs.client.read.shortcircuit.buffer.size的數(shù)目，其中hbase.dfs.client.read.shortcircuit.buffer.size設(shè)置為128k。如果你使用堆外緩存，你將會(huì)使用直接內(nèi)存。RPCServer使用ByteBuffer池。從2.0.0開(kāi)始，這些緩沖區(qū)是堆外ByteBuffers。啟動(dòng)您的JVM，在conf/hbase-env.sh中確保-XX:MaxDirectMemorySize設(shè)置，考慮堆外塊緩存(hbase.bucketcache.size)、DFSClient使用，RPC端ByteBufferPool最大大小。這必須比堆外BlockCache大小和最大ByteBufferPool大小的總和要高一點(diǎn)。為最大直接內(nèi)存大小分配額外的1-2 GB在測(cè)試中起作用。直接內(nèi)存是Java進(jìn)程堆的一部分，與-Xmx分配的對(duì)象堆是分開(kāi)的。MaxDirectMemorySize分配的值不得超過(guò)物理RAM，并且由于其他內(nèi)存要求和系統(tǒng)限制，可能會(huì)少于總可用RAM。

您可以通過(guò)查看UI 中的“服務(wù)器度量標(biāo)準(zhǔn)：內(nèi)存（Server Metrics: Memory）”選項(xiàng)卡，查看RegionServer配置為使用多少內(nèi)存和堆外/直接內(nèi)存以及以及每次使用的時(shí)間。它也可以通過(guò)JMX獲取。特別是可以在java.nio.type=BufferPool,name=directbean 上找到服務(wù)器當(dāng)前使用的直接內(nèi)存。Terracotta在Java中使用非堆內(nèi)存有一個(gè)很好的記錄。這是為了他們的產(chǎn)品BigMemory，但是很多問(wèn)題都提到了對(duì)任何試圖外堆的嘗試，檢查出來(lái)。

hbase.bucketcache.percentage.in.combinedcache

這是一個(gè)HBase 1.0之前的配置，因?yàn)樗芑靵y。這是一個(gè)浮點(diǎn)數(shù)，你會(huì)設(shè)置0.0到1.0之間的某個(gè)值，它的默認(rèn)值是0.9。如果部署使用CombinedBlockCache，則LruBlockCache L1大小計(jì)算為：(1 - hbase.bucketcache.percentage.in.combinedcache) * size-of-bucketcache ，BucketCache大小為：hbase.bucketcache.percentage.in.combinedcache * size-of-bucket-cache。如果size-of-bucket-cache指定為Megabytes，則它EITHER配置hbase.bucketcache.size的值；如果hbase.bucketcache.size在0到1.0之間，則hbase.bucketcache.size * -XX:MaxDirectMemorySize。

在1.0中，它應(yīng)該更直接。Onheap LruBlockCache大小設(shè)置為使用hfile.block.cache.size設(shè)置（并非最佳）的java堆的一小部分，并且BucketCache在絕對(duì)兆字節(jié)中設(shè)置為上述值。

壓縮BlockCache

HBASE- 11331引入了懶惰的BlockCache解壓縮，更簡(jiǎn)單地稱為壓縮BlockCache。當(dāng)啟用壓縮BlockCache時(shí)，數(shù)據(jù)和編碼數(shù)據(jù)塊將以磁盤(pán)格式緩存在BlockCache中，而不是在緩存之前解壓縮和解密。

對(duì)于承載更多數(shù)據(jù)而不適合緩存的RegionServer，通過(guò)SNAPPY壓縮啟用此功能可以使吞吐量增加50％，平均延遲增加30％，同時(shí)將垃圾收集增加80％，并增加整體CPU負(fù)載2％。有關(guān)如何衡量和實(shí)現(xiàn)性能的更多詳細(xì)信息，請(qǐng)參閱HBASE-11331。對(duì)于容納適合緩存的數(shù)據(jù)的RegionServer，或者如果您的工作負(fù)載對(duì)額外的CPU或垃圾收集負(fù)載敏感，則可能會(huì)收到較少的收益。

壓縮的BlockCache默認(rèn)是禁用的。要啟用它，請(qǐng)?jiān)谒蠷egionServers的hbase-site.xml中設(shè)置hbase.block.data.cachecompressed為true。