[[181835]]

隨著越來越多的業(yè)務(wù)選擇HBase作為存儲引擎，對HBase的可用性要求也越來越高，對于HBase的運維也提出了新的挑戰(zhàn)。目前運維集群超過30+，而且接入的業(yè)務(wù)類型繁多，對于性能要求也不完全一樣，這是今年面臨的問題。從15年開始，結(jié)合京東的業(yè)務(wù)情況，基于大數(shù)據(jù)平臺，實現(xiàn)用戶接入使用全流程自動化。而今年，我們主要從集群層面上提升集群可用性。

1.控制隔離——rsgroup

在94版本中，經(jīng)常困擾我們的一個問題就是集群上的某些機器會因為某些用戶的不恰當(dāng)操作，例如熱點問題，大量的scan操作等導(dǎo)致機器上的其他表正常讀寫受到影響。之前的運維經(jīng)驗，一般的做法就是stop balance，然后通過move region的方式把有影響的表移到某些機器上。由于存在這個原因和業(yè)務(wù)的壓力，往往只能采用拆分集群的方式，在一個HDFS 上往往運行幾個HBase集群，但是帶來的是運維成本的增加。

今年618之前，在我們決定采用新版本之后，我們將HBase 2.0 尚未發(fā)布的rsgroup功能遷移到我們的自己維護的1.1.X版本中，從而實現(xiàn)在HBase集群上隔離和控制。整個架構(gòu)如下：

***我們把分組功能接入了BDP運維平臺。DBA在配置實例的時候，根據(jù)業(yè)務(wù)選擇不同的分組。通過rsgroup 解決拆分集群問題，可運維性也得到了提升。另外，不同于之前的平滑滾動重起，動不動就需要幾天，我們也通過移動分組的方式進行集群滾動從而縮短維護時間。考慮到不同分組的replication可能會產(chǎn)生影響，我們也開發(fā)不同分組的replication功能，主集群的日志只能發(fā)送到備份集群的同一個分組的regionserver中。在集群頁面上，我們也添加不同分組統(tǒng)計，效果如下：

2.異地容災(zāi)——replication

HDFS提供了三個備份的功能，但是對于重要的業(yè)務(wù)還遠遠不夠。HBase本身的replication功能可以實現(xiàn)集群間秒級的數(shù)據(jù)同步，而且整個replication的過程是異步化，對于主集群幾乎沒有影響?？紤]業(yè)務(wù)的重要性，在新版本的集群配置了集群間的主主同步。如果機房出現(xiàn)問題或者主集群異常短時間無法恢復(fù)，那么用戶可以切換到備份集群。

由于采用實例來管理集群，所以DBA配置的時候可以選擇實例是否進行主備以及集群：增加備份集群之后，我們把所有需要抽取的表從主集群改成為備份集群，這樣對于大量的抽取可以減少對主集群的影響。

目前集群的數(shù)據(jù)，除了用戶普通的寫入之外，還有采用bulkload的方式入庫，不同用戶在不同的集市生成HFile導(dǎo)入到HBase中。針對這種情況，我們把2.0 版本的HBASE-13153(Bulk Loaded HFile Replication)打進到我們的版本中，實現(xiàn)了HFile的replication。

最終通過replication實現(xiàn)數(shù)據(jù)的備份和聚合，這樣在用戶申請實例的時候，可以選擇不同的套餐組合。例如只需要實時數(shù)據(jù)存儲，可以選擇主主備份，需要離線分析的可以選擇主備同步到離線分析集群。

3.資源限制——配置quotas

雖然rsgroup 起到了隔離功能，HBase本身讀寫隊列分離，但是同個分組的表還會互相影響，而且京東這么多業(yè)務(wù)部門，不可能都獨立分組。HBase1.0 發(fā)布了一個針對讀寫進行限制的功能——配額管理。使用配額管理做到對namespace和table 的rpc請求的限制，目前是限制讀寫次數(shù)和流量。

這個功能很適合我們，作為底層提供者，很大程度上我們沒有辦法預(yù)估用戶的所有情況，在運維過程中，經(jīng)常有用戶出現(xiàn)熱點問題導(dǎo)致單臺服務(wù)的請求量過高從而影響到了其他表的讀寫。我們針對實例，也就是表空間的請求進行限制，這就需要用戶在申請的時候衡量資源了。

通過配額，我們可以做到對集群的資源整體把控。唯一的遺憾是當(dāng)前HBase的quotas 只能限制單臺的ReginServe。目前配額管理功能在開發(fā)集成自動化配置流程當(dāng)中，預(yù)計年后上線。