hbase 架構

來源 https://www.cnblogs.com/duanxz/p/4516283.html

HBase是一個分佈式的架構，除去底層存儲的HDFS外，HBase自己從功能上能夠分爲三塊：Zookeeper羣、HMaster羣和HRegionServer羣。

• Zookeeper羣：HBase集羣中不可缺乏的重要部分，主要用於存儲Master地址、協調Master和RegionServer等上下線、存儲臨時數據等等。
• HMaster羣：Master主要是作一些管理操做，如：region的分配，手動管理操做下發等等，通常數據的讀寫操做並不須要通過Master集羣，因此Master通常不須要很高的配置便可。
• HRegionServer羣：RegionServer羣是真正數據存儲的地方，每一個HRegionServer由若干個region組成，而一個region維護了必定區間rowkey值的數據，

整個架構中，Zookeeper用於服務協調和整個集羣運行過程當中部分信息的保存和-ROOT-表地址定位，Master用於集羣內部管理，因此剩下的HRegionServer主要用於處理數據。

 

Zookeeper

Zookeeper Quorum存儲-ROOT-表地址、HMaster地址
HRegionServer把本身以Ephedral方式註冊到Zookeeper中，HMaster隨時感知各個HRegionServer的健康情況
Zookeeper避免HMaster單點問題

 

HMaster

（HMaster沒有單點問題，HBase中能夠啓動多個HMaster，經過Zookeeper的MasterElection機制保證總有一個Master在運行。）

主要負責Table和Region的管理工做：

1 管理用戶對錶的增刪改查操做

2 管理HRegionServer的負載均衡，調整Region分佈

3 Region Split後，負責新Region的分佈

4 在HRegionServer停機後，負責失效HRegionServer上Region遷移

5 HDFS上的垃圾文件回收

6 處理schema更新請求

 

HRegionServer

HBase中最核心的模塊，主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據

HRegionServer管理一些列HRegion對象；
每一個HRegion對應Table中一個Region，HRegion由多個HStore組成；
每一個HStore對應Table中一個Column Family的存儲；
Column Family就是一個集中的存儲單元，故將具備相同IO特性的Column放在一個Column Family會更高效

 HStore：

HBase存儲的核心。由MemStore和StoreFile組成。

MemStore是Sorted Memory Buffer。用戶寫入數據的流程

 

HLog

引入HLog緣由： 在分佈式系統環境中，沒法避免系統出錯或者宕機，一旦HRegionServer意外退出，MemStore中的內存數據就會丟失，引入HLog就是防止這種狀況 工做機制： 每 個HRegionServer中都會有一個HLog對象，HLog是一個實現Write Ahead Log的類，每次用戶操做寫入Memstore的同時，也會寫一份數據到HLog文件，HLog文件按期會滾動出新，並刪除舊的文件(已持久化到 StoreFile中的數據)。當HRegionServer意外終止後，HMaster會經過Zookeeper感知，HMaster首先處理遺留的 HLog文件，將不一樣region的log數據拆分，分別放到相應region目錄下，而後再將失效的region從新分配，領取到這些region的 HRegionServer在Load Region的過程當中，會發現有歷史HLog須要處理，所以會Replay HLog中的數據到MemStore中，而後flush到StoreFiles，完成數據恢復。

 

LogFlusher

前面提到，數據以KeyValue形式到達HRegionServer，將寫入WAL，以後，寫入一個SequenceFile。看過去沒問題，可是由於數據流在寫入文件系統時，常常會緩存以提升性能。這樣，有些本覺得在日誌文件中的數據實際在內存中。這裏，咱們提供了一個LogFlusher的類。它調用HLog.optionalSync(),後者根據 hbase.regionserver.optionallogflushinterval (默認是10秒)，按期調用Hlog.sync()。另外，HLog.doWrite()也會根據 hbase.regionserver.flushlogentries (默認100秒)按期調用Hlog.sync()。Sync() 自己調用HLog.Writer.sync()，它由SequenceFileLogWriter實現。

LogRoller

