福利！你要的入門HBase正確姿式

HBase簡介

​ HBase是一個分佈式的、面向列的開源數據庫存儲系統，是對Google論文BigTable的實現，具備高可靠性、高性能和可伸縮性，它能夠處理分佈在數千臺通用服務器上的PB級的海量數據。BigTable的底層是經過GFS（Google文件系統）來存儲數據，而HBase對應的則是經過HDFS（Hadoop分佈式文件系統）來存儲數據的。

​ HBase不一樣於通常的關係型數據庫，它是一個適合於非結構化數據存儲的數據庫。HBase不限制存儲的數據的種類，容許動態的、靈活的數據模型。HBase能夠在一個服務器集羣上運行，而且可以根據業務進行橫向擴展。

HBase特色

• 海量存儲：HBase適合存儲PB級別的海量數據，在PB級別的數據以及採用廉價PC存儲的狀況下，能在幾十到百毫秒內返回數據。這與HBase的記憶擴展性息息相關。正是由於HBase的良好擴展性，才爲海量數據的存儲提供了便利。
• 列式存儲：列式存儲，HBase是根據列族來存儲數據的。列族下面能夠有很是多的列，列族在建立表的時候就必須指定，而不用指定列。
• 極易擴展：HBase的擴展性主要體如今兩個方面，一個是基於上層處理能力（RegionServer）的擴展，一個是基於存儲能力（HDFS）的擴展。
• 高併發：目前大部分使用HBase的架構，都是採用廉價PC，所以單個IO的延遲其實並不小，通常在幾十到上百ms之間。這裏說的高併發，主要是在併發的狀況下，HBase的單個IO延遲降低並很少。
• 稀疏：稀疏主要是針對HBase列的靈活性，在列族中，能夠指定任意多的列，在列數據爲空的狀況下，是不會佔用存儲空間。

HBase與關係型數據庫對比

HBase數據模型

• Namespace（表命名空間）：表命名空間不是強制的，若是想把多個表分到一個組去統一管理的時候纔會用到表命名空間。
• Table（表）：一個表由一個或者多個列族組成。
• Row（行）：一個行包含了多個列，這些列經過列族來分類。行中的數據所屬列族只能從該表所定義的列族中選取，不能定義這個表中不存在的列族。
• Column Family（列族）：列族是多個列的集合。
• Column Qualifier（列）：多個列組成一個行。列族和列用：Column Family:Column Qualifier表示。列是能夠隨意定義的，一個行中的列不限名字，不限數量，只限定列族。
• Cell（單元格）：一個列中能夠存儲多個版本的數據，每一個版本就稱爲一個Cell。也就是說在HBase中一個列能夠保存多個版本的數據。
• Timestamp（時間戳/版本號）：用來標定同一個列中多個Cell的版本號。當在插入數據的時候，若是不指定版本號，系統會自動採用系統的當前時間戳來做爲版本號，也能夠手動指定一個數字做爲版本號。
• Rowkey（行鍵）：用來標識表中惟一的一行數據，以字節數組形式存儲，相似關係型數據庫中表的主鍵。rowkey在HBase中時嚴格按照字典序排序的。

物理視圖

在物理存儲上，數據是以Key-Vaule對形式存儲，每一個Key-Value只存儲一個Cell裏面的數據，不一樣的列族存儲在不一樣的文件中，每一個邏輯單元格（Cell）會對應一行數據，有Timestamp標記版本，每次插入、刪除都會生成一行數據（append-only，寫效率高）。

HBase體系架構

​ HBase的服務器體系結構遵循簡單的主從服務器架構，通常一個HBase集羣由一個Master服務（高可用的話，至少兩個）和1個或多個RegionServer服務組成。Master服務負責維護表結構信息，實際的數據是保存在RegionServer上，最終RegionServer保存的表數據會直接存儲在HDFS上。HBase的體系架構圖以下圖所示：

Master HBase的管理節點，在一個集羣中Master通常是主備的，主備的選擇是由Zookeeper實現的。

HBase Master主要職責：

• 爲RegionServer分配Region；
• 負責RegionServer的負載均衡；
• 發現失效的RegionServer並從新分配其上的Region；
• 處理Schema更新請求（表的建立、刪除、修改、列族的增長等）。

