HBase工作原理是什么

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)HBase工作原理是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

1. HBase系統(tǒng)架構(gòu)圖

整個HBase架構(gòu)重點關(guān)注幾部分：HMaster、HRegionServer、Zookeeper、HRegion（內(nèi)部包括HLog、StoreFile、MemStore）。

2. HMaster介紹

Hbase集群采用的是master/slave模式，HMaster是集群老大（后面簡稱Master），統(tǒng)籌管理，所以干的底層雜活不多，負(fù)載不高。

2.1 Master職責(zé)
（1）為RegionServer分配Region。
（2）負(fù)責(zé)RegionServer的負(fù)載均衡。
（3）發(fā)現(xiàn)下線或dead的RegionServer，并重新分配其上的Region。
（4）回收HDFS上的垃圾文件。
（5）處理Schema的更新請求。

2.2 Master工作機(jī)制
(1) master上線
1）從zookeeper上獲取唯一一個代表active master的鎖，用來阻止其它master成為master。
2）掃描zookeeper上的server父節(jié)點，獲得當(dāng)前可用的region server列表。
3）和每個region server通信，獲得當(dāng)前已分配的region和region server的對應(yīng)關(guān)系。
4）掃描.META.region的集合，計算得到當(dāng)前還未分配的region，將他們放入待分配region列表。 
(2) master下線
由于master只維護(hù)表和region的元數(shù)據(jù)，而不參與表數(shù)據(jù)IO的過程（尋址訪問zk和RegionServer，數(shù)據(jù)讀寫訪問RegionServer），所以Master的負(fù)載很低，master下線僅導(dǎo)致所有元數(shù)據(jù)的修改被凍結(jié)(無法創(chuàng)建刪除表，無法修改表的schema，無法進(jìn)行region的負(fù)載均衡，無法處理region 上下線，無法進(jìn)行region的合并，唯一例外的是region的split可以正常進(jìn)行，因為只有region server參與)，表的數(shù)據(jù)讀寫還可以正常進(jìn)行。因此master下線短時間內(nèi)對整個hbase集群沒有影響。從上線過程可以看到，master保存的 信息全是可以冗余信息（都可以從系統(tǒng)其它地方收集到或者計算出來），因此，一般hbase集群中總是有一個master在提供服務(wù)，還有一個以上 的’master’在等待時機(jī)搶占它的位置。
 
3. HRegionServer介紹

HRegionServer（后面簡稱RegionSever）是集群中的slave，負(fù)責(zé)處理具體的讀寫請求及對數(shù)據(jù)的compact和split等具體過程。

3.1 RegionServer職責(zé)
(1) 維護(hù)Master給它分配的Region，并處理這些Region的I/O請求。
(2) 負(fù)責(zé)切分在運行過程中不斷變大的Region。
3.2 RegionServer工作機(jī)制
(1) regionserver上線
master通過zk來獲取regionserver信息。當(dāng)某個regionserver啟動時，首先會在zk的server目錄下建立一個屬于自己的文件，并獲得該文件的獨占鎖。由于master訂閱了server目錄的變更消息，所以當(dāng)server目錄下的文件出現(xiàn)新增或變更時，zk會及時通知master。

(2) regionserver下線
當(dāng)region server下線時，它和zookeeper的會話斷開，zookeeper而自動釋放代表這臺server的文件上的獨占鎖。而master不斷輪詢 server目錄下文件的鎖狀態(tài)。如果master發(fā)現(xiàn)某個region server丟失了它自己的獨占鎖，(或者master連續(xù)幾次和region server通信都無法成功),master就是嘗試去獲取代表這個region server的讀寫鎖，一旦獲取成功，就可以確定：
1) region server和zookeeper之間的網(wǎng)絡(luò)斷開了。
2) region server掛了。
的其中一種情況發(fā)生了，無論哪種情況，region server都無法繼續(xù)為它的region提供服務(wù)了，此時master會刪除server目錄下代表這臺region server的文件，并將這臺region server的region分配給其它還活著的同志。
如果網(wǎng)絡(luò)短暫出現(xiàn)問題導(dǎo)致region server丟失了它的鎖，那么region server重新連接到zookeeper之后，只要代表它的文件還在，它就會不斷嘗試獲取這個文件上的鎖，一旦獲取到了，就可以繼續(xù)提供服務(wù)。

4. Zookeeper介紹

