hbase rowkey設計

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。以下圖所示：

事務數據Rowkey設計
第0字節	第1字節	第2字節	第3字節	第4字節	第5字節	…
散列字段	時間字段(毫秒)	擴展字段
0~65535(0x0000~0xFFFF)	0~86399999(0x00000000~0x05265BFF)

這樣的設計從操做系統內存管理層面沒法節省開銷，由於64位操做系統是必須8字節對齊。可是對於持久化存儲中Rowkey部分能夠節省25%的開銷。也許有人要問爲何不將時間字段以主機字節序保存，這樣它也能夠做爲散列字段了。這是由於時間範圍內的數據仍是儘可能保證連續，相同時間範圍內的數據查找的機率很大，對查詢檢索有好的效果，所以使用獨立的散列字段效果更好，對於某些應用，咱們能夠考慮利用散列字段所有或者部分來存儲某些數據的字段信息，只要保證相同散列值在同一時間（毫秒）惟一。

2.2.2 針對統計數據的Rowkey設計

統計數據也是帶時間屬性的，統計數據最小單位只會到分鐘（到秒預統計就沒意義了）。同時對於統計數據咱們也缺省採用按天數據分表，這樣設計的好處無需多說。按天分表後，時間信息只須要保留小時分鐘，那麼0~1400只需佔用兩個字節便可保存時間信息。因爲統計數據某些維度數量很是龐大，所以須要4個字節做爲序列字段，所以將散列字段同時做爲序列字段使用也是6個字節組成惟一Rowkey。以下圖所示：

統計數據Rowkey設計
第0字節	第1字節	第2字節	第3字節	第4字節	第5字節	…
散列字段(序列字段）	時間字段(分鐘)	擴展字段
0x00000000~0xFFFFFFFF)	0~1439(0x0000~0x059F)

一樣這樣的設計從操做系統內存管理層面沒法節省開銷，由於64位操做系統是必須8字節對齊。可是對於持久化存儲中Rowkey部分能夠節省25%的開銷。預統計數據可能涉及到屢次反覆的重計算要求，需確保做廢的數據能有效刪除，同時不能影響散列的均衡效果，所以要特殊處理。

2.2.3 針對通用數據的Rowkey設計

通用數據採用自增序列做爲惟一主鍵，用戶能夠選擇按天建分表也能夠選擇單表模式。這種模式須要確保同時多個入庫加載模塊運行時散列字段（序列字段）的惟一性。能夠考慮給不一樣的加載模塊賦予惟一因子區別。設計結構以下圖所示。

通用數據Rowkey設計
第0字節	第1字節	第2字節	第3字節	…
散列字段(序列字段）	擴展字段（控制在12字節內）
0x00000000~0xFFFFFFFF)	可由多個用戶字段組成

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期間建立的文件），文件名（「中國好聲音」），分類（「綜藝」），全部者（「浙江衛視」）。

假設當前咱們一共有以下文件：

ID	CreateTime	Name	Category	UserID
1	20120902	中國好聲音第1期	綜藝	1
2	20120904	中國好聲音第2期	綜藝	1
3	20120906	中國好聲音外卡賽	綜藝	1
4	20120908	中國好聲音第3期	綜藝	1
5	20120910	中國好聲音第4期	綜藝	1
6	20120912	中國好聲音選手採訪	綜藝花絮	2
7	20120914	中國好聲音第5期	綜藝	1
8	20120916	中國好聲音錄製花絮	綜藝花絮	2
9	20120918	張瑋獨家專訪	花絮	3
10	20120920	加多寶涼茶廣告	綜藝廣告	4

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

1表明 浙江衛視； 2表明 好聲音劇組； 3表明 XX微博； 4表明贊助商。調用查詢接口的時候將上述5個條件同時輸入find(20120901,20121001,」中國好聲音」,」綜藝」,」浙江衛視」)。此時咱們應該獲得記錄應該有第一、二、三、四、五、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表結構設計。