Hbase底層原理

 

一、系統架構

Client

• • 1 包含訪問hbase的接口，client維護着一些cache來加快對hbase的訪問，好比regione的位置信息。

  • Zookeeper

  • 1 保證任什麼時候候，集羣中只有一個master

  • 2 存貯全部Region的尋址入口

  • 3 實時監控Region Server的狀態，將Region server的上線和下線信息實時通知給Master

  • 4 存儲Hbase的schema,包括有哪些table，每一個table有哪些column family

Master職責

• • 1 爲Region server分配region

  • 2 負責region server的負載均衡

  • 3 發現失效的region server並從新分配其上的region

  • 4 HDFS上的垃圾文件回收

  • 5 處理schema更新請求

Region Server職責

• • 1 Region server維護Master分配給它的region，處理對這些region的IO請求

  • 2 Region server負責切分在運行過程當中變得過大的region

能夠看到，client訪問hbase上數據的過程並不須要master參與（尋址訪問zookeeper和region server，數據讀寫訪問regione server），master僅僅維護者table和region的元數據信息，負載很低。

二、總體結構（物理存儲）

• • 1 Table中的全部行都按照row key的字典序排列；

  • 2 Table 在行的方向上分割爲多個Hregion；

  • 3 region按大小分割的(默認10G)，每一個表一開始只有一個region，隨着數據不斷插入表，region不斷增大，當增大到一個閥值的時候，Hregion就會等分會兩個新的Hregion。當table中的行不斷增多，就會有愈來愈多的Hregion；

  • 4 Hregion是Hbase中分佈式存儲和負載均衡的最小單元。最小單元就表示不一樣的Hregion能夠分佈在不一樣的HRegion server上。但一個Hregion是不會拆分到多個server上的；

  • 5 HRegion雖然是負載均衡的最小單元，但並非物理存儲的最小單元。

    事實上，HRegion由一個或者多個Store組成，每一個store保存一個column family。每一個Strore又由一個memStore和0至多個StoreFile組成。

（1）STORE FILE & HFILE結構

StoreFile以HFile格式保存在HDFS上。

（2）Memstore與storefile

一個region由多個store組成，每一個store包含一個列族的全部數據Store包括位於內存的memstore和位於硬盤的storefile；

客戶端檢索數據時，先在memstore找，找不到再找storefile。

（3）HLog(WAL log)

每一個Region Server維護一個Hlog,而不是每一個Region一個。這樣不一樣region(來自不一樣table)的日誌會混在一塊兒，這樣作的目的是不斷追加單個文件相對於同時寫多個文件而言，能夠減小磁盤尋址次數，所以能夠提升對table的寫性能。

若是一臺region server下線，爲了恢復其上的region，須要將region server上的log進行拆分，而後分發到其它region server上進行恢復。HLog文件就是一個普通的Hadoop Sequence File。

三、讀寫過程

（1）讀請求過程

一、HRegionServer保存着meta表以及表數據，要訪問表數據，首先Client先去訪問zookeeper，從zookeeper裏面獲取meta表所在的位置信息，即找到這個meta表在哪一個HRegionServer上保存着。

二、接着Client經過剛纔獲取到的HRegionServer的IP來訪問Meta表所在的HRegionServer，從而讀取到Meta，進而獲取到Meta表中存放的元數據。

三、Client經過元數據中存儲的信息，訪問對應的HRegionServer，而後掃描所在HRegionServer的Memstore和Storefile來查詢數據。

四、最後HRegionServer把查詢到的數據響應給Client。

（2）寫請求過程

一、Client也是先訪問zookeeper，找到Meta表，並獲取Meta表元數據。肯定當前將要寫入的數據所對應的HRegion和HRegionServer服務器。

二、Client向該HRegionServer服務器發起寫入數據請求，而後HRegionServer收到請求並響應。

三、Client先把數據寫入到HLog，以防止數據丟失，而後將數據寫入到Memstore。

四、若是HLog和Memstore均寫入成功，則這條數據寫入成功，若是Memstore達到閾值，會把Memstore中的數據flush到Storefile中。當Storefile愈來愈多，會觸發Compact合併操做，把過多的Storefile合併成一個大的Storefile。當Storefile愈來愈大，Region也會愈來愈大，達到閾值後，會觸發Split操做，將Region一分爲二。

（3）細節描述

一、數據在更新時首先寫入Log(WAL log)和內存(MemStore)中，MemStore中的數據是排序的，當MemStore累計到必定閾值時，就會建立一個新的MemStore，並 且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成爲一個StoreFile。於此同時，系統會在zookeeper中記錄一個redo point，表示這個時刻以前的變動已經持久化了。

