[TOC]
一饲趋、RowKey 的作用
HBase 由于其存儲和讀寫的高性能荒吏，在 OLAP 即時分析中越來越發(fā)揮重要的作用巴碗。作為 Nosql 數(shù)據(jù)庫的一員耸棒，HBase 查詢只能通過其 Rowkey 來查詢(Rowkey用來表示唯一一行記錄)，Rowkey 設(shè)計的優(yōu)劣直接影響讀寫性能姨蟋。
1.1屉凯、RowKey 在查詢中的作用
HBase 是根據(jù) RowKey 進(jìn)行檢索，系統(tǒng)通過找到某個 RowKey (或者某個 RowKey 范圍)所在的 Region眼溶，然后將查詢數(shù)據(jù)的請求路由到該 Region 獲取數(shù)據(jù)悠砚。
HBase 的檢索支持3種方式：
- 通過單個 RowKey 訪問，即按照某個 RowKey 鍵值進(jìn)行 get 操作堂飞，這樣獲取唯一一條記錄灌旧；
- 通過 RowKey 的 range 進(jìn)行 scan绑咱，即通過設(shè)置 startRowKey 和 endRowKey，在這個范圍內(nèi)進(jìn)行掃描节榜，這樣可以按指定的條件獲取一批記錄羡玛；
- 全表掃描，即直接掃描整張表中所有行記錄宗苍。
HBase 中的數(shù)據(jù)是按照 Rowkey 的 ASCII 字典順序進(jìn)行全局排序的，舉例說明：假如有 5 個 Rowkey："012", "0", "123", "234", "3"薄榛，按 ASCII 字典排序后的結(jié)為："0", "012", "123", "234", "3"讳窟。
Rowkey 排序時會先比對兩個 Rowkey 的第一個字節(jié)，如果相同敞恋，然后會比對第二個字節(jié)丽啡，依次類推......對比到第X個字節(jié)時，已經(jīng)超出了其中一個 Rowkey 的長度硬猫，短的 Rowkey 排在前面补箍。
HBase 按單個 RowKey 檢索的效率是很高的，耗時在1毫秒以下啸蜜，每秒鐘可獲取1000~2000條記錄坑雅，不過非 key 列的查詢很慢。因此在設(shè)計 HBase 表時衬横，Rowkey 是最重要的裹粤，應(yīng)該基于預(yù)期的訪問模式來為 Rowkey 建模，一般 Rowkey 上都會存一些比較關(guān)鍵的檢索信息蜂林，據(jù)查詢方式進(jìn)行數(shù)據(jù)存儲格式的設(shè)計遥诉，避免做全表掃描，因為效率特別低噪叙。并且在設(shè)計 RowKey 的時候選擇好字段之后矮锈，還應(yīng)該結(jié)合我們的實際的高頻的查詢場景來組合選擇的字段，越高頻的查詢字段排列越靠左睁蕾。
1.2苞笨、RowKey 在 Region 中的作用
在 HBase 中，Region 相當(dāng)于一個數(shù)據(jù)的分片惫霸，每個 Region 都有 StartRowKey 和 StopRowKey 猫缭，這是表示 Region 存儲的 RowKey 的范圍，HBase 表的數(shù)據(jù)時按照 RowKey 來分散到不同的 Region壹店，要想將數(shù)據(jù)記錄均衡的分散到不同的Region中去猜丹，因此需要 RowKey 滿足這種散列的特點。此外硅卢，在數(shù)據(jù)讀寫過程中也是與RowKey 密切相關(guān)射窒，RowKey 在讀寫過程中的作用：
- 讀寫數(shù)據(jù)時通過 RowKey 找到對應(yīng)的 Region藏杖；
- MemStore 中的數(shù)據(jù)是按照 RowKey 的字典序排序；
- HFile 中的數(shù)據(jù)是按照 RowKey 的字典序排序脉顿。
二蝌麸、RowKey 應(yīng)該具備的特性
2.1、字符串類型
雖然行鍵在 HBase 中是以 byte[] 字節(jié)數(shù)組的形式存儲的艾疟，但是建議在系統(tǒng)開發(fā)過程中將其數(shù)據(jù)類型設(shè)置為 String 類型来吩，保證通用性。
如果在開發(fā)過程中將 RowKey 規(guī)定為其他類型蔽莱，譬如 Long 型弟疆，那么數(shù)據(jù)的長度將可能受限于編譯環(huán)境等所規(guī)定的數(shù)據(jù)長度。
2.2盗冷、有明確意義
RowKey 的主要作用是為了進(jìn)行數(shù)據(jù)記錄的唯一性標(biāo)示怠苔，但是唯一性并不是其全部，具有明確意義的行鍵對于應(yīng)用開發(fā)仪糖、數(shù)據(jù)檢索等都具有特殊意義柑司。譬如數(shù)字字符串 9559820140512，其實際意義是這樣：95598（電網(wǎng)客服電話）+ 20140512（日期）锅劝。
行鍵往往由多個值組合而成攒驰，而各個值的位置順序?qū)⒂绊懙綌?shù)據(jù)存儲和檢索效率，所以在設(shè)計行鍵時鸠天，需要對日后的業(yè)務(wù)應(yīng)用開發(fā)有比較深入的了解和前瞻性預(yù)測讼育，才能設(shè)計出可盡量高效率檢索的行鍵。
2.3稠集、具有有序性
RowKey 是按照字典序存儲奶段，因此，設(shè)計 RowKey 時剥纷，要充分利用這個排序特點痹籍，將經(jīng)常一起讀取的數(shù)據(jù)存儲到一塊，將最近可能會被訪問的數(shù)據(jù)放在一塊晦鞋。
比如：如果最近寫入 HBase 表中的數(shù)據(jù)是最可能被訪問的蹲缠，可以考慮將時間戳作為 RowKey 的一部分，由于是字典序排序悠垛，所以可以使用 Long.MAX_VALUE – timestamp 作為 RowKey线定，這樣能保證新寫入的數(shù)據(jù)在讀取時可以被快速命中。
2.4确买、具有定長性
行鍵具有有序性的基礎(chǔ)便是定長斤讥，譬如 20140512080500、20140512083000湾趾，這兩個日期時間形式的字符串是遞增的芭商，不管后面的秒數(shù)是多少派草，都將其設(shè)置為14位數(shù)字形式，如果把后面的0去除了铛楣，那么 201405120805 將大于20140512083近迁，其有序性發(fā)生了變更。
三簸州、RowKey 設(shè)計原則
3.1鉴竭、RowKey 的唯一原則
由于在 HBase 中數(shù)據(jù)存儲是 Key-Value 形式，若 HBase 中同一表插入相同Rowkey岸浑，則原先的數(shù)據(jù)會被覆蓋掉(如果表的 version 設(shè)置為1的話)拓瞪，所以務(wù)必保證 Rowkey 的唯一性。
3.2助琐、RowKey 的排序原則
HBase 的 RowKey 是按照 ASCII 有序設(shè)計的，在設(shè)計 RowKey 時要充分利用這點面氓。比如視頻網(wǎng)站上的彈幕信息兵钮，這個彈幕是按照時間倒排序展示視頻里，這個時候設(shè)計的 Rowkey 要和時間順序相關(guān)舌界，可以使用 "Long.MAX_VALUE - 彈幕發(fā)表時間" 的 long 值作為 Rowkey 的前綴掘譬。
3.3、RowKey 的長度原則
RowKey 是一個二進(jìn)制呻拌，RowKey 的長度建議設(shè)計在 10~100 個字節(jié)葱轩，越短越好。
原因有兩點：
- HBase 的持久化文件 HFile 是按照 KeyValue 存儲的藐握，如果 RowKey 過長靴拱，比如 500 個字節(jié)，1000 萬列數(shù)據(jù)光 RowKey 就要占用500*1000 萬 = 50 億個字節(jié)猾普，將近 1G 數(shù)據(jù)袜炕，這會極大影響HFile的存儲效率；
- MemStore 緩存部分?jǐn)?shù)據(jù)到內(nèi)存初家，如果 RowKey 字段過長內(nèi)存的有效利用率會降低偎窘，系統(tǒng)無法緩存更多的數(shù)據(jù)，這會降低檢索效率溜在。
其實不僅 RowKey 的長度是越短越好陌知，列族名、列名等也應(yīng)該盡量使用短名字掖肋，因為 HBase 屬于列式數(shù)據(jù)庫仆葡，這些名字都是會寫入到 HBase 的持久化文件 HFile 中去，過長的 RowKey培遵、列族浙芙、列名都會導(dǎo)致整體的存儲量成倍增加登刺。
3.5、RowKey 散列原則
設(shè)計的 RowKey 應(yīng)均勻的分布在各個 HBase節(jié)點上嗡呼。
拿時間戳舉例纸俭，假如 RowKey 是按系統(tǒng)時間戳的方式遞增，時間戳信息作為RowKey 的第一部分南窗，將造成所有新數(shù)據(jù)都在一個 RegionServer 上堆積揍很，也就是通常說的 Region 熱點問題。
熱點發(fā)生在大量的 client 直接訪問集中在個別 RegionServer 上（訪問可能是讀万伤，寫或者其他操作）窒悔，導(dǎo)致單個 RegionServer 機器自身負(fù)載過高，引起性能下降甚至 Region 不可用敌买，常見的是發(fā)生 jvm full gc 或者顯示 region too busy 異常情況简珠，當(dāng)然這也會影響同一個 RegionServer 上的其他 Region。
設(shè)計良好的數(shù)據(jù)訪問模式以使集群被充分虹钮，均衡的利用聋庵。
四、RowKey 避免熱點的方法
首先明白熱點產(chǎn)生原因：RowKey 前面的字符過于固定芙粱，有大量連續(xù)編號的 RowKey 集中在個別 region祭玉，client 檢索記錄時或者寫入記錄時，個別 region 負(fù)荷過大春畔。
4.1脱货、加鹽 Salting
既然是因為前面字符過于集中，那么可以通過在 RowKey 前面添加隨機的一個字符串律姨，Salting 是就在 RowKey 的前面增加隨機數(shù)振峻，使得它和之前的 RowKey 的開頭不同。這可以使得數(shù)據(jù)分散在多個不同的 Region线召，達(dá)到 Region 負(fù)載均衡的目標(biāo)铺韧，避免熱點。分配的前綴種類數(shù)量應(yīng)該和想使數(shù)據(jù)分散到不同的 Region 的數(shù)量一致缓淹。
隨機字符計算的一種方法：
int saltNumber = new Long(new Long(timestamp).hashCode()) %<number of region servers>
比如在一個有 4 個 Region (注：以 [ a)哈打、[a,b)、[b,c)讯壶、[c, )為 Region 起至)的 HBase表中料仗，加鹽前的 RowKey：abc001、abc002伏蚊、abc003立轧，默認(rèn)會在第 2 個Region中。
現(xiàn)在分別加上 a、b氛改、c 前綴帐萎，加鹽后 RowKey 為：a-abc001、b-abc002胜卤、c-abc003 疆导，數(shù)據(jù)會分布在 3 個 Region 中，理論上處理后的吞吐量應(yīng)是之前的3倍葛躏。
由于前綴是隨機的澈段，讀這些數(shù)據(jù)時需要耗費更多的時間，所以 Salting 雖然增加了寫操作的吞吐量舰攒，與此同時也增加了讀操作的開銷败富。
4.2、Hash 散列或者 Mod 取模
哈希會使同一行永遠(yuǎn)用一個前綴加鹽摩窃，而不是隨機前綴兽叮。哈希同樣可以使負(fù)載分散到整個集群，但是讀卻是可以預(yù)測的猾愿。使用確定的哈希(比如md5后取前4位做前綴)可以讓客戶端重構(gòu)完整的 RowKey 充择，可以使用 get 操作準(zhǔn)確獲取某一個行數(shù)據(jù)。
將上述的原始 RowKey 經(jīng)過 hash 處理匪蟀，比如采用 md5 散列算法取前4位做前綴。結(jié)果如下：
9bf0-abc001 （abc001在md5后是9bf049097142c168c38a94c626eddf3d宰僧，取前4位是9bf0）材彪、7006-abc002、95e6-abc003琴儿。
若以前4個字符作為不同分區(qū)的起止段化，上面幾個 RowKey 數(shù)據(jù)會分布在3個 Region中。實際應(yīng)用場景是當(dāng)數(shù)據(jù)量越來越大的時候造成，這種設(shè)計會使得分區(qū)之間更加均衡显熏。
如果 RowKey 是數(shù)字類型的，也可以考慮 Mod 方法晒屎。
4.3喘蟆、反轉(zhuǎn) Reverse
第三種防止熱點的方法是反轉(zhuǎn)固定長度或者數(shù)字格式的 RowKey ，可以使得 RowKey 中經(jīng)常改變的部分（最沒有意義的部分）放在前面鼓鲁。這樣可以有效的隨機 RowKey 蕴轨，但是犧牲了 RowKey 的有序性。
反轉(zhuǎn) RowKey 的例子：通常以手機舉例骇吭，可以將手機號反轉(zhuǎn)后的字符串作為RowKey橙弱，這樣的就避免了以手機號那樣比較固定開頭(137x、15x等)導(dǎo)致熱點問題。
4.4棘脐、時間戳反轉(zhuǎn)
一個常見的數(shù)據(jù)處理問題是快速獲取數(shù)據(jù)的最近版本斜筐，使用反轉(zhuǎn)的時間戳作為 RowKey 的一部分對這個問題十分有用，可以用 Long.Max_Value - timestamp 追加到 key 的末尾蛀缝，例如 key_reverse_timestamp 顷链，key 的最新值可以通過 scan key 獲得 key 的第一條記錄，因為 HBase 中 RowKey 是有序的内斯，第一條記錄是最后錄入的數(shù)據(jù)蕴潦。
比如需要保存一個用戶的操作記錄，按照操作時間倒序排序俘闯，在設(shè)計 RowKey 的時候潭苞，可以這樣設(shè)計 userId反轉(zhuǎn)-(Long.Max_Value - timestamp)，在查詢用戶的所有操作記錄數(shù)據(jù)的時候真朗，直接指定反轉(zhuǎn)后的 userId此疹，startRow 是 userId反轉(zhuǎn)-000000000000，stopRow 是 userId反轉(zhuǎn)-(Long.Max_Value - timestamp)
如果需要查詢某段時間的操作記錄遮婶，startRow 是 user反轉(zhuǎn)-(Long.Max_Value - 起始時間)蝗碎，stopRow是 userId反轉(zhuǎn)-(Long.Max_Value - 結(jié)束時間)。
五旗扑、RowKey 設(shè)計經(jīng)驗
RowKey 的設(shè)計和數(shù)據(jù)的分布有很大關(guān)系蹦骑，RowKey 設(shè)計的時候需要保證數(shù)據(jù)入庫時的并發(fā)度，但又不能過于分散臀防。
5.1眠菇、可枚舉值較少的屬性放在 RowKey 前面
在 RowKey 中，需要放入多個屬性袱衷，這多個屬性的先后次序和訪問的效率有直接的關(guān)系捎废。
一個普遍的規(guī)則是：數(shù)量較少，可控的屬性放在 RowKey 前面（如 ServiceType致燥，CPID 等）登疗；反之放在后面（如 url，mxid 等）嫌蚤。這樣做的原因是可控屬性放在前面辐益，對各種不同查詢需求的平衡性強一些，反之平衡性較差脱吱。
5.1.1荷腊、案例
201010-http-cp001-s-shanghai-xxx-1
201010-http-cp002-s-shenzhen-xxx-2
201010-rtsp-cp001-s-shanghai-xxx-1
201010-rtsp-cp002-s-shenzhen-xxx-21234
ServiceType 可枚舉，并且數(shù)量較少急凰，分為 http 和 rtsp 兩種女仰，放在前面猜年； 而 cpid 可能會比較多（假設(shè)有5個 cp），因此放在后面疾忍。
這樣的設(shè)計能夠適應(yīng)如下兩種需求乔外，復(fù)雜度都比較小：
- 查詢 2010 年 10 月所有 cp 的 http 數(shù)據(jù)一罩。這種需求設(shè)置 scan 的 startRow= ‘201010-http-’杨幼，endRow=‘201010-http-z’，即可聂渊；
- 查詢 2010 年 10 月 cp001 的所有協(xié)議的數(shù)據(jù)差购。這種需求下，根據(jù) scan RowKey 連續(xù)的原則汉嗽，需要將查詢劃分成兩個 scan欲逃，分別查詢 http 類型 cp001 的數(shù)據(jù)和 rtsp 類型 cp001 的數(shù)據(jù)。
但是饼暑，如果將 cp 放在前面稳析，如下所示，適應(yīng)性就差一些弓叛，如下所示：
201010-cp001-http-s-shanghai-xxx-1
201010-cp002-http-s-shenzhen-xxx-2
201010-cp001-rtsp-s-shanghai-xxx-1
201010-cp002-rtsp-s-shenzhen-xxx-21234
- 查詢 2010 年 10 月 cp001 的所有協(xié)議的數(shù)據(jù)彰居。這種需求下，設(shè)置 scan 的startRow=‘201010-cp001-’撰筷，endRow=‘201010-cp001-z’陈惰，即可；
- 查詢 2010 年10 月毕籽，所有 cp 的 http 數(shù)據(jù)奴潘。 這種需求下，根據(jù) scan 的RowKey 連續(xù)原則影钉，需要將查詢分成 cp001-http、cp002-http掘剪、cp003-http平委、cp004-http、cp005-http 五個查詢進(jìn)行夺谁，相對模型一復(fù)雜了一些廉赔。
5.2、業(yè)務(wù)訪問中權(quán)重高的 RowKey 放在前面
例如 URLRecords 表的主要用途是用來計算當(dāng)天的 URL 訪問排名匾鸥。根據(jù)業(yè)務(wù)需求蜡塌，需要訪問某天的所有 URL，因此 date 是主鍵勿负，權(quán)重更高馏艾，放在前面，而 URL 則放在后面。
5.3琅摩、構(gòu)造冗余數(shù)據(jù)
例如铁孵，另一張表的數(shù)據(jù)包含了 URL Records 的數(shù)據(jù)，URL Records 的數(shù)據(jù)是冗余存儲的房资，區(qū)別在于該表的 URL 放在 date 前面蜕劝，而 URL Records 表的 URL 放在 date 后面。這就是由于 URL 在滿足不同需求的時候轰异，權(quán)重不同岖沛，由于 URL Records 需要的數(shù)據(jù)量不大，因此可以采用冗余的機制解決該矛盾搭独。
權(quán)衡需求的重要性和系統(tǒng)忍受度選擇一種方案婴削，當(dāng)兩種需求有矛盾，但其中一方屬于次要需求戳稽，并且在系統(tǒng)忍受度范圍之內(nèi)的話馆蠕，可以舍棄一種方案。優(yōu)先滿足需求更強的一方惊奇。
5.4互躬、時間屬性在 RowKey 中的使用
如果需要經(jīng)常訪問特定時間段的數(shù)據(jù)，將時間屬性放在 RowKey 中是一個較好的選擇颂郎。和利用時間戳來訪問特定時間段的數(shù)據(jù)方法相比吼渡，將時間屬性放在 RowKey 中具有可控性，容易將能夠同時訪問的數(shù)據(jù)相對集中存放的優(yōu)點乓序。
時間屬性放在 RowKey 中需要注意數(shù)據(jù)分布和并發(fā)度的問題：HBase 數(shù)據(jù)是按照 RowKey 排序的寺酪，時間屬性放在 RowKey 中容易造成數(shù)據(jù)總是在末尾寫入的情況，這種情況下并發(fā)度很差替劈〖娜福可以通過在時間屬性前面增加 prefix 和提前預(yù)分 Region 的方法解決。
5.5陨献、循環(huán) RowKey 使用
如果 RowKey 中有時間屬性盒犹，并且隨著時間的增加，RowKey 會不斷的增大下去眨业，造成 Region 數(shù)量不斷地增加急膀。如果使用 TTL 來控制數(shù)據(jù)的生命周期，一些老的數(shù)據(jù)就會過期龄捡，進(jìn)而導(dǎo)致老的 Region 數(shù)據(jù)量會逐漸減少甚至成為空的 Region卓嫂。這樣一方面 Region 總數(shù)在不斷增加，另外一方面老的 Region 在不斷的成為空的 Region聘殖，而空的 Region 不會自動合并晨雳，進(jìn)而造成過多空的 Region 占用負(fù)載和內(nèi)存消耗的情況行瑞。
這種情況下，可以使用循環(huán) RowKey 的方法解決悍募。思路是根據(jù)數(shù)據(jù)的生命周期設(shè)定 RowKey 的循環(huán)周期蘑辑，當(dāng)一個周期過去以后，通過時間映射的方法坠宴，繼續(xù)使用老的過期數(shù)據(jù)的 RowKey 洋魂。
例如 RowKey 的格式如下： YY-MM-DD-URL。如果數(shù)據(jù)的生命周期是一年喜鼓，則可以使用 MM-DD-URL 的格式副砍。這樣當(dāng)前一年過去以后，數(shù)據(jù)已經(jīng)老化庄岖，后一年的數(shù)據(jù)可以繼續(xù)寫入前一年的位置豁翎，使用前一年數(shù)據(jù)的 RowKey 。這樣可以避免空的 Region 占用資源的情況隅忿。
根據(jù) HBase 的原理心剥，RowKey 的周期需要至少比 TTL 大 2* hbase.hregion.majorcompaction（默認(rèn)24小時）的時間，才能夠保證過期的數(shù)據(jù)能夠在 RowKey 循環(huán)回來之前得到完全清理背桐。
按照時間周期進(jìn)行建表的方式也可以解決空 Region 的問題优烧，和循環(huán) RowKey 方法相比較，循環(huán) RowKey 的優(yōu)點如下：
- 操作簡單链峭，不需要重復(fù)建表畦娄，系統(tǒng)自動處理
同樣，循環(huán) RowKey 具有如下劣勢：
- 需要使用 TTL 來老化數(shù)據(jù)弊仪，可能會增加 compact 負(fù)擔(dān)
- 需要保證查詢操作不會查詢到過期數(shù)據(jù)熙卡，否則會影響系統(tǒng)性能。
如果在系統(tǒng)壓力不是特別大励饵，需要長期運行驳癌，能夠控制查詢不會查詢到過期數(shù)據(jù)的場景下，建議使用 TTL+循環(huán) RowKey 的方式役听，否則建議使用按照時間周期進(jìn)行建表的方式颓鲜。
六、RowKey 設(shè)計案例剖析
6.1禾嫉、交易類表 RowKey 設(shè)計
查詢某個賣家某段時間內(nèi)的交易記錄
sellerId + timestamp + orderId查詢某個買家某段時間內(nèi)的交易記錄
buyerId + timestamp + orderId根據(jù)訂單號查詢
orderNo-
如果某個商家賣了很多商品，可以如下設(shè)計 RowKey 實現(xiàn)快速搜索
salt + sellerId + timestamp
其中蚊丐，salt 是隨機數(shù)熙参。可以支持的場景：- 全表 Scan
- 按照 sellerId 查詢
- 按照 sellerId + timestamp 查詢
6.2麦备、金融風(fēng)控 RowKey 設(shè)計
查詢某個用戶的用戶畫像數(shù)據(jù)
- prefix + uid
- prefix + idcard
- prefix + tele
其中 prefix = substr(md5(uid),0 ,x)孽椰，x 取 5-6昭娩。uid、idcard以及 tele 分別表示用戶唯一標(biāo)識符黍匾、身份證栏渺、手機號碼。
6.3锐涯、車聯(lián)網(wǎng) RowKey 設(shè)計
- 查詢某輛車在某個時間范圍的交易記錄
carId + timestamp - 某批次的車太多磕诊，造成熱點
prefix + carId + timestamp 其中 prefix = substr(md5(uid),0 ,x)
6.4、查詢最近的數(shù)據(jù)
查詢用戶最新的操作記錄或者查詢用戶某段時間的操作記錄纹腌，RowKey 設(shè)計如下：
uid + Long.Max_Value - timestamp
支持的場景：
- 查詢用戶最新的操作記錄
Scan [uid] startRow [uid][000000000000] stopRow [uid][Long.Max_Value - timestamp] - 查詢用戶某段時間的操作記錄
Scan [uid] startRow [uid][Long.Max_Value – startTime] stopRow [uid][Long.Max_Value - endTime]
七霎终、參考博文
1.HBase設(shè)計之RowKey行鍵設(shè)計規(guī)范（2）
2.[HBase的rowkey的設(shè)計原則
3.HBase rowkey設(shè)計案例
4.HBase Rowkey 設(shè)計指南
