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

        3、HRegion是Hbase中分布式存盤和負載均衡的最小單元，最小單元就表示不同的Hregion可以分布在不同的HRegion server上，但一個Hregion是不會拆分到多個server上的，如下圖

        4、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尋址（詳情見上一節尋址部分），如下圖：

獲取資料順序規則，如下圖：

 參考和來源：https://www.cnblogs.com/tgzhu/p/5857035.html

參考資料：

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

標籤：NoSQL

上一篇：mongodb 基礎入門教程

下一篇：redis初識