只要使用過，聽說過HBase的人，我想對HBase的數據熱點想必也不會陌生。
數據熱點是如何出現的，這得從HBase的存儲結構說起，對於HBase詳細的存儲結構可以上網搜一下，這裏就不補充了。
我們只需要知道，我們的HBase的表會被劃分爲1個或多個Region,被託管在RegionServer中。
Region被託管在RegionServer中
由上圖我們可以看出，Region有兩個重要的屬性：StartKey和EndKey。表示這個Region維護的rowkey的範圍，當我們要讀寫數據時，如果rowkey落在某個start-end key範圍內，那麼就會定位到目標region並且讀寫到相關的數據。
默認情況下，當我們通過hbaseAdmin來創建一張表時，剛開始的時候只有一個Region，start-endkey無邊界，也就是說無論來什麼，本Region統統收，如下圖。
一個Region，無邊界
所有的rowkey都寫入到這個region裏，然後數據越來越多，region的size越來越大時，大到一定的閥值，hbase就會將region一分爲二，成爲2個region，這個過程稱爲分裂（region-split）。
如果我們就這樣默認建表，表裏不斷的put數據，一般情況我們的rowkey還是順序增大的，這樣，存在的缺點比較明顯：我們總是向最大的startkey所在的region寫數據，因爲我們的rowkey總是會比之前的大，並且hbase的是按升序方式排序的。所以寫操作總是被定位到無上界的那個region中，之前分裂出來的region不會被寫數據，所以這樣產生的結果是不利的。
如果在寫比較頻繁的場景下，數據增長太快，split的次數也會增多，由於split是比較耗費資源的，所以我們並不希望這種事情經常發生。
在集羣中爲了得到更好的並行性，讓每個節點提供的請求都是均衡的，我們也不希望，region不要經常split，因爲split會使server有一段時間的停頓，如何能做到呢？
rowkey的散列或預分區貌似就可以辦的到。
預分區一開始就預建好了一部分region，這些region都維護着自己的start-end keys，我們將rowkey做一些處理，比如RowKey%i，寫數據能均衡的命中這些預建的region，就能解決上面的那些缺點，大大提供性能。
而將rowkey散列化就是避免rowkey自增，這樣也能解決上面所說的缺點。
Hbase常見避免熱點問題的方法
加鹽
一把rowkey前綴，決定了在哪一個分區。
降低熱點問題，但是會造成讀的時候，效率下降。
哈希
反轉
舉例：
前綴都是一樣，可能都會往一個region裏面寫數據時，就會出現熱點問題。
返回來，把號碼倒過來，就會是不同的數字，解決了熱點問題。
時間戳反轉
HBASE總結
1、儘量減少行和列的大小
2、列簇儘可能越短越好，最好是一個字符
3、冗長的屬性名雖然可讀性好，但是更短的屬性存儲在HBase中會更好