HBase工作原理是什么

這期內容當中小編將會給大家帶來有關HBase工作原理是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

1. HBase系統架構圖

整個HBase架構重點關注幾部分：HMaster、HRegionServer、Zookeeper、HRegion（內部包括HLog、StoreFile、MemStore）。

2. HMaster介紹

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

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

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

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

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

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

4. Zookeeper介紹

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

Zookeeper的主要功能：

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

5. Region介紹

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

5.1 Region和Table的關系

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

5.2 Region細分

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

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

5.2.1 關于HLog

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

5.2.2 關于MemStore

MemStore是擋在StoreFile前面的一層緩存，當Region請求到達時，會先去在MemStore中查找，若命中直接返回結果，這樣可以避免對大規模的StoreFile進行掃描。

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

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

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

7. -ROOT-和.Meta.兩張內置表介紹

Hbase內置兩張表(-ROOT-、.META.)來管理region相關信息，且這兩張表結構相同。

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

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

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

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

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