Log的大小經過$HBASE_HOME/conf/hbase-site.xml 的 hbase.regionserver.logroll.period 限制，默認是一個小時。因此每60分鐘，會打開一個新的log文件。長此以往，會有一大堆的文件須要維護。首先，LogRoller調用HLog.rollWriter()，定時滾動日誌，以後，利用HLog.cleanOldLogs()能夠清除舊的日誌。它首先取得存儲文件中的最大的sequence number，以後檢查是否存在一個log全部的條目的「sequence number」均低於這個值，若是存在，將刪除這個log。

每一個region server維護一個HLog，而不是每個region一個，這樣不一樣region（來自不一樣的table）的日誌會混在一塊兒，這樣作的目的是不斷追加單個文件相對於同時寫多個文件而言，能夠減小磁盤尋址次數，所以能夠提升table的寫性能。帶來麻煩的時，若是一個region server下線，爲了恢復其上的region，須要講region server上的log進行拆分，而後分發到其餘region server上進行恢復。

 

HBase中的全部數據文件都存儲在Hadoop HDFS文件系統上，格式主要有兩種：
1 HFile HBase中KeyValue數據的存儲格式，HFile是Hadoop的二進制格式文件，實際上StoreFile就是對HFile作了輕量級包裝，即StoreFile底層就是HFile
2 HLog File，HBase中WAL（Write Ahead Log） 的存儲格式，物理上是Hadoop的Sequence File

 

RS（HRegionServer）是處理數據的主要場所，那麼在RS內部的數據是怎麼分佈的？其實RS自己只是一個容器，其定義了一些功能線程，好比：數據合併線程(compact thread)、storeFile分割線程(split thread)等等。容器中的主要對象就是region，region是一個表根據自身rowkey範圍劃分的一部分，一個表能夠被劃分紅若干部分，也就是若干個region，region能夠根據rowkey範圍不一樣而被分佈在不一樣的RS上(固然也能夠在同一個RS上，但不建議這麼作)。一個RS上能夠包含多個表的region，也能夠只包含一個表的部分region，RS和表是兩個不一樣的概念。
這裏還有一個概念——列簇。對HBase有一些瞭解的人，或多或少據說過：HBase是一個列式存儲的數據庫，而這個列式存儲中的列，實際上是區別於通常數據庫的列，這裏的列的概念，就是列簇，列簇，顧名思義就是不少列的集合，而在數據存儲上來說，不一樣列簇的數據，必定是分開存儲的，即便是在同一個region內部，不一樣的列簇也存儲在不一樣的文件夾中，這樣作的好處是，通常咱們定義列簇的時候，一般會把相似的數據放入同一個列簇，不一樣的列簇分開存儲，有利於數據的壓縮，而且HBase自己支持多種壓縮方式。

 

訪問HBase經過HBase客戶端(或API)進行，整個HBase提供給外部的地址，實際上是ZK的入口，前面也介紹了，ZK中有保存-ROOT-所在的RS地址，從-ROOT-表能夠獲取.META.表信息，根據.META.表能夠獲取region在RS上的分佈，整個region尋址過程大體以下

RS定位過程

1. 首先，Client經過訪問ZK來請求目標數據的地址。
2. ZK中保存了-ROOT-表的地址，因此ZK經過訪問-ROOT-表來請求數據地址。
3. 一樣，-ROOT-表中保存的是.META.的信息，經過訪問.META.表來獲取具體的RS。
4. .META.表查詢到具體RS信息後返回具體RS地址給Client。
5. Client端獲取到目標地址後，而後直接向該地址發送數據請求。

Region數據寫入

HBase經過ZK —> -ROOT-  —> .META.的訪問獲取RS地址後，直接向該RS上進行數據寫入操做，整個過程以下圖：

RegionServer數據操做過程

Client經過三層索引得到RS的地址後，便可向指定RS的對應region進行數據寫入，HBase的數據寫入採用WAL(write ahead log)的形式，先寫log，後寫數據。HBase是一個append類型的數據庫，沒有關係型數據庫那麼複雜的操做，因此記錄HLog的操做都是簡單的put操做(delete/update操做都被轉化爲put進行)

