需求描述：
掃描（查詢）某個區間---》列用hbase多節點的資源，分布式掃描，加快速度==》 然后拼接到一起 如何打散數據 冠字號逆序，hash
並不一定數據連續就會造成熱點，這個是由數據訪問模式決定的。
ex:時間作為rowkey，但查詢經常按一個時間段來查詢=====》 時間作為rowkey會造成時間差不多的在一個region，這就會造成region server 壓力大，===》形成熱點
ex：不按照時間段查詢，簡單的全局掃描，這個就不是熱點===》例如爬蟲的需求。
http://www.udpwork.com/item/11992.html
人民幣冠字號作為rowkey，是連續的 ，會造成熱點，所以要經過 hash打撒
爬蟲是hostid_pid_urlid 就希望他存儲到一塊去，方便掃描，不擔心熱點
why why why why~~
訪問次數少，但是連續讀（也就是排序）的需求強的，就要放在一起。
訪問次數多的，比如冠字號這種的，就得哈希打撒~~~
避免HBase訪問熱點
在作了較多優化改進后發現仍有幾個worker比較慢，跟蹤那幾個慢的worker日志發現讀HBase經常超時，找到超時的region server，從HMaster UI上觀察到這個server的讀寫請求數明顯是其它server的好幾倍。開始懷疑是數據有傾斜，有熱點region落到了這台機器上。在HBase UI上逐個檢查Pora2用到的HBase表，果然在其中的一張表上發現它的第一個region的請求數比其它region高出一兩個數量級。
按我們的設計預期，這個表的rowkey是加了hash前綴的，理論上不該有熱點region，最終檢查代碼后才發現是生成rowkey的代碼存在 bug，生成前綴的代碼用了 key.hashCode() % regionNum，結果有很多key的hashcode返回是負數，使得很多前綴是負數，全都落在了第一個region上。
而對hbase來說，一旦有一個region有熱點，就會導致該region所在的region server變慢，進而使得這個server上其它表的region訪問也慢，從而影響了整個hbase的性能。