HBase之六：HBase的RowKey設計

資料模型

 我們可以将一個表想象成一個大的映射關系，通過行健、行健+時間戳或行鍵+列（列族：列修飾符），就可以定位特定資料，Hbase是稀疏存儲資料的，是以某些列可以是空白的，

Row Key

Time Stamp

Column Family:c1

Column Family:c2

列

值

r1

t7

c1:1

value1-1/1

t6

c1:2

value1-1/2

t5

c1:3

value1-1/3

t4

c2:1

value1-2/1

t3

c2:2

value1-2/2

t2

value2-1/1

t1

從上表可以看出，test表有r1和r2兩行資料，并且c1和c2兩個列族，在r1中，列族c1有三條資料，列族c2有兩條資料；在r2中，列族c1有一條資料， 列族c2有一條資料，每一條資料對應的時間戳都用數字來表示，編号越大表示資料越舊，反而表示資料越新。

3：實體視圖

    雖然從概念視圖來看每個表格是由很多行組成的，但是在實體存儲上面，它是按照列來儲存的。

             表：HBase資料的實體視圖（1）

          表：HBase資料的實體視圖（2）

需要注意的是，在概念視圖上面有些列是空白的，這樣的列實際上并不會被存儲，當請求這些空白的單元格時，會傳回null值。如果在查詢的時候不

提供時間戳，那麼會傳回距離現在最近的那一個版本的資料，因為在存儲的時候，資料會按照時間戳來排序。

通過shell操作hbase 會更清楚結構

這裡我們用一個學生成績表作為例子,對HBase的基本操作和基本概念進行講解:

下面是學生的成績表:

name grad      course:math   course:art

Tom    1                87                    97

Jerry   2            100                  80

        這裡grad對于表來說是一個列,course對于表來說是一個列族,這個列族由兩個列組成:math和art,當然我們可以根據我們的需要在course中建立更多的列族,如computer,physics等相應的列添加入course列族.

        有了上面的想法和需求,我們就可以在HBase中建立相應的資料表啦!

1, 建立一個表格 scores 具有兩個列族grad 和courese

hbase(main):002:0> create 'scores', 'grade', 'course'

0 row(s) in 4.1610 seconds

2,檢視當先HBase中具有哪些表

hbase(main):003:0> list

scores

1 row(s) in 0.0210 seconds

3,檢視表的構造

hbase(main):004:0> describe 'scores'

{NAME => 'scores', IS_ROOT => 'false', IS_META => 'false', FAMILIES => [{NAME => 'course', BLOOMFILTER => 'false', IN_MEMORY => 'false', LENGTH => '2147483647', BLOCKCACHE => 'false', VERSIONS => '3', TTL => '-1', COMPRESSION => 'NONE'}, {NAME => 'grade', BLOOMFILTER => 'false', IN_MEMORY => 'false', LENGTH => '2147483647', BLOCKCACHE => 'false', VERSIONS => '3', TTL => '-1', COMPRESSION => 'NONE'}]}

1 row(s) in 0.0130 seconds

4, 加入一行資料,行名稱為 Tom 列族grad的列名為”” 值位1

hbase(main):005:0> put 'scores', 'Tom', 'grade:', '1'

0 row(s) in 0.0070 seconds

5,給Tom這一行的資料的列族添加一列 <math,87>

hbase(main):006:0> put 'scores', 'Tom', 'course:math', '87'

0 row(s) in 0.0040 seconds

6,給Tom這一行的資料的列族添加一列 <art,97>

hbase(main):007:0> put 'scores', 'Tom', 'course:art', '97'

0 row(s) in 0.0030 seconds

7, 加入一行資料,行名稱為 Jerry 列族grad的列名為”” 值位2

hbase(main):008:0> put 'scores', 'Jerry', 'grade:', '2'

8,給Jerry這一行的資料的列族添加一列 <math,100>

hbase(main):009:0> put 'scores', 'Jerry', 'course:math', '100'

9,給Jerry這一行的資料的列族添加一列 <art,80>

hbase(main):010:0> put 'scores', 'Jerry', 'course:art', '80'

0 row(s) in 0.0050 seconds

10,檢視scores表中Tom的相關資料

hbase(main):011:0> get 'scores', 'Tom'

COLUMN                       CELL

course:art                  timestamp=1224726394286, value=97

course:math                 timestamp=1224726377027, value=87

grade:                      timestamp=1224726360727, value=1

3 row(s) in 0.0070 seconds

11,檢視scores表中所有資料

hbase(main):012:0> scan 'scores'

ROW                          COLUMN+CELL

Tom                         column=course:art, timestamp=1224726394286, value=97

Tom                         column=course:math, timestamp=1224726377027, value=87

Tom                         column=grade:, timestamp=1224726360727, value=1

Jerry                        column=course:art, timestamp=1224726424967, value=80

Jerry                        column=course:math, timestamp=1224726416145, value=100

Jerry                        column=grade:, timestamp=1224726404965, value=2

6 row(s) in 0.0410 seconds

12,檢視scores表中所有資料courses列族的所有資料