HLog寫入

HLog是HBase實現WAL方式產生的日誌信息，其內部是一個簡單的順序日誌，每一個RS上的region都共享一個HLog，全部對於該RS上的region數據寫入都被記錄到該HLog中。HLog的主要做用就是在RS出現意外崩潰的時候，能夠儘可能多的恢復數據，這裏說是儘可能多，由於在通常狀況下，客戶端爲了提升性能，會把HLog的auto flush關掉，這樣HLog日誌的落盤全靠操做系統保證，若是出現意外崩潰，短期內沒有被fsync的日誌會被丟失。

HLog過時

HLog的大量寫入會形成HLog佔用存儲空間會愈來愈大，HBase經過HLog過時的方式進行HLog的清理，每一個RS內部都有一個HLog監控線程在運行，其週期能夠經過hbase.master.cleaner.interval進行配置。 HLog在數據從memstore flush到底層存儲上後，說明該段HLog已經再也不被須要，就會被移動到.oldlogs這個目錄下，HLog監控線程監控該目錄下的HLog，當該文件夾下的HLog達到hbase.master.logcleaner.ttl設置的過時條件後，監控線程當即刪除過時的HLog。

Memstore

數據存儲

memstore是region內部緩存，其大小經過HBase參數hbase.hregion.memstore.flush.size進行配置。RS在寫完HLog之後，數據寫入的下一個目標就是region的memstore，memstore在HBase內部經過LSM-tree結構組織，因此可以合併大量對於相同rowkey上的更新操做。 正是因爲memstore的存在，HBase的數據寫入都是異步的，並且性能很是不錯，寫入到memstore後，該次寫入請求就能夠被返回，HBase即認爲該次數據寫入成功。這裏有一點須要說明，寫入到memstore中的數據都是預先按照rowkey的值進行排序的，這樣有利於後續數據查找。

數據刷盤

memstore中的數據在必定條件下會進行刷寫操做，使數據持久化到相應的存儲設備上，觸發memstore刷盤的操做有多種不一樣的方式以下圖：

Memstore刷寫流程

以上1,2,3均可以觸發memstore的flush操做，可是實現的方式不一樣：

• 1經過全局內存控制，觸發memstore刷盤操做。memstore總體內存佔用上限經過參數hbase.regionserver.global.memstore.upperLimit進行設置，固然在達到上限後，memstore的刷寫也不是一直進行，在內存降低到hbase.regionserver.global.memstore.lowerLimit配置的值後，即中止memstore的刷盤操做。這樣作，主要是爲了防止長時間的memstore刷盤，會影響總體的性能。
• 在該種狀況下，RS中全部region的memstore內存佔用都沒達到刷盤條件，但總體的內存消耗已經到一個很是危險的範圍，若是持續下去，頗有可能形成RS的OOM，這個時候，須要進行memstore的刷盤，從而釋放內存。
• 2手動觸發memstore刷盤操做
• HBase提供API接口，運行經過外部調用進行memstore的刷盤
• 3 memstore上限觸發數據刷盤
• 前面提到memstore的大小經過hbase.hregion.memstore.flush.size進行設置，當region中memstore的數據量達到該值時，會自動觸發memstore的刷盤操做。

 

刷盤影響

memstore在不一樣的條件下會觸發數據刷盤，那麼整個數據在刷盤過程當中，對region的數據寫入等有什麼影響？memstore的數據刷盤，對region的直接影響就是：在數據刷盤開始到結束這段時間內，該region上的訪問都是被拒絕的，這裏主要是由於在數據刷盤結束時，RS會對改region作一個snapshot，同時HLog作一個checkpoint操做，通知ZK哪些HLog能夠被移到.oldlogs下。從前面圖上也能夠看到，在memstore寫盤開始，相應region會被加上UpdateLock鎖，寫盤結束後該鎖被釋放。

Compact

