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按以下方式來建表： 

create 'ns_boco:test ', {METADATA => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy'}},{NAME => 'info', COMPRESSION => 'SNAPPY' },{NUMREGIONS => 600, SPLITALGO => 'HexStringSplit'}

該建表語句指定了表ns_boco:test Region split策略為按固定大小分裂(ConstantSizeRegionSplitPolicy),壓縮方式採用SNAPPY，表預分600（需按業務實際情況估算）個Region，列族為info

下面測試Rowkey在有雜湊欄位和無雜湊欄位對HDFS檔案入庫Hbase效率的影響。

1、使用bulkload方式把HDFS的檔案匯入Hbase，大小均為340.7G。建表均採用預分40個Region。

create 'ns_boco:import_test1', {METADATA => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy'}},{NAME => 'info', COMPRESSION => 'SNAPPY' },{NUMREGIONS => 40, SPLITALGO => 'HexStringSplit'}
create 'ns_boco:import_test2', {METADATA => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy'}},{NAME => 'info', COMPRESSION => 'SNAPPY' },{NUMREGIONS => 40, SPLITALGO => 'HexStringSplit'}

2、import_test2 Rowkey設計為MD5(MSISDN)取前4位+MSISDN+時間，高位使用MD5得到雜湊欄位。如41c11877721065620170801142654645。

入庫時間：09:23:35–08:51:53≈31分鐘。

可以發現入庫後各Region的資料量分佈比較均衡，每個Region約分配到了7.5G的資料。

3、import_test1 RowkeyRowkey設計為MSISDN（8-11位）+MSISDN+時間，高位直接取手機號碼8-11位，沒做雜湊處理，如06561877721065620170801142654645。

入庫時間：10:20:12-09:25:54≈54分鐘。
入庫後各Region的資料量分佈不均衡，40個Region中有19個（大小為63位元組的目錄）沒有分配到資料，有些Region分配到的資料又比較大，大於20G。

由此可見，Rowkey設計時對高位進行雜湊處理，不僅能提高讀寫效率，還能讓資料均衡的分佈到各個Regions上，實現負載均衡