HBase的構成
物理上來講，HBase是由三種類型的服務器以主從模式構成的。這三種服務器分別是：Region server，HBase HMaster，ZooKeeper。node
其中Region server負責數據的讀寫服務。用戶經過溝通Region server來實現對數據的訪問。算法
HBase HMaster負責Region的分配及數據庫的建立和刪除等操做。數據庫
ZooKeeper做爲HDFS的一部分，負責維護集羣的狀態（某臺服務器是否在線，服務器之間數據的同步操做及master的選舉等）。緩存
另外，Hadoop DataNode負責存儲全部Region Server所管理的數據。HBase中的全部數據都是以HDFS文件的形式存儲的。出於使Region server所管理的數據更加本地化的考慮，Region server是根據DataNode分佈的。HBase的數據在寫入的時候都存儲在本地。但當某一個region被移除或被從新分配的時候，就可能產生數據不在本地的狀況。這種狀況只有在所謂的compaction以後才能解決。安全
NameNode負責維護構成文件的全部物理數據塊的元信息（metadata）。服務器
HBase結構以下圖所示：網絡
Regions架構
HBase中的表是根據row key的值水平分割成所謂的region的。一個region包含表中全部row key位於region的起始鍵值和結束鍵值之間的行。集羣中負責管理Region的結點叫作Region server。Region server負責數據的讀寫。每個Region server大約能夠管理1000個region。Region的結構以下圖所示：負載均衡
HBase的HMaster分佈式
HMaster負責region的分配，數據庫的建立和刪除操做。
具體來講，HMaster的職責包括：
- 調控Region server的工做
- 在集羣啓動的時候分配region，根據恢復服務或者負載均衡的須要從新分配region。
- 監控集羣中的Region server的工做狀態。（經過監聽zookeeper對於ephemeral node狀態的通知）。
- 管理數據庫
- 提供建立，刪除或者更新表格的接口。
HMaster的工做以下圖所示：
ZooKeeper
HBase利用ZooKeeper維護集羣中服務器的狀態並協調分佈式系統的工做。ZooKeeper維護服務器是否存活，是否可訪問的狀態並提供服務器故障/宕機的通知。ZooKeeper同時還使用一致性算法來保證服務器之間的同步。同時也負責Master選舉的工做。須要注意的是要保證良好的一致性及順利的Master選舉，集羣中的服務器數目必須是奇數。例如三臺或五臺。
ZooKeeper的工做以下圖所示：
HBase各組成部分之間的合做
ZooKeeper用來協調分佈式系統的成員之間共享的狀態信息。Region Server及HMaster也與ZooKeeper鏈接。ZooKeeper經過心跳信息爲活躍的鏈接維持相應的ephemeral node。以下圖所示：
每個Region server都在ZooKeeper中建立相應的ephemeral node。HMaster經過監控這些ephemeral node的狀態來發現正常工做的或發生故障下線的Region server。HMaster之間經過互相競爭建立ephemeral node進行Master選舉。ZooKeeper會選出區中第一個建立成功的做爲惟一一個活躍的HMaster。活躍的HMaster向ZooKeeper發送心跳信息來代表本身在線的狀態。不活躍的HMaster則監聽活躍HMaster的狀態，並在活躍HMaster發生故障下線以後從新選舉，從而實現了HBase的高可用性。
若是Region server或者HMaster不能成功向ZooKeeper發送心跳信息，則其與ZooKeeper的鏈接超時以後與之相應的ephemeral node就會被刪除。監聽ZooKeeper狀態的其餘節點就會獲得相應node不存在的信息，從而進行相應的處理。活躍的HMaster監聽Region Server的信息，並在其下線後從新分配Region server來恢復相應的服務。不活躍的HMaster監聽活躍HMaster的信息，並在起下線後從新選出活躍的HMaster進行服務。
HBase的第一次讀寫
HBase中有一個特殊的起目錄做用的表格，稱爲META table。META table中保存集羣region的地址信息。ZooKeeper中會保存META table的位置。
當用戶第一次想HBase中進行讀或寫操做時，如下步驟將被執行：
1.客戶從ZooKeeper中獲得保存META table的Region server的信息。
2.客戶向該Region server查詢負責管理本身想要訪問的row key的所在的region的Region server的地址。客戶會緩存這一信息以及META table所在位置的信息。
3.客戶與負責其row所在region的Region Server通訊，實現對該行的讀寫操做。
在將來的讀寫操做中，客戶會根據緩存尋找相應的Region server地址。除非該Region server再也不可達。這時客戶會從新訪問META table並更新緩存。這一過程以下圖所示：
HBase的META table
- META table中保存了HBase中全部region的信息。
- META table的格式相似於B tree。
- META table的結構以下：
- 鍵：region的起始鍵，region id。
- 值：Region server
- 以下圖所示：
Region Server的組成
運行在HDFS DataNode上的Region server包含以下幾個部分：
- WAL：既Write Ahead Log。WAL是HDFS分佈式文件系統中的一個文件。WAL用來存儲還沒有寫入永久性存儲區中的新數據。WAL也用來在服務器發生故障時進行數據恢復。
- Block Cache：Block cache是讀緩存。Block cache將常常被讀的數據存儲在內存中來提升讀取數據的效率。當Block cache的空間被佔滿後，其中被讀取頻率最低的數據將會被殺出。
- MemStore：MemStore是寫緩存。其中存儲了從WAL中寫入但還沒有寫入硬盤的數據。MemStore中的數據在寫入硬盤以前會先進行排序操做。每個region中的每個column family對應一個MemStore。
- Hfiles：Hfiles存在於硬盤上，根據排序號的鍵存儲數據行。
- Region server的結構以下圖所示：
- **HBase的寫操做步驟
步驟一
當HBase的用戶發出一個PUT請求時（也就是HBase的寫請求），HBase進行處理的第一步是將數據寫入HBase的write-ahead log（WAL）中。
- WAL文件是順序寫入的，也就是全部新添加的數據都被加入WAL文件的末尾。WAL文件存在硬盤上。
- 當server出現問題以後，WAL能夠被用來恢復還沒有寫入HBase中的數據（由於WAL是保存在硬盤上的）。
- 以下圖所示：
步驟二
當數據被成功寫入WAL後，HBase將數據存入MemStore。這時HBase就會通知用戶PUT操做已經成功了。
過程以下圖所示：
HBase的MemStore
Memstore存在於內存中，其中存儲的是按鍵排好序的待寫入硬盤的數據。數據也是按鍵排好序寫入HFile中的。每個Region中的每個Column family對應一個Memstore文件。所以對數據的更新也是對應於每個Column family。
以下圖所示：
HBase Region Flush
當MemStore中積累了足夠多的數據以後，整個Memcache中的數據會被一次性寫入到HDFS裏的一個新的HFile中。所以HDFS中一個Column family可能對應多個HFile。這個HFile中包含了相應的cell，或者說鍵值的實例。這些文件隨着MemStore中積累的對數據的操做被flush到硬盤上而建立。
須要注意的是，MemStore存儲在內存中，這也是爲何HBase中Column family的數目有限制的緣由。每個Column family對應一個MemStore，當MemStore存滿以後，裏面所積累的數據就會一次性flush到硬盤上。同時，爲了使HDFS可以知道當前哪些數據已經被存儲了，MemStore中還保存最後一次寫操做的序號。
每一個HFile中最大的序號做爲meta field存儲在其中，這個序號標明瞭以前的數據向硬盤存儲的終止點和接下來繼續存儲的開始點。當一個region啓動的時候，它會讀取每個HFile中的序號來得知當前region中最新的操做序號是什麼（最大的序號）。
以下圖所示：
HFile
HBase中的鍵值數據對存儲在HFile中。上面已經說過，當MemStore中積累足夠多的數據的時候就會將其中的數據整個寫入到HDFS中的一個新的HFile中。由於MemStore中的數據已經按照鍵排好序，因此這是一個順序寫的過程。因爲順序寫操做避免了磁盤大量尋址的過程，因此這一操做很是高效。
以下圖所示：
HFile的結構
HFile中包含了一個多層索引系統。這個多層索引是的HBase能夠在不讀取整個文件的狀況下查找數據。這一多層索引相似於一個B+樹。
- 鍵值對根據鍵大小升序排列。
- 索引指向64KB大小的數據塊。
- 每個數據塊還有其相應的葉索引（leaf-index）。
- 每個數據塊的最後一個鍵做爲中間索引（intermediate index）。
- 根索引（root index）指向中間索引。
文件結尾指向meta block。由於meta block是在數據寫入硬盤操做的結尾寫入該文件中的。文件的結尾同時還包含一些別的信息。好比bloom filter及時間信息。Bloom filter能夠幫助HBase加速數據查詢的速度。由於HBase能夠利用Bloom filter跳過不包含當前查詢的鍵的文件。時間信息則能夠幫助HBase在查詢時跳過讀操做所指望的時間區域以外的文件。
以下圖所示：
HFile的索引
HFile的索引在HFile被打開時會被讀取到內存中。這樣就能夠保證數據檢索只需一次硬盤查詢操做。
以下圖所示：
HBase的讀合併（Read Merge）以及讀放大（Read amplification）
經過上面的論述，咱們已經知道了HBase中對應於某一行數據的cell可能位於多個不一樣的文件或存儲介質中。好比已經存入硬盤的行位於硬盤上的HFile中，新加入或更新的數據位於內存中的MemStore中，最近讀取過的數據則位於內存中的Block cache中。因此當咱們讀取某一行的時候，爲了返回相應的行數據，HBase須要根據Block cache，MemStore以及硬盤上的HFile中的數據進行所謂的讀合併操做。
1.HBase會首先從Block cache（HBase的讀緩存）中尋找所需的數據。
2.接下來，HBase會從MemStore中尋找數據。由於做爲HBase的寫緩存，MemStore中包含了最新版本的數據。
3.若是HBase從Block cache和MemStore中沒有找到行所對應的cell全部的數據，系統會接着根據索引和bloom filter從相應的HFile中讀取目標行的cell的數據。
以下圖所示：
這裏一個須要注意的地方是所謂的讀放大效應（Read amplification）。根據前文所說，一個MemStore對應的數據可能存儲於多個不一樣的HFile中（因爲屢次的flush），所以在進行讀操做的時候，HBase可能須要讀取多個HFile來獲取想要的數據。這會影響HBase的性能表現。
以下圖所示：
HBase的Compaction
Minor Compaction
HBase會自動選取一些較小的HFile進行合併，並將結果寫入幾個較大的HFile中。這一過程稱爲Minor compaction。Minor compaction經過Merge sort的形式將較小的文件合併爲較大的文件，從而減小了存儲的HFile的數量，提高HBase的性能。
這一過程以下圖所示：
Major Compaction
所謂Major Compaction指的是HBase將對應於某一個Column family的全部HFile從新整理併合併爲一個HFile，並在這一過程當中刪除已經刪除或過時的cell，更新現有cell的值。這一操做大大提高讀的效率。可是由於Major compaction須要從新整理全部的HFile並寫入一個HFile，這一過程包含大量的硬盤I/O操做以及網絡數據通訊。這一過程也稱爲寫放大（Write amplification）。在Major compaction進行的過程當中，當前Region基本是處於不可訪問的狀態。
Major compaction能夠配置在規定的時間自動運行。爲避免影響業務，Major compaction通常安排在夜間或週末進行。
須要注意的一點事，Major compaction會將當前Region所服務的全部遠程數據下載到本地Region server上。這些遠程數據可能因爲服務器故障或者負載均衡等緣由而存儲在於遠端服務器上。
這一過程以下圖所示：
Region的分割（Region split）
首先咱們快速複習一下Region：
- HBase中的表格能夠根據行鍵水平分割爲一個或幾個region。每一個region中包含了一段處於某一塊兒始鍵值和終止鍵值之間的連續的行鍵。
- 每個region的默認大小爲1GB。
- 相應的Region server負責向客戶提供訪問某一region中的數據的服務。
- 每個Region server可以管理大約1000個region（這些region可能來自同一個表格，也可能來自不一樣的表格）。
- 以下圖所示：
- 每個表格最初都對應於一個region。隨着region中數據量的增長，region會被分割成兩個子region。每個子region中存儲原來一半的數據。同時Region server會通知HMaster這一分割。出於負載均衡的緣由，HMaster可能會將新產生的region分配給其餘的Region server管理（這也就致使了Region server服務遠端數據的狀況的產生）。
- 以下圖所示：
讀操做的負載均衡（Read Load Balancing）
Region的分割最初是在Region server本地發生的。可是出於負載均衡的緣由，HMaster可能會將新產生的region分配給其餘的Region server進行管理。這也就致使了Region server管理存儲在遠端服務器上的region狀況的產生。這一狀況會持續至下一次Major compaction以前。如上文所示，Major compaction會將任何不在本地的數據下載至本地。
也就是說，HBase中的數據在寫入時老是存儲在本地的。可是隨着region的從新分配（因爲負載均衡或數據恢復），數據相對於Region server再也不必定是本地的。這種狀況會在Major compaction後獲得解決。
以下圖所示：
HDFS的數據備份（Data Replication）
HDFS中全部的數據讀寫操做都是針對主節點進行的。HDFS會自動備份WAL和HFile。HBase以來HDFS來提供可靠的安全的數據存儲。當數據被寫入HDFS本地時，另外兩份備份數據會分別存儲在另外兩臺服務器上。
以下圖所示：
HBase的異常恢復（Crash Recovery）
WAL文件和HFile都存儲於硬盤上且存在備份，所以恢復它們是很是容易的。那麼HBase如何恢復位於內存中的MemStore呢？
當Region server宕機的時候，其所管理的region在這一故障被發現並修復以前是不可訪問的。ZooKeeper負責根據服務器的心跳信息來監控服務器的工做狀態。當某一服務器下線以後，ZooKeeper會發送該服務器下線的通知。HMaster收到這一通知以後會進行恢復操做。
HMaster會首先將宕機的Region server所管理的region分配給其餘仍在工做的活躍的Region server。而後HMaster會將該服務器的WAL分割並分別分配給相應的新分配的Region server進行存儲。新的Region server會讀取並順序執行WAL中的數據操做，從而從新建立相應的MemStore。
以下圖所示：
數據恢復（Data Recovery）
WAL文件之中存儲了一系列數據操做。每個操做對應WAL中的一行。新的操做會順序寫在WAL文件的末尾。
那麼當MemStore中存儲的數據由於某種緣由丟失以後應該如何恢復呢？HBase以來WAL對其進行恢復。相應的Region server會順序讀取WAL並執行其中的操做。這些數據被存入內存中當前的MemStore並排序。最終當MemStore存滿以後，這些數據被flush到硬盤上。
- 須要更多大數據開發相關學習資料（Hadoop，spark，kafka，MapReduce，scala，，推薦算法，實時交易監控系統，用戶分析行爲，推薦系統）加裙免費獲取：792133408 點擊加入 【大數據開發交流圈子】
以下圖所示：
Apache HBase的優缺點
優勢
- 強一致性模型
- 當一個寫操做獲得確認時，全部的用戶都將讀到同一個值。
- 可靠的自動擴展
- 當region中的數據太多時會自動分割。
- 使用HDFS分佈存儲並備份數據。
- 內置的恢復功能
- 使用WAL進行數據恢復。
- 與Hadoop集成良好
- MapReduce在HBase上很是直觀。
缺點
- WAL回覆較慢。
- 異常恢復複雜且低效。
- 須要進行佔用大量資源和大量I/O操做的Major compaction