RegionServer

RegionServer主要負責服務和管理Region。在分佈式集羣中，建議RegionServer和DataNode按照1:1比例部署，這樣RegionServer中的數據文件能夠存儲一個副本於本機的DataNode節點中，從而在讀取數據時能夠利用HDFS的"短路徑讀取（Short Circuit）"來繞過網絡請求，下降讀延時。

RegionServer內部管理一個或多個Region。Region許多Store組成。每一個Store對用Table中的一個列族存儲，即一個Store管理一個Region上的一個列族。每一個Store包含一個MemStore和0到多個StoreFile。

RegionServer的主要職責：

• RegionServe維護Master分配給它的Region，處理Client對這些Region的IO請求；
• RegionServer還負責Region的Split、Compaction。

Zookeeper

HBase經過Zookeeper來作Master的高可用、RegionServer的監控、元數據的入口以及集羣配置的維護等工做。具體工做以下：

• 爲HBase提供Failover機制，選舉master，避免master單點故障問題；
• 存儲全部Region的尋址入口，保存hbase:meta表信息；
• 實時監控RegionServer的狀態，將RegionServer的上線和下線信息實時通知給master；
• 存儲HBase的Schema，包括有哪些Table，每一個Table有哪些Column Family。

HDFS

HDFS爲HBase提供最終的底層數據存儲服務，同時爲HBase提供高可用（HLog）的支持。HBase底層存儲並不是必須是HDFS文件系統，可是HDFS是最佳選擇，也是目前應用最普遍的選擇。HDFS具體功能以下：

• 提供元數據和表數據的底層分佈式存儲服務；
• 數據多副本，保證了高可靠和高可用性

Client

Client使用HBase的RPC機制與HMaster、RegionServer進行通訊，Client與Master進行管理類通訊，與RegionServer進行數據操做類通訊。Client包含了訪問HBase的接口，另外Client還維護了對應的cache來加速HBase的訪問，好比.META.元數據信息。

RegionServer內部結構

• WAL：預寫日誌（Write Ahead Log）。當操做到達Region的時候，HBase先把數據寫到WAL中，再把數據寫到MemStore中，等數據達到閾值時纔會被刷寫（flush）到最終存儲的HFile中。WAL是一個保險機制，這樣在Region的機器宕機時，因爲WAL的數據是存儲在HDFS中的，能夠從WAL中恢復數據，因此數據並不會丟失。
• BlockCache：讀緩存，用於在內存中緩存常常被讀的數據。Least Recently Used (LRU) 數據在存滿時會被失效。
• Region：Region至關於一個數據的分片。每個Region都有起始rowkey和結束rowkey，這表示了Region的存儲的row的範圍。一個RegionServer包含多個Region，一個表的一段鍵值在一個RegionServer上會產生一個Region。在一個RegionServer中有一個或多個Region。
• Store：一個Region包含多個Store，一個列族分爲一個Store，若是一個表只有一個列族，那麼這個表在這臺機器上的每個Region裏面都只有一個Store。Store是HBase的存儲核心，一個Store裏面有一個MemStore和一個或多個HFile。
• MemStore：有序的內存緩衝區，用於緩存還未被持久化到磁盤的數據，在持久化以前會先將數據排序，每一個Region的每一個列族（Store）都有一個 MemStore。
• HFile：真正存在硬盤上的，對數據按照Rowkey排好序的鍵值對文件。每次MemStore的flush會產生新的HFile文件。

用戶寫入的數據先寫入WAL，而後寫入MemStore，當MemStore滿了之後會Flush成一個StoreFile（存儲爲HFile），當StoreFile數量到達必定閾值，會觸發Compact合併，將多個StoreFile合併成一個StoreFile。StoreFiles合併後會逐漸造成愈來愈大的StoreFile，當Region內的全部的StoreFiles的總的大小超過閾值（hbase.hregion.max.filesize）會觸發Split操做。會把當前Region Split成兩個Region，父Region下線，新Split的兩個子Region被Master分配到合適的RegionServer上，使得原先一個Region的壓力分流到兩個Region上。

