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的主要功能：
- 使用HBase的RPC機制與HMaster和HRegionServer進行通信
- 對於管理類操作，Client與HMaster進行RPC
- 對於數據讀寫類操作，Client與HRegionServer進行RPC
- Zookeeper功能：
- 通過選舉，保證任何時候，集群中只有一個master，Master與RegionServers 啟動時會向ZooKeeper注冊
- 實時監控Region server的上線和下線信息,並實時通知給Master
- 存貯所有Region的尋址入口和HBase的schema和table元數據
- Zookeeper的引入實現HMaster主從節點的failover
詳細工作原理如下圖：
- 在HMaster和HRegionServer連接到ZooKeeper后創建Ephemeral節點，並使用Heartbeat機制維持這個節點的存活狀態，如果某個Ephemeral節點失效，則HMaster會收到通知，並做相應的處理
- HMaster通過監聽ZooKeeper中的Ephemeral節點(默認：/hbase/rs/*)來監控HRegionServer的加入和宕機
- 在第一個HMaster連接到ZooKeeper時會創建Ephemeral節點(默認：/hbasae/master)來表示Active的HMaster，其后加進來的HMaster則監聽該Ephemeral節點，如果當前Active的HMaster宕機，則該節點消失，因而其他HMaster得到通知，而將自身轉換成Active的HMaster，在變為Active的HMaster之前，它會創建在/hbase/back-masters/下創建自己的Ephemeral節點
- HMaster功能：
- 管理HRegionServer，實現其負載均衡
- 管理和分配HRegion，比如在HRegion split時分配新的HRegion；在HRegionServer退出時遷移其內的HRegion到其他HRegionServer上
- 監控集群中所有HRegionServer的狀態(通過Heartbeat和監聽ZooKeeper中的狀態)
- 處理schema更新請求 (創建、刪除、修改Table的定義）, 如下圖：
- HRegionServer功能：
- Region server維護Master分配給它的region，處理對這些region的IO請求
- Region server負責切分在運行過程中變得過大的region
- 小結：
- client訪問hbase上數據的過程並不需要master參與（尋址訪問zookeeper，數據讀寫訪問regione server），master僅僅維護者table和region的元數據信息，負載很低
- HRegion所處理的數據盡量和數據所在的DataNode在一起，實現數據的本地化
數據模型：
- Table: 與傳統關系型數據庫類似，HBase以表(Table)的方式組織數據，應用程序將數據存入HBase表中
- Row: HBase表中的行通過 RowKey 進行唯一標識，不論是數字還是字符串，最終都會轉換成字段數據進行存儲；HBase表中的行是按RowKey字典順序排列
- Column Family: HBase表由行和列共同組織，同時引入列族的概念，它將一列或多列組織在一起，HBase的列必須屬於某一個列族，在創建表時只需指定表名和至少一個列族
- Cell: 行和列的交叉點稱為單元格，單元格的內容就是列的值，以二進制形式存儲，同時它是版本化的
- version: 每個cell的值可保存數據的多個版本（到底支持幾個版本可在建表時指定），按時間順序倒序排列，時間戳是64位的整數，可在寫入數據時賦值，也可由RegionServer自動賦值
- 注意：
- HBase沒有數據類型，任何列值都被轉換成字符串進行存儲
- 與關系型數據庫在創建表時需明確包含的列及類型不同，HBase表的每一行可以有不同的列
- 相同RowKey的插入操作被認為是同一行的操作。即相同RowKey的二次寫入操作，第二次可被可為是對該行某些列的更新操作
- 列由列族和列名連接而成， 分隔符是冒號，如 d:Name （d: 列族名， Name: 列名）
- 以一個示例來說明關系型數據表和HBase表各自的解決方案（示例：博文及作者），關系型數據庫表結構設計及數據如下圖：
表結構設計
示例數據
用HBase設計表結構如下圖：
存儲示例數據如下：
- 小結：
- HBase不支持條件查詢和Order by等查詢，讀取記錄只能按Row key（及其range）或全表掃描
- 在表創建時只需聲明表名和至少一個列族名，每個Column Family為一個存儲單元，在下節物理模型會詳細介紹
- 在上例中設計了一個HBase表blog，該表有兩個列族：article和author，但在實際應用中強烈建議使用單列族
- Column不用創建表時定義即可以動態新增，同一Column Family的Columns會群聚在一個存儲單元上，並依Column key排序，因此設計時應將具有相同I/O特性的Column設計在一個Column Family上以提高性能。注意：這個列是可以增加和刪除的，這和我們的傳統數據庫很大的區別。所以他適合非結構化數據
- HBase通過row和column確定一份數據，這份數據的值可能有多個版本，不同版本的值按照時間倒序排序，即最新的數據排在最前面，查詢時默認返回最新版本。如上例中row key=1的author:nickname值有兩個版本，分別為1317180070811對應的“一葉渡江”和1317180718830對應的“yedu”（對應到實際業務可以理解為在某時刻修改了nickname為yedu，但舊值仍然存在）。Timestamp默認為系統當前時間（精確到毫秒），也可以在寫入數據時指定該值
- 每個單元格值通過4個鍵唯一索引，tableName+RowKey+ColumnKey+Timestamp=>value， 例如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’ 1317180718830’}索引到的唯一值是“yedu”
- 存儲類型：
-
- 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倒序排列
- 小結：
- Table中的所有行都按照row key的字典序排列，Table 在行的方向上分割為多個Hregion，如下圖1
- 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，見如下圖的目錄結構：
- hbase：系統內建表，包括namespace和meta表
- 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動作的時機：
- 當一個MemStore的大小超過了hbase.hregion.memstore.flush.size的大小，此時當前的HRegion中所有的MemStore會Flush到HDFS中
- 當全局MemStore的大小超過了hbase.regionserver.global.memstore.upperLimit的大小，默認40％的內存使用量。此時當前HRegionServer中所有HRegion中的MemStore都會Flush到HDFS中，Flush順序是MemStore大小的倒序，直到總體的MemStore使用量低於hbase.regionserver.global.memstore.lowerLimit，默認38%的內存使用量
- 待確認：一個HRegion中所有MemStore總和作為該HRegion的MemStore的大小還是選取最大的MemStore作為參考？
- 當前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
- 注意：因為這個大小超過限制引起的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
- Minor Compaction: 是指選取一些小的、相鄰的StoreFile將他們合並成一個更大的StoreFile，在這個過程中不會處理已經Deleted或Expired的Cell。一次Minor Compaction的結果是更少並且更大的StoreFile, 如下圖:
- Major Compaction: 是指將所有的StoreFile合並成一個StoreFile，在這個過程中，標記為Deleted的Cell會被刪除，而那些已經Expired的Cell會被丟棄，那些已經超過最多版本數的Cell會被丟棄。一次Major Compaction的結果是一個HStore只有一個StoreFile存在
- Major Compaction可以手動或自動觸發，然而由於它會引起很多的IO操作而引起性能問題，因而它一般會被安排在周末、凌晨等集群比較閑的時間, 如下示意圖：
- 修改Hbase配置文件可以控制compaction行為
- hbase.hstore.compaction.min :默認值為 3，(老版本是：hbase.hstore.compactionThreshold)，即store下面的storeFiles數量 減去 正在compaction的數量 >=3是，需要做compaction
- hbase.hstore.compaction.max 默認值為10，表示一次minor compaction中最多選取10個store file
- hbase.hstore.compaction.min.size 表示文件大小小於該值的store file 一定會加入到minor compaction的store file中
- 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,示意圖如下：
- 在zookeeper上創建ephemeral的znode指示parent region正在splitting
- HMaster監控父Regerion的region-in-transition znode
- 在parent region的文件夾中創建臨時split目錄
- 關閉parent region（會flush 所有memory store（memory file），等待active compaction結束），從現在開始parent region 不可服務。同時從本地server上offline parent region，每個region server都維護了一個valid region的list，該步將parent region從該list中移除
- Split所有的store file，這一步為每個文件做一個reference file，reference file由兩部分組成
- 第一部分是源文件的路徑，第二部分是新的reference file引用源文件split key以及引用上半截還是下半截
- 舉個例子：源文件是Table1/storefile.11，split point 是key1, 則split 成兩個子文件可能可能是Table1/storefile.11.bottom.key1，Table1/storefile.11.up.key1，表示從key1切開storefile.11后，兩個引用文件分別引用源文件的下半部分和上半部分
- 創建child region
- 設置各種屬性，比如將parent region的訪問指標平分給child region，每人一半
- 將上面在parent 文件夾中生成的臨時文件夾（里面包含對parent region的文件reference）move到表目錄下，現在在目錄層次上，child region已經跟parent region平起平坐了
- 向系統meta server中寫入parent region split完畢的信息，並將child region的名字一並寫入（split狀態在meta層面持久化）
- 分別Open 兩個child region，主要包含以下幾個步驟：
- 將child region信息寫入meta server
- Load 所有store file，並replay log等
- 如果包含reference文件，則做一次compaction（類似merge），直到將所有的reference文件compact完畢，這里可以看到parent region的文件是會被拆開寫入各個child regions的
- 將parent region的狀態由SPLITTING轉為SPLIT，zookeeper會負責通知master開始處理split事件，master開始offline parent region，並online child regions
- Worker等待master處理完畢之后，確認child regions都已經online，split結束
read:
- 根據Rowkey尋址（詳情見上一節尋址部分），如下圖：
獲取數據順序規則，如下圖：
參考和來源：https://www.cnblogs.com/tgzhu/p/5857035.html
參考資料：