Hbase-2.0.0_04_Hbase原理

 

參考博客：Hadoop HBase概念學習系列

參考博客：Hadoop HBase概念學習系列之HBase裏的Zookeeper（二十一）

參考博客：Hadoop HBase概念學習系列之HBase裏的客戶端和HBase集羣創建鏈接（詳細）（十四）

參考博客：Hadoop HBase概念學習系列之META表和ROOT表（六）

參考博客：Hadoop HBase概念學習系列之HBase裏的HRegion（五）

參考博客：Hadoop HBase概念學習系列之HLog（二）

參考博客：Hadoop HBase概念學習系列之HRegion服務器（三）

參考博客：Hadoop HBase概念學習系列之HMaster服務器（四）

參考博客：ZooKeeper 原理及其在 Hadoop 和 HBase 中的應用

參考博客：HBase介紹和工做原理

參考博客：深刻了解HBASE架構（轉）

 

1. 體系結構圖

 

1.1. Hbase特性：

• 強烈一致的讀寫:HBase不是「最終一致」的數據存儲。這使得它很是適合於高速計數器聚合之類的任務。
• 自動分片:HBase表經過區域分佈在集羣上，隨着數據的增加，區域會自動分割和從新分佈。
• RegionServer自動故障轉移
• Hadoop/HDFS集成:HBase支持HDFS開箱即用的分佈式文件系統。
• MapReduce: HBase支持經過MapReduce進行大規模並行處理，將HBase用做source和sink。
• Java客戶端API: HBase支持易於使用的Java API進行編程訪問。
• Thrift/REST API: HBase還支持非java前端的Thrift 和REST。
• Block Cache和Bloom Filters:HBase支持Block緩存和Bloom過濾器，用於高容量查詢優化。
• 操做管理:HBase提供了內置的web頁面，用於操做洞察以及JMX度量

 

 

2. Zookeeper在HBase中的應用

HMaster選舉與主備切換

       HMaster選舉與主備切換的原理和HDFS中NameNode及YARN中ResourceManager的HA原理相同。

 

系統容錯

       當HBase啓動時，每一個RegionServer都會到ZooKeeper的/hbase/rs節點下建立一個信息節點（下文中，咱們稱該節點爲」rs狀態節點」），例如/hbase/rs/[Hostname]，同時，HMaster會對這個節點註冊監聽。當某個 RegionServer 掛掉的時候，ZooKeeper會由於在一段時間內沒法接受其心跳（即 Session 失效），而刪除掉該 RegionServer 服務器對應的 rs 狀態節點。與此同時，HMaster 則會接收到 ZooKeeper 的 NodeDelete 通知，從而感知到某個節點斷開，並當即開始容錯工做。

 

       HBase爲何不直接讓HMaster來負責RegionServer的監控呢？若是HMaster直接經過心跳機制等來管理RegionServer的狀態，隨着集羣愈來愈大，HMaster的管理負擔會愈來愈重，另外它自身也有掛掉的可能，所以數據還須要持久化。在這種狀況下，ZooKeeper就成了理想的選擇。

 

RootRegion管理

       對應HBase集羣來講，數據存儲的位置信息是記錄在元數據region，也就是RootRegion上的。每次客戶端發起新的請求，須要知道數據的位置，就會去查詢RootRegion，而RootRegion自身位置則是記錄在ZooKeeper上的（默認狀況下，是記錄在ZooKeeper的/hbase/meta-region-server節點中）。當RootRegion發生變化，好比Region的手工移動、從新負載均衡或RootRegion所在服務器發生了故障等是，就可以經過ZooKeeper來感知到這一變化並作出一系列相應的容災措施，從而保證客戶端老是可以拿到正確的RootRegion信息。

 

Region狀態管理

       HBase裏的Region會常常發生變動，這些變動的緣由來自於系統故障、負載均衡、配置修改、Region分裂與合併等。一旦Region發生移動，它就會經歷下線（offline）和從新上線（online）的過程。

 

