一、引言 HBase由於其儲存和讀寫的高效能，在OLAP即時分析中越來越發揮重要的作用，在易觀精細化運營產品--易觀方舟也有廣泛的應用。作為Nosql資料庫的一員，HBase查詢只能通過其Rowkey來查詢(Rowkey用來表示唯一一行記錄)，Rowkey設計的優劣直接影響讀寫效能。HBase中的資料是按照Rowkey的ASCII字典順序進行全域性排序的,有夥伴可能對ASCII字典序印象不夠深刻，下面舉例說明： 假如有5個Rowkey："012", "0", "123", "234", "3"，按ASCII字典排序後的結果為："0", "012", "123", "234", "3"。（注：文末附常用ASCII碼錶） Rowkey排序時會先比對兩個Rowkey的第一個位元組，如果相同，然後會比對第二個位元組，依次類推... 對比到第X個位元組時，已經超出了其中一個Rowkey的長度，短的Rowkey排在前面。

由於HBase是通過Rowkey查詢的，一般Rowkey上都會存一些比較關鍵的檢索資訊，我們需要提前想好資料具體需要如何查詢，根據查詢方式進行資料儲存格式的設計，要避免做全表掃描，因為效率特別低。

二、Rowkey設計原則 Rowkey設計應遵循以下原則： 1.Rowkey的唯一原則

必須在設計上保證其唯一性。由於在HBase中資料儲存是Key-Value形式，若HBase中同一表插入相同Rowkey，則原先的資料會被覆蓋掉(如果表的version設定為1的話)，所以務必保證Rowkey的唯一性

1. Rowkey的排序原則

   HBase的Rowkey是按照ASCII有序設計的，我們在設計Rowkey時要充分利用這點。比如視訊網站上對影片《泰坦尼克號》的彈幕資訊，這個彈幕是按照時間倒排序展示視訊裡，這個時候我們設計的Rowkey要和時間順序相關。可以使用"Long.MAX_VALUE - 彈幕發表時間"的 long 值作為 Rowkey 的字首
    
   

2. Rowkey的雜湊原則

   我們設計的Rowkey應均勻的分佈在各個HBase節點上。拿常見的時間戳舉例，假如Rowkey是按系統時間戳的方式遞增，Rowkey的第一部分如果是時間戳資訊的話將造成所有新資料都在一個RegionServer上堆積的熱點現象，也就是通常說的Region熱點問題， 熱點發生在大量的client直接訪問集中在個別RegionServer上（訪問可能是讀，寫或者其他操作），導致單個RegionServer機器自身負載過高，引起效能下降甚至Region不可用，常見的是發生jvm full gc或者顯示region too busy異常情況，當然這也會影響同一個RegionServer上的其他Region。
    
   

通常有3種辦法來解決這個Region熱點問題： ΩΩ1、Reverse反轉

原文連結