Region尋址方式

在進行數據操做的時候，首先要定位須要對哪一個Region進行操做，或者從哪一個Region上讀取數據，所以HBase數據讀取的第一步是Region尋址。

Region尋址步驟：

1. 首先Client請求Zookeeper，獲取hbase:meta表所在的RegionServer的地址（/hbase/meta-region-server）。
2. Client鏈接hbase:meta表所在的RegionServer，獲取須要訪問的數據所在的RegionServer地址。Client會將hbase:meta表的相關信息緩存起來，以便下一次可以快速訪問。hbase:meta表存儲了全部Region的行鍵範圍信息，經過這個表能夠查詢出你要操做的Rowkey屬於哪一個Region的範圍裏面，以及這個Region是屬於哪一個RegionServer。
3. Client請求數據所在的RegionServer，獲取所須要的數據

HBase讀寫流程

HBase寫流程

1. Client經過Region尋址定位到須要訪問的RegionServer；
2. 將更新寫入WAL HLog，而後將更新寫入MemStore，二者寫入完成即返回ACK到Client；
3. 判斷MemStore的大小是否達到閾值，是否須要flush爲StoreFile。

細節：

HBase使用MemStore和StoreFile存儲對象表的更新，數據在更新的時候首先寫入HLog和MemStore。MemStore中的數據時排序的，當MemStore累積到必定閾值時，就會建立一個新的MemStore並將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成爲一個StoreFile。同時，系統會在Zookeeper中記錄一個checkpoint，表示這個時刻以前的更新已經持久化了，當系統出現意外時，可能致使MemStore中的數據丟失，此時使用HLog來恢復chckpoint以後的數據。

HBase讀流程

1. Client經過Region尋址定位到須要訪問的RegionServer
2. 先從BlockCache中查找數據，找不到再去MemStore和StoreFile中查詢數據

​ 在對HBase進行寫操做的時候，進行Put和Update操做的時候，實際上是新增了一條數據，即便是在進行Delete操做的時候，也是新增一條數據，只是這條數據沒有value，類型爲DELETE，這條數據叫作墓碑標記（Tobstone）。數據的真正刪除是在compact操做時進行的。

WAL機制

WAL（Write-Ahead Log，預寫日誌）主要用來來解決宕機以後的操做恢復問題的。數據到達Region的時候會先寫入WAL，而後再被寫入MemStore。就算Region的機器宕掉了，因爲WAL的數據時存儲在HDFS中的，因此數據並不會丟失，還能夠從WAL中恢復。

HLog的生命週期

產生

全部涉及到數據的變動都會先寫到HLog中，除非是關閉了HLog。

滾動

HLog的大小能夠經過參數hbase.regionserver.logroll.period來控制，默認是1小時，時間達到該參數設置的時間，HBase會建立一個新的HLog文件。這就實現了HLog滾動的目的。HBase經過hbase.regionserver.maxlogs參數控制HLog的個數。滾動的目的是爲了不單個HLog文件過大的狀況，方便後續的過時和刪除。

過時

HLog的過時依賴於sequenceid的判斷。HBase會將HLog的sequenceid和HFile最大的sequenceid（刷新到的最新位置）進行比較，若是該HLog文件中的sequenceid比刷新的最新位置的sequenceid都要小，那麼這個HLog就過時了，對應HLog會被移動到/hbase/oldWALs目錄。

由於HBase有主從同步的功能，這個是依賴於HLog來同步HBase的變動，因此HLog雖然過時，也不會當即刪除，而是移動到別的目錄中。再增長對應的檢查和保留時間機制。

刪除

若是HBase開啓了replication，當replication執行完一個HLog的時候，會刪除Zookeeper上的對應HLog節點，在HLog被移動到/hbase/oldWALs目錄後，HBase每隔hbase.master.cleaner.interval（默認60秒）時間會去檢查/hbase/oldWALs目錄下的全部HLog，確認對應的Zookeeper的HLog節點是否被刪除，若是Zookeeper上不存在對應的HLog節點，那麼久直接刪除對應的HLog。

hbase.master.logcleaner.ttl（默認10分鐘）這個參數用來控制HLog在/hbase/oldWALs目錄保留的最長時間。

