尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
本文轉載自：https://zhuanlan.zhihu.com/p/51635980
一、背景
目前滴滴 HBase 集群接入了幾百個項目，近千張表，上層有用戶自己的業務做到以及 Phoenix（HBase SQL 引擎）和 GeoMesa（基於 HBase 的時空索引做到）。
不同用戶間請求方式，業務邏輯，以及要求的響應時間都不同，如何減少用戶之間的影響，及時發現特定業務問題？
我們在社區的 HBase 版本基礎上增加了 RegionServer Group 的功能 (HBASE-6721)。
此功能用於將一個大 HBase 集群的 RegionServer 劃分為多個分組，管理員可以將不同的表放入不同分組進行隔離，避免無關係的業務之間互相影響。
二、原理
HBase 是一個分布式存儲的集群，那麼首先肯定有很多 server 進行具體的數據存儲和讀寫 RPC 的處理。HBase 將一個表通過 split 方式分成多個 Region。然後將這些 Region 分配到不同的機器，達到將請求分散的目的。
我們來看看集群是通過什麼方式進行表 Region 的管理。
既然有這麼多 server，那麼一般都需要有一個管理者來進行管理，這個管理者就是 HMaster。HMaster 通過 Balancer 來將一個表的 N 個 split 之後的 N 個 Region 均衡到不同的 RegionServer 上。
由淺入深
先來看看只有一個表的情況。
比如現在我們有一個表 A 在集群上創建，如下圖，根據默認的 Balance 權重，每個機器上基本上 Region 數量很平均。做好 rowkey 的散列之後，每個機器的請求壓力也很平均了，看上去還不錯，下面我們看看創建了多個表的情況。
進階，增加了新的表
舊的 Region 分配策略當表 B 也在這個集群創建之後，表 A 和表 B 的 Region 是混合分配在多個 RegionServer 上的，當 Table_B 有很多請求給服務器造成壓力時，本來穩定的 Table_A 也會受到影響。
RegionServer Group 的應用
將 RegionServer Group 特性應用之後的策略：
增加兩個 Group A 和 B。Table_A 有兩台機器，Table_B 有兩台機器。
這樣兩個表如果其中一個表的請求量增大，也不會對另外一個表所在機器的 CPU、記憶體和 JVM 有影響。
三、資源規劃
不過目前同一個集群底層的 HDFS 還是一套磁盤的流量，IO 壓力還是要注意。有獨立分組的用戶也不是無限制的去使用集群資源的。
應用 RegionServer Group 之後，資源分配計算我們總結了方案，通過以下方法來大致判斷用戶的流量以及需要分配多少資源。
下圖中是藍色部分是讀操作，綠色部分是寫操作，由操作次數和每次操作 Size 大小，我們可以得到對應的 IO 流量；通過寫流量和存儲 TTL，我們可以預估出存儲大小。
當然集群內部的 compaction 機制和 load 文件的 Bulkload 操作，也會帶來一定的流量和計算量，不過這兩項操作都可以通過參數進行限流，也都是可控的。
再通過壓測的單機讀寫流量 + IO 能力以及存儲空間，我們就可以大致計算出某一個表需要多少的機器了。
雖然是大致的估算，但是我們把目前能統計和限制的地方都做了相應的計算和限制，也已經解決了不少問題。
四、具體應用
HBase meta Group：
用來存放 HBase 本身的 meta 表，HBase:meta、HBase:acl、HBase:rsgroup、HBase:namespace 等，當集群個別表出現性能問題時，至少不會影響 HBase 本身的元數據，這樣才能保證其他表的服務正常。
Phoenix meta Group：
用來存放 Phoenix 的 meta 表，Phoenix 的 meta 表本身也有掛載了 coprocessor，某些特殊情況下，部分操作也會對 meta 表有一定壓力.
SYSTEM.CATALOG
SYSTEM.SEQUENCE
SYSTEM.FUNCTION
SYSTEM.MUTEX
SYSTEM.STATS
特定業務 Group：
用來存放壓力比較大 / 對響應時間有一定要求的表.
公共 Group：
專享的 Group，有了以上隔離方案進行支持，看上去非常完美，是否公共的 Group 就沒有存在必要呢？
經過和用戶的溝通我們發現，有一部分用戶有以下特徵：
資源劃分：部分用戶的請求量比較低，獨立分組至少要 2~3 台機器，如果這種用戶也專門有一個分組，比較浪費 HBase 的存儲和讀寫能力。
響應時間：用來存放對響應時間沒有明確要求的業務表。
這部分用戶放在公共 Group。能比較好的合理利用公共 Group 的資源，使機器提高一定利用率。
五、進一步的優化
特殊 Group 的利用率：
業務專享的 Group 利用率和公共 Group 利用率提升了，但是集群整體排查一遍，運維同事提出 meta 表的兩個 Group請求量日常還是很低，也基本不占用什麼存儲量。這兩個機器和業務表的機器使用相同機型又浪費了。
因此，meta 表的 Group 在和運維同事的共同討論下，我們選擇了存儲量，記憶體都相對小一些的機器。
最終，每個集群減少了 4 台機器的成本。
六、後期管理
監控，報警的增加，發現了哪些問題，如何處理？
專享 Group 的管理
對於重點業務分別進行監控：每個 Group 不同的 Rpc P99 監控、請求量、compact 時長等 metric 的監控，每個業務的 metric 有不同的報警閾值。
嘗試在 RegionServer Group 基礎上改進更多功能.
專享 Group 是比較好統計的，那麼共享 Group 的表如何進行控制，有問題如何進行排查呢？
公共 Group 的管理
信息統計：如果公共池有機器壓力大，如果找到具體的用戶？我們在 RegionServer 端，增加了采樣的 log，輸出一小部分用戶的請求 IP、帳號名、請求類型，請求體大小等信息，來統計用戶行為的占比。
資源限制：增加 Quota 機制進行用戶行為的控制。用戶在接入 HBase 之前會提供自己的請求量峰值，我們在用戶填寫的峰值基礎之上設置 Quota 限制並預留一定 buffer 給用戶。
七、總結
分布式集群在管理時經常遇到資源分配和占用的問題，最好的方案就是進行資源限制和隔離，比如 Hadoop 集群的 Yarn 可以通過 label 進行節點的管理，通過 cgroup 進行記憶體、CPU 等資源的限制。HBase 則是通過 RegionServer Group 和 Quota 來進行隔離和限制。