HBase的性能優化

數據預分區

主要針對初建表時只有一個region，若是寫入的數據量比較大就會致使所在的region server不堪重負，寫入性能低下。

create 'test', {NAME => 'cf', COMPRESSION => 'SNAPPY'}, SPLITS => ['10','20','30']
複製代碼

Rowkey設計

1. 明確查詢條件

   Hbase基本能夠當作一個keyvalue數據庫，其中的數據須要經過key來查找，所以須要把查詢條件拼接成key，將必需的條件放在前面，其餘的放在後面。

2. 熱點問題

   全部的方法都會改變原始數據的存儲順序，所以須要針對不一樣的場景採起適合於查詢的方法。

   主要有3個方法來避免熱點現象，分別是反轉，加鹽和哈希。

• 反轉: 把固定長度或者數字格式的 rowkey進行反轉，反轉分爲通常數據反轉和時間戳反轉，其中以時間戳反轉較常見。 缺點： 利於Get操做，但不利於Scan操做，由於數據在原RowKey上的天然順序已經被打亂。 好比須要保存一個用戶的操做記錄，就能夠按照操做時間倒序排序，在設計rowkey的時候，能夠這樣設計 反轉後的userId，在查詢用戶的全部操做記錄數據的時候，直接指定反轉後的userId，startRow 是 反轉後的userId，stopRow 是 反轉後的userId。若是須要查詢某段時間的操做記錄，startRow 是[反轉後的userId[Long.Max_Value - 起始時間]， stopRow 是反轉後的userId。
• 加鹽: 在原RowKey的前面添加固定長度的隨機數，也就是給RowKey分配一個隨機前綴使它和以前的RowKey的開頭不一樣
• 哈希: 基於RowKey的完整或部分數據進行Hash，然後將哈希後的值完整替換或部分替換原RowKey的前綴部分。 與加鹽類似只不過不是隨機數,而是能夠預知的一個數

代碼優化

1. 批量讀取/寫入

   • get時可傳List，減小rpc調用的次數。

   • scan時可加大cache數（默認爲100），使每次rpc操做取回更多的數據。

   scan.setCaching(500)

2. 只取須要的列

   在列較多的狀況下使用QualifierFilter，減小傳回客戶端的數據量。

磁盤佔用

1. Rowkey、列族名稱和列名稱在知足需求的狀況下儘可能短一點，由於每一個cell都包含這些信息，在數據量大的狀況下能夠顯著節省磁盤空間。
2. 建表時採用snappy壓縮