MemStore刷盤

爲了提升HBase的寫入性能，當寫請求寫入MemStore後，不會當即刷盤，而是會等到必定的時候再進行刷盤操做。

發生MemStore刷盤場景：

1. 全局內存控制

當整個RegionServer中全部MemStore佔用的內存達到閾值的時候，會觸發刷盤的操做。

2. MemStore達到上限

當MemStore佔用內存的大小達到hbase.hregion.memstore.flush.size的值的時候會觸發刷盤，默認128M。

3. RegionServer的HLog數量達到上限

若是HLog太多的話，會致使故障恢復的時間過長，所以HBase會對HLog的最大個數作限制。當達到HLog的最大個數的時候，會強制刷盤（hbase.regionserver.max.logs，默認32個）。

4. MemStore達到刷寫時間間隔

當MemStore達到時間間隔的閾值，會觸發刷寫操做，hbase.regionserver.optionalcacheflushinterval，默認3600000，即1小時，若是設置爲0，則意味着關閉定時自動刷寫。

5. 手工觸發

能夠經過hbase shell或者java api手工觸發flush的操做

6. 關閉RegionServer觸發

當正常關閉RegionServer會觸發刷盤的操做，所有數據刷盤後就不須要再使用HLog恢復數據

7. Region使用HLog恢復完數據後觸發

當RegionServer出現故障的時候，其上面的Region會遷移到其餘正常的RegionServer上，在恢復完Region的數據後，會觸發刷盤，當刷盤完成後纔會提供給業務訪問。

Region拆分

隨着業務的發展，在表中的數據會愈來愈多，Region會愈來愈大，這樣會嚴重影響數據讀取效率。因此當一個Region變的過大後，會觸發Split操做，將一個Region分裂成兩個子Region。Region的拆分分爲自動拆分和手動拆分兩種。

Region拆分流程

1. RegionServer自身決定region拆分，並準備發起拆分。做爲第一步，它將在zookeeper的分區/hbase/region-in-transition/region-name下中建立一個znode。
2. 由於Master是父region-in-transition的znode節點的觀察者，因此它知曉這個znode的創建。
3. RegionServer在HDFS的父region目錄下建立一個名爲「.splits」的子目錄。
4. RegionServer關閉父region，強制cache刷盤並在本地數據結構中將這個region標記爲offline。此時，父region的client請求將拋出NotServingRegionException，client將重試。
5. RegionServer爲子region A和B分別在.splits目錄下的region目錄，並建立必要的數據結構。而後拆分存儲文件，即先在父region中建立每一個存儲文件兩個reference文件。這兩個reference文件將指向父region文件。
6. RegionServer在HDFS中建立實際的region目錄，併爲每一個子region更新相應的reference文件。
7. RegionServer發起Put請求到.META.表，並在.META.表中將父region設置爲offline，表並添加有關子region的信息。此時，.META.表中不會有每一個子region的單獨的條目。client能夠經過scan .META.表來知曉父region正在拆分，可是除非子region信息記錄到.META.表，不然client是看不到子region的。若是前面的Put操做成功寫入到.META.表，則標誌父region拆分完成。若是RegionServer在put操做前返回失敗，則Master和打開這個region的RegionServer將會清除region拆分的錯誤狀態，若是.META.表成功更新，則region拆分狀態會被Master向前翻。
8. RegionServer打開子region並行地接受寫入請求。
9. RegionServer將子region A和B，以及它們的承載者信息分別添加到.META.表。以後，client就能夠發現新的region，並訪問之。client本地緩存.META.表信息，可是當它們訪問RegionServer或者.META.表時，本地緩存失效，client從.META.表獲取新的region信息。
10. RegionServer更新zookeeper的/hbase/region-in-transition/region-name節點中的region狀態到SPLIT，以便master感知其狀態變化。若是須要的話，負載器能夠將子region自由地指定到其它region。
11. region拆分完成後，其元數據和HDFS仍將包含對父region的引用。這些引用將在子region壓縮重寫數據文件時被刪除。Master的GC任務會按期檢查子region是否仍然引用父文件，若是沒有，父region將被刪除。

