hbase讀寫效能優化一般可以從三個方面入手
1、hbase服務端讀寫配置
2、hbase客戶端配置
3、hbase表的設計
本文從表設計的rowkey和預分割槽角度優化hbase讀寫效能，避免region讀寫熱點問題。
先了解hbase讀取資料方式：
1、隨機讀：通過get方式，指定rowkey獲取唯一記錄
2、區域性順序讀（隨機讀+順序讀）：通過scan方式，設定startrow和stoprow引數進行範圍匹配
3、順序讀（全表順序讀）：通過scan方式，全表掃瞄，並通過filter過濾出資料
hbase資料分成多個region存在於集群各機器上，region的資料邊界是startkey和endkey，所以設計乙個好的rowkey，使讀寫請求均勻落在各個region上尤為重要。
rowkey設計思路大致有以下幾種：
1、隨機
取乙個隨機數作為rowkey，如new random().nextlong()
讀取方式：只支援全表掃表，無法支援隨機讀
2、雜湊
取業務id的雜湊值作為rowkey，如hash(url)
讀取方式：支援隨機讀和順序讀，不支援區域性順序讀
3、雜湊+業務id（推薦）
對業務id取雜湊，再拼接業務id，如hash(url)+url
讀取資料：支援隨機讀、區域性順序讀、順序讀
hbase表預分割槽
避免讀寫熱點：hbase表預分割槽設計，加上rowkey的合理設計，使得讀寫資料請求分散在多個region上。
提前預防region**：hbase表的單個region超過一定大小後，會進行**，**後的major compaction會占用大量的系統資源（cpu,io,記憶體,頻寬），導致讀寫延遲，並且compaction極有可能導致寫阻塞。
語法：指定預分割槽數目和分割槽策略
create 't1', 'f1',
指定分割槽rowkey，rowkey是前乙個分割槽的stopkey，後乙個分割槽的startkey，第乙個分割槽沒有startkey，最後乙個分割槽沒有stopkey
create 't1', 'f1', splits => ['1', '2', '3', '4']
以檔案形式指定分割槽的rowkey
create 't1', 'f1', splits_file => 'splits.txt'
在splits.txt中，每一行為乙個rowkey
123
4
分析：hbase預設每個region的最大大小10g，每個region預留空間20%，乙個region可儲存資料為8g，800/8=100，所以預分割槽數目為100。
以url為業務id，且同乙個站點資料一起寫入，如果直接以url作為rowkey，則短時間內所有寫入請求都落在乙個region上，造成寫熱點，所以，對url適當處理按照雜湊+業務id的方式處理比較合適。
region分割槽檔案可以設計如下：
總共99行，分成100個區，每個分割槽中rowkey的字首為乙個固定的兩位數字（注意01-09前面補0了）。
雜湊處理：最終的rowkey=prefix+url
支援讀取方式：
隨機get：以上述相同的方式獲得url的rowkey，然後進行get
區域性順序讀：指定讀取的url範圍為url1~url2，需要分別掃瞄落在各個字首區間的資料，如落在以005字首的區間內，掃瞄時的startkey=005url1，stopkey=005url2，迴圈處理[00-99]各個字首，即可完成對url1~url2區間內資料的掃瞄。（該讀取方式還是有一點點複雜）
全表順序讀：無需講解。
HBase RowKey設計原則
對於關係型資料庫，資料定位可以理解為 二維座標 但是hbase中需要四維來定位乙個單元格，即 行健 列族 列限定符 時間戳 hbase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行訪問在臨近位置，便於scan。然而糟糕的rowkey設計是熱點...
HBase Rowkey 設計指南
文章目錄 2 rowkey設計技巧 3 rowkey 設計案例剖析 我們常說看一張 hbase 表設計的好不好，就看它的 rowkey 設計的好不好。可見 rowkey 在 hbase 中的地位。那麼 rowkey 到底是什麼？rowkey 的特點如下 如果我們的 rowkey 設計為 uid ph...
HBase Rowkey 設計指南
我們常說看一張 hbase 表設計的好不好，就看它的 rowkey 設計的好不好。可見 rowkey 在 hbase 中的地位。那麼 rowkey 到底是什麼？rowkey 的特點如下 如果我們的 rowkey 設計為 uid phone name，那麼這種設計可以很好的支援以下的場景 難以支援的場...