Hbase架構剖析

  HBase隸屬於hadoop生態系統，它參考了谷歌的BigTable建模，實現的編程語言爲 Java, 創建在hdfs之上，提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的數據庫系統。它僅能經過主鍵(row key)和主鍵的range來檢索數據，主要用來存儲非結構化和半結構化的鬆散數據。與hadoop同樣，Hbase目標主要依靠橫向擴展，經過不斷增長廉價的商用服務器，來增長計算和存儲能力。Hbase數據庫中的表通常有這樣的特色：

• 大： 一個表能夠有上億行，上百萬列
• 面向列:  面向列(族)的存儲和權限控制，列(族)獨立檢索
• 稀疏: 對於爲空(null)的列，並不佔用存儲空間，所以，表能夠設計的很是稀疏

目錄：

• 系統架構
• 數據模型
• RegionServer
• nameSpace
• HBase尋址
• write
• Compaction
• splite
• read

系統架構：

HBase採用Master/Slave架構搭建集羣，由HMaster節點、HRegionServer節點、ZooKeeper集羣組成，而在底層，它將數據存儲於HDFS中，於是涉及到HDFS的NN、DN等，整體結構以下（注意：在hadoop(四): 本地 hbase 集羣配置 Azure Blob Storage 介紹過，也能夠將底層的存儲配置爲 Azure Blob Storage 或 Amazon Web Services），圖A較清楚表達各組件之間的訪問及內部實現邏輯，圖B更直觀表達hbase 與 hadoop hdfs 部署結構及 hadoop NN 和 HMaster 的 SPOF 解決方案

架構圖A

 

 

 架構圖B

• Client的主要功能：

1. 使用HBase的RPC機制與HMaster和HRegionServer進行通訊
2. 對於管理類操做，Client與HMaster進行RPC
3. 對於數據讀寫類操做，Client與HRegionServer進行RPC

• Zookeeper功能：

1. 經過選舉，保證任什麼時候候，集羣中只有一個master，Master與RegionServers 啓動時會向ZooKeeper註冊
2. 實時監控Region server的上線和下線信息,並實時通知給Master
3. 存貯全部Region的尋址入口和HBase的schema和table元數據
4. Zookeeper的引入實現HMaster主從節點的failover

詳細工做原理以下圖：

 

