一、概述

HBase有以下幾個特點：

• HBase列的可以動態增加，並且列為空就不儲存資料,節省儲存空間.
• hbase自動切分資料，使得資料儲存自動具有水平scalability.
• Hbase可以提供高併發讀寫操作的支援。
• HBase不能支援條件查詢，只支援按照Row key來查詢.
• 暫時不能支援Master server的故障切換,當Master宕機後,整個儲存系統就會掛掉.

因為HBase的這些特點，是它和Mysql的等關係型資料庫的應用場景和設計理念完全不同。傳統關係型資料庫(mysql，oracle)資料儲存方式主要如下：

上圖是個很典型的資料儲存方式，我把每條記錄分成3部分: 主鍵、記錄屬性、索引欄位 。我們會對索引欄位建立索引，達到二級索引的效果。
但是隨著業務的發展，查詢條件越來越複雜，需要更多的索引欄位，且很多值都不存在，如下圖：

上圖是6個索引欄位， 實際情況可能是上百個甚至更多，並且還需要根據多個索引欄位刷選。查詢效能越來越低，甚至無法滿足查詢要求。關係型資料裡的侷限也開始顯現，於是很就出現了Nosql等非關係資料庫。
HBase作為一個列族資料庫很強大，很多人就想把資料從mysql遷到hbase，儲存的內容還是跟上圖一樣，主鍵設為為rowkey。其他各個欄位的資料，儲存一個列族下的不同列。但是想對索引欄位查詢就沒有辦法，目前還沒有比較好的基於bigtable的二級索引方案，所以無法對索引欄位做查詢。這時候其實可以轉換下思維，可以把資料倒過來，如下圖：

把各個索引欄位的值作為rowkey，然後把記錄的主鍵和屬性值按照一定順序存在對應rowkey的value裡。上圖只有一個列族，是最簡單的方式。 Value裡的記錄可以設定成定長的byte[]，多個記錄集合通過移位快速查詢到。
但是上面只適合單個索引欄位的查詢。如果要同時對多個索引欄位查詢，比如查詢“浙江”and“手機”，需要取出兩個value，再解析出各自的主鍵求交集。如果每條記錄的屬性有上百個，對效能影響很大。
接下來的的問題就是解決多索引欄位查詢的問題。我們將主鍵欄位和屬性欄位分開儲存 ，儲存在不同的列族下，多索引查詢只需要取出列族1下的資料，再去最小集合的列族2裡取得想要的值。儲存如下圖：

為什麼是不同列族，而不是一個列族下的兩個列？
列族資料庫資料檔案是按照列族分的。在取資料時，都會把一個列族的所有列資料都取出來，事實上我們並不需要把記錄明細取出來，所以把這部分資料放到了另一個列族下。
接下來是對列族2擴充套件，列族2儲存更多的列，用來做各種刷選、計算處理。如下圖：

二、HBase和RDBMS的區別

1、資料型別

Hbase只有簡單的字元型別，所有的型別都是交由使用者自己處理，它只儲存字串。使用者需要自己進行型別轉換。而關係資料庫有豐富的型別和儲存方式。

2、資料操作

HBase只有很簡單的插入、查詢、刪除、清空等操作，表和表之間是分離的，沒有複雜的表和表之間的關係。而傳統資料庫通常有各式各樣的函式和連線操作。

3、儲存模式

HBase是基於列儲存的，每個列族都由幾個檔案儲存，不同的列族的檔案時分離的。而傳統的關係型資料庫是基於表格結構和行模式儲存的 。

4、資料維護

HBase的更新操作不應該叫更新，它實際上是插入了新的資料原來的舊版本仍然保留著，而傳統資料庫是替換修改。

5、可伸縮性

Hbase這類分散式資料庫就是為了這個目的而開發出來的，所以它能夠輕鬆增加或減少硬體的數量，並且對錯誤的相容性比較高。而傳統資料庫通常需要增加中間層才能實現類似的功能。

三、Hbase檢索時間複雜度