Zookeeper應(yīng)該可以說是在Hadoop生態(tài)中主從結(jié)構(gòu)架構(gòu)的設(shè)計中是大眾情人，它能夠很好的協(xié)調(diào)整個集群統(tǒng)統(tǒng)一有序的工作。在HBase的架構(gòu)中，ZooKeeper提供了類似文件系統(tǒng)一樣的訪問目錄和文件（稱為znode）的功能，通常分布式文件系統(tǒng)利用它協(xié)調(diào)所有權(quán)、注冊服務(wù)、監(jiān)聽更新。
每臺Region服務(wù)器在ZooKeeper中注冊一個自己的臨時節(jié)點，主服務(wù)器會利用這些臨時節(jié)點來發(fā)現(xiàn)可用服務(wù)器，還可以利用臨時節(jié)點來跟蹤機(jī)器故障和網(wǎng)絡(luò)分區(qū)。
在ZooKeeper服務(wù)器中，每個臨時節(jié)點都屬于某一個會話，這個會話是客戶端連接ZooKeeper服務(wù)器后自動生成的。每個會話在服務(wù)器中有一個唯一的id，并且客戶端會以此id不斷的向ZooKeeper發(fā)送“心跳”，一旦發(fā)生故障ZooKeeper客戶端進(jìn)程死掉，ZooKeeper服務(wù)器會判定該會話超時，并自動刪除屬于它的臨時節(jié)點。
HBase還可以利用ZooKeeper確保只有一個主服務(wù)器在運行，存儲用于發(fā)現(xiàn)Region的引導(dǎo)位置，作為一個Region服務(wù)器的注冊表，一級實現(xiàn)其他目的。ZooKeeper是一個關(guān)鍵組成部分，沒有它HBase就無法工作。

Zookeeper的主要功能：

(1) 保證master的唯一性。    原理：master啟動時會從ZK上獲取一個active master鎖，阻止其他節(jié)點成為master。 
(2) 實時監(jiān)控RegionServer的狀態(tài)，將Regionserver上下線的消息及時告知master。
(3) 存儲所有Region的尋址入口（即ROOT表在哪臺服務(wù)器上）。
(4) 存儲Hbase的Scema（Zookeeper存的是-ROOT-和.META.這兩張表的location，實際存在HBase中），包括有哪些table，每個table有哪些column family。
 

5. Region介紹

Region是HBase存儲和管理數(shù)據(jù)的基本單位。Region和RegionServer是多對一的關(guān)系，即一個Region只能同時被一個RegionServer使用，而一個RegionServer可以同時處理多個Region。

5.1 Region和Table的關(guān)系

Region實際是Table在行方向上的一個個劃分，一般來說一個表在初始的時候只有一個Region，隨著數(shù)據(jù)的增多，當(dāng)達(dá)到某個閾值時，ReginServer就會把這個Region切分成兩個Region，以此類推。

5.2 Region細(xì)分

繼續(xù)深究的話，Region還是可以再細(xì)分的，它是由一個或多個Store組成的，在這里有必要搞清楚幾個基本概念：HFile、HLog、StoreFile、MemStore。

上圖反應(yīng)了客戶端對數(shù)據(jù)請求在底層的流轉(zhuǎn)，可以簡單理解為：HLog實際就是備份數(shù)據(jù)，用來做災(zāi)難恢復(fù)的；MemStore是緩存數(shù)據(jù)，用來提高讀寫效率；StoreFile是最下面一層的存儲，它基本等于HFile，前者是相對于HBase而已邏輯上的存儲，后者是相對于HDFS在物理上的存儲（也就是前面說的hbase不管存，數(shù)據(jù)二進(jìn)制文件存在HDFS上，指的就是HFile）。

5.2.1 關(guān)于HLog

(1)HLog 又叫WAL(Write Ahead Log)，類似于mysql中的binlog，用來做災(zāi)難恢復(fù)的，HLog記錄所有數(shù)據(jù)的變更，一旦數(shù)據(jù)發(fā)生變化就會在HLog里記錄，所以也可以從這里恢復(fù)。
(2) 每個RegionServer維護(hù)一個HLog，而不是每個Region對應(yīng)一個。所以不同的Region（來自不同的table）的日志就會混合在一起。
        好處：所有日志都往一個文件寫，減少磁盤尋址次數(shù)，提高對Hbase寫的性能。
        缺點：假設(shè)某臺RegionServer下線，正好要恢復(fù)某個Region，這時就需要將這個HLog發(fā)送到其他RegionServer然后再恢復(fù)。
補充：HLog就是一個普通的Hadoop Sequence File，Sequence File的key為HLogKey對象（包括數(shù)據(jù)的歸屬信息、tablename、region等信息，還包括sequence number和timestamp），value為Hbase實際的key-value對象數(shù)據(jù)。

