設計HBase RowKey需要注意什么

這篇文章將為大家詳細講解有關設計HBase RowKey需要注意什么，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

1. 打散RowKeyHBase中的行是按照RowKey字典序排序的。

這對Scan操作非常友好，因為RowKey相近的行總是存儲在相近的位置，順序讀的效率比隨機讀要高。

但是，如果大量的讀寫操作總是集中在某個RowKey范圍，那么就會造成Region熱點，拖累RegionServer的性能。

因此，要適當地將RowKey打散。

加鹽（salting）+哈希（hashing）這里的“加鹽”與密碼學中的“加鹽”不是一回事。

它是指在RowKey的前面增加一些前綴。

加鹽的前綴種類越多，RowKey就被打得越散。

前綴不可以是隨機的，因為必須要讓客戶端能夠完整地重構RowKey。

我們一般會拿原RowKey或其一部分計算hash值，然后再對hash值做運算作為前綴。

反轉固定格式的數值以手機號為例，手機號的前綴變化比較少（如152、185等），但后半部分變化很多。

如果將它反轉過來，可以有效地避免熱點。

不過其缺點就是失去了有序性。

反轉時間這個操作嚴格來講不算“打散”，但可以調整數據的時間排序。

如果將時間按照字典序排列，最近產生的數據會排在舊數據后面。

如果用一個大值減去時間（比如用99999999減去yyyyMMdd，或者Long.MAX_VALUE減去時間戳），最新的數據就可以排在前面了。

2. 控制RowKey長度在HBase中，RowKey、列族、列名等都是以byte[]形式傳輸的。

RowKey的最大長度限制為64KB，但在實際應用中最多不會超過100B。

設計短RowKey有以下兩方面考慮：

在HBase的底層存儲HFile中，RowKey是KeyValue結構中的一個域。假設RowKey長度100B，那么1000萬條數據中，只算RowKey就占用掉將近1G空間，會影響HFile的存儲效率。

HBase中設計有MemStore和BlockCache，分別對應列族/Store級別的寫入緩存，和RegionServer級別的讀取緩存。如果RowKey過長，緩存中存儲數據的密度就會降低，影響數據落地或查詢效率。

另外，我們目前使用的服務器操作系統都是64位系統，內存是按照8B對齊的，因此設計RowKey時一般做成8B的整數倍，如16B或者24B，可以提高尋址效率。

同樣地，列族、列名的命名在保證可讀的情況下也應盡量短。HBase官方不推薦使用3個以上列族，因此實際上列族命名幾乎都用一個字母，比如‘c’或‘f’。

3. 保證RowKey唯一性

這個就是顯而易見的了，不再贅述。

舉個例子我們的業務中，有一部分是用戶在日歷上記錄自己的行為。需要儲存在RowKey中的維度有：用戶ID（uid，不會超過十億）、日歷上的日期（date，yyyyMMdd格式）、記錄行為的類型（type，0~99之間）。記錄的詳細數據則存儲在列f:data中。根據查詢邏輯，我們設計的RowKey格式如下：

9~79809782~05~0008839540

長度正好是24B。以字符‘~’為分界（‘~’的ASCII碼是最大的，方便），各個部分的含義如下：

• uid.toString().hashCode() % 10

• 99999999 - date

• StringUtils.leftPad(type, 2, "0")

• StringUtils.leftPad(uid, 10, "0")

基于這種設計，我們在建表階段就可以將其預分區，使得數據在一開始就均勻分布在不同的Region上。建表語句參考：

create 'user_calendar_record', {  NAME => 'f',  VERSIONS => '1',  BLOCKCACHE => 'true',  BLOCKSIZE => '65536',   BLOOMFILTER => 'row',  COMPRESSION => 'SNAPPY'}, {  SPLITS => ['1', '2', '3', '4', '5', '6', '7', '8', '9']}

如果不做預分區，那么表剛開始只會有一個Region。隨著數據量增大，就會頻繁觸發Region split，影響效率。

關于“設計HBase RowKey需要注意什么”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。