hbase(main):013:0> scan 'scores', ['course:']

4 row(s) in 0.0200 seconds

        上面就是HBase的基本shell操作的一個例子,可以看出,hbase的shell還是比較簡單易用的,從中也可以看出HBase shell缺少很多傳統sql中的一些類似于like等相關操作,當然,HBase作為BigTable的一個開源實作,而BigTable是作為 google業務的支援模型,很多sql語句中的一些東西可能還真的不需要.

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列的查詢很慢。

Table中Family和Qualifier的關系與差別

就像用MySQL一樣，我們要做的是表設計，MySQL中的表，行，列的在HBase已經有所差別了，在HBase中主要是Table和Family和Qualifier，這三個概念。Table可以直接了解為表，而Family和Qualifier其實都可以了解為列，一個Family下面可以有多個Qualifier，是以可以簡單的了解為，HBase中的列是二級列，也就是說Family是第一級列，Qualifier是第二級列。兩個是父子關系。

測試發現：

在實際應用場景中，對于單column qualifier和多column qualifier兩種情況，

如果value長度越長，row key長度越短，字段數（column qualifier數）越少，前者和後者在實際傳輸資料量上會相差小些；反之則相差較大。

如果采用多column qualifier的方式存儲，且用戶端采取批量寫入的方式，則可以根據實際情況，适當增大用戶端的write buffer大小，以便能夠提高用戶端的寫入吞吐量。

從性能的角度談table中family和qualifier的設定

　　對于傳統關系型資料庫中的一張table，在業務轉換到hbase上模組化時，從性能的角度應該如何設定family和qualifier呢？

　　最極端的，①每一列都設定成一個family，②一個表僅有一個family，所有列都是其中的一個qualifier，那麼有什麼差別呢？

　　從讀的方面考慮：

　　family越多，那麼擷取每一個cell資料的優勢越明顯，因為io和網絡都減少了。

　　如果隻有一個family，那麼每一次讀都會讀取目前rowkey的所有資料，網絡和io上會有一些損失。

　　當然如果要擷取的是固定的幾列資料，那麼把這幾列寫到一個family中比分别設定family要更好，因為隻需一次請求就能拿回所有資料。

　　從寫的角度考慮：

　　首先，記憶體方面來說，對于一個Region，會為每一個表的每一個Family配置設定一個Store，而每一個Store，都會配置設定一個MemStore，是以更多的family會消耗更多的記憶體。

　　其次，從flush和compaction方面說，目前版本的hbase，在flush和compaction都是以region為機關的，也就是說當一個family達到flush條件時，該region的所有family所屬的memstore都會flush一次，即使memstore中隻有很少的資料也會觸發flush而生成小檔案。這樣就增加了compaction發生的機率，而compaction也是以region為機關的，這樣就很容易發生compaction風暴進而降低系統的整體吞吐量。

　　第三，從split方面考慮，由于hfile是以family為機關的，是以對于多個family來說，資料被分散到了更多的hfile中，減小了split發生的機率。這是把雙刃劍。更少的split會導緻該region的體積比較大，由于balance是以region的數目而不是大小為機關來進行的，是以可能會導緻balance失效。而從好的方面來說，更少的split會讓系統提供更加穩定的線上服務。而壞處我們可以通過在請求的低谷時間進行人工的split和balance來避免掉。

     是以對于寫比較多的系統，如果是離線應該，我們盡量隻用一個family好了，但如果是線上應用，那還是應該根據應用的情況合理地配置設定family。

首先，不同的family是在同一個region下面。而每一個family都會配置設定一個memstore，是以更多的family會消耗更多的記憶體。

其次,目前版本的hbase，在flush和compaction都是以region為機關的，也就是說當一個family達到flush條件時，該region的所有family所屬的memstore都會flush一次，即使memstore中隻有很少的資料也會觸發flush而生成小檔案。這樣就增加了compaction發生的機率，而compaction也是以region為機關的，這樣就很容易發生compaction風暴進而降低系統的整體吞吐量。

第三，由于hfile是以family為機關的，是以對于多個family來說，資料被分散到了更多的hfile中，減小了split發生的機率。這是把雙刃劍。更少的split會導緻該region的體積比較大，由于balance是以region的數目而不是大小為機關來進行的，是以可能會導緻balance失效。而從好的方面來說，更少的split會讓系統提供更加穩定的線上服務。

上述第三點的好處對于線上應用來說是明顯的，而壞處我們可以通過在請求的低谷時間進行人工的split和balance來避免掉。

是以對于寫比較多的系統，如果是離線應該，我們盡量隻用一個family好了，但如果是線上應用，那還是應該根據應用的情況合理地配置設定family。

2 HBase的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唯一原則

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

基于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設計

散列字段(序列字段）

時間字段(分鐘)

0x00000000~0xFFFFFFFF)

0~1439(0x0000~0x059F)

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

2.2.3 針對通用資料的Rowkey設計

