1 概述

HBase是一個分散式的、面向列的資料庫，它和一般關係型資料庫的最大區別是：HBase很適合於儲存非結構化的資料，還有就是它基於列的而不是基於行的模式。

既然HBase是採用KeyValue的列儲存，那Rowkey就是KeyValue的Key了，表示唯一一行。Rowkey也是一段二進位制碼流，最大長度為64KB，內容可以由使用的使用者自定義。資料載入時，一般也是根據Rowkey的二進位制序由小到大進行的。

HBase是根據Rowkey來進行檢索的，系統通過找到某個Rowkey (或者某個 Rowkey 範圍)所在的Region，然後將查詢資料的請求路由到該Region獲取資料。HBase的檢索支援3種方式：

（1） 通過單個Rowkey訪問，即按照某個Rowkey鍵值進行get操作，這樣獲取唯一一條記錄；

（2） 通過Rowkey的range進行scan，即通過設定startRowKey和endRowKey，在這個範圍內進行掃描。這樣可以按指定的條件獲取一批記錄；

（3） 全表掃描，即直接掃描整張表中所有行記錄。

HBASE按單個Rowkey檢索的效率是很高的，耗時在1毫秒以下，每秒鐘可獲取1000~2000條記錄，不過非key列的查詢很慢。

2 HBase的RowKey設計

2.1 設計原則

2.1.1 Rowkey長度原則

Rowkey是一個二進位制碼流，Rowkey的長度被很多開發者建議說設計在10~100個位元組，不過建議是越短越好，不要超過16個位元組。

原因如下：

（1）資料的持久化檔案HFile中是按照KeyValue儲存的，如果Rowkey過長比如100個位元組，1000萬列資料光Rowkey就要佔用100*1000萬=10億個位元組，將近1G資料，這會極大影響HFile的儲存效率；

（2）MemStore將快取部分資料到記憶體，如果Rowkey欄位過長記憶體的有效利用率會降低，系統將無法快取更多的資料，這會降低檢索效率。因此Rowkey的位元組長度越短越好。

（3）目前作業系統是都是64位系統，記憶體8位元組對齊。控制在16個位元組，8位元組的整數倍利用作業系統的最佳特性。

2.1.2 Rowkey雜湊原則

如果Rowkey是按時間戳的方式遞增，不要將時間放在二進位制碼的前面，建議將Rowkey的高位作為雜湊欄位，由程式迴圈生成，低位放時間欄位，這樣將提高資料均衡分佈在每個Regionserver實現負載均衡的機率。如果沒有雜湊欄位，首欄位直接是時間資訊將產生所有新資料都在一個 RegionServer上堆積的熱點現象，這樣在做資料檢索的時候負載將會集中在個別RegionServer，降低查詢效率。

2.1.3 Rowkey唯一原則

必須在設計上保證其唯一性。

2.2 應用場景

基於Rowkey的上述3個原則，應對不同應用場景有不同的Rowkey設計建議。

2.2.1 針對事務資料Rowkey設計

事務資料是帶時間屬性的，建議將時間資訊存入到Rowkey中，這有助於提示查詢檢索速度。對於事務資料建議預設就按天為資料建表，這樣設計的好處是多方面的。按天分表後，時間資訊就可以去掉日期部分只保留小時分鐘毫秒，這樣4個位元組即可搞定。加上雜湊欄位2個位元組一共6個位元組即可組成唯一 Rowkey。如下圖所示：

這樣的設計從作業系統記憶體管理層面無法節省開銷，因為64位作業系統是必須8位元組對齊。但是對於持久化儲存中Rowkey部分可以節省25%的開銷。也許有人要問為什麼不將時間欄位以主機位元組序儲存，這樣它也可以作為雜湊欄位了。這是因為時間範圍內的資料還是儘量保證連續，相同時間範圍內的資料查詢的概率很大，對查詢檢索有好的效果，因此使用獨立的雜湊欄位效果更好，對於某些應用，我們可以考慮利用雜湊欄位全部或者部分來儲存某些資料的欄位資訊，只要保證相同雜湊值在同一時間（毫秒）唯一。

2.2.2 針對統計資料的Rowkey設計

統計資料也是帶時間屬性的，統計資料最小單位只會到分鐘（到秒預統計就沒意義了）。同時對於統計資料我們也預設採用按天資料分表，這樣設計的好處無需多說。按天分表後，時間資訊只需要保留小時分鐘，那麼0~1400只需佔用兩個位元組即可儲存時間資訊。由於統計資料某些維度數量非常龐大，因此需要4個位元組作為序列欄位，因此將雜湊欄位同時作為序列欄位使用也是6個位元組組成唯一Rowkey。如下圖所示：

