rowkey是hbase每一行記錄的唯一標識，在設計rowkey時，不僅要考慮業務需求，也需要考慮hbase本身的特性。如果rowkey設計不合理，不僅不能充分發揮hbase集群並行處理的優勢，還會造成資料傾斜、region熱點等影響讀寫效率的問題。
rowkey設計原則
rowkey設計一般遵循以下三個原則：
1、 唯一性原則
rowkey在設計時必須保持唯一性，如果兩條記錄rowkey相同，hbase會儲存為同乙個rowkey的不同版本。
2、 長度原則
hbase資料的持久化檔案hfile是按照keyvalue儲存的，如果rowkey過長，在資料量大的時候，會占用很大的儲存，極大的影響hfile的儲存效率。
3、 雜湊原則
建議rowkey的高位作為雜湊字段，低位作為時間字段，這樣rowkey會比較均勻的分布到各個region上，以實現負載均衡的機率。如果沒有雜湊字段，大部分資料都會集中在某些region上，而某些region資料量小甚至沒有分配到資料，造成熱點問題，降低hbase讀寫效率。
建表預分割槽原則
hbase region在大小達到一定閾值後（目前是10g），就會splite(**)兩個region，而當乙個region的hfile個數達到一定的閾值（目前為4個），就會對這些hfile進行compact(合併)。splite和compact都會比較消耗io，所以要儘量減少region**和合併的次數。這就需要對資料的大小進行評估，建表時預先分割槽。如果不預分割槽，預設就只有乙個分割槽，在匯入資料時就只會起乙個reduce任務處理，而且region達到閾值大小後會不斷**，非常影響入庫效率。所以需要合理估算分割槽數，過小會導致region不斷**，過大又會增加masterserver管理的壓力。計算分割槽數原則如下：
n = totalsize/hbase.hregion.max.filesize(目前是10g)
例如目前http介面信令資料一天的大小約為6.5t，那麼分割槽數為：6.5*1024/10=665.6，因為建表時一般會指定壓縮方式，入庫後的資料會變小，故分割槽數設定為600就足夠了。dns介面每天大小約2t，分割槽數為：2*1024/10=204.8，分割槽數設定為了200就可以了。
建議hbase按以下方式來建表：
下面測試rowkey在有雜湊欄位和無雜湊欄位對hdfs檔案入庫hbase效率的影響。
1、 使用bulkload方式把hdfs的檔案匯入hbase，大小均為340.7g。建表均採用預分40個region。
2、 import_test2 rowkey設計為md5(msisdn)取前4位+msisdn+時間，高位使用md5得到雜湊字段。如41c11877721065620170801142654645。
可以發現入庫後各region的資料量分布比較均衡，每個region約分配到了7.5g的資料。
3、 import_test1 rowkeyrowkey設計為msisdn（8-11位）+msisdn+時間，高位直接取手機號碼8-11位，沒做雜湊處理，如06561877721065620170801142654645。
入庫後各region的資料量分布不均衡，40個region中有19個（大小為63位元組的目錄）沒有分配到資料，有些region分配到的資料又比較大，大於20g。
由此可見，rowkey設計時對高位進行雜湊處理，不僅能提高讀寫效率，還能讓資料均衡的分布到各個regions上，實現負載均衡
Hbase中rowkey設計原則
1.rowkey長度原則 rowkey不宜過長 建議不要超過16個位元組 若rowkey長度過長，memorystore會將部分快取資料存入記憶體降低記憶體利用率，降低檢索效率，hfile進行資料持久化時也會極大影響儲存效率 2.rowkey雜湊原則 設計目標 將資料均勻的分布在每個regionse...
Hbase中rowkey設計原則
1.熱點問題 在某一時間段，有大量的資料同時對乙個region進行操作 2.原因 對rowkey的設計不合理 對rowkey的劃分不合理 3.解決方式 rowkey是hbase的讀寫唯一標識 最大長度是64kb。4.核心原則 設計必須按照業務需求進行設計 5.長度原則 經驗 10 100位元組可以 ...
Hbase中Rowkey設計對庫效率的影響
rowkey是hbase每一行記錄的唯一標識，在設計rowkey時，不僅要考慮業務需求，也需要考慮hbase本身的特性。如果rowkey設計不合理，不僅不能充分發揮hbase集群並行處理的優勢，還會造成資料傾斜 region熱點等影響讀寫效率的問題。rowkey設計原則 rowkey設計一般遵循以下...