在闡述HBase高階特性和熱點問題處理前，首先回顧一下HBase的特點：分散式、列儲存、支援實時讀寫、儲存的資料型別都是位元組陣列byte[]，主要用來處理結構化和半結構化資料，底層資料儲存基於hdfs。
同時，HBase和傳統資料庫一樣提供了事務的概念，但是HBase的事務是行級事務，可以保證行級資料的原子性、一致性、隔離性以及永續性。
布隆過濾器在HBase中的應用
布隆過濾器（Bloom Filter）是空間利用效率很高的資料結構，利用位陣列表示一個集合，判斷一個元素是否屬於該集合。但存在一定的錯誤率，在判斷一個元素是否屬於某個集合時，有可能會把不屬於這個集合的元素誤認為屬於這個集合，所以適用於能容忍一定錯誤率的場景下。
布隆過濾器是HBase的高階功能屬性，它能夠降低特定訪問模式下的查詢時間，但是會增加記憶體和儲存的負擔，是一種以空間換時間的典型應用，預設為關閉狀態。
可以單獨為每個列族單獨啟用布隆過濾器，可以在建表時直接指定，也可以通過使用HColumnDescriptor.setBloomFilterType對某個列族指定布隆過濾器。
目前HBase支援以下3種布隆過濾器型別：
NONE：不使用布隆過濾器（預設）
ROW：行鍵使用布隆過濾器過濾
ROWCOL；列鍵（row key + column family + qualifier）使用布隆過濾器過濾
下圖展示了何種情況下使用布隆過濾器，一般建議使用ROW模式，它在額外的儲存空間開銷和利用選擇過濾儲存檔案提升效能方面做了很好的權衡，具體使用哪一種，要看具體的使用場景：
協處理器
HBase協處理器目前分為兩種observer和endpoint，二者可以結合使用，都是執行在HBase服務端的。
1. observer
與RDBMS的觸發器類似，執行客戶端在操作HBase叢集資料過程中，通過鉤子函式在特定的事件（包括一些使用者產生和服務期內部自動產生的事件）發生時做一些預處理（如插入之前做一些業務處理）和後處理（如插入之後做出響應等）的操作。
observer提供的幾個典型的介面：
RegionObserver：處理資料修改事件。典型的應用場景就是用作處理HBase二級索引，如在put前在針對處理的資料生成二級索引，處理引擎可以通過MapReduce做，也可以將生成的二級索引儲存在solr或者es中
MasterObserver：管理或DDL型別的操作，針對叢集級的事件
WALObserver：提供針對WAL的鉤子函式
2. endpoint
類似於RDBMS中的儲存過程，可以通過新增一些遠端過程呼叫來動態擴充套件RPC協議。允許擴充套件叢集的能力，對客戶端應用自定義開發新的運算命令，使用者程式碼可以被部署到服務端
列族設計
一個列族在資料底層是一個檔案，所以將經常一起查詢的列放到一個列族中，同時儘可能建立較少數量的列族，且不要頻繁修改，這樣可以減少檔案的IO、定址時間，從而提高效能。
row key設計
HBase中rowkey可以唯一標識一行資料，在HBase查詢的時候，主要以下兩種方式：
get：指定rowkey獲取唯一一條記錄
scan：設定startRow和stopRow引數進行範圍匹配
在設計row key時，首先要保證row key唯一，其次要考慮以下幾個方面：
1. 位置相關性
儲存時，資料按照row key的字典順序排序儲存。設計row key時，要充分考慮排序儲存這個特性，將經常一起讀取的行儲存放到一起。
2. row key長度
row key是一個二進位制碼流，可以是任意字串，最大長度 64kb ，一般為10-100bytes，原因如下：
1）HBase資料的持久化檔案hfile是按照Key Value儲存的，如果row key過長，當儲存的數量很大時，僅row key就會佔據很大空間，會極大影響hfile儲存效率
2）row key設計過長，memstore快取到記憶體的資料就會相對減少，檢索效率低
3. row key雜湊性
row key是按照字典順序儲存的，如果row key按照遞增或者時間戳遞增生成，那麼資料可能集中儲存在某幾臺甚至某一臺region server上，導致某些region server的負載非常高，影響查詢效率，嚴重了可能導致region server當機。
因此，可以將row key的一部分由程式生成雜湊數字，將row key打散，均勻分佈在HBase叢集中的region server上，具體分為以下幾種處理方式：
1）反轉
通過反轉固定長度或數字格式的row key，將row key中經常變化的部分（即相對比較隨機的部分）放在前面，這種方式的弊端就是失去了rowkey的有序性。
最常用的就是，使用者的訂單資料儲存在HBase中，利用手機號後4位通常是隨機的的特性，以使用者的手機號反轉再根據業務場景加上一些其他資料拼成row key或者是僅僅使用反轉後的手機號作為row key，從而避免以手機號固定開頭導致的熱點問題。
2）加鹽
並非密碼學中的加鹽，而是通過在row key加隨機數字首，字首種類數應和你想使資料分散到不同的region的數量保持一致。
3）雜湊雜湊方式
利用一些雜湊演算法如MD5，生成雜湊雜湊值作為row key的字首，確保region所管理的start-end rowkeys範圍儘可能隨機。
HBase熱點問題及處理
HBase中熱點問題其實就是資料傾斜問題，由於資料的分配不均勻，如row key設計的不合理導致資料過多集中於某一個或某幾個region server上，會導致這些region server的訪問壓力，造成效能下降甚至不能夠提供對外服務。
還有就是，在預設一個region的情況下，如果寫操作比較頻繁，資料增長太快，region 分裂的次數會增多，比較消耗資源。
主要通過兩種方式相結合，row key設計（具體參考上文）和預分割槽。
這裡主要說一下預分割槽，一般兩種方式：
1. 建表時，指定分割槽方式。
如create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
2. 通過程式生成splitKeys，程式中建表時指定splitKeys
但這兩種方式也並非一勞永逸，因為資料是不斷地增長的，已經劃分好的分割槽可能承載不了更多的資料，就需要進一步split，但隨之帶來的是效能損耗。所以我們還要規劃好資料增長速率，定期觀察維護資料，根據實際業務場景分析是否要進一步分割槽，或者極端情況下，可能要重建表做更大的預分割槽然後進行資料遷移。
關注微信公眾號：大資料學習與分享，獲取更對技術乾貨