好用的東西，總能找到對應的開源實現，這就是開源得魅力。

下面一張圖看下Hbase的前世今生：

HBase是一個構建在HDFS上的分散式列儲存系統；
HBase是基於Google BigTable模型開發的，典型的key/value系統；
HBase是Apache Hadoop生態系統中的重要一員，主要用於海量結構化資料儲存；
從邏輯上講，HBase將資料按照表、行和列進行儲存。
與hadoop一樣，Hbase目標主要依靠橫向擴充套件，通過不斷增加廉價的商用伺服器，來增加計算和儲存能力。

Hbase表的特點
大：一個表可以有數十億行，上百萬列；
無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一張表中不同的行可以有截然不同的列；
面向列：面向列（族）的儲存和許可權控制，列（族）獨立檢索；
稀疏：空（null）列並不佔用儲存空間，表可以設計的非常稀疏；
資料多版本：每個單元中的資料可以有多個版本，預設情況下版本號自動分配，是單元格插入時的時間戳；
資料型別單一：Hbase中的資料都是字串，沒有型別。

我們再看一下Hbase在hadoop中所佔的角色：

其中：

HBase位於結構化儲存層，圍繞HBase，各部件對HBase的支援情況：
Hadoop部件　　　　　　　　　　　　作用
HDFS　　　　　　　　　　　　　 高可靠的底層儲存支援
MapReduce   　　　　　　 　　高效能的計算能力
Zookeeper   　　　　　　　　 穩定服務和failover機制
Pig&Hive　　　　　　　　　　　高層語言支援，便於資料統計
Sqoop　　　　　　　　　　　　　提供RDBMS資料匯入，便於傳統資料庫向HBase遷移

Hbase的資料模型：

• 行鍵，Table的主鍵，Table中的記錄按照Row Key排序
• 時間戳，每次資料操作對應的時間戳，可以看作是資料的version number
• 列簇，Table在水平方向有一個或者多個Column Family組成，一個Column Family中可以由任意多個Column組成，即Column Family支援動態擴充套件，無需預先定義Column的數量以及型別，所有Column均以二進位制格式儲存，使用者需要自行進行型別轉換。

Table與Region

1. Table隨著記錄增多不斷變大，會自動分裂成多份Splits，成為Regions
2. 一個region由[startkey，endkey)表示
3. 不同region會被Master分配給相應的RegionServer進行管理

ROOT與META表

• Hbase中有兩張特殊表，ROOT和META
• META：記錄了使用者表的Region資訊，可以有多個region
• ROOT：記錄了META表的Region資訊，ROOT中只有一個region
• Zookeeper中記錄了ROOT表的location
• 客戶端訪問資料的流程：
  Client -> Zookeeper -> -ROOT- -> .META. -> 使用者資料表

Memstore與storefile

• 1：一個region由個store組成，每個store包含一個列族的所有資料。
• 2：store包括位於把記憶體的memstore和位於硬碟的storefile
• 3：寫操作先寫memstore，當memstore中的資料量到達某個閥值，hregionserver會啟動flashcache進場寫入storefile，每次寫入形成單獨的一個storefile
• 4：當storefile檔案的數量增到到一定閥值後，系統會進行自動合併，在合併過程中會進行版本合併和刪除，形成更大的storefile
• 5：當storefile大小超越一定閥值後，會把當前的region分割為兩個，並有Hmaster分配到相應的region伺服器，實現負載均衡。
• 6：客戶端檢索資料時，先在memstore找，然後是storefile。

Hbase系統架構

組成部件說明

1. Client：
   使用HBase RPC機制與HMaster和HRegionServer進行通訊
   Client與HMaster進行通訊進行管理類操作
   Client與HRegionServer進行資料讀寫類操作
2. Zookeeper：
   Zookeeper Quorum儲存-ROOT-表地址、HMaster地址
   HRegionServer把自己以Ephedral方式註冊到Zookeeper中，HMaster隨時感知各個HRegionServer的健康狀況
   Zookeeper避免HMaster單點問題
3. HMaster：
   HMaster沒有單點問題，HBase中可以啟動多個HMaster，通過Zookeeper的Master Election機制保證總有一個Master在執行
   主要負責Table和Region的管理工作：
   1 管理使用者對錶的增刪改查操作
   2 管理HRegionServer的負載均衡，調整Region分佈
   3 Region Split後，負責新Region的分佈
   4 在HRegionServer停機後，負責失效HRegionServer上Region遷移
4. HRegionServer：
   HBase中最核心的模組，主要負責響應使用者I/O請求，向HDFS檔案系統中讀寫資料

–Region server維護region，處理對這些region的IO請求
–Region server負責split在執行過程中變得過大的region

如上圖所示，當Client連上HReigonServer後，後者會開啟相應的HRegion物件，為每個HColumeFamily建立Store例項，每個Store例項有一個MemStore，一個或多個StoreFile，StoreFile是HFile輕量級的包裝。
1 寫資料過程
首先是把Log寫入到HLog中，HLog是標準的Hadoop Sequence File，由於Log資料量小，而且是順序寫，速度非常快；同時把資料寫入到記憶體MemStore中，成功後返回給Client，所以對Client來說，HBase寫的速度非常快，因為資料只要寫入到記憶體中，就算成功了。
接著檢查MemStore是否已滿，如果滿了，就把記憶體中的MemStore Flush到磁碟上，形成一個新的StoreFile。
當Storefile檔案的數量增長到一定閾值後，系統會進行合併（Compact），在合併過程中會進行版本合併和刪除工作，形成更大的storefile。
當Storefile大小超過一定閾值後，會把當前的Region分割為兩個（Split），並由Hmaster分配到相應的HRegionServer，實現負載均衡
2 讀資料過程
由於無法直接修改HBase裡的資料，所有的update和delete操作都轉換成insert操作，而且HBase裡也沒有索引，因此讀資料都是以Scan的方式進行。
Client在讀資料時，一般會指定timestamp和ColumnFamily.
首先，根據ColumnFamily可以過濾掉很大一部分Store，這也是HBase作為列式資料庫的一大優勢。
然後，根據timestamp和Bloom Filter排除掉一些StoreFiles
最後，在剩下的StoreFile （包含MemStore）裡Scan查詢

Hstore：

HBase儲存的核心。由MemStore和StoreFile組成。
MemStore是Sorted Memory Buffer。使用者寫入資料的流程：

Client寫入 -> 存入MemStore，一直到MemStore滿 -> Flush成一個StoreFile，直至增長到一定閾值 -> 出發Compact合併操作 -> 多個StoreFile合併成一個StoreFile，同時進行版本合併和資料刪除 -> 當StoreFiles Compact後，逐步形成越來越大的StoreFile -> 單個StoreFile大小超過一定閾值後，觸發Split操作，把當前Region Split成2個Region，Region會下線，新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer上，使得原先1個Region的壓力得以分流到2個Region上
由此過程可知，HBase只是增加資料，有所得更新和刪除操作，都是在Compact階段做的，所以，使用者寫操作只需要進入到記憶體即可立即返回，從而保證I/O高效能。

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，完成資料恢復。