Rowkey設計部分

Rowkey 設計

1. 熱點

HBase中的行按照Rowkey的字典順序進行存儲。這種設計，允許你將一些相關的行或者經常一起讀的行存儲在一起，優化了scan方法。然而糟糕的rowkey設計是產生熱點問題的主要來源。當大量的客戶端跟其中的一個節點或者少量節點進行通信的時候，熱點現象就會產生。這種通信包括讀，寫或者其他的操作，將壓垮負責該region的機器，引起性能下降和region不可用的情況。也將對其他的regions產生不利的影響，因爲其他的regions可能託管在相同的region server上（該regionserver已經不能再進行相關的請求負載啦）。重要的是要設計數據訪問模式，這樣集羣才能被充分均勻使用。

爲了阻止熱點寫問題，設計你的rowkey使得行能夠真正的存放在相同的regions上，但是從全局考慮，數據是寫入到集羣中的多個regions中，而不是每次寫入到一個region。下面有一些常見的技術來避免熱點問題，並對這些技術的優缺點進行了分析。

分散（Salting）

分散(salting)在該場景下與密碼學沒有什麼關係，但是與增加隨機數據到一個rowkey的開始有關。在這種情況下，分散是指添加一個隨機指定的前綴給rowkey使得它排序不同於原來的排序結果。前綴數量與你想要分散數據的regions個數想對應。如果你有一些“熱點”rowkey不停的在其他均勻分佈的行之間不停的出現，那麼分散將可能會有用。考慮下面的例子，該例子可以展示分散能夠在多個regionserver上平均寫負載，而且闡述了一些寫方面的負面影響。

Example 16. 散射 salting Example

假設你有以下的rowkey列表，你的數據表被分裂使得一個region對應字母表中的一個字母。前綴‘a'是一個region，前綴‘b'是另一個region。在該表中，所有的行以‘f'開頭，都存儲在f開頭的那個region中。這個例子的rowkey如下所示:

foo0001
foo0002
foo0003
foo0004

現在，假設你想分散這些row到四個不同的region中。你決定使用四個不同的salts:a，b，c，d。在這個場景中，每個前綴字母將會存儲在不同的region中。當使用了salts後，將會有以下的rowkeys替代。以後你可以寫入四個不同的regions了。理論上你有四倍於所有寫都進入相同region的吞吐量。

a-foo0003
b-foo0001
c-foo0004
d-foo0002

然後，如果你增加另一行，它將會隨機的指定到四個可能的salt values中，在靠近現有的一行處結束(it will randomly be assigned one of the four possible salt values and end up near one of the existing rows.)

a-foo0003
b-foo0001
c-foo0003
c-foo0004
d-foo0002

由於該指定是隨機指定的，在檢索這些行的時候你需要做更多的工作。在這種方式下，散射（salting)嘗試增加寫的吞吐量，但是在讀的時候有巨大的消耗。

哈希(Hashing）

與自由指定不同，你可以使用單向的hash使得一個給予的行總是與“salted”擁有相同的前綴，在該方式下，負載將會直接分散到Regionservers中，但是在讀的時候允許可預見性。用一個確定性的hash將允許客戶來重新構造完全的rowkey，並且使用一個Get操作來檢索正常的行。

例子17. 哈希（Hashing） Example

給上面salting例子一樣的情況，你可以使用單向hash從而使得foo0003總是預測性的接受a的前綴。然後，在檢索行的時候，你已經知道了該key值。你也可以優化一些東西使得確定的keys對總是在相同的region上面。例如：

反轉Key

第三個常見的阻止熱點寫的技巧是反轉一個固定寬度或者數字的rowkey，這樣的話，經常改變的那個部分將會是第一個。這將會有效的隨機化rowkeys,但是犧牲了row的排序特點。

可以查看Phoenix工程上的https://communities.intel.com/community/itpeernetwork/datastack/blog/2013/11/10/discussion-on-designing-hbase-tables,和article on Salted Tables, 避免熱點寫的更多信息與相關討論在HBASE-11682。

Client

HBase客戶端查找那些服務於感興趣的row範圍內的regionservers，它通過查找hbase:meta表實現。在定位了需要的region後，客戶端與regionserver建立連接響應讀寫請求，而不是通過去查找master節點。消息被緩存在客戶端，使得後續的請求不會經過查找過程。一個region是否需要重新指定由master的負載均衡或者regionserver是否死亡決定，客戶端將會去查詢目錄表來決定用戶region的新的位置。

參考網址：http://hbase.apache.org/book.html#rowkey.design

http://hbase.apache.org/book.html#architecture.client