在HBase1.1.0發布之前，HBase同一集群上的用戶、表都是平等的，大家平等共用集群資源。容易碰到兩個問題：
- 一是某些業務較其他業務重要，需要在資源有限的情況下優先保證核心重要業務的正常運行
- 二是有些業務QPS常常很高，占用大量系統資源，導致其他業務無法正常運轉。
這是典型的多租戶問題。因此，我們需要通過資源隔離來解決多租戶問題，同時，需要考慮計算型業務與存儲型業務混合部署來提高集群的資源利用率。
1.基本概念
1.1 namespace邏輯隔離
HBase命名空間 namespace 與關系數據庫系統中的數據庫database類似，方便對表在業務上進行划分，實現邏輯隔離。
Apache HBase從0.98.0, 0.95.2兩個版本開始支持namespace級別的授權操作，HBase全局管理員可以創建、修改和回收namespace的授權。
這種抽象為即將出現的多租戶相關功能奠定了基礎。
1.2. 配額管理(Quotas)
資源限制，主要針對用戶、namespace以及表的QPS和請求大小進行限制。
相關jira見：
https://issues.apache.org/jira/browse/HBASE-8410、https://issues.apache.org/jira/browse/HBASE-11598
一般可以對熱點表進行限制，或者在高峰期，對非核心業務表進行限制。
常用語句：
hbase> set_quota TYPE => THROTTLE, TABLE => 't1', LIMIT => '1000req/sec' hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => WRITE, USER => 'u1', LIMIT => '10M/sec'
注意事項:
1）set_quota 的限制都是針對單個region server來說的，並不是針對整個集群，是一種分布式的限制
2）set_quota 默認執行后並不會立刻生效，需要等待一段時間才會生效，等待時間默認為5min。可以通過參數 hbase.quota.refresh.period 進行設置，比如可以通過設置
hbase.quota.refresh.period = 60000將生效時間縮短為1min
3）可以通過命令list_quotas查看當前所有執行的set_quota命令
4）本質上是一種限流手段，無法充分隔離資源
1.3 RS隔離 （region group）
一般情況下，為了保證核心業務的隔離性，會為每個業務搭建一個集群，但是這樣可能會導致資源使率過低，比如有些業務重計算輕存儲，有些業務重存儲輕計算，完全的物理隔離勢必帶來資源的不協調，有些集群資源過剩，有些集群資源不足。
對此，得益於HBase的共享存儲、計算分離的架構，Hbase提供了多租戶隔離技術region group。
相關jira見：
https://issues.apache.org/jira/browse/HBASE-6721
RegionServer Group 技術是通過對 RegionServer 進行分組，不同的 RegionServer 分到不同的組。每個組可以按需掛載不同的表，並且當組內的表發生異常后，Region 不會遷移到其他的組。這樣，每個組就相當於一個邏輯上的子集群，通過這種方式達到存儲資源共享、計算資源隔離的效果，提高資源利用率，降低管理成本，不必為每個高 SLA 的業務線單獨搭集群。
2.多租戶核心架構圖
下面，我們進一步深入多租戶的核心架構圖，通過架構圖能清晰的看到，資源的隔離和共享情況，某一個租戶的RS上哪些操作會對其他租戶的資源產生影響，具體影響在哪里，影響大小如何量化。
從上圖可以看的，group對region server做了隔離，因此，在計算資源上是物理隔離的。
因此，多租戶場景下，相互直接的影響是在共享存儲層面的。
在共享存儲上，發生相互影響的根本原因在於HDFS的數據三副本寫入，如下圖所示
從以上可以看出多租戶間可能產生的影響主要來自於其他租戶引發的一些寫流量，主要包括：
- HBase寫入產生的WAL同步
- MemStore 刷盤導致的數據同步（flush）
- StoreFile合並導致的數據同步（MinorCompaction & MajorCompaction）
- 尤其是大數據量的寫入，會對其他group的load造成顯著影響
3.容量規划
一個實例（集群）的情況下，壓測的結果和性能表現就是該實例（集群）的prod后實際運行的表現，但是針對一個集群多個用戶的情況（主要是HBase的存儲節點共享），如何來評估容量，分配資源顯然更具挑戰。
重點解決業務訴求對HBase集群資源的合理科學分配。例如下面這個參考：
為了方便我們識別某個業務是“存儲型”還是“計算型”，我們對當前業務需要的機器做個評估。
定義資源系數m（簡化計算，暫時不考慮內存）：
m = 核數 * cpu使用率/ （存儲容量*容量使用率）
由於我們一般采用8c64g 1788GB(三副本，實際存儲為0.6T)作為標准core，根據上文資源系數m的計算公式：
標准core的
m = 8 * 50%/（0.6*100%） = 6.67
其中，cpu安全水位為50%。
如果某個業務的預估m值低於6.67，則認為是存儲型，高於6.67則認為是計算型（當然，隨着業務的發展，這個偏向可能會發生變化）。
多租戶的核心在於提高資源利用率，因此，我們需要將便計算型業務和便存儲型業務進行混合部署。
4.告警監控
同集群多租戶下的監控告警方案，區別不同集群的監控方案，需要更細粒度的關系映射。
對於多租戶集群，采用最小租戶單位為namespace，記錄namespace對應的group name、core-id
1）監控看版
在原本集群監控的基礎上，手動記錄租戶與實例資源的映射關系，然后在目前的看板上進一步篩選core-id進行監控。
2）告警
監控針對core-id進行指標判斷，一旦指標到達閾值，根據instanceid、core-id請求hbase-ops獲取相關報警聯系人
沒有按core區分的系統指標只需要instanceid，請求hbase-ops獲取該集群所有相關聯系人。
5.多租戶最佳實踐
- 單個集群不能太小，太小沒有意義。
- 單個group內region server也不要太少，至少2個，region server越少，單個region server故障的影響面越大。
- 如果做了group，那么default的group最好空出來，只用來放meta表。
- 最佳模式是按照namespace緯度進行group的划分。
- 集群中，可以划分一個buffer group，不承擔任何流量，如果出現線上的熱點，可以臨時把這個熱點表移動到buffer group上
看到這里了，原創不易，點個關注、點個贊吧，你最好看了～
知識碎片重新梳理，構建Java知識圖譜：https://github.com/saigu/JavaKnowledgeGraph（歷史文章查閱非常方便）