既然使用Hbase的目的是高效、高可靠、高併發的訪問海量非結構化資料，那麼Hbase檢索資料的時間複雜度是關係到基於Hbase的業務系統開發設計的重中之重，Hbase的運算有多快，我們從計算機演算法的數學角度做簡要分析，以便讀者理解後文的專案例項中Hbase業務建模及設計模式中的考量因素。
我們先以如下變數定義Hbase的相關資料資訊：

n=表中KeyValue條目數量（包括Put結果和Delete留下的標記）
b=HFile裡資料庫（HFileBlock）的數量
e=平均一個HFile裡面KeyValue條目的數量（如果知道行的大小，可以計算得到）
c=每行裡列的平均數量

我們知道Hbase中有兩張特殊表：-ROOT-&.META.，其中.META.表記錄Region分割槽資訊，同時，.META.也可以有多個Region分割槽，同時-ROOT-表又記錄.META.表的Region資訊，但-ROOT-只有一個Region，而-ROOT-表的位置由Hbase的叢集管控框架，即Zookeeper記錄。
關於-ROOT-&.META.表的細節這裡不再累述，感興趣的讀者可以參閱Hbase–ROOT-及.META.表資料，理解HbaseIO及資料檢索時序原理。
Hbase檢索一條資料的流程如下圖所示。