1. 在HMaster和HRegionServer鏈接到ZooKeeper後建立Ephemeral節點，並使用Heartbeat機制維持這個節點的存活狀態，若是某個Ephemeral節點失效，則HMaster會收到通知，並作相應的處理
2. HMaster經過監聽ZooKeeper中的Ephemeral節點(默認：/hbase/rs/*)來監控HRegionServer的加入和宕機
3. 在第一個HMaster鏈接到ZooKeeper時會建立Ephemeral節點(默認：/hbasae/master)來表示Active的HMaster，其後加進來的HMaster則監聽該Ephemeral節點，若是當前Active的HMaster宕機，則該節點消失，於是其餘HMaster獲得通知，而將自身轉換成Active的HMaster，在變爲Active的HMaster以前，它會建立在/hbase/back-masters/下建立本身的Ephemeral節點

 

• HMaster功能：

1. 管理HRegionServer，實現其負載均衡
2. 管理和分配HRegion，好比在HRegion split時分配新的HRegion；在HRegionServer退出時遷移其內的HRegion到其餘HRegionServer上
3. 監控集羣中全部HRegionServer的狀態(經過Heartbeat和監聽ZooKeeper中的狀態)
4. 處理schema更新請求 (建立、刪除、修改Table的定義）, 以下圖：

 

 

 

• HRegionServer功能：

1. Region server維護Master分配給它的region，處理對這些region的IO請求
2. Region server負責切分在運行過程當中變得過大的region

• 小結：
1. client訪問hbase上數據的過程並不須要master參與（尋址訪問zookeeper，數據讀寫訪問regione server），master僅僅維護者table和region的元數據信息，負載很低
2. HRegion所處理的數據儘可能和數據所在的DataNode在一塊兒，實現數據的本地化

數據模型：

---

• Table: 與傳統關係型數據庫相似，HBase以表(Table)的方式組織數據，應用程序將數據存入HBase表中
• Row: HBase表中的行經過 RowKey 進行惟一標識，不管是數字仍是字符串，最終都會轉換成字段數據進行存儲；HBase表中的行是按RowKey字典順序排列
• Column Family: HBase表由行和列共同組織，同時引入列族的概念，它將一列或多列組織在一塊兒，HBase的列必須屬於某一個列族，在建立表時只需指定表名和至少一個列族
• Cell: 行和列的交叉點稱爲單元格，單元格的內容就是列的值，以二進制形式存儲，同時它是版本化的
• version: 每一個cell的值可保存數據的多個版本（到底支持幾個版本可在建表時指定），按時間順序倒序排列，時間戳是64位的整數，可在寫入數據時賦值，也可由RegionServer自動賦值
• 注意：

1. HBase沒有數據類型，任何列值都被轉換成字符串進行存儲
2. 與關係型數據庫在建立表時需明確包含的列及類型不一樣，HBase表的每一行能夠有不一樣的列
3. 相同RowKey的插入操做被認爲是同一行的操做。即相同RowKey的二次寫入操做，第二次可被可爲是對該行某些列的更新操做
4. 列由列族和列名鏈接而成， 分隔符是冒號，如  d:Name  （d: 列族名， Name: 列名）

• 以一個示例來講明關係型數據表和HBase表各自的解決方案（示例：博文及做者），關係型數據庫表結構設計及數據以下圖：

 

 

 表結構設計

 

 

 示例數據

 

用HBase設計表結構以下圖：

 

 

 

 存儲示例數據以下：

 

 

 

• 小結：

1. HBase不支持條件查詢和Order by等查詢，讀取記錄只能按Row key（及其range）或全表掃描
2. 在表建立時只需聲明表名和至少一個列族名，每一個Column Family爲一個存儲單元，在下節物理模型會詳細介紹
3. 在上例中設計了一個HBase表blog，該表有兩個列族：article和author，但在實際應用中強烈建議使用單列族
4. Column不用建立表時定義便可以動態新增，同一Column Family的Columns會羣聚在一個存儲單元上，並依Column key排序，所以設計時應將具備相同I/O特性的Column設計在一個Column Family上以提升性能。注意：這個列是能夠增長和刪除的，這和咱們的傳統數據庫很大的區別。因此他適合非結構化數據
5. HBase經過row和column肯定一份數據，這份數據的值可能有多個版本，不一樣版本的值按照時間倒序排序，即最新的數據排在最前面，查詢時默認返回最新版本。如上例中row key=1的author:nickname值有兩個版本，分別爲1317180070811對應的「一葉渡江」和1317180718830對應的「yedu」（對應到實際業務能夠理解爲在某時刻修改了nickname爲yedu，但舊值仍然存在）。Timestamp默認爲系統當前時間（精確到毫秒），也能夠在寫入數據時指定該值
6. 每一個單元格值經過4個鍵惟一索引，tableName+RowKey+ColumnKey+Timestamp=>value， 例如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’ 1317180718830’}索引到的惟一值是「yedu」
7. 存儲類型：
• • TableName 是字符串
  • RowKey 和 ColumnName 是二進制值（Java 類型 byte[]）
  • Timestamp 是一個 64 位整數（Java 類型 long）
  • value 是一個字節數組（Java類型 byte[]）

RegionServer:

---

• HRegionServer通常和DN在同一臺機器上運行，實現數據的本地性，如圖B。HRegionServer包含多個HRegion，由WAL(HLog)、BlockCache、MemStore、HFile組成，如圖A，其中圖A是0.94-的架構圖，圖B是0.96+的新架構圖

 

圖A

 

 

 

 圖B

• WAL(Write Ahead Log)：它是HDFS上的一個文件，全部寫操做都會先保證將數據寫入這個Log文件後，纔會真正更新MemStore，最後寫入HFile中
• 採用這種模式，能夠保證HRegionServer宕機後，依然能夠從該Log文件中讀取數據，Replay全部的操做，來保證數據的一致性
• 一個HRegionServer只有一個WAL實例，即一個HRegionServer的全部WAL寫都是串行，這固然會引發性能問題，在HBase 1.0以後，經過HBASE-5699實現了多個WAL並行寫(MultiWAL)，該實現採用HDFS的多個管道寫，以單個HRegion爲單位
• Log文件會按期Roll出新的文件而刪除舊的文件(那些已持久化到HFile中的Log能夠刪除)。WAL文件存儲在/hbase/WALs/${HRegionServer_Name}的目錄中
• BlockCache（圖B）：是一個讀緩存，將數據預讀取到內存中，以提高讀的性能
• HBase中提供兩種BlockCache的實現：默認on-heap LruBlockCache和BucketCache(一般是off-heap)。一般BucketCache的性能要差於LruBlockCache，然而因爲GC的影響，LruBlockCache的延遲會變的不穩定，而BucketCache因爲是本身管理BlockCache，而不須要GC，於是它的延遲一般比較穩定，這也是有些時候須要選用BucketCache的緣由
• HRegion:是一個Table中的一個Region在一個HRegionServer中的表達,是Hbase中分佈式存儲和負載均衡的最小單元
• 一個Table擁有一個或多個Region，分佈在一臺或多臺HRegionServer上
• 一臺HRegionServer包含多個HRegion，能夠屬於不一樣的Table
• 見圖A，HRegion由多個Store(HStore)構成，每一個HStore對應了一個Table在這個HRegion中的一個Column Family，即每一個Column Family就是一個集中的存儲單元
• HStore是HBase中存儲的核心，它實現了讀寫HDFS功能，一個HStore由一個MemStore 和0個或多個StoreFile組成
• MemStore：是一個寫緩存(In Memory Sorted Buffer)，全部數據的寫在完成WAL日誌寫後，會 寫入MemStore中，由MemStore根據必定的算法將數據Flush到底層HDFS文件中(HFile)，一般每一個HRegion中的每一個 Column Family有一個本身的MemStore
• HFile(StoreFile)： 用於存儲HBase的數據(Cell/KeyValue)。在HFile中的數據是按RowKey、Column Family、Column排序，對相同的Cell(即這三個值都同樣)，則按timestamp倒序排列

• 小結：

1. Table中的全部行都按照row key的字典序排列，Table 在行的方向上分割爲多個Hregion，以下圖1
2. region按大小分割的，每一個表一開始只有一個region，隨着數據不斷插入表，region不斷增大，當增大到一個閥值的時候，Hregion就會等分會兩個新的Hregion，以下圖2

 

圖1

 

 

 

圖2

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

 

 

        四、HRegion雖然是分佈式存儲的最小單元，但並非存儲的最小單元。事實上，HRegion由一個或者多個Store組成，每一個store保存一個columns family，每一個Strore又由一個memStore和0至多個StoreFile組成，以下圖，說明：StoreFile以HFile格式保存在HDFS上

 

nameSpace：

---

• 在HBase中，namespace命名空間指對一組表的邏輯分組，相似RDBMS中的database，方便對錶在業務上劃分。
• Apache HBase從0.98.0, 0.95.2兩個版本開始支持namespace級別的受權操做，HBase全局管理員能夠建立、修改和回收namespace的受權
• HBase系統默認定義了兩個缺省的namespace，見以下圖的目錄結構：

1. hbase：系統內建表，包括namespace和meta表
2. default：用戶建表時未指定namespace的表都建立在此

 

 

 

 

HBase尋址：

---

• 本節主要討論的問題：Client訪問用戶數據時如何找到某個row key所在的region？
• 0.94- 版本 Client訪問用戶數據以前須要首先訪問zookeeper，而後訪問-ROOT-表，接着訪問.META.表，最後才能找到用戶數據的位置去訪問，中間須要屢次網絡操做，以下圖：

 

 

•  0.96+ 刪除了root 表，改成zookeeper裏面的文件，以下圖 A， 以讀爲例，尋址示意圖如B

圖A

 

 

 

 

 圖B

Write：

---

• 當客戶端發起一個Put請求時，首先根據RowKey尋址，從hbase:meta表中查出該Put數據最終須要去的HRegionServer
• 客戶端將Put請求發送給相應的HRegionServer，在HRegionServer中它首先會將該Put操做寫入WAL日誌文件中(Flush到磁盤中)，以下圖：

 

 

• 完WAL日誌文件後，HRegionServer根據Put中的TableName和RowKey找到對應的HRegion，並根據Column Family找到對應的HStore
• 將Put數據寫入到該HStore的MemStore中。此時寫成功，並返回通知客戶端

 

 

• 上一節介紹過，MemStore是一個In Memory Sorted Buffer，在每一個HStore中都有一個MemStore，即它是一個HRegion的一個Column Family對應一個實例。
• 它的排列順序以RowKey、Column Family、Column的順序以及Timestamp的倒序，以下示意圖：

 

 

• 每一次Put請求都是先寫入到MemStore中，當MemStore滿後會Flush成一個新的StoreFile(底層實現是HFile)，即一個HStore(Column Family)能夠有0個或多個StoreFile(HFile)
• 注意：MemStore的最小Flush單元是HRegion而不是單個MemStore， 這就是建議使用單列族的緣由，太多的Column Family一塊兒Flush會引發性能問題
• MemStore觸發Flush動做的時機：

1. 當一個MemStore的大小超過了hbase.hregion.memstore.flush.size的大小，此時當前的HRegion中全部的MemStore會Flush到HDFS中
2. 當全局MemStore的大小超過了hbase.regionserver.global.memstore.upperLimit的大小，默認40％的內存使用量。此時當前HRegionServer中全部HRegion中的MemStore都會Flush到HDFS中，Flush順序是MemStore大小的倒序，直到整體的MemStore使用量低於hbase.regionserver.global.memstore.lowerLimit，默認38%的內存使用量
3. 待確認：一個HRegion中全部MemStore總和做爲該HRegion的MemStore的大小仍是選取最大的MemStore做爲參考？
4. 當前HRegionServer中WAL的大小超過了hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的數量，當前HRegionServer中全部HRegion中的MemStore都會Flush到HDFS中，Flush使用時間順序，最先的MemStore先Flush直到WAL的數量少於hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs
5. 注意：由於這個大小超過限制引發的Flush不是一件好事，可能引發長時間的延遲

• 在MemStore Flush過程當中，還會在尾部追加一些meta數據，其中就包括Flush時最大的WAL sequence值，以告訴HBase這個StoreFile寫入的最新數據的序列，那麼在Recover時就直到從哪裏開始。在HRegion啓動時，這個sequence會被讀取，並取最大的做爲下一次更新時的起始sequence，以下圖：

 

 

Compaction:

---

• MemStore每次Flush會建立新的HFile，而過多的HFile會引發讀的性能問題，HBase採用Compaction機制來解決這個問題
• HBase中Compaction分爲兩種：Minor Compaction和Major Compaction

1. Minor Compaction: 是指選取一些小的、相鄰的StoreFile將他們合併成一個更大的StoreFile，在這個過程當中不會處理已經Deleted或Expired的Cell。一次Minor Compaction的結果是更少而且更大的StoreFile, 以下圖:

 

 

1. Major Compaction: 是指將全部的StoreFile合併成一個StoreFile，在這個過程當中，標記爲Deleted的Cell會被刪除，而那些已經Expired的Cell會被丟棄，那些已經超過最多版本數的Cell會被丟棄。一次Major Compaction的結果是一個HStore只有一個StoreFile存在
2. Major Compaction能夠手動或自動觸發，然而因爲它會引發不少的IO操做而引發性能問題，於是它通常會被安排在週末、凌晨等集羣比較閒的時間, 以下示意圖：

 

 

• 修改Hbase配置文件能夠控制compaction行爲

1. hbase.hstore.compaction.min :默認值爲 3，(老版本是：hbase.hstore.compactionThreshold)，即store下面的storeFiles數量 減去 正在compaction的數量 >=3是，須要作compaction
2. hbase.hstore.compaction.max 默認值爲10，表示一次minor compaction中最多選取10個store file
3. hbase.hstore.compaction.min.size 表示文件大小小於該值的store file 必定會加入到minor compaction的store file中
4. hbase.hstore.compaction.max.size 表示文件大小大於該值的store file 必定會被minor compaction排除

splite:

---

• 最初，一個Table只有一個HRegion，隨着數據寫入增長，若是一個HRegion到達必定的大小，就須要Split成兩個HRegion，這個大小由hbase.hregion.max.filesize指定
• split時，兩個新的HRegion會在同一個HRegionServer中建立，它們各自包含父HRegion一半的數據，當Split完成後，父HRegion會下線，而新的兩個子HRegion會向HMaster註冊上線
• 處於負載均衡的考慮，這兩個新的HRegion可能會被HMaster分配到其餘的HRegionServer,示意圖以下：

 

 

1. 在zookeeper上建立ephemeral的znode指示parent region正在splitting
2. HMaster監控父Regerion的region-in-transition znode
3. 在parent region的文件夾中建立臨時split目錄
4. 關閉parent region（會flush 全部memory store（memory file），等待active compaction結束），從如今開始parent region 不可服務。同時從本地server上offline parent region，每一個region server都維護了一個valid region的list，該步將parent region從該list中移除
5. Split全部的store file，這一步爲每一個文件作一個reference file，reference file由兩部分組成
   1. 第一部分是源文件的路徑，第二部分是新的reference file引用源文件split key以及引用上半截仍是下半截
   2. 舉個例子：源文件是Table1/storefile.11，split point 是key1, 則split 成兩個子文件可能多是Table1/storefile.11.bottom.key1，Table1/storefile.11.up.key1，表示從key1切開storefile.11後，兩個引用文件分別引用源文件的下半部分和上半部分
6. 建立child region
   1. 設置各類屬性，好比將parent region的訪問指標平分給child region，每人一半
   2. 將上面在parent 文件夾中生成的臨時文件夾（裏面包含對parent region的文件reference）move到表目錄下，如今在目錄層次上，child region已經跟parent region分庭抗禮了
7. 向系統meta server中寫入parent region split完畢的信息，並將child region的名字一併寫入（split狀態在meta層面持久化）
8. 分別Open 兩個child region，主要包含如下幾個步驟：
   1. 將child region信息寫入meta server
   2. Load 全部store file，並replay log等
   3. 若是包含reference文件，則作一次compaction（相似merge），直到將全部的reference文件compact完畢，這裏能夠看到parent region的文件是會被拆開寫入各個child regions的
9. 將parent region的狀態由SPLITTING轉爲SPLIT，zookeeper會負責通知master開始處理split事件，master開始offline parent region，並online child regions
10. Worker等待master處理完畢以後，確認child regions都已經online，split結束

 read:

---

• 根據Rowkey尋址（詳情見上一節尋址部分），以下圖：

 

 

獲取數據順序規則，以下圖：

 

 參考和來源：http://www.javashuo.com/article/p-qzzzdtwc-ko.html

參考資料：

---

• http://hortonworks.com/blog/apache-hbase-region-splitting-and-merging/
• https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx