在設計hbase資料庫時，第乙個要面臨的問題就是如何避免發生資料傾斜，導致熱點問題。此資料傾斜和前面spark效能調優中的資料傾斜，在其產生原因和處理方向上均有所不同，文字簡要的列出一些基本的處理方案，作為記錄。
熱點問題發生在大量的client直接訪問集群的乙個或極少數個節點。了解hbase的讀者都知道，hbase使用了regionsever來管理region，這裡再簡單複述一下資料的定址過程(附圖供參考):
client首先連線到zookeeper這是就要先查詢-root-的位置(老版本)
通過-root-獲取所請求行所在範圍所屬的.meta.region的位置
查詢.meta.region來獲取user-space region所在的節點和位置
client就可以直接和管理者那個region的regionserver進行互動
hbase內部維護著-root-和.meta.兩個元資料表(新版本hbase中root表已被取消，因為meta就夠了，減少索引次數)。內容為當前集群所有region 的列表、狀態和位置。簡單來說就是zookeeper記錄-root-表的位置，-root-表維護.meta.的位置，.meta.維護hbase集群全部region的資訊。當然，-root-只有乙個 region,而.meta.會隨著內容增多而**為多個region。
熱點問題其實就是client總是定址到某個或者某幾個region，要解決這個問題，自然是希望資料能夠分散到各個region中，而不是集中在某幾個節點。處理方法分為兩步，第一步：預分割槽，讓表的資料可以均衡的分散在集群中，而不是預設只有乙個region分布在集群的乙個節點上。預設的情況下，建立一張表時只有1個region，隨著表內資料的增多，會觸發**(region-split)過程，依次繼續**進行，這種情況下，顯然很容易造成熱點問題，其他節點都在閒置，只有當前節點不斷擴容，直至**。
解決方案也很簡單，就是預分割槽。乙個regionserver能管理10-1000個region，預設每個region大小為10g，因此我們可以根據資料量集群可用節點數預估所需分割槽數，之後在建立表時指定分割槽數，方法如下：
hbase shell：create 『tablenmae』,
,,splits =
>
[『0′,』1』, 『2』, 『3』, 『4』,』5′,』6′,』7′,』8′,』9′]
hbase api：admin.
createtable
(descriptor, splitkeys)
//splitkeys為bytes陣列
這裡有乙個引數可以調整，預設情況下，hbase的balancer是regionserver級別，與表無關，在極端情況下，雖然每個regionserver下的region個數一樣多,但一張表的所有region可能都在一台機器上，這也容易造成熱點問題，可以通過hbase.master.loadbalance.bytable設定表級別的region均衡。
資料傾斜
在完成預分割槽後，只是降低了一部分可預見的熱點問題，更重要的點在於，hbase自身的資料傾斜，雖然劃分了分割槽，但根據rowkey順序儲存的特點，讀取region時仍然可能集中在個別region上。
首先簡單判斷是否存在資料分布傾斜，就是檢視hbase指定表目錄下各資料夾大小，每個資料夾就對應乙個region：
~]$ hadoop fs -du -h /hbase/data/default/**tablename**其中rowkey設計的目標是將資料合理地分配到每乙個region中，從而很好地滿足業務的讀寫需求。如何合理的設計rowkey，是hbase資料庫的重中之重，下面就簡單羅列幾種常用的方法：
首先rowkey的長度建議為10-16位元組。提高hfile儲存效率，降低memstore快取占用，64位系統系8位元組對齊，提高效能。
rowkey雜湊原則。對於rowkey和資料產生的順序有關的情況，例如以時間戳開頭的資料，如果不做處理，顯然每個時間段儲存的節點比較集中，建議將rowkey的高位作為雜湊字段，例如主鍵雜湊後當成rowkey的頭部或者直接使用短8位的uuid當成rowkey的頭部。
reversing翻轉。例如以**號碼開頭的rowkey，翻轉後將擁有較好的雜湊性，同時尾部位元組仍保留關聯性。
當然，任何處理都將破壞rowkey原有的序列性，對於資料的讀取是不利的。在避免資料傾斜時，要盡可能兼顧到讀取資料方面的優化，rowkey的設計有許多可以挖掘的地方。
參考：如何合理的設計hbase rowkey
Hbase熱點問題
當處理由連續事件得到的資料時，即時間上連續的資料。這些資料可能來自於某個感測器網路 交易或者乙個監控系統。它們顯著的特點就是rowkey中含有事件發生時間。帶來的乙個問題便是hbase對於row的不均衡分布，它們被儲存在乙個唯一的rowkey區間中，被稱為region，區間的範圍被稱為start k...
Hbase熱點問題
需求描述 掃瞄 查詢 某個區間 列用hbase多節點的資源，分布式掃瞄，加快速度 然後拼接到一起 如何打散資料 冠字型大小逆序，hash 並不一定資料連續就會造成熱點，這個是由資料訪問模式決定的。ex 時間作為rowkey，但查詢經常按乙個時間段來查詢 時間作為rowkey會造成時間差不多的在乙個r...
Hbase 3）熱點問題及預分region表
當表被建立時，hbase預設只會為該錶分配乙個region，那麼，初始狀態時所有的請求都會集中在乙個region server上，當大量資料寫入時，該節點將成為熱點。當然，region熱點不僅體現在建立表階段。對於一張擁有很多region的大表來說，其在region sever上的分布往往不會十分均...