分佈式SplitWAL任務管理

       當某臺RegionServer服務器掛掉時，因爲總有一部分新寫入的數據尚未持久化到HFile中，所以在遷移該RegionServer的服務時，一個重要的工做就是從WAL中恢復這部分還在內存中的數據，而這部分工做最關鍵的一步就是SplitWAL，即HMaster須要遍歷該RegionServer服務器的WAL，並按Region切分紅小塊移動到新的地址下，並進行日誌的回放（replay）。

 

       因爲單個RegionServer的日誌量相對龐大（可能有上千個Region，上GB的日誌），而用戶又每每但願系統可以快速完成日誌的恢復工做。所以一個可行的方案是將這個處理WAL的任務分給多臺RegionServer服務器來共同處理，而這就又須要一個持久化組件來輔助HMaster完成任務的分配。當前的作法是，HMaster會在ZooKeeper上建立一個splitWAL節點（默認狀況下，是/hbase/splitWAL節點），將「哪一個RegionServer處理哪一個Region」這樣的信息以列表的形式存放到該節點上，而後由各個RegionServer服務器自行到該節點上去領取任務並在任務執行成功或失敗後再更新該節點的信息，以通知HMaster繼續進行後面的步驟。ZooKeeper在這裏擔負起了分佈式集羣中相互通知和信息持久化的角色。

 

 

3. Catalog Tables

       目錄表hbase:meta以hbase表的形式存在，並從hbase shell的列表命令中過濾出來，但實際上它和其餘表同樣是一個表。

       hbase:meta表(之前稱爲.META.)保存了系統中全部的regions列表，hbase:meta的位置存儲在ZooKeeper中。

 

4. 寫流程

一、client向Hregionserver發送寫請求。

二、Hregionserver將數據寫到Hlog（write ahead log）。爲了數據的持久化和恢復。

三、hregionserver將數據寫到內存（memstore）

四、反饋client寫成功。

 

 

5. 數據flush過程

一、當memstore數據達到閾值（默認是128M），將數據刷到硬盤【數據存儲到hdfs中】，將內存中的數據刪除，同時刪除Hlog中的歷史數據。

二、在hlog中作標記點。

 

 

6. Hbase的讀流程

一、經過zookeeper和-ROOT- .META.表定位hregionserver。

二、數據從內存和硬盤合併後返回給client

三、數據塊會緩存

 

 

7. Hmaster的職責

一、管理用戶對Table表的增、刪、改、查操做；

二、管理HRegion服務器的負載均衡，調整HRegion分佈；

三、在HRegion分裂後，負責新HRegion的分配；

四、在HRegion服務器停機後，負責失效HRegion服務器上的HRegion遷移。

 

       Master負責監視集羣中的全部RegionServer實例，是全部元數據更改的接口。在分佈式集羣中，主機一般在NameNode上運行。

       一個常見的列表問題涉及到Master宕機時HBase集羣發生了什麼。由於Hbase客戶端直接與regionserver通訊，因此集羣仍然能夠在「穩定狀態」運行。此外，根據目錄表，hbase:meta做爲hbase表存在，並不駐留在Master中。可是，主服務器控制關鍵功能，如區RegionServer故障轉移和完成區域分割。所以，雖然集羣在沒有Master的狀況下仍然能夠運行很短的時間，可是主服務器應該儘快重啓。

 

在分佈式集羣中，主機一般在NameNode上運行。

 

 

8. Hregionserver的職責

一、HRegion Server主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據，是HBASE中最核心的模塊。

二、HRegion Server管理了不少table的分區，也就是region。

 

 

9. Client請求

       HBase客戶端找到服務於特定行範圍的RegionServers。它經過查詢hbase:meta表來實現這一點。在定位所需的區域以後，客戶端聯繫服務於該region(s)的RegionServer，而不是經過master，併發出讀或寫請求。這些信息緩存在客戶端中，以便後續請求不須要通過查找過程。若是某個區域被主負載均衡器從新分配，或者由於某個RegionServer已死亡，客戶端將從新請求目錄表以肯定用戶region的新位置。