5.2.2 關(guān)于MemStore

MemStore是擋在StoreFile前面的一層緩存，當(dāng)Region請求到達(dá)時，會先去在MemStore中查找，若命中直接返回結(jié)果，這樣可以避免對大規(guī)模的StoreFile進(jìn)行掃描。

6. 數(shù)據(jù)讀寫過程
數(shù)據(jù)在更新時首先寫入Log(WAL log)和內(nèi)存(MemStore)中，MemStore中的數(shù)據(jù)是排序的，當(dāng)MemStore累計到一定閾值時，就會創(chuàng)建一個新的MemStore，并且將老的MemStore添加到Flush隊列，由單獨的線程Flush到磁盤上，成為一個StoreFile。于此同時，系統(tǒng)會在Zookeeper中記錄一個Redo Point，表示這個時刻之前的變更已經(jīng)持久化了。(minor Compact)當(dāng)系統(tǒng)出現(xiàn)意外時，可能導(dǎo)致內(nèi)存(MemStore)中的數(shù)據(jù)丟失，此時使用Log(WAL log)來恢復(fù)Checkpoint之后的數(shù)據(jù)。StoreFile是只讀的，一旦創(chuàng)建后就不可以再修改。因此Hbase的更新其實是不斷追加的操作。當(dāng)一個Store中的StoreFile達(dá)到一定的閾值后，就會進(jìn)行一次合并(Major Compact),將對同一個Key的修改合并到一起，形成一個大的StoreFile，當(dāng)StoreFile的大小達(dá)到一定閾值后，又會對 StoreFile進(jìn)行Split，等分為兩個StoreFile。由于對表的更新是不斷追加的，處理讀請求時，需要訪問Store中全部的 StoreFile和MemStore，將他們的按照row key進(jìn)行合并，由于StoreFile和MemStore都是經(jīng)過排序的，并且StoreFile帶有內(nèi)存中索引，合并的過程還是比較快。

6.1 讀請求
（1）客戶端通過ZK和ROOT表、META表找到目標(biāo)數(shù)據(jù)所在的RegionServer。
（2）請求RegionServer查找目標(biāo)數(shù)據(jù)。
（3）由RegionServer定位到目標(biāo)數(shù)據(jù)所在的Region，發(fā)出查詢請求。
（4）Region會先從Memstore中查，命中則返回（先查Memstore的好處是在內(nèi)存中，查詢快）。
（3）若Memstore沒有，則掃描StoreFile（這個過程可以能會掃描很多StorFfiel，借助Bloomfilter）。

6.2 寫請求
（1）Client向Regionserver提交寫請求。
（2）Regionserver找到目標(biāo)Region。
（3）Region會檢查數(shù)據(jù)是否與Schema一致。
（4）若客戶端沒有指定時間戳，默認(rèn)取當(dāng)前時間。
（5）將數(shù)據(jù)更新到WAL Log。
（6）將數(shù)據(jù)寫入到Memstore。
（7）判斷Memstore是否需要Flush為Storefile文件。

7. -ROOT-和.Meta.兩張內(nèi)置表介紹

Hbase內(nèi)置兩張表(-ROOT-、.META.)來管理region相關(guān)信息，且這兩張表結(jié)構(gòu)相同。

大致尋址過程：client-->Zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client

關(guān)于兩張表的具體介紹及實例尋址過程，參考：http://greatwqs.iteye.com/blog/1838904

注意幾點：
(1) 為什么要設(shè)計兩張一模一樣的表？
首先要注意這兩張表也是兩張普通的表，所以有可能會有多個region的情況（其實只有.META.表可能會有，.ROOT.很?。?。
.META.表用來存儲的是region相關(guān)的信息，每一行代表一個region，.META.表可能也會有很多region，且散落到不同的regionServer上，所以就用-ROOT-表，以同樣的原理來管理.META.表的region（有點繞，其實就是公司管理的層級關(guān)系），然后把-ROOT-表的地址放到Zookeeper上（默認(rèn)地址：/hbase/root-region-server），這樣大家就知道所有查詢的入口了。

(2) -ROOT-表并不會很大，永遠(yuǎn)不會被split，所以不會出現(xiàn)-ROOT-表也有很多region的情況，就避免了一直套表的現(xiàn)象了。
(3) -ROOT-表是放在內(nèi)存中的，所以查詢很快。
(4) 其實client的每次請求并非都走這么復(fù)雜的過程，client會將查詢過的位置信息緩存起來，緩存不會主動失效。

上述就是小編為大家分享的HBase工作原理是什么了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。