HBase高級特性、rowkey設計以及熱點問題處理
在闡述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，但隨之帶來的是性能損耗。所以我們還要規劃好數據增長速率，定期觀察維護數據，根據實際業務場景分析是否要進一步分區，或者極端情況下，可能要重建表做更大的預分區然後進行數據遷移。
關注微信公眾號：大數據學習與分享，獲取更對技術乾貨