大量HFile的產生，會消耗更多的文件句柄，同時會形成RS在數據查詢等的效率大幅度降低，HBase爲解決這個問題，引入了compact操做，RS經過compact把大量小的HFile進行文件合併，生成大的HFile文件。 RS上的compact根據功能的不一樣，能夠分爲兩種不一樣類型，即：minor compact和major compact。

• Minor Compact

minor compact又叫small compact，在RS運行過程當中會頻繁進行，主要經過參數hbase.hstore.compactionThreshold進行控制，該參數配置了HFile數量在知足該值時，進行minor compact，minor compact只選取region下部分HFile進行compact操做，而且選取的HFile大小不能超過hbase.hregion.max.filesize參數設置。

• Major Compact

相反major compact也被稱之爲large compact，major compact會對整個region下相同列簇的全部HFile進行compact，也就是說major compact結束後，同一個列簇下的HFile會被合併成一個。major compact是一個比較長的過程，對底層I/O的壓力相對較大。 major compact除了合併HFile外，另一個重要功能就是清理過時或者被刪除的數據。前面提到過，HBase的delete操做也是經過append的方式寫入，一旦某些數據在HBase內部被刪除了，在內部只是被簡單標記爲刪除，真正在存儲層面沒有進行數據清理，只有經過major compact對HFile進行重組時，被標記爲刪除的數據才能被真正的清理。 compact操做都有特定的線程進行，通常狀況下不會影響RS上數據寫入的性能，固然也有例外：在compact操做速度跟不上region中HFile增加速度時，爲了安全考慮，RS會在HFile達到必定數量時，對寫入進行鎖定操做，直到HFile經過compact降到必定的範圍內才釋放鎖。

 

Split

compact將多個HFile合併單個HFile文件，隨着數據量的不斷寫入，單個HFile也會愈來愈大，大量小的HFile會影響數據查詢性能，大的HFile也會，HFile越大，相對的在HFile中搜索的指定rowkey的數據花的時間也就越長，HBase一樣提供了region的split方案來解決大的HFile形成數據查詢時間過長問題。 一個較大的region經過split操做，會生成兩個小的region，稱之爲Daughter，通常Daughter中的數據是根據rowkey的之間點進行切分的，region的split過程大體以下圖：

region split流程

1. region先更改ZK中該region的狀態爲SPLITING。
2. Master檢測到region狀態改變。
3. region會在存儲目錄下新建.split文件夾用於保存split後的daughter region信息。
4. Parent region關閉數據寫入並觸發flush操做，保證全部寫入Parent region的數據都能持久化。
5. 在.split文件夾下新建兩個region，稱之爲daughter A、daughter B。
6. Daughter A、Daughter B拷貝到HBase根目錄下，造成兩個新的region。
7. Parent region通知修改.META.表後下線，再也不提供服務。
8. Daughter A、Daughter B上線，開始向外提供服務。
9. 若是開啓了balance_switch服務，split後的region將會被從新分佈。

上面1 ~ 9就是region split的整個過程，split過程很是快，速度基本會在秒級內，那麼在這麼快的時間內，region中的數據怎麼被從新組織的？ 其實，split只是簡單的把region從邏輯上劃分紅兩個，並無涉及到底層數據的重組，split完成後，Parent region並無被銷燬，只是被作下線處理，再也不對外部提供服務。而新產生的region Daughter A和Daughter B，內部的數據只是簡單的到Parent region數據的索引，Parent region數據的清理在Daughter A和Daughter B進行major compact之後，發現已經沒有到其內部數據的索引後，Parent region纔會被真正的清理。

 

 

HBase設計

HBase是一個分佈式數據庫，其性能的好壞主要取決於內部表的設計和資源的分配是否合理。

Rowkey設計

rowkey是HBase實現分佈式的基礎，HBase經過rowkey範圍劃分不一樣的region，分佈式系統的基本要求就是在任什麼時候候，系統的訪問都不要出現明顯的熱點現象，因此rowkey的設計相當重要，通常咱們建議rowkey的開始部分以hash或者MD5進行散列，儘可能作到rowkey的頭部是均勻分佈的。禁止採用時間、用戶id等明顯有分段現象的標誌直接看成rowkey來使用。

