最近關注Hadoop，因此也順便關注了一下Hadoop相關的項目。HBASE就是基于Hadoop的一個開源項目，也是對Google的BigTable的一種實現。
BigTable是什么？Google的Paper對其作了充分的說明。字面上看就是一張大表，其實和我們想象的傳統數據庫的表還是有些差別的。松散數據可以說是介于Map Entry（key & value）和DB Row之間的一種數據。在我使用Memcache的時候，有時候的需求是需要存儲的不僅僅是簡單的一個key對應一個value，可能我需要類似于數據庫表結構中多屬性的存儲，但是又不會有傳統數據庫表結構中那么多關聯關系的需求，其實這類數據就是所謂的松散數據。BigTable最淺顯來看就是一張很大的表，表的屬性可以根據需求去動態增加，但是又沒有表與表之間關聯查詢的需求。
互聯網應用有一個最大的特點，就是速度，功能再強大，速度慢，還是會被舍棄。因此在大訪問量的網站都采取前后的緩存來提升性能和響應時間。對于Map Entry類型的數據，集中式分布式Cache都有很多選擇，對于傳統的關系型數據，從MySQL到Oracle都給了很好的支持，唯有松散數據這類數據，采用前后兩種解決方案都不能最大化它的處理能力。因此BigTable才有了它用武之地。
HBASE作為Apache的開源項目，也是出于起步階段，因為其實它所依賴的Hadoop也不能說已經到了成熟階段，所以都有很大的發展空間，這也為我們這些開源愛好者提供了更多空間去貢獻。這里主要會談到HBASE的框架設計方面的知識和它的一些特點，不論是否采用HBASE去解決工作中的問題，一種好的流程設計總會給開發者和架構設計者帶來一些思想上的火花。
HBASE設計介紹
數據模型
HBASE中的每一張表，就是所謂的BigTable。BigTable會存儲一系列的行記錄，行記錄有三個基本類型的定義：Row Key,Time Stamp,Column。Row Key是行在BigTable中的唯一標識，Time Stamp是每次數據操作對應關聯的時間戳，可以看作類似于SVN的版本，Column定義為：<family>:<label>，通過這兩部分可以唯一的指定一個數據的存儲列，family的定義和修改需要對HBASE作類似于DB的DDL操作，而對于label的使用，則不需要定義直接可以使用，這也為動態定制列提供了一種手段。family另一個作用其實在于物理存儲優化讀寫操作，同family的數據物理上保存的會比較臨近，因此在業務設計的過程中可以利用這個特性。
看一下邏輯數據模型：
|
Row Key
|
Time Stamp
|
Column "contents:"
|
Column "anchor:"
|
Column "mime:"
|
|
"com.cnn.www"
|
t9
|
|
"anchor:cnnsi.com"
|
"CNN"
|
|
|
t8
|
|
"anchor:my.look.ca"
|
"CNN.com"
|
|
|
t6
|
"<html>..."
|
|
|
"text/html"
|
|
t5
|
"<html>..."
|
|
|
|
|
t3
|
"<html>..."
|
|
|
|
上表中有一列，列的唯一標識為com.cnn.www，每一次邏輯修改都有一個timestamp關聯對應，一共有四個列定義：<contents:>,<anchor:cnnsi.com>,<anchor:my.look.ca>,<mime:>。如果用傳統的概念來將BigTable作解釋，那么BigTable可以看作一個DB Schema，每一個Row就是一個表，Row key就是表名，這個表根據列的不同可以劃分為多個版本，同時每個版本的操作都會有時間戳關聯到操作的行。
再看一下HBASE的物理數據模型：
|
Row Key
|
Time Stamp
|
Column "contents:"
|
|
"com.cnn.www"
|
t6
|
"<html>..."
|
|
t5
|
"<html>..."
|
|
t3
|
"<html>..."
|
|
Row Key
|
Time Stamp
|
Column "anchor:"
|
|
"com.cnn.www"
|
t9
|
"anchor:cnnsi.com"
|
"CNN"
|
|
t8
|
"anchor:my.look.ca"
|
"CNN.com"
|
|
Row Key
|
Time Stamp
|
Column "mime:"
|
|
"com.cnn.www"
|
t6
|
"text/html"
|
物理數據模型其實就是將邏輯模型中的一個Row分割成為根據Column family存儲的物理模型。
對于BigTable的數據模型操作的時候，會鎖定Row，并保證Row的原子操作。
框架結構及流程
圖1 框架結構圖
HBASE依托于Hadoop的HDFS作為存儲基礎，因此結構也很類似于Hadoop的Master-Slave模式，Hbase Master Server 負責管理所有的HRegion Server，但Hbase Master Server本身并不存儲HBASE中的任何數據。HBASE邏輯上的Table被定義成為一個Region存儲在某一臺HRegion Server上，HRegion Server與Region的對應關系是一對多的關系。每一個HRegion在物理上會被分為三個部分：Hmemcache、Hlog、HStore，分別代表了緩存，日志，持久層。通過一次更新流程來看一下這三部分的作用：
圖2 提交更新以及刷新Cache流程
由流程可以看出，提交更新操作將會寫入到兩部分實體中，HMemcache和Hlog中，HMemcache就是為了提高效率在內存中建立緩存，保證了部分最近操作過的數據能夠快速的被讀取和修改，Hlog是作為同步Hmemcache和Hstore的事務日志，在HRegion Server周期性的發起Flush Cache命令的時候，就會將Hmemcache中的數據持久化到Hstore中，同時會清空Hmemecache中的數據，這里采用的是比較簡單的策略來做數據緩存和同步，復雜一些其實可以參照java的垃圾收集機制來做。
在讀取Region信息的時候，優先讀取HMemcache中的內容，如果未取到再去讀取Hstore中的數據。
幾個細節：
1． 由于每一次Flash Cache，就會產生一個Hstore File，在Hstore中存儲的文件會越來越多，對性能也會產生一定影響，因此達到設置文件數量閥值的時候就會Merge這些文件為一個大文件。
2． Cache大小的設置以及flush的時間間隔設置需要考慮內存消耗以及對性能的影響。
3． HRegion Server每次重新啟動的時候會將Hlog中沒有被Flush到Hstore中的數據再次載入到Hmemcache，因此Hmemcache過大對于啟動的速度也有直接影響。
4． Hstore File中存儲數據采用B-tree的算法，因此也支持了前面提到對于Column同Family數據操作的快速定位獲取。
5． HRegion可以Merge也可以被Split，根據HRegion的大小決定。不過在做這些操作的時候HRegion都會被鎖定不可使用。
6． Hbase Master Server通過Meta-info Table來獲取HRegion Server的信息以及Region的信息，Meta最頂部的一個Region是虛擬的一個叫做Root Region，通過Root Region可以找到下面各個實際的Region。
7． 客戶端通過Hbase Master Server獲得了Region所在的Region Server，然后就直接和Region Server進行交互，而對于Region Server相互之間不通信，只和Hbase Master Server交互，受到Master Server的監控和管理。
后話
對HBase還沒有怎么使用，僅僅只是看了wiki去了解了一下結構和作用，暫時還沒有需要使用的場景，不過對于各種開源項目的設計有所了解，對自己的框架結構設計也會有很多幫助，因此分享一下。