通用資料采用自增序列作為唯一主鍵，使用者可以選擇按天建分表也可以選擇單表模式。這種模式需要確定同時多個入庫加載子產品運作時散列字段（序列字段）的唯一性。可以考慮給不同的加載子產品賦予唯一因子差別。設計結構如下圖所示。

通用資料Rowkey設計

擴充字段（控制在12位元組内）

可由多個使用者字段組成

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期

綜藝

2

20120904

中國好聲音第2期

3

20120906

中國好聲音外卡賽

4

20120908

中國好聲音第3期

5

20120910

中國好聲音第4期

6

20120912

中國好聲音選手采訪

綜藝花絮

7

20120914

中國好聲音第5期

8

20120916

中國好聲音錄制花絮

9

20120918

張玮獨家專訪

花絮

10

20120920

加多寶涼茶廣告

綜藝廣告

這裡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表結構設計。

HBase的rowkey的設計原則

HBase是三維有序存儲的，通過rowkey（行鍵），column key（column family和qualifier）和TimeStamp（時間戳）這個三個次元可以對HBase中的資料進行快速定位。

HBase中rowkey可以唯一辨別一行記錄，在HBase查詢的時候，有兩種方式：

1、通過get方式，指定rowkey擷取唯一一條記錄 

2、通過scan方式，設定startRow和stopRow參數進行範圍比對 

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

rowkey長度原則:

rowkey是一個二進制碼流，可以是任意字元串，最大長度64kb，實際應用中一般為10-100bytes，以byte[]形式儲存，一般設計成定長。建議越短越好，不要超過16個位元組，原因如下：

資料的持久化檔案HFile中是按照KeyValue存儲的，如果rowkey過長，比如超過100位元組，1000w行資料，光rowkey就要占用100*1000w=10億個位元組，将近1G資料，這樣會極大影響HFile的存儲效率； 

MemStore将緩存部分資料到記憶體，如果rowkey字段過長，記憶體的有效使用率就會降低，系統不能緩存更多的資料，這樣會降低檢索效率。 

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

rowkey散列原則:

如果rowkey按照時間戳的方式遞增，不要将時間放在二進制碼的前面，建議将rowkey的高位作為散列字段，由程式随機生成，低位放時間字段，這樣将提高資料均衡分布在每個RegionServer，以實作負載均衡的幾率。如果沒有散列字段，首字段直接是時間資訊，所有的資料都會集中在一個RegionServer上，這樣在資料檢索的時候負載會集中在個别的RegionServer上，造成熱點問題，會降低查詢效率。

rowkey唯一原則:

必須在設計上保證其唯一性，rowkey是按照字典順序排序存儲的，是以，設計rowkey的時候，要充分利用這個排序的特點，将經常讀取的資料存儲到一塊，将最近可能會被通路的資料放到一塊。

什麼是熱點：

HBase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以将相關的行以及會被一起讀取的行存取在臨近位置，便于scan。然而糟糕的rowkey設計是熱點的源頭。熱點發生在大量的client直接通路叢集的一個或極少數個節點（通路可能是讀，寫或者其他操作）。大量通路會使熱點region所在的單個機器超出自身承受能力，引起性能下降甚至region不可用，這也會影響同一個RegionServer上的其他region，由于主機無法服務其他region的請求。設計良好的資料通路模式以使叢集被充分，均衡的利用。

為了避免寫熱點，設計rowkey使得不同行在同一個region，但是在更多資料情況下，資料應該被寫入叢集的多個region，而不是一個。

下面是一些常見的避免熱點的方法以及它們的優缺點：

加鹽

這裡所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加随機數，具體就是給rowkey配置設定一個随機字首以使得它和之前的rowkey的開頭不同。配置設定的字首種類數量應該和你想使用資料分散到不同的region的數量一緻。加鹽之後的rowkey就會根據随機生成的字首分散到各個region上，以避免熱點。

哈希

哈希會使同一行永遠用一個字首加鹽。哈希也可以使負載分散到整個叢集，但是讀卻是可以預測的。使用确定的哈希可以讓用戶端重構完整的rowkey，可以使用get操作準确擷取某一個行資料

反轉

第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey。這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的随機rowkey，但是犧牲了rowkey的有序性。

反轉rowkey的例子 

以手機号為rowkey，可以将手機号反轉後的字元串作為rowkey，這樣的就避免了以手機号那樣比較固定開頭導緻熱點問題

時間戳反轉

一個常見的資料處理問題是快速擷取資料的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用Long.Max_Value - timestamp追加到key的末尾，例如[key][reverse_timestamp],[key]的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最後錄入的資料。

比如需要儲存一個使用者的操作記錄，按照操作時間倒序排序，在設計rowkey的時候，可以這樣設計 

[userId反轉][Long.Max_Value - timestamp]，在查詢使用者的所有操作記錄資料的時候，直接指定反轉後的userId，startRow是[userId反轉][000000000000],stopRow是[userId反轉][Long.Max_Value - timestamp] 

如果需要查詢某段時間的操作記錄，startRow是[user反轉][Long.Max_Value - 起始時間]，stopRow是[userId反轉][Long.Max_Value - 結束時間]