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
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
參考資料：
http://hortonworks.com/blog/apache-hbase-region-splitting-and-merging/
https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx
作者的原創文章，轉載須注明出處。原創文章歸作者所有，歡迎轉載，但是保留版權。對于轉載了部落客的原創文章，不标注出處的，作者将依法追究版權，請尊重作者的成果。