推薦大家去看原文博主的文章，條理清晰閱讀方便，轉載是爲了方便以後個人查閱 https://www.cnblogs.com/i80386/p/3696492.html 需求描述： 掃描（查詢）某個區間---》列用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的性能。