二、當系統出現意外時，可能致使內存(MemStore)中的數據丟失，此時使用Log(WAL log)來恢復checkpoint以後的數據。

三、StoreFile是隻讀的，一旦建立後就不能夠再修改。所以Hbase的更新實際上是不斷追加的操做。當一個Store中的StoreFile達到必定的閾值後，就會進行一次合併(minor_compact, major_compact),將對同一個key的修改合併到一塊兒，造成一個大的StoreFile，當StoreFile的大小達到必定閾值後，又會對 StoreFile進行split，等分爲兩個StoreFile。

四、因爲對錶的更新是不斷追加的，compact時，須要訪問Store中所有的 StoreFile和MemStore，將他們按row key進行合併，因爲StoreFile和MemStore都是通過排序的，而且StoreFile帶有內存中索引，合併的過程仍是比較快。

四、Region管理

(1) region分配

任什麼時候刻，一個region只能分配給一個region server。master記錄了當前有哪些可用的region server。以及當前哪些region分配給了哪些region server，哪些region尚未分配。當須要分配的新的region，而且有一個region server上有可用空間時，master就給這個region server發送一個裝載請求，把region分配給這個region server。region server獲得請求後，就開始對此region提供服務。

(2) region server上線

master使用zookeeper來跟蹤region server狀態。

當某個region server啓動時，會首先在zookeeper上的server目錄下創建表明本身的znode。因爲master訂閱了server目錄上的變動消息，當server目錄下的文件出現新增或刪除操做時，master能夠獲得來自zookeeper的實時通知。所以一旦region server上線，master能立刻獲得消息。

(3) region server下線

當region server下線時，它和zookeeper的會話斷開，zookeeper而自動釋放表明這臺server的文件上的獨佔鎖。master就能夠肯定，master會刪除server目錄下表明這臺region server的znode數據，並將這臺region server的region分配給其它還活着的同志。

（4）Master工做機制

master上線

一、 從zookeeper上獲取惟一一個表明active master的鎖，用來阻止其它master成爲master。

2 、掃描zookeeper上的server父節點，得到當前可用的region server列表。

3 、和每一個region server通訊，得到當前已分配的region和region server的對應關係。

四、 掃描.META.region的集合，計算獲得當前還未分配的region，將他們放入待分配region列表。

master下線

一、因爲master只維護表和region的元數據，而不參與表數據IO的過程，master下線僅致使全部元數據的修改被凍結(沒法建立刪除表，沒法修改表的schema，沒法進行region的負載均衡，沒法處理region 上下線，沒法進行region的合併，惟一例外的是region的split能夠正常進行，由於只有region server參與)，表的數據讀寫還能夠正常進行。所以master下線短期內對整個hbase集羣沒有影響。

五、HBase三個重要機制

（1）flush機制

一、（hbase.regionserver.global.memstore.size）默認;堆大小的40%regionServer的全局memstore的大小，超過該大小會觸發flush到磁盤的操做；

二、（hbase.hregion.memstore.flush.size）默認：128M，單個region裏memstore的緩存大小，超過那麼整個HRegion就會flush；

三、（hbase.regionserver.optionalcacheflushinterval）默認：1h，內存中的文件在自動刷新以前可以存活的最長時間

（2） compact機制

把小的storeFile文件合併成大的Storefile文件，清理過時的數據，包括刪除的數據，將數據的版本號保存爲3個。

（3）split機制

當Region達到閾值，會把過大的Region一分爲二，默認一個HFile達到10Gb的時候就會進行切分。

五、協處理器

以 HBase0.92 版本爲例，它提供了三種觀察者接口：

● RegionObserver：提供客戶端的數據操縱事件鉤子： Get、 Put、 Delete、 Scan 等。

● WALObserver：提供 WAL 相關操做鉤子。

● MasterObserver：提供 DDL-類型的操做鉤子。如建立、刪除、修改數據表等。

六、HBase當中的二級索引

因爲HBase的查詢比較弱，若是須要實現相似於 select name,salary,count(1),max(salary) from user group by name,salary order by salary 等這樣的複雜性的統計需求，基本上不可能，或者說比較困難，因此咱們在使用HBase的時候，通常都會藉助二級索引的方案來進行實現；

HBase的一級索引就是rowkey，咱們只能經過rowkey進行檢索。若是咱們相對hbase裏面列族的列列進行一些組合查詢，就須要採用HBase的二級索引方案來進行多條件的查詢。

常見的二級索引咱們通常能夠藉助各類其餘的方式來實現，例如solr或者ES等。