同樣這樣的設計從作業系統記憶體管理層面無法節省開銷，因為64位作業系統是必須8位元組對齊。但是對於持久化儲存中Rowkey部分可以節省25%的開銷。預統計資料可能涉及到多次反覆的重計算要求，需確保作廢的資料能有效刪除，同時不能影響雜湊的均衡效果，因此要特殊處理。

2.2.3 針對通用資料的Rowkey設計

通用資料採用自增序列作為唯一主鍵，使用者可以選擇按天建分表也可以選擇單表模式。這種模式需要確保同時多個入庫載入模組執行時雜湊欄位（序列欄位）的唯一性。可以考慮給不同的載入模組賦予唯一因子區別。設計結構如下圖所示。

2.2.4 支援多條件查詢的RowKey設計

HBase按指定的條件獲取一批記錄時，使用的就是scan方法。 scan方法有以下特點：

（1）scan可以通過setCaching與setBatch方法提高速度（以空間換時間）；

（2）scan可以通過setStartRow與setEndRow來限定範圍。範圍越小，效能越高。

通過巧妙的RowKey設計使我們批量獲取記錄集合中的元素挨在一起（應該在同一個Region下），可以在遍歷結果時獲得很好的效能。

（3）scan可以通過setFilter方法新增過濾器，這也是分頁、多條件查詢的基礎。

在滿足長度、三列、唯一原則後，我們需要考慮如何通過巧妙設計RowKey以利用scan方法的範圍功能，使得獲取一批記錄的查詢速度能提高。下例就描述如何將多個列組合成一個RowKey，使用scan的range來達到較快查詢速度。

例子：

我們在表中儲存的是檔案資訊，每個檔案有5個屬性：檔案id（long，全域性唯一）、建立時間（long）、檔名（String）、分類名（String）、所有者（User）。

我們可以輸入的查詢條件：檔案建立時間區間（比如從20120901到20120914期間建立的檔案），檔名（“中國好聲音”），分類（“綜藝”），所有者（“浙江衛視”）。

假設當前我們一共有如下檔案：

這裡UserID應該對應另一張User表，暫不列出。我們只需知道UserID的含義：

1代表 浙江衛視； 2代表 好聲音劇組； 3代表 XX微博； 4代表贊助商。呼叫查詢介面的時候將上述5個條件同時輸入find(20120901,20121001,”中國好聲音”,”綜藝”,”浙江衛視”)。此時我們應該得到記錄應該有第1、2、3、4、5、7條。第6條由於不屬於“浙江衛視”應該不被選中。我們在設計RowKey時可以這樣做：採用 UserID + CreateTime + FileID組成RowKey，這樣既能滿足多條件查詢，又能有很快的查詢速度。

需要注意以下幾點：

（1）每條記錄的RowKey，每個欄位都需要填充到相同長度。假如預期我們最多有10萬量級的使用者，則userID應該統一填充至6位，如000001，000002…

（2）結尾新增全域性唯一的FileID的用意也是使每個檔案對應的記錄全域性唯一。避免當UserID與CreateTime相同時的兩個不同檔案記錄相互覆蓋。

按照這種RowKey儲存上述檔案記錄，在HBase表中是下面的結構：

rowKey（userID 6 + time 8 + fileID 6） name category ….

00000120120902000001

00000120120904000002

00000120120906000003

00000120120908000004

00000120120910000005

00000120120914000007

00000220120912000006

00000220120916000008

00000320120918000009

00000420120920000010

怎樣用這張表？

在建立一個scan物件後，我們setStartRow(00000120120901)，setEndRow(00000120120914)。

這樣，scan時只掃描userID=1的資料，且時間範圍限定在這個指定的時間段內，滿足了按使用者以及按時間範圍對結果的篩選。並且由於記錄集中儲存，效能很好。

然後使用 SingleColumnValueFilter（org.apache.hadoop.hbase.filter.SingleColumnValueFilter），共4個，分別約束name的上下限，與category的上下限。滿足按同時按檔名以及分類名的字首匹配。

（注意：使用SingleColumnValueFilter會影響查詢效能，在真正處理海量資料時會消耗很大的資源，且需要較長的時間）

如果需要分頁還可以再加一個PageFilter限制返回記錄的個數。

以上，我們完成了高效能的支援多條件查詢的HBase表結構設計。

http://www.open-open.com/lib/view/open1417612091323.html