如上圖我們可以看出，Hbase檢索一條客戶資料需要的處理過程大致如下：
(1)如果不知道行健，直接查詢列key-value值，則你需要查詢整個region區間，或者整個Table，那樣的話時間複雜度是O(n)，這種情況是最耗時的操作，通常客戶端程式是不能接受的，我們主要分析針對行健掃描檢索的時間複雜度情況，也就是以下2至4步驟的內容。
(2)客戶端尋找正確的RegionServer和Region。花費3次固定運算找到正確的region，包括查詢ZooKeeper，查詢-ROOT-表，找找.META表，這是一次O(1)運算。
(3)在指定Region上，行在讀過程中可能存在兩個地方，如果還沒有刷寫到硬碟，那就是在MemStore中，如果已經刷寫到硬碟，則在一個HFile中。假定只有一個HFile，這一行資料要麼在這個HFile中，要麼在Memstore中。
(4)對於後者，時間複雜度通常比較固定，即O(loge)，對於前者，分析起來要複雜得多，在HFile中查詢正確的資料塊是一次時間複雜度為O(logb)的運算，找到這一行資料後，再查詢列簇裡面keyvalue物件就是線性掃描過程了（同一列簇的列資料通常是在同一資料塊中的），這樣的話掃描的時間複雜度是O(elb),如果列簇中的列資料不在同一資料塊，則需要訪問多個連續資料塊，這樣的時間複雜度為O(c)，因此這樣的時間複雜度是兩種可能性的最大值，也就是O(max(c,elb)。
綜上所述，查詢Hbase中某一行的時間開銷為：

O(1)用於查詢region
O(loge)用來在region中定位KeyValue，如果它還在MemStore中
O(logb）用來查詢HFile裡面正確的資料塊
O(max（celb)用來查詢HFile

四、HBase的模式設計原則及優化

1、列簇(clumn family)

不要在一張表裡定義太多的列簇，目前hbase不能很好處理超過3個列簇的表。hbase的flush和壓縮是基於region的，當一個列簇所儲存的資料達到flush閾值時，該表的所有列簇將同時進行flush操作，這將帶來不必要的I/O開銷。
同時還要到同一個表中不同列簇所儲存的記錄數量的差別，即列簇的勢。當列簇數量差別過大將會使包含記錄數量較少的列簇的資料分散在多個region上，而region可能是分佈在不同的regionserver上，這樣當進行查詢等操作，系統的效率會受到一定的影響。

2、行健(row key)

在HBase中，row key可以是任意字串，最大長度64KB，實際應用中一般為10~100bytes，存為byte[]位元組陣列，一般設計成定長的。
row key是按照字典序儲存，因此，設計row key時，要充分利用這個排序特點，將經常一起讀取的資料儲存到一塊，將最近可能會被訪問的資料放在一塊。
其次，還要避免使用時序或單調行健。因為當資料到來時，hbase首先根據記錄的行健來確定儲存位置，及region位置。如果行健是時序或單調行健，那麼連續到來的資料將會被分配到同一個region中，而此時系統中的其他region/regionserver將處於空閒狀態，這是分散式系統不希望看到的。 可以將時序作為行鍵的第二個欄位，併為行鍵新增一個字首。

3、儘量最小化行健和列簇的大小

hbase中一條記錄是由儲存該值的行健，對應的列以及該值的時間戳決定。hbase中索引是為了加速隨機訪問的速度。該索引的建立是基於”行健+列簇：列+時間戳+值”的，如果行健和列簇的大小過大，將會增加索引的大小，加重系統的負擔。

4、版本數量

建立表的時候，可以通過HColumnDescriptor.setMaxVersions(int maxVersions)設定表中資料的最大版本，如果只需要儲存最新版本的資料，那麼可以設定setMaxVersions(1)。HBase在進行資料儲存時，新資料不會直接覆蓋舊的資料，而是進行追加操作，不同的資料通過時間戳進行區分。預設每行資料儲存三個版本，建議不要將其設定過大。

5、存入記憶體

建立表的時候，可以通過HColumnDescriptor.setInMemory(true)將表放到RegionServer的快取中，保證在讀取的時候被cache命中。

6、TTL

建立表的時候，可以通過HColumnDescriptor.setTimeToLive(int timeToLive)設定表中資料的儲存生命期，過期資料將自動被刪除，例如如果只需要儲存最近兩天的資料，那麼可以設定setTimeToLive(2 * 24 * 60 * 60)。

7、合併和分片(compact&split)

在HBase中，資料在更新時首先寫入WAL 日誌(HLog)和記憶體(MemStore)中，MemStore中的資料是排序的，當MemStore累計到一定閾值時，就會建立一個新的MemStore，並且將老的MemStore新增到flush佇列，由單獨的執行緒flush到磁碟上，成為一個StoreFile。於此同時， 系統會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了(minor compact)。
StoreFile是隻讀的，一旦建立後就不可以再修改。因此Hbase的更新其實是不斷追加的操作。當一個Store中的StoreFile達到一定的閾值後，就會進行一次合併(major compact)，將對同一個key的修改合併到一起，形成一個大的StoreFile，當StoreFile的大小達到一定閾值後，又會對 StoreFile進行分割(split)，等分為兩個StoreFile。
由於對錶的更新是不斷追加的，處理讀請求時，需要訪問Store中全部的StoreFile和MemStore，將它們按照row key進行合併，由於StoreFile和MemStore都是經過排序的，並且StoreFile帶有記憶體中索引，通常合併過程還是比較快的。
實際應用中，可以考慮必要時手動進行major compact，將同一個row key的修改進行合併形成一個大的StoreFile。同時，可以將StoreFile設定大些，減少split的發生。

五、HBase的表設計例項

基於Hbase的系統設計與開發中，需要考慮的因素不同於關係型資料庫，Hbase模式本身很簡單，但賦予你更多調整的空間，有一些模式寫效能很好，但讀取資料時表現不好，或者正好相反，類似傳統資料庫基於正規化的OR建模，在實際專案中考慮Hbase設計模式是，我們需要從以下幾方面內容著手：

1. 這個表應該有多少個列簇
2. 列簇使用什麼資料
3. 每個列簇應有多少個列
4. 列名應該是什麼，儘管列名不必在建表時定義，但是讀寫資料時是需要的
5. 單元應該存放什麼資料
6. 每個單元儲存什麼時間版本
7. 行健結構是什麼，應該包括什麼資訊

以下我們以一個使用Hbase技術的客戶案例為例來展示。

1、場景介紹

客戶簡介：客戶是一個網際網路手機遊戲平臺，需要針對廣大手遊玩家進行手遊產品的統計分析，需要儲存每個手遊玩家即客戶對每個手遊產品的關注度（遊戲熱度），且儲存時間維度上的關注度資訊，從而能針對客戶的喜好進行挖掘並進行類似精準營銷的手遊定點推送，廣告營銷等業務，從而擴大該平臺的使用者量並提升使用者粘著度。
該平臺上手遊產品分類眾多，總共在500餘以上，註冊玩家（使用者帳號）數量在200萬左右，線上玩家數量5萬多，每天使用手遊頻率峰值在10萬/人次以上，年增量10%以上。
根據以上需求，手遊產品動態增長，無法確定哪些手遊產品需要被儲存，全部儲存又會超過200列，造成大量空間浪費，玩家每天使用手遊的頻率及分類不確定，客戶註冊使用者超百萬，按天的使用熱度資料量超過1000萬行，海量資料也使得表查詢及業務分析需要的叢集數量龐大及SQL優化，效率低下，因此傳統關係型資料庫不適合該類資料分析和處理的需求，在專案中我們決定採用Hbase來進行資料層的儲存的分析。

2、高表設計

讓我們回到上文中設計模式來考慮該客戶案例中表的設計，我們需要儲存玩家資訊，通常是微訊號，QQ號及在該手遊平臺上註冊的帳號，同時需要儲存該使用者關注什麼手遊產品的資訊。而使用者每天會玩一個或者多個手遊產品，每個產品玩一次或者多次，因此儲存的應該是該使用者對某一手遊產品的關注度（使用次數），該使用次數在每天是一個動態的值，而使用者對手遊產品也是一個多對多的key value鍵值的集合。該手遊平臺廠商關心的是諸如“XXX客戶玩家關注YYY手遊了麼？”，“YYY手遊被使用者關注了麼？”這類的業務維度分析。
假設每天每個手遊玩家對每個產品的關注度都存在該表中，則一個可能的設計方案是每個使用者每天對應一行，使用使用者ID+當天的時間戳作為行健，建立一個儲存手遊產品使用資訊的列簇，每列代表該天該使用者對該產品的使用次數。
本案例中我們只設計一個列簇，一個特定的列簇在HDFS上會由一個Region負責，這個region下的物理儲存可能有多個HFile，一個列簇使得所有列在硬碟上存放在一起，使用這個特性可以使不同型別的列資料放在不同的列簇上，以便隔離，這也是Hbase被稱為面向列儲存的原因，在這張表裡，因為所有手遊產品並沒有明顯的分類，對錶的訪問模式也不需區分手遊產品型別，因此並不需要多個列簇的劃分，你需要意識到一點：一旦建立了表，任何對該表列簇的動作通常都需要先讓表offline。
我們可以使用HbaseShell建立表，Hbaseshell指令碼示例如下：

然後向該表中插入資料，最後儲存的示例樣本如下：

表設計解釋如下：
rowkey為QQ121102645$20141216表示帳號為QQ121102645的手遊玩家（以QQ號聯邦認證的）在2014年12月16日當天的遊戲記錄；列簇degeeInfo記錄該行賬戶當天對每種產品型別的點選熱度(遊戲次數)，比如SpaceHunter: 1表示玩(或者點開)SpaceHunter(時空獵人)的次數為1次。
現在我們需要檢驗這張表是否滿足需求，為此最重要的事是定義訪問模式，也就是應用系統如何訪問Hbase表中的資料，在整個Hbase系統設計開發過程中應該儘早這麼做。
我們現在來看，我們設計的該Hbase表是否能回答客戶關心的問題：比如“帳號為QQ121102645的使用者關注過哪些手遊？”，沿著這個方向進一步思考，有相關業務分析的問題：“QQ121102645使用者是否玩過3CountryBattle（三國3）手遊？”“哪些使用者關注了DTLegend（刀塔傳奇)？”“3CountryBattle（三國3）手遊被關注過嗎？”
基於現在的prodFocus表設計，要回答“帳號為QQ121102645的使用者關注過哪些手遊？”這個訪問模式，可以在表上執行一個簡單的Scan掃描操作，該呼叫會返回整個QQ121102645字首的整個行，每一行的列簇進行列遍歷就能找到使用者關注的手遊列表。
程式碼如下：

HTablePool pool = new HTablePool();
HTableInterface prodTable = pool.getTable(“prodFocus”);
Scan a = new Scan();
a.addFamily(Bytes.toBytes(“degreeInfo”));
a.setStartRow(Bytes.toBytes(“QQ121102645”));
ResultScanner results = prodTable.getScanner(a);
List<KeyValue> list = result.list();
List<String> followGamess = new ArrayList<String>();
for(Result r:results){
    KeyValue kv = iter.next();;
    String game =kv.get(1];
    followGames.add(user);
}

因為prodFocus表rowkey設計為使用者ID $ 當天的時間戳，因此我們建立以使用者“QQ121102645”為檢索字首的Scan掃描，掃描返回的ResultScanner即為該使用者相關的所有行資料，遍歷每行的“degreeInfo”列簇中的各個列即可獲得該使用者所有關注（玩過）的手遊產品。

第二個問題“QQ121102645使用者是否玩過3CountryBattle（三國3）手遊”的業務跟第一個類似，客戶端程式碼可以用Scan找出行健為QQ121102645字首的所有行，返回的result集合可以建立一個數組列表，遍歷這個列表檢查3CountryBattles手遊是否作為列名存在，即可判斷該使用者是否關注某一手遊，相應程式碼與上文問題1的程式碼類似：

HTablePool pool = new HTablePool();
HTableInterface prodTable = pool.getTable(“prodFocus”);
Scan a = new Scan();
a.addFamily(Bytes.toBytes(“degreeInfo”));
a.setStartRow(Bytes.toBytes(“QQ121102645”));
ResultScanner results = prodTable.getScanner(a);
List<Integer> degrees = new ArrayList<Integer>();
List<KeyValue> list = results.list();
Iterator<KeyValue> iter = list.iterator();
String gameNm =“3CountryBattle”;
while(iter.hasNext()){
    KeyValue kv = iter.next();
    if(gameNm.equals(Bytes.toString(kv.getKey()))){
        return true;
    }
}
prodTable.close();
return false;

程式碼解釋：同樣通過掃描字首為“QQ121102645”的Scan執行表檢索操作，返回的List<keyValue>陣列中每一Key-value是degreeInfo列簇中每一列的鍵值對，即使用者關注（玩過）的手遊產品資訊，判斷其Key值是否包含“3CountryBattle”的遊戲名資訊即可知道該使用者是否關注該手遊產品。

看起來這個表設計是簡單實用的，但是如果我們接著看第三個和第四個業務問題“哪些使用者關注了DTLegend（刀塔傳奇)？”“3CountryBattle（三國3）手遊被關注過嗎？”
如你所看到的，現有的表設計對於多個手遊產品是放在列簇的多個列欄位中的，因此當某一使用者對產品的喜好趨於多樣化的時候（productkey-value鍵值對會很多，意味著某一rowkey的表列簇會變長，這本身也不是大問題，但它影響到了客戶端讀取的程式碼模式，會讓客戶端應用程式碼變得很複雜。
同時，對於第三和第四問題而言，每增加一種手遊關注的key-value鍵值，客戶端程式碼必須要先讀出該使用者的row行，再遍歷所有行列簇中的每一個列欄位。從上文Hbase索引的原理及內部檢索的機制我們知道，行健是所有Hbase索引的決定性因素，如果不知道行健，就需要把掃描限定在若干HFile資料塊中，更麻煩的是，如果資料還沒有從HDFS讀到資料塊快取，從硬碟讀取HFile的開銷更大，從上文Hbase檢索的時間複雜度分析來看，現在的Hbase表設計模式下需要在Region中檢索每一列，效率是列的個數*O(max(elb)，從理論上已經是最複雜的資料檢索過程。
對關注該平臺業務的客戶公司角度考慮，第三個第四個的業務問題更加關注客戶端獲取分析結果的實時分析的效能，因此從設計模式上應該設計更長的行健，更短的列簇欄位，提高Hbase行健的檢索效率並同時減少訪問寬行的開銷。

3、寬表設計

Hbase設計模式的簡單和靈活允許您做出各種優化，不需要做很多的工作就可以大大簡化客戶端程式碼，並且使檢索的效能獲得顯著提升。我們現在來看看prodFocus表的另一種設計模式，之前的表設計是一種寬表（widetable）模式，即一行包括很多列。每一列代表某一手遊的熱度。同樣的資訊可以用高表（talltable）形式儲存，新的高表形式設計的產品關注度表結構如下所示：

表解釋：將產品在某一天被某使用者關注的關聯關係設計到rowkey中，而其關注度資料只用一個key-value來儲存，行健Daqier_weixin1398765386465串聯了兩個值，產品名和使用者的帳號，這樣原來表設計中某一使用者在某天的資訊被轉換為一個“產品-關注的使用者”的關係，這是典型的高表設計。
HFile中的key-value物件儲存列簇名字。使用短的列簇名字在減少硬碟和網路IO方面很有幫助。這種優化方式也可以應用到行健，列名，甚至單元。緊湊的rowkey儲存業務資料意味應用程式檢索時，IO負載方面會大大降低。這種新表設計在回答之前業務關心的“哪些使用者關注了XXXX產品？”或者“XXXX產品被關注過嗎？”這類問題時，就可以基於行健使用get()直接得到答案，列簇中只有一個單元，所以不會有第一種設計中多個key-value遍歷的問題，在Hbase中訪問駐留在BlockCache的一個窄行是最快的讀操作。從IO方面來看，掃描這些行在一個寬行上執行get命令然後遍歷所有單元相比，從RegionServer讀取的資料量是相同的，但索引訪問效率明顯大大提高了。
例如要分析“3CountryBattles（三國群雄）手遊是否被QQ121102645使用者關注？”時，客戶端程式碼示例如下：

HTablePool pool = new HTablePool();
HTableInterface prodTable = pool.getTable(“prodFocusV2”);
String userNm =“QQ121102645”;
String gameNm =“3CountryBattles”;
Get g = new Get(Bytes.toBytes(userNm+”$”+gameNm));
g.addFamily(Bytes.toBytes(“degreeInfo”));
Result r = prodTable.get(g);
if(!r.isEmpty()){
    return true;
}
table.close();
return false;

程式碼解釋：由於prodFocusV2的rowkey設計改為被關注產品$使用者Id的高表模式，手遊產品及使用者資訊直接存放在行健中，因此程式碼以手遊產品名“3CountryBattles$”加使用者帳號“QQ121102645”的Byte資料作為Get鍵值，在表上直接執行Get操作，判斷返回的Result結果集是否為空即可知道該手遊產品是否被使用者關注。

4、其他優化

當然還有一些其他優化技巧。你可以使用MD5值做為行健，這樣可以得到定長的rowkey。使用雜湊鍵還有其他好處，你可以在行健中使用MD5去掉“$”分隔符，這會帶來兩個好處：一是行鍵都是統一長度的，可以幫助你更好的預測讀寫效能。第二個好處是，不再需要分隔符後，scan的操作程式碼更容易定義起始和停止鍵值。這樣的話你使用基於使用者$手遊名的MD5雜湊值來設定Scan掃描緊鄰的起始行（startRow和stopRow）就可以找到該手遊受關注的最新的熱度資訊。
使用雜湊鍵也會有助於資料更均勻的分佈在region上。如該案例中，如果客戶的關注度是正常的（即每天都有不同的客戶玩不同的遊戲），那資料的分佈不是問題，但有可能某些客戶的關注度是天生傾斜的（即某使用者就是喜歡某一兩個產品，每天熱度都在這一兩個產品上），那就會是一個問題，你會遇到負載沒有分攤在整個Hbase叢集上而是集中在某一個熱點的region上，這幾個region會成為整體效能的瓶頸，而如果對Daqier_weixin$1398765386465模式做MD5計算並把結果作為行鍵，你會在所有region上實現一個均勻的分佈。
使用MD5雜湊prodFocusV2表後的表示例如下：