爲了減小對業務的影響，Region Split過程並不會真正將父Region中的HFile數據搬到子Region目錄中。Split過程僅僅是在子Region中建立了到父Region的HFile的引用文件，子Region1中的引用文件指向原HFile的上部，而子Region2的引用文件指向原HFile2的下部。數據的真正搬遷工做是在Compaction過程當中完成的。

Region合併

Region的合併分爲小合併（Minor Compaction）和大合併（Major Compaction）。

小合併（Minor Compaction）

當MemStore達到hbase.hregion.memstore.flush.size大小的時候會將數據刷寫到磁盤，生成StoreFile。隨着業務的發展，數據量會愈來愈大，會產生不少的小文件，對於HBase的數據讀取，若是要掃描大量的小文件，會致使性能不好，所以須要將這些小文件合併成一個大一點的文件。

所謂的小合併，就是把多個小的StoreFile組合在一塊兒，造成一個較大的StoreFile，一般是累積到3個SotreFile後執行。經過hbase.hstore.compationThreadhold參數配置，小合併的步驟以下：

1. 分別讀取出待合併的StoreFile文件的KeyValues，並順序地寫入到位於/hbase/.tmp目錄下的臨時文件中；
2. 將臨時文件移動到對應的Region目錄中；
3. 將合併的輸入文件路徑和輸出路徑封裝成KeyValues寫入WAL日誌，並打上compaction標記，最後強制執行sync；
4. 將對應region數據目錄下的合併的輸入文件所有刪除，合併完成。

這種小合併通常速度比較快，對業務的影響也比較小。本質上，小合併就是使用短期的IO消耗以及帶寬消耗換取後續查詢的低延遲。在Minor Compaction過程當中，達到TTL（記錄保留時間）的數據會被移除，可是由墓碑標記的記錄不會被移除，由於墓碑標記可能存儲在不一樣HFile中，合併可能會跨過部分墓碑標記。

大合併（Major Compation）

大合併就是將一個Region下的全部StoreFile合併成一個大的StoreFile文件。在大合併的過程當中，以前刪除的行和過時的版本都會被刪除。大合併通常一週作一次，由hbase.hregion.majorcompaction參數控制。大合併的影響通常比較大，儘可能避免同一時間多個Region進行合併，所以HBase經過hbase.hregion.majorcompaction.jitter參數來進行控制，用於防止多個Region同時進行大合併。

具體算法：

hbase.hregion.majorcompaction參數的值乘以一個隨機分數，這個隨機分數不能超過hbase.hregion.majorcompation.jitter的值（默認爲0.5）。

經過hbase.hregion.majorcompaction參數的值加上或減去hbase.hregion.majorcompaction參數的值乘以一個隨機分數的值就肯定下一次大合併的時間區間。

能夠經過hbase.hregion.majorcompaction設置爲0來禁用major compaction。

RegionServer故障恢復

在Zookeeper中保存着RegionServer的相關信息，在RegionServer啓動的時候，會在Zookeeper中建立對應的臨時節點。RegionServer經過Socket和Zookeeper創建session會話，RegionServer會週期性的向Zookeeper發送ping消息包，以此說明本身還處於存活狀態。而Zookeeper收到ping包後，則會更新對應Session的超時時間。

當Zookeeper超過session超時時間還未收到RegionServer的ping包，則Zookeeper會認爲該RegionServer出現故障，Zookeeper會將該RegionServer對應的臨時節點刪除出，並通知Master，Master收到RegionServer掛掉的信息後就會啓動數據恢復流程。

PS：固然學習以上這麼多，只能說是剛剛入門，要想繼續深刻學習。別擔憂，在這裏爲你們準備了學習資料（暫時不透露，嘿嘿），長按識別如下二維碼，關注"DigNew"公衆號，並在後臺回覆"HBase"便可以獲取資料哈~（建議複製，避免錯字）

---

好文推薦：

• Spark任務調度

• Spark Streaming讀取Kafka數據兩種方式

• 初識Spark執行過程 | Spark快速入門

• Spark快速入門-RDD操做手冊

• Spark快速入門-RDD

• Hive性能優化小結