列簇設計

HBase的表設計時，根據不一樣需求有不一樣選擇，須要作在線查詢的數據表，儘可能不要設計多個列簇，咱們知道，不一樣的列簇在存儲上是被分開的，多列簇設計會形成在數據查詢的時候讀取更多的文件，從而消耗更多的I/O。

TTL設計

選擇合適的數據過時時間也是表設計中須要注意的一點，HBase中容許列簇定義數據過時時間，數據一旦超過過時時間，能夠被major compact進行清理。大量無用歷史數據的殘餘，會形成region體積增大，影響查詢效率。

Region設計

通常地，region不宜設計成很大，除非應用對階段性性能要求不少，可是在未來運行一段時間能夠接受停服處理。region過大會致使major compact調用的週期變長，而單次major compact的時間也相應變長。major compact對底層I/O會形成壓力，長時間的compact操做可能會影響數據的flush，compact的週期變長會致使許多刪除或者過時的數據不能被及時清理，對數據的讀取速度等都有影響。 相反，小的region意味着major compact會相對頻繁，可是因爲region比較小，major compact的相對時間較快，並且相對較多的major compact操做，會加速過時數據的清理。 固然，小region的設計意味着更多的region split風險，region容量太小，在數據量達到上限後，region須要進行split來拆分，其實split操做在整個HBase運行過程當中，是被不怎麼但願出現的，由於一旦發生split，涉及到數據的重組，region的再分配等一系列問題。因此咱們在設計之初就須要考慮到這些問題，儘可能避免region的運行過程當中發生split。 HBase能夠經過在表建立的時候進行region的預分配來解決運行過程當中region的split產生，在表設計的時候，預先分配足夠多的region數，在region達到上限前，至少有部分數據會過時，經過major compact進行清理後， region的數據量始終維持在一個平衡狀態。 region數量的設計還須要考慮內存上的限制，經過前面的介紹咱們知道每一個region都有memstore，memstore的數量與region數量和region下列簇的數量成正比,一個RS下memstore內存消耗：

Memory = memstore大小 * region數量 * 列簇數量

若是不進行前期數據量估算和region的預分配，經過不斷的split產生新的region，容易致使由於內存不足而出現OOM現象。

 

在HBase中，表被分割成區域，並由區域服務器提供服務。區域被列族垂直分爲「Stores」。Stores被保存在HDFS文件。

HBase有三個主要組成部分：客戶端庫，主服務器和區域服務器。區域服務器能夠按要求添加或刪除。

源自：https://www.yiibai.com/hbase/hbase_architecture.html

主服務器

主服務器是 -

• 分配區域給區域服務器並在Apache ZooKeeper的幫助下完成這個任務。
• 處理跨區域的服務器區域的負載均衡。它卸載繁忙的服務器和轉移區域較少佔用的服務器。
• 經過斷定負載均衡以維護集羣的狀態。
• 負責模式變化和其餘元數據操做，如建立表和列。

區域

區域只不過是表被拆分，並分佈在區域服務器。

區域服務器

區域服務器擁有區域以下 -

• 與客戶端進行通訊並處理數據相關的操做。
• 句柄讀寫的全部地區的請求。
• 由如下的區域大小的閾值決定的區域的大小。

須要深刻探討區域服務器：包含區域和存儲，以下圖所示：

存儲包含內存存儲和HFiles。memstore就像一個高速緩存。在這裏開始進入了HBase存儲。數據被傳送並保存在Hfiles做爲塊而且memstore刷新。

Zookeeper

• Zookeeper管理是一個開源項目，提供服務，如維護配置信息，命名，提供分佈式同步等
• Zookeeper表明不一樣區域的服務器短暫節點。主服務器使用這些節點來發現可用的服務器。
• 除了可用性，該節點也用於追蹤服務器故障或網絡分區。
• 客戶端經過與zookeeper區域服務器進行通訊。
• 在模擬和獨立模式，HBase由zookeeper來管理。

HBase 具備以下特性：

• 強一致性讀寫：HBase 不是「eventually consistent（最終一致性）」數據存儲。這讓它很適合高速計數聚合類任務；
• 自動分片(Automatic sharding)： HBase 表經過 region 分佈在集羣中。數據增加時，region 會自動分割並從新分佈；
• RegionServer 自動故障轉移；
• Hadoop/HDFS 集成：HBase 支持開箱即用地支持 HDFS 做爲它的分佈式文件系統；
• MapReduce： HBase 經過 MapReduce 支持大併發處理；
• Java 客戶端 API：HBase 支持易於使用的 Java API 進行編程訪問；
• Thrift/REST API：HBase 也支持 Thrift 和 REST 做爲非 Java 前端的訪問；
• Block Cache 和 Bloom Filter：對於大容量查詢優化， HBase 支持 Block Cache 和 Bloom Filter；
• 運維管理：HBase 支持 JMX 提供內置網頁用於運維。

HBase 的應用場景

首先，確信有足夠多數據，若是有上億或上千億行數據，HBase 是很好的備選。若是隻有上千或上百萬行，則用傳統的R DBMS 多是更好的選擇。由於全部數據能夠在一兩個節點保存，集羣其餘節點可能閒置。

其次，確信能夠不依賴全部 RDBMS 的額外特性（例如，列數據類型、 第二索引、事務、高級查詢語言等）。

第三，確信你有足夠的硬件。由於 HDFS 在小於5個數據節點時，基本上體現不出它的優點。

Hbase 的優缺點

Hbase 的優勢：

• 列的能夠動態增長，而且列爲空就不存儲數據，節省存儲空間
• Hbase 自動切分數據，使得數據存儲自動具備水平擴展
• Hbase 能夠提供高併發讀寫操做的支持
• 與 Hadoop MapReduce 相結合有利於數據分析
• 容錯性
• 版權免費
• 很是靈活的模式設計（或者說沒有固定模式的限制）
• 能夠跟 Hive 集成，使用類 SQL 查詢
• 自動故障轉移
• 客戶端接口易於使用
• 行級別原子性，即，PUT 操做必定是徹底成功或者徹底失敗

Hbase 的缺點：

• 不能支持條件查詢，只支持按照 row key 來查詢
• 容易產生單點故障（在只使用一個 HMaster 的時候）
• 不支持事務
• JOIN 不是數據庫層支持的，而須要用 MapReduce
• 只能在逐漸上索引和排序
• 沒有內置的身份和權限認證

HBase的特色

1. 大：一個表能夠有上億行，上百萬列。
2. 面向列：面向列表（簇）的存儲和權限控制，列（簇）獨立檢索。
3. 稀疏：對於爲空（NULL）的列，並不佔用存儲空間，所以，表能夠設計的很是稀疏。
4. 無模式：每一行都有一個能夠排序的主鍵和任意多的列，列能夠根據須要動態增長，同一張表中不一樣的行能夠有大相徑庭的列。
5. 數據多版本：每一個單元中的數據能夠有多個版本，默認狀況下，版本號自動分配，版本號就是單元格插入時的時間戳。
6. 數據類型單一：HBase中的數據都是字符串，沒有類型。

訪問 HBase table 中的行，只有三種方式：

       1 經過單個row key訪問

　　2 經過row key的range

　　3 全表掃描

 HBase 表中的每一個列都歸屬於某個列族。列族是表的 Schema 的一部分（而列不是），必須在使用表以前定義。列名都以列族做爲前綴。

HBase 中經過 Row 和 Columns 肯定的一個存儲單元稱爲 Cell。每一個 Cell 都保存着同一份數據的多個版本。爲了不數據存在過多版本形成的管理（包括存儲和索引）負擔，HBase 提供了兩種數據版本回收方式。 一是保存數據的最後 n 個版本，二是保存最近一段時間內的版本（好比最近七天）。用戶能夠針對每一個列族進行設置。

Cell 是由 {row key，column(=< family> + < label>)，version} 惟一肯定的單元。Cell 中的數據是沒有類型的，所有是字節碼形式存儲。