1.本文說(shuō)明
筆者最近一年從事維護(hù)Hbase相關(guān)工作，總結(jié)相關(guān)文章用于闡述對(duì)于Hbase的部分理解，本文知識(shí)點(diǎn)來(lái)源于
《HBase原理與實(shí)踐》第四章
2.前言
對(duì)于使用Hbase的業(yè)務(wù)方來(lái)說(shuō)，從Hbase客戶端到Hbase服務(wù)端，再到HDFS客戶端，最后到HDFS服務(wù)端，這是一整條路徑，其中任何一個(gè)環(huán)節(jié)出現(xiàn)問(wèn)題，都會(huì)影響業(yè)務(wù)的可用性并造成延遲。因此，Hbase的業(yè)務(wù)方需要對(duì)Hbase客戶端有較好地理解，以便優(yōu)化服務(wù)體驗(yàn)。而事實(shí)上，由于Hbase本身功能的復(fù)雜性以及Region定位功能設(shè)計(jì)在客戶端上，導(dǎo)致Hbase客戶端并不足夠輕量級(jí)。
2.1 Hbase客戶端實(shí)現(xiàn)
Hbase提供了面向Java、C/C++、Python等多種語(yǔ)言的客戶端，由于Hbase本身是Java開(kāi)發(fā)的，所以非Java語(yǔ)言的客戶端需要先訪問(wèn)ThriftServer，然后通過(guò)ThriftServer的Java Hbase客戶端來(lái)請(qǐng)求Hbase集群。
對(duì)其他語(yǔ)言的客戶端，推薦使用ThriftServer的方式來(lái)訪問(wèn)Hbase服務(wù)。
- 基礎(chǔ)訪問(wèn)說(shuō)明
步驟1：獲取集群的Configuration對(duì)象
對(duì)訪問(wèn)Hbase集群的客戶端來(lái)說(shuō)，一般需要3個(gè)配置文件：hbase-site.xml、core-site.xml、hdfs-site.xml。只需要把這3個(gè)配置文件放到JVM能加載的classpath下即可。
步驟2：通過(guò)Configuration初始化集群Connection
Connection是Hbase客戶端進(jìn)行一切操作的基礎(chǔ)，它維持了客戶端到整個(gè)Hbase集群的連接，例如一個(gè)Hbase集群中有2個(gè)HMaste、5個(gè)RegionServer，那么一般來(lái)說(shuō)，這個(gè)Connection會(huì)維持一個(gè)到Active Master的TCP連接和5個(gè)到RegionServer的TCP連接。
通常，一個(gè)進(jìn)程只需要為一個(gè)獨(dú)立的集群建立一個(gè)Connection即可，并不需要建立連接池。
建立多個(gè)連接，是為了提高客戶端的吞吐量，連接池是為了減少建立和銷毀連接的開(kāi)銷，而Hbase的Connection本質(zhì)上是由連接多個(gè)節(jié)點(diǎn)的TCP鏈接組成，客戶端的請(qǐng)求分發(fā)到各個(gè)不同的物理節(jié)點(diǎn)，因此吞吐量并不存在問(wèn)題，另外，客戶端主要負(fù)責(zé)收發(fā)請(qǐng)求，而大部分請(qǐng)求的響應(yīng)耗時(shí)都花在服務(wù)端，所以使用連接池也不應(yīng)能帶來(lái)更高的收益。
Connection還緩存了訪問(wèn)的Meta信息，這樣后續(xù)的大部分請(qǐng)求都可以通過(guò)緩存的Meta信息定位到對(duì)應(yīng)的RegionServer。
步驟3:通過(guò)Connection初始化Table
Table是一個(gè)非常輕量級(jí)的對(duì)象，它實(shí)現(xiàn)了用戶訪問(wèn)表的所有API操作，例如Put、Get、Delete、Scan等，本質(zhì)上，它所使用的連接資源、配置信息、線程池、Meta緩存等，都來(lái)自步驟2創(chuàng)建的Connection對(duì)象，因此由一個(gè)Connectiobn創(chuàng)建的多個(gè)Table，都會(huì)共享連接、配置信息、線程池、Meta緩存這些資源。
步驟4:通過(guò)Table執(zhí)行Put和Scan操作。
2.2 定位Meta表
Hbase一張表的數(shù)據(jù)是由多個(gè)Region構(gòu)成，而這些Region是分布在整個(gè)集群的RegionServer上的，那么客戶端在做任何數(shù)據(jù)操作的時(shí)候，都要先確定數(shù)據(jù)在哪個(gè)RegionServer上，然后再根據(jù)Region的RegionServer信息，去對(duì)應(yīng)的RegionServer上讀取數(shù)據(jù)。
hbase:meta表的結(jié)構(gòu)非常簡(jiǎn)單，整個(gè)表只有一個(gè)名為info的CF，而且Hbase保證hbase:meta表始終只有一個(gè)Region，這是為了確保meta表多次操作的原子性，因?yàn)镠base本質(zhì)上只支持Region級(jí)別的事務(wù)。
-
hbase:meta的設(shè)計(jì)
hbase:meta的一個(gè)rowkey就對(duì)應(yīng)一個(gè)Region，rowkey主要由TableName（業(yè)務(wù)表名）、StartRow（業(yè)務(wù)表Region區(qū)間的起始rowkey）、TimeStamp（Region創(chuàng)建的時(shí)間戳）、EncodeName（上面3個(gè)字段的MD5Hex值）4個(gè)字段拼接而成。
image.png
各個(gè)字段解釋的腦圖如下：
Hbase-Meta.png -
如何根據(jù)rowkey查找業(yè)務(wù)的Region，例如：現(xiàn)在需要查找micloud，note表中rowkey=‘userid334452'所在的region，可以設(shè)計(jì)如下語(yǔ)句：
image.png - 解惑1，為什么需要用一個(gè)9999999999999的timestamp，以及為什么要用反向查詢Reversed Scan呢？
答：首先，9999999999999是13位時(shí)間戳中最大值，其次因?yàn)镠base在設(shè)計(jì)hbase:meta表rowkey時(shí)，把業(yè)務(wù)表的StartRow（而不是StopRow）放在hbase:meta表的rowkey上。這樣，如果某個(gè)Region對(duì)應(yīng)的區(qū)間是[bbb,ccc)，為了定位rowkey=bc的Region，通過(guò)正向Scan只會(huì)找到[bbb,ccc)這個(gè)區(qū)間的下一個(gè)區(qū)間，但是，即使我們找到了[bbb,ccc）的下一個(gè)區(qū)間，也沒(méi)法快速找到[bbb,ccc)這個(gè)Region的信息，所以采用ReversedScan是比較合理的方案。 -
解惑2，Hbase作為一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)，一個(gè)大的集群可能承擔(dān)數(shù)千萬(wàn)的查詢寫(xiě)入請(qǐng)求，而hbase:meta表只有一個(gè)Region，如果所有的流量都先請(qǐng)求hbase:meta表找到Region，再請(qǐng)求Region所在的RegionServer，那么hbase:meta表將承載巨大的壓力，這個(gè)Region會(huì)馬上變?yōu)闊狳c(diǎn)，且根本無(wú)法承擔(dān)數(shù)千萬(wàn)的流量，如何解決這個(gè)問(wèn)題？
image.png
答：把hbase:meta表的Region信息緩存在Hbase客戶端，Hbase客戶端有個(gè)叫做MetaCache的緩存，在調(diào)用Hbase API時(shí)，客戶端會(huì)先去MetaCache中找到業(yè)務(wù)RowKey所在的Region，這個(gè)Region可能有一下三種情況：
1.Region信息為空，說(shuō)明MetaCache中沒(méi)有這個(gè)RowKey所在Region的任何Cache。此時(shí)直接用上述查詢語(yǔ)句去hbase:meta表中Reversed Scan即可，注意首次查找時(shí)，需要先讀取ZK的/hbase/meta-region-server這個(gè)ZNode，以便確定hbase:meta表所在的RS。在hbase:meta表中找到業(yè)務(wù)rowkey所在的Region之后，將（regionStartRow,region）這樣的二元組信息存放在一個(gè)MetaCache中。
2.Region信息不為空，但是調(diào)用RPC請(qǐng)求對(duì)應(yīng)RS后，發(fā)現(xiàn)Region并不在這個(gè)RS上；這說(shuō)明MetaCache過(guò)期了，同樣直接Reversed Scan Hbase:meta表，找到正確的Region并緩存。通常，某些Region在兩個(gè)RS之間移動(dòng)后會(huì)發(fā)生這種情況，但事實(shí)上，無(wú)論RS宕機(jī)導(dǎo)致的Region移動(dòng)，還是由于Balance導(dǎo)致Region移動(dòng)，發(fā)生的概率都極小。而且，也只會(huì)對(duì)Region移動(dòng)后的極少數(shù)請(qǐng)求產(chǎn)生影響，這些請(qǐng)求只需要通過(guò)Hbase客戶端自動(dòng)重試locate meta即可成功。
3.Region信息不為空，且調(diào)用RPC請(qǐng)求到對(duì)應(yīng)RS后，發(fā)現(xiàn)是正確的RS，絕大部分的請(qǐng)求屬于這種情況，也是代價(jià)極小的方案。
由于MetaCache的設(shè)計(jì)，客戶端分?jǐn)偭藥缀跛卸ㄎ籖egion的流量壓力；避免出現(xiàn)所有流量都打在hbase:meta的情況，這也是Hbase具備良好擴(kuò)展性的基礎(chǔ)。
4.需要注意，所謂Region級(jí)別事務(wù)，就是當(dāng)多個(gè)操作落在同一個(gè)Region內(nèi)時(shí)，Hbase能保證這一批操作執(zhí)行的原子性。如果多個(gè)操作分散在不同的Region，則無(wú)法保證這批操作的原子性。
2.3 Scan的復(fù)雜之處
2.3.1 基礎(chǔ)流程
Hbase客戶端的Scan操作應(yīng)該是比較復(fù)雜的RPC操作，為了滿足客戶端多樣化的數(shù)據(jù)庫(kù)查詢需求，Scan必須能設(shè)置眾多維度的屬性。常用的有startRow、endRow、Filter、caching、batch、reversed、maxResultSize、version、timeRange等。
table.getScanner(scan)可以拿到一個(gè)Scanner，然后只要不斷地執(zhí)行scanner.next()就能拿到一個(gè)Result，如圖4-3所示：
用戶每次執(zhí)行scanner.next()，都會(huì)嘗試去名為cache的隊(duì)列中拿result(步驟4)，如果cache隊(duì)列為空，則會(huì)發(fā)起一次RPC向服務(wù)端請(qǐng)求當(dāng)前scanner的后續(xù)result數(shù)據(jù)（步驟1）?？蛻舳耸盏絩esult列表后(步驟2)，通過(guò)scanResultCache把這些results內(nèi)的多個(gè)Cell進(jìn)行重組，最終組成用戶需要的result放入到Cache中（步驟3）。其中步驟1+步驟2+步驟3統(tǒng)稱為loadCache操作。
為什么要在步驟3對(duì)Rpc Responce中的result進(jìn)行重組呢？這是因?yàn)镽S為了避免被當(dāng)前RPC請(qǐng)求耗盡資源，實(shí)現(xiàn)了多個(gè)維度的資源限制（例如timeout、單次RPC響應(yīng)最大字節(jié)數(shù)），一旦某個(gè)維度資源到達(dá)閾值，就馬上把當(dāng)前拿到的Cell返回給客戶端。這樣客戶端拿到的result可能就不是一行完整的數(shù)據(jù)，因此在步驟3需要對(duì)result進(jìn)行重組。
2.3.2 幾個(gè)重要概念
2.3.3 Hbase客戶端避坑指南
2.3.3.1 RPC重試配置要點(diǎn)
在Hbase客戶端到服務(wù)端的通信過(guò)程中，可能會(huì)碰到各種各樣的異常，例如有如下幾種導(dǎo)致重試的常見(jiàn)異常：
1.待訪問(wèn)Region所在的RS宕機(jī)，此時(shí)Region已經(jīng)被移到一個(gè)新的RS上，但是由于客戶端存在meta緩存，首次RPC請(qǐng)求仍然訪問(wèn)到了舊的RS，后續(xù)將重試發(fā)起RPC
2.服務(wù)端負(fù)載較大，導(dǎo)致單次RPC響應(yīng)超時(shí)，客戶端后續(xù)將繼續(xù)重試，直到RPC成功或者超過(guò)客戶容忍最大延遲。
2.3.3.2 Hbase常見(jiàn)的幾個(gè)超時(shí)參數(shù)
1.hbase.rpc.timeout：表示單次RPC請(qǐng)求的超時(shí)時(shí)間，一旦單次RPC超過(guò)該時(shí)間，上層將收到TimeOutException，默認(rèn)時(shí)間為60000ms.
2.hbase.client.retries.number：表示調(diào)用API時(shí)最多容許發(fā)生多少次RPC重試，默認(rèn)為35次。
3.hbase.client.pause：表示連續(xù)兩次RPC重試之間的休眠時(shí)間，默認(rèn)為100ms。重試策略如下：
第1次 RPC重試 100ms
第2次 RPC重試 200ms
第3次 RPC重試 300ms
第4次 RPC重試 500ms
第5次 RPC重試 1000ms
第6次 RPC重試 2000ms
按照默認(rèn)配置將會(huì)卡在休眠和重試兩個(gè)步驟。
4.hbase.client.operation.timeout：表示單次API的超時(shí)時(shí)間，默認(rèn)值為1200000ms，注意，get/put/delete等表操作稱為一次API操作，一次API可能會(huì)有多次RPC重試，這個(gè)operation.timeout限制的是API操作的總超時(shí)。
案例：
假設(shè)某業(yè)務(wù)要求單次Hbase的讀請(qǐng)求延遲不超過(guò)1s，那么該如何設(shè)置上述4個(gè)超時(shí)參數(shù)呢？
首先，hbase.client.operation.timeout應(yīng)該設(shè)為1s，其次，在SSD集群上，如果集群參數(shù)設(shè)置合適且集群服務(wù)正常，則基本可以保證p99延遲在100ms以內(nèi)，因此hbase.rpc.timeout設(shè)成100ms，這里，hbase.client.pause用默認(rèn)的100ms，hbase.client.retries.number可以稍微設(shè)大一點(diǎn)，比如6次。
2.3.3.3 CAS接口是Region級(jí)別串行執(zhí)行的，吞吐受限
這些接口在高并發(fā)場(chǎng)景下，能很好地保證讀取與寫(xiě)入操作的原子性。例如：有多個(gè)分布式的客戶端同時(shí)更新一個(gè)計(jì)數(shù)器Count，可以通過(guò)increment接口來(lái)保證任意時(shí)刻都只有一個(gè)客戶端能成功原子地執(zhí)行count++操作。
需要特別注意的是，這些CAS接口在RS上是Region級(jí)別串行執(zhí)行的，也就是說(shuō)，同一個(gè)Region內(nèi)部的多個(gè)CAS操作是嚴(yán)格串行執(zhí)行的，不同Region間的多個(gè)CAS操作可以并行執(zhí)行。
以checkAndPut為例，簡(jiǎn)要說(shuō)明一下CAS的操作步驟：
1.服務(wù)端拿到Region的行鎖（row-lock），避免出現(xiàn)兩個(gè)線程同時(shí)修改一行數(shù)據(jù)，從而破壞了行級(jí)別原子性的情況。
2.等待該Region內(nèi)的所有寫(xiě)入事務(wù)都已經(jīng)成功提交并在mvcc上可見(jiàn)。
3.通過(guò)Get操作拿到需要check的行數(shù)據(jù)，進(jìn)行條件檢查，若條件不符合，則終止CAS。
4.將checkAndPut的put數(shù)據(jù)持久化。
5.釋放1）步拿到的行鎖。
關(guān)鍵在于第2）步，必須要等所有正在寫(xiě)入的事務(wù)成功提交并在mvcc上可見(jiàn)。
因此那些依賴CAS的接口服務(wù)，需要意識(shí)到這個(gè)操作的吞吐是受限的，因?yàn)镃AS操作本質(zhì)上是Region級(jí)別串行執(zhí)行的。當(dāng)然，在Hbase2.x版已經(jīng)調(diào)整設(shè)計(jì)，對(duì)同一個(gè)Region內(nèi)的不同行可以并行執(zhí)行CAS，這大大提高了Region內(nèi)的CAS吞吐。
2.3.3.4 Scan Filter設(shè)置
Hbase作為一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)，提供了多樣化的查詢過(guò)濾手段，最常用的就是Filter，例如一個(gè)表有很多個(gè)列簇，用戶想找到那些列簇不為C的數(shù)據(jù)?？梢栽O(shè)計(jì)一個(gè)如下的Scan:
如果想查詢列簇不為C且Qualifier在[a,z]區(qū)間的數(shù)據(jù)，可以設(shè)計(jì)一個(gè)如下的Scan:
上面代碼使用了一個(gè)帶AND的FilterList來(lái)連接FamilyFilter和ColumnRangeFilter，有了Filter，大量無(wú)效數(shù)據(jù)可以在服務(wù)端內(nèi)部過(guò)濾，相比直接返回全局?jǐn)?shù)據(jù)到客戶端，然后在客戶端過(guò)濾，要高效很多。
案例剖析
prefixFilter
1.PrefixFilter是將RowKey前綴為指定字節(jié)串的數(shù)據(jù)都過(guò)濾出來(lái)并返回給用戶。
例如：如下Scan會(huì)返回所有RowKey前綴為'def'的數(shù)據(jù)：
注意，這個(gè)Scan雖然能得到預(yù)期的效果，但并不高效。因?yàn)閷?duì)于rowkey在區(qū)間（-?，def)的數(shù)據(jù)，Scan會(huì)一條條掃描，發(fā)現(xiàn)前綴不為def，就讀下一行，直到找到第一個(gè)Rowkey前綴為def的行為止。
解決方法1:
在Scan中簡(jiǎn)單加一個(gè)startRow即可，RegionServer發(fā)現(xiàn)Scan設(shè)了startRow，首先尋址定位到這個(gè)startRow，然后從這個(gè)位置開(kāi)始掃描數(shù)據(jù)，這樣就跳過(guò)了大量的（-?，def)的數(shù)據(jù)。代碼如下所示：
解決方法2:
將PrefixFilter直接展開(kāi)，掃描[def,deg)區(qū)間的數(shù)據(jù)，這樣效率是最高的
pageFilter
Hbase里的Filter狀態(tài)全部都是Region內(nèi)有效的，也就是說(shuō)，Scan一旦從一個(gè)Region切換到另一個(gè)Region，之前那個(gè)Filter的內(nèi)部狀態(tài)就無(wú)效了，新Region內(nèi)用的其實(shí)是一個(gè)全新的Filter。具體到這個(gè)問(wèn)題，就是PageFilter內(nèi)部計(jì)數(shù)器從一個(gè)Region切換到另一個(gè)Region，計(jì)數(shù)器已經(jīng)被清0.
當(dāng)然，如果想實(shí)現(xiàn)分頁(yè)功能，可以不通過(guò)Filter而直接通過(guò)limit實(shí)現(xiàn)，代碼如下：
所以，對(duì)用戶來(lái)說(shuō)，正常情況下PageFilter并沒(méi)有太多存在的價(jià)值。
SingleColumnPageFilter
這個(gè)Filter的定義比較復(fù)雜，讓人有點(diǎn)難以理解，但是事實(shí)上，這個(gè)Filter卻非常有用，下面舉例說(shuō)明：
這個(gè)例子表面上是將列簇為family、列為qualifier、且值為value的Cell返回給用戶，但是事實(shí)上，對(duì)那些不包含family:qualifier列的行，也會(huì)默認(rèn)返回給用戶。
如果用戶不希望讀取那些不包含family:qualifier的數(shù)據(jù)，需要設(shè)計(jì)如下Scan:
不要使用SingleColumnValueFilter和其他Filter組合成FilterList，直接指定列，通過(guò)ValueFilter替換掉SingleColumnValueFilter，代碼如下：
2.3.3.4 少量寫(xiě)和批量寫(xiě)
Hbase是一種對(duì)寫(xiě)入操作非常友好的系統(tǒng)，但是當(dāng)業(yè)務(wù)有大批量的數(shù)據(jù)要寫(xiě)入Hbase時(shí)，仍會(huì)碰到寫(xiě)入瓶頸，為了適應(yīng)不同數(shù)據(jù)量的寫(xiě)入場(chǎng)景，Hbase提供了3種常見(jiàn)的數(shù)據(jù)寫(xiě)入API，如下：
2.3.3.5 業(yè)務(wù)發(fā)現(xiàn)請(qǐng)求延遲很高，但是Hbase服務(wù)端延遲正常
某些業(yè)務(wù)發(fā)現(xiàn)Hbase客戶端上報(bào)的P99和P999延遲非常高，但是觀察HBase服務(wù)端的P99和P999延遲正常，這種情況下一般需要觀察Hbase客戶端的監(jiān)控和日志。按照我們的經(jīng)驗(yàn)，一般來(lái)說(shuō)，有這樣一些常見(jiàn)問(wèn)題：
- Hbase客戶端所在進(jìn)程JAVA GC，由于Hbase客戶端作為業(yè)務(wù)代碼的一個(gè)Java依賴，因此一旦業(yè)務(wù)進(jìn)程發(fā)生較為嚴(yán)重的FULL GC，必然會(huì)導(dǎo)致Hbase客戶端監(jiān)控到的請(qǐng)求延遲很高，這時(shí)需要排查GC原因。
- 業(yè)務(wù)進(jìn)程所在機(jī)器的CPU或者網(wǎng)絡(luò)負(fù)載較高，對(duì)于上層業(yè)務(wù)來(lái)說(shuō)一般不涉及磁盤(pán)資源開(kāi)銷，所以主要看load和網(wǎng)絡(luò)是否過(guò)載。
- Hbase客戶端層面的BUG，這種情況出現(xiàn)概率不大，但也不排除有這種可能。
2.3.3.6 Batch數(shù)據(jù)量太大，可能導(dǎo)致MutilActionResultTooLarge異常
Hbase的batch接口使得用戶可以把一批操作通過(guò)一次RPC發(fā)送到服務(wù)端，以便提升系統(tǒng)的吞吐量，這些操作可以是PUT、DELETE、GET、INCREMENT、APPEND等等。像Get或者INCREMENT的BATCH操作中，需要先把對(duì)應(yīng)的Block從HDFS中讀取到HBASE內(nèi)存中，然后通過(guò)RPC返回相關(guān)數(shù)據(jù)給客戶端。
如果Batch中的操作過(guò)多，則可能導(dǎo)致一次RPC讀取的Block數(shù)據(jù)量很多，容易造成Hbase的RegionServer出現(xiàn)OOM，或者出現(xiàn)長(zhǎng)時(shí)間的FULL GC。因此，HBase的RegionServer會(huì)限制每次請(qǐng)求的Block總字節(jié)數(shù)，一旦超過(guò)則會(huì)報(bào)MultiActionResultTooLarge異常，此時(shí)客戶端最好控制每次Batch操作的個(gè)數(shù)，以免服務(wù)端為單次RPC消耗太多內(nèi)存。
