彌補MySQL和Redis短板：看HBase怎麼確保高可用

HBase 是一個基於 Hadoop 面向列的非關係型分佈式數據庫（NoSQL），設計概念來源於谷歌的 BigTable 模型。

它面向實時讀寫、隨機訪問大規模數據集的場景，是一個高可靠性、高性能、高伸縮的分佈式存儲系統，在大數據相關領域應用普遍。

HBase 系統支持對所存儲的數據進行透明切分，從而使得系統的存儲以及計算具備良好的水平擴展性。

知乎從 2017 年起開始逐漸採用 HBase 系統存儲各種在線業務數據，並在 HBase 服務之上構建各種應用模型以及數據計算任務。

伴隨着知乎這兩年的發展，知乎核心架構團隊基於開源容器調度平臺 Kubernetes 打造了一整套 HBase 服務平臺管理系統。

通過近兩年的研發迭代，目前已經造成了一套較爲完整的 HBase 自動化運維服務體系，可以完成 HBase 集羣的快捷部署、平滑擴縮容、HBase 組件細粒度監控、故障跟蹤等功能。

知乎對 HBase 的使用經驗不算太長，在 2017 年初的時候，HBase 服務主要用於離線算法、推薦、反做弊，還有基礎數據倉庫數據的存儲計算，經過 MapReduce 和 Spark 來進行訪問。

而在當時知乎的在線存儲主要採用 MySQL 和 Redis 系統，其中：

• MySQL：支持大部分的業務數據存儲，當數據規模增大後有一些須要進行擴容的表，分表會帶來必定的複雜性。

  有些業務但願能屏蔽這個事情，還有一些是由於歷史緣由在表設計的時候用 rmsdb 的形式存了一些本該由列存儲的數據，但願作一下遷移。此外 MySQL 基於 SSD，雖然性能很好，花銷也比較大。

• Redis：能夠提供大規模的緩存，也能夠提供必定的存儲支持。Redis 性能極好，主要的侷限是作數據 Resharding 較爲繁瑣，其次是內存成本較高。

針對以上兩種在線存儲所存在的一些問題，咱們但願創建一套在線存儲 NoSQL 服務，對以上兩種存儲做爲一個補充。

選型期間咱們也考慮過 Cassandra，早期一些業務曾嘗試使用 Cassandra 做爲存儲。

隔壁團隊在運維了一段時間的 Cassandra 系統以後，遇到很多的問題，Cassandra 系統可操做性沒有達到預期，目前除了 Tracing 相關的系統，其餘業務已經放棄使用 Cassandra。

咱們從已有的離線存儲系統出發，在衡量了穩定性、性能、代碼成熟度、上下游系統承接、業界使用場景以及社區活躍度等方面以後，選擇了 HBase，做爲知乎在線存儲的支撐組件之一。

HBase On Kubernetes

初期知乎只有一套進行離線計算的集羣，全部業務都跑在一個集羣上，而且 HBase 集羣和其餘離線計算 Yarn 以及 Impala 混合部署，HBase 的平常離線計算和數據讀寫都嚴重受到其餘系統影響。

而且 HBase 的監控都只停留在主機層面的監控，出現運行問題時，進行排查很困難，系統恢復服務時間較長，這種狀態下，咱們須要從新構建一套適用於在線服務的系統。

在這樣的場景下，咱們對在線 HBase 服務的需求是明確的：

①隔離性：從業務方的視角來講，但願相關的服務作到環境隔離，權限收歸業務，避免誤操做和業務相互影響。

對於響應時間，服務的可用性，均可以根據業務的須要指定 SLA；對於資源的分配和 blockcache 等參數的配置也可以更加有適應性，提供業務級別的監控和報警，快速定位和響應問題。

②資源利用率：從運維的角度，資源的分配要合理，儘量的提高主機 CPU，內存包括磁盤的有效利用率。

③成本控制：團隊用最小的成本去獲得最大的運維收益，因此須要提供便捷的調用接口，可以靈活的進行 HBase 集羣的申請、擴容、管理、監控。

同時成本包括機器資源，還有工程師。當時咱們線上的這套系統是由一位工程師獨立去進行維護。

綜合以上需求，參考咱們團隊以前對基礎設施平臺化的經驗，最終的目標是把 HBase 服務作成基礎組件服務平臺提供給上游業務。

這個也是知乎技術平臺部門工做思路之一，儘量的把全部的組件對業務都黑盒化，接口化，服務化。

同時在使用和監控的粒度上儘量的準確，細緻，全面。這是咱們構建在線 HBase 管理運維繫統的一個初衷。

Why Kubernetes?

前文說到咱們但願將整個 HBase 系統平臺服務化，那就涉及到如何管理和運維 HBase 系統，知乎在微服務和容器方面的工做積累和經驗是至關豐富的：

• 在當時咱們全部的在線業務都已經完成了容器化的遷移工做，超萬級別的業務容器平穩運行在基於 Mesos 的容器管理平臺 Bay 上（參見[1]）。

• 與此同時，團隊也在積極的作着 Infrastructure 容器化的嘗試，已經成功將基礎消息隊列組件 Kafka 容器化運行於 Kubernetes 系統之上（參見[2]），所以咱們決定也將 HBase 經過 Kubernetes 來進行資源的管理調度。

Kubernetes 是谷歌開源的容器集羣管理系統，是 Google 多年大規模容器管理技術 Borg 的開源版本。

Kubernetes 提供各類維度組件的資源管理和調度方案，隔離容器的資源使用，各個組件的 HA 工做，同時還有較爲完善的網絡方案。

Kubernetes 被設計做爲構建組件和工具的生態系統平臺，能夠輕鬆地部署、擴展和管理應用程序。有着 Kubernetes 大法的加持，咱們很快有了最初的落地版本（[4]）。

初代架構

最初的落地版本架構見下圖，平臺在共享的物理集羣上經過 Kubernetes（如下簡稱 K8S）API 創建了多套邏輯上隔離的 HBase 集羣。

每套集羣由一組 Master 和若干個 Regionserver（如下簡稱 RS）構成，集羣共享一套 HDFS 存儲集羣，各自依賴的 Zookeeper 集羣獨立；集羣經過一套管理系統 Kubas 服務來進行管理（[4]）。

第一代架構

模塊定義：在 K8S 中如何去構建 HBase 集羣，首先須要用 K8S 自己的基礎組件去描述 HBase 的構成。

K8S 的資源組件有如下幾種：

• Node：定義主機節點，能夠是物理機，也能夠是虛擬機；

• Pod：一組緊密關聯的容器集合，是 K8S 調度的基本單位；

• ReplicationController：一組 Pod 的控制器，經過其可以確保 Pod 的運行數量和健康，並可以彈性伸縮。

結合以前 Kafka on K8S 的經驗，出於高可用和擴展性的考慮，咱們沒有采用一個 Pod 裏帶多個容器的部署方式。

而是統一用一個 ReplicationController 定義一類HBase組件，就是上圖中的 Master，Regionserver 還有按需建立的 Thriftserver。

經過以上概念，咱們在 K8S 上就能夠這樣定義一套最小 HBase 集羣：

• 2*MasterReplicationController

• 3*RegionserverReplicationController

• 2*ThriftserverReplicationController（可選）

高可用以及故障恢復

做爲面向在線業務服務的系統，高可用和故障轉移是必需在設計就要考慮的事情，在總體設計中，咱們分別考慮組件級別、集羣級別和數據存儲級別的可用性和故障恢復問題。

①組件級別

HBase 自己已經考慮了不少故障切換和恢復的方案：

• Zookeeper 集羣：自身設計保證了可用性。

• Master：經過多個 Master 註冊在 Zookeeper 集羣上來進行主節點的 HA 和更新。

• RegionServer：自己就是無狀態的，節點失效下線之後會把上面的 Region 自動遷走，對服務可用性不會有太大影響。

• Thriftserver：當時業務大多數是 Python 和 Golang，經過用 Thrift 對 HBase 的進行，Thriftserver 自己是單點的，這裏咱們經過 HAProxy 來代理一組 Thriftserver 服務。

• HDFS：自己又由 Namenode 和 DataNode 節點組成，Namenode 咱們開啓 HA 功能，保證了 HDFS 的集羣可用性。

②集羣級別

關於集羣級別：

• Pod 容器失效：Pod 是經過 Replication Controller 維護的，K8S 的 Controller Manager 會在它的存儲 etcd 去監聽組件的失效狀況，若是副本少於預設值會自動新的 Pod 容器來進行服務。

• Kubernetes 集羣崩潰：該場景曾經在生產環境中出現過，針對這種狀況，咱們對 SLA 要求較高的業務採用了少許物理機搭配容器的方式進行混合部署，極端場景出現時，能夠保證重要業務受到的影響可控。

③數據級別

全部在 K8S 上構建的 HBase 集羣都共享了一套 HDFS 集羣，數據的可用性由 HDFS 集羣的多副原本提供。

實現細節

資源分配

初期物理節點統一採用 2*12 核心的 CPU，128G 內存和 4T 的磁盤，其中磁盤用於搭建服務的 HDFS，CPU 和內存則在 K8S 環境中用於創建 HBase 相關服務的節點。

Master 組件的功能主要是管理 HBase 集羣，Thriftserver 組件主要承擔代理的角色，因此這兩個組件資源都按照固定額度分配。

在對 Regionserver 組件進行資源分配設計的時候，考慮兩種方式去定義資源：

資源分配方式

按照業務需求分配：

• 根據業務方對自身服務的描述，對相關的 QPS 以及 SLA 進行評估，爲業務專門配置參數，包含 Blockcache，Region 大小以及數量等。

• 優勢是針對業務優化，可以充分的利用資源，下降業務的資源佔用成本。

• 管理成本增長，須要對每個業務進行評估，對平臺維護人員很是不友好，同時須要業務同窗自己對 HBase 有理解。

統一規格的資源分配：

• CPU 以及 MEM 都按照預先設定好的配額來分配，提供多檔的配置，將 CPU 和 MEM 的配置套餐化。

• 方便之處在於業務擴容時直接增長 Regionserver 的個數，配置穩定，運維成本較低，遇到問題時排障方便。

• 針對某些有特有訪問方式的業務有侷限性，如 CPU 計算型，大 KV 存儲，或者有 MOB 需求的業務，須要特殊的定製。

• 介於當時考慮接入的在線業務並很少，因此採用了按業務定製的方式去配置 Regionserver，正式環境同一業務採用統一配置的一組 Regionserver，不存在混合配置的 Regionserver 組。

參數配置

# Example for hbase dockerfile 
# install cdh5.5.0-hbase1.0.0
ADD hdfs-site.xml /usr/lib/hbase/conf/
ADD core-site.xml /usr/lib/hbase/conf/
ADD env-init.py /usr/lib/hbase/bin/
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
ENV HBASE_HOME /usr/lib/hbase
ENV HADOOP_PREFIX /usr/lib/hadoop
ADD env-init.py /usr/lib/hbase/bin/
ADD hadoop_xml_conf.sh /usr/lib/hbase/bin/

基礎鏡像基於 cdh5.5.0-hbase1.0.0 構建：

• 固定的環境變量，如 JDK_HOME，HBASE_HOME，都經過 ENV 注入到容器鏡像中。

• 與 HDFS 相關的環境變量，如 hdfs-site.xml 和 core-site.xml 預先加入 Docker 鏡像中，構建的過程當中就放入了 HBase 的相關目錄中，用以確保 HBase 服務可以經過對應配置訪問到 HDFS。

• 與 HBase 相關的配置信息，如組件啓動依賴的 Zookeeper 集羣地址， HDFS 數據目錄路徑，堆內存以及 GC 參數等，這些配置都須要根據傳入 KubasService 的信息進行對應變量的修改。

一個典型的傳入參數示例：

REQUEST_DATA = {
       "name": 'test-cluster',
       "rootdir": "hdfs://namenode01:8020/tmp/hbase/test-cluster",
       "zkparent": "/test-cluster",
       "zkhost": "zookeeper01,zookeeper02,zookeeper03",
       "zkport": 2181,
       "regionserver_num": '3',
       "codecs": "snappy",
       "client_type": "java",
       "cpu": '1',
       "memory": '30',
       "status": "running",
}

經過上面的參數 KubasService 啓動 Docker 時，在啓動命令中利用 hadoop_xml_conf.sh 和 env-init.py 修改 hbase-site.xml 和 hbase-env.sh 文件來完成最後的配置注入，以下所示：

source /usr/lib/hbase/bin/hadoop_xml_conf.sh
&& put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.regionserver.codecs --value snappy
&& put_config --file /etc/hbase/conf/hbase-site.xml --property zookeeper.znode.parent --value /test-cluster
&& put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.rootdir --value hdfs://namenode01:8020/tmp/hbase/test-cluster
&& put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.zookeeper.quorum --value zookeeper01,zookeeper02,zookeeper03
&& put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.zookeeper.property.clientPort --value 2181
&& service hbase-regionserver start && tail -f /var/log/hbase/hbase-hbase-regionserver.log

網絡通訊

網絡方面，採用了 Kubernetes 上原生的網絡模式，每個 Pod 都有本身的 IP 地址，容器之間能夠直接通訊。

同時在 Kubernetes 集羣中添加了 DNS 自動註冊和反註冊功能，以 Pod 的標識名字做爲域名，在 Pod 建立和重啓和銷燬時將相關信息同步全局 DNS。

在這個地方咱們遇到過問題，當時咱們的 DNS 解析不能在 Docker 網絡環境中經過 IP 反解出對應的容器域名。

這就使得 Regionserver 在啓動以後向 Master 註冊和向 Zookeeper 集羣註冊的服務名字不一致。

致使 Master 中對同一個 Regionserver 登記兩次，形成 Master 與 Regionserver 沒法正常通訊，整個集羣沒法正常提供服務。

通過咱們對源碼的研究和實驗以後，咱們在容器啓動 Regionserver 服務以前修改 /etc/hosts 文件，將 Kubernetes 對注入的 hostname 信息屏蔽。

這樣的修改讓容器啓動的 HBase 集羣可以順利啓動並初始化成功，可是也給運維提高了複雜度。

由於如今 HBase 提供的 Master 頁如今看到的 Regionserver 都是 IP 形式的記錄，給監控和故障處理帶來了諸多不便。

存在問題

初代架構順利落地，在成功接入了近十個集羣業務以後，這套架構面臨瞭如下幾個問題。

管理操做業務 HBase 集羣較爲繁瑣：

• 須要手動提早肯定 HDFS 集羣的存儲，以及申請獨立 Zookeeper 集羣，早期爲了省事直接多套 HBase 共享了一套 Zookeeper 集羣，這和咱們設計的初衷不符合。

• 容器標識符和 HBaseMaster 裏註冊的 Regionserver 地址不一致，影響故障定位。

• 單 Regionserver 運行在一個單獨的 Replication Controller（如下簡稱 RC），可是擴容縮容爲充分利用 RC 的特性，粗暴的採用增長或減小 RC 的方式進行擴容縮容。

HBase 配置：

• 最初的設計缺少靈活性，與 HBase 服務配置有關的 hbase-site.xml 以及 hbase-env.sh 固化在 DockerImage 裏，這種狀況下，若是須要更新大量配置，則須要從新 build 鏡像。

• 因爲最初設計是共享一套 HDFS 集羣做爲多 HBase 集羣的存儲，因此與 HDFS 有關的 hdfs-site.xml 和 core-site.xml 配置文件也被直接配置進了鏡像。

  若是須要在 Kubasservice 中上線依賴其餘 HDFS 集羣的 HBase，也須要從新構建鏡像。

HDFS 隔離：

• 隨着接入 HBase 集羣的增多，不一樣的 HBase 集羣業務對 HDFS 的 IO 消耗有不一樣的要求，所以有了分離 HBase 依賴的 HDFS 集羣的需求。

• 主要問題源自 Docker 鏡像對相關配置文件的固化，與 HDFS 有關的 hdfs-site.xml 和 core-site.xml 配置文件與相關 Docker 鏡像對應。

  而不一樣 Docker 鏡像的版本徹底由研發人員本身管理，最第一版本的實現並未考慮到這些問題。

監控運維：

• 指標數據不充分，堆內堆外內存變化，Region 以及 Table 的訪問信息都未有提取或聚合。

• Region 熱點定位較慢，沒法在短期內定位到熱點 Region。

• 新增或者下線組件只能經過掃 KubasService 的數據庫來發現相關變動，組件的異常如 RegionServer 掉線或重啓，Master 切換等不能及時反饋。

重構

爲了進一步解決第一版架構存在的問題，優化 HBase 的管控流程，咱們從新審視了已有的架構。

並結合 Kubernetes 的新特性，對原有的架構進行升級改造，從新用 Golang 重寫了整個 Kubas 管理系統的服務（第一版使用了 Python 進行開發）。

並在 Kubas 管理系統的基礎上，開發了多個用於監控和運維的基礎微服務，提升了在 Kubernetes 上進行 HBase 集羣部署的靈活性。

架構以下圖所示：

二代架構圖

Deployment&ConfigMap

Deployment：

• Deployment（部署）是 Kubernetes 中的一個概念，是 Pod 或者 ReplicaSet 的一組更新對象描述，用於取代以前的 ReplicationController。

  Deployment 繼承了 ReplicationController 的全部功能，並擁有更多的管理新特性。

• 在新的 Kubas 管理系統中，新設計用 Deployment 代替 Replication Controller 作 Pod 的管理。

  使用一個 Deployment 部署一組 Region Servers 的方式來代替單 Regionserver 對應一個 Replication Controller 的設計，提高集羣部署擴縮容管理的靈活性。

• 每一組 Deployment 都會注入各種信息維度的標籤，如相關集羣的信息，服務類型，所屬應用等。

Deployment 部署

ConfigMap：

• ConfigMap 是 Kubernetes 用來存儲配置文件的資源對象，經過 ConfigMap 能夠將外部配置在啓動容器以前掛載到容器中的指定位置，並以此爲容器中運行的程序提供配置信息。

• 重構以後管理系統中，全部 HBase 的組件配置都存放至 ConfigMap 之中，系統管理人員會根據須要預先生成若干 HBase 的配置模板存放到 K8S 系統的 ConfigMap 中。

• 在業務方提供出 HBase 服務申請時，管理人員經過業務資源的需求結合配置模板，爲申請的 HBase 集羣組件渲染具體的 hbase-site。

  xml 以及 hbase-env，sh 等 HBase 配置相關的文件再存放到 ConfigMap 中。

• 最後在容器啓動時，K8S 會根據 Deployment 將 ConfigMap 中的配置文件 Mount 到配置中指定的路徑中。

• 和 Deployment 的操做相似，每一份 ConfigMap 也都會標記上標籤，將相關的 ConfigMap 和對應的集羣和應用關聯上。

ConfigMap 存檔

組件參數配置

在引入了 ConfigMap 功能以後，以前建立集羣的請求信息也隨之改變：

RequestData
{
  "name": "performance-test-rmwl",
  "namespace": "online",
  "app": "kubas",
  "config_template": "online-example-base.v1",
  "status": "Ready",
  "properties": {
    "hbase.regionserver.codecs": "snappy",
    "hbase.rootdir": "hdfs://zhihu-example-online:8020/user/online-tsn/performance-test-rmwl",
    "hbase.zookeeper.property.clientPort": "2181",
    "hbase.zookeeper.quorum": "zookeeper01,zookeeper02,zookeeper03",
    "zookeeper.znode.parent": "/performance-test-rmwl"
  },
  "client_type": "java",
  "cluster_uid": "k8s-example-hbase---performance-test-rmwl---example"
}

其中 config_template 指定了該集羣使用的配置信息模板，以後全部和該 HBase 集羣有關的組件配置都由該配置模板渲染出具體配置。

config_template 中還預先約定了 HBase 組件的基礎運行配置信息，如組件類型，使用的啓動命令，採用的鏡像文件，初始的副本數等。

servers:
{
  "master": {
    "servertype": "master",
    "command": "service hbase-master start && tail -f /var/log/hbase/hbase-hbase-master.log",
    "replicas": 1,
    "image": "dockerimage.zhihu.example/apps/example-master:v1.1",
    "requests": {
      "cpu": "500m",
      "memory": "5Gi"
    },
    "limits": {
      "cpu": "4000m"
    }
  },
}

Docker 鏡像文件配合 ConfigMap 功能，在預先約定的路徑方式存放配置文件信息，同時在真正的 HBase 配置路徑中加入軟鏈文件。

RUN mkdir -p /data/hbase/hbase-site
RUN mv /etc/hbase/conf/hbase-site.xml /data/hbase/hbase-site/hbase-site.xml
RUN ln -s /data/hbase/hbase-site/hbase-site.xml /etc/hbase/conf/hbase-site.xml
RUN mkdir -p /data/hbase/hbase-env
RUN mv /etc/hbase/conf/hbase-env.sh /data/hbase/hbase-env/hbase-env.sh
RUN ln -s /data/hbase/hbase-env/hbase-env.sh /etc/hbase/conf/hbase-env.sh

構建流程

HBase on Kubernetes 構建流程

結合以前對 Deployment 以及 ConfigMap 的引入，以及對 Dockerfile 的修改，整個 HBase 構建流程也有了改進：

• 編制相關的 Dockerfile 並構建基礎的 HBase 組件鏡像。

• 爲將要建立的 HBase 構建基礎屬性配置模板，訂製基礎資源，這部分能夠經過 KubasAPI 在 Kubernetes 集羣中建立 ConfigMap。

• 具體建立部署集羣時，經過調用 KubasAPI，結合以前構建的 ConfigMap 模板，渲染出 HBase 集羣中各種組件的詳細 ConfigMap，而後在 Kubernetes 集羣中構建 Deployment。

• 最終經過以前構建好的鏡像加載組件 ConfigMap 中的配置，完成在 KubernetesNode 中運行的一個 HBase 組件容器。

經過結合 K8S 的 ConfigMap 功能的配置模板，以及 KubasAPI 調用，咱們就能夠在短期部署出一套可用的 HBase 最小集羣（2 Master + 3 Region Server + 2 Thriftserver）。

在全部宿主機 Host 都已經緩存 Docker 鏡像文件的場景下，部署並啓動一整套 HBase 集羣的時間不超過 15 秒。

同時在缺乏專屬前端控制檯的狀況下，能夠徹底依託 Kubernetesdashboard 完成 HBase 集羣組件的擴容縮容，以及組件配置的查詢修改更新以及從新部署。

資源控制

在完成重構以後，HBase 服務面向知乎內部業務進行開放，短時間內知乎 HBase 集羣上升超過 30+ 集羣。

伴隨着 HBase 集羣數量的增多，有兩個問題逐漸顯現：

• 運維成本增高：須要運維的集羣逐漸增高。

• 資源浪費：這是由於不少業務的業務量並不高，可是爲了保證 HBase 的高可用，咱們至少須要提供 2 個 Master+3 個 RegionServer，而每每 Master 的負載都很是低，這就形成了資源浪費。

爲了解決如上的兩個問題，同時又不能打破資源隔離的需求，咱們將 HBaseRSGroup 功能加入到了 HBase 平臺的管理系統中。

優化後的架構以下：

RSGroup 的使用

因爲平臺方對業務 HBase 集羣的管理自己就具備隔離性，因此在進行更進一步資源管理的時候，平臺方採用的是降級的方式來管理 HBase 集羣。

經過監聽每一個單獨集羣的指標，若是業務集羣的負載在上線一段時間後低於閾值，平臺方就會配合業務方，將該 HBase 集羣遷移到一套 MixedHBase 集羣上。

同時若是在 MixedHBase 集羣中運行的某個 HBase 業務負載增長，並持續一段時間超過閾值後，平臺方就會考慮將相關業務提高至單獨的集羣。

多 IDC 優化

隨着知乎業務的發展和擴大，知乎的基礎架構逐漸升級至多機房架構，知乎 HBase 平臺管理方式也在這個過程當中進行了進一步升級，開始構建多機房管理的管理方式。

HBase 數據同步

在知乎 HBase 平臺中，咱們採用兩種方式進行 HBase 集羣間的數據同步：

• HBase Snapshot。全量數據複製咱們採用了 HBaseSnapshot 的方式進行；主要應用在離線數據同步在線數據的場景。

• WALTransfer。主要用於 HBase 集羣之間的的增量數據同步；增量複製咱們沒有采用 HBaseReplication，相關同步方式咱們經過自研的 WALTransfer 組件來對 HBase 數據進行增量同步。

WALTransfer 經過讀取源數據 HBase 集羣提供 WAL 文件列表，於 HDFS 集羣中定位對應的 WAL 文件，將 HBase 的增量數據按序寫入到目的集羣。

監控

從以前重構後的架構圖上咱們能夠看到，在 Kubas 服務中咱們添加了不少模塊，這些模塊基本屬於 HBase 平臺的監控管理模塊。

Kubas-Monitor 組件

基本的監控模塊，採用輪詢的方式發現新增 HBase 集羣，經過訂閱 Zookeeper 集羣發現 HBase 集羣 Master 以及 Regionserver 組。

採集 Regionserver Metric 中的數據，主要採集數據包括：

• Region 的信息，上線 Region 數量，Store 的數量、Storefile 的大小、Storefileindex 的大小，讀取時 Memstore 命中的次數和缺失次數。

• Blockcache 的信息，例如 Blockcache 中使用多少、空閒多少、累計的缺失率、命中率等。

• 讀寫請求的統計信息，例如最大最小讀寫響應時間，讀寫的表分佈、讀寫數據量、讀寫失敗次數等。

• Compact 與 Split 的操做信息，例如隊列的長度、操做次數和時間等。

• Handler的信息，例如隊列長度、處於活躍 Handler 的數量以及活躍的 Reader 數量。

其餘維度的指標如容器 CPU 以及 Mem 佔用來自 Kubernetes 平臺監控，磁盤 IO，磁盤佔用等來自主機監控：

HBase 部分監控

Kubas-Region-Inspector 組件

採集 HBase 表 Region 信息，經過 HBaseAPI 接口，獲取每一個 HBaseRegion 的數據統計信息，並將 Region 數據聚合成數據表信息。

經過調用開源組件造成 HBase 集羣 Region 分佈的圖表，對 Region 熱點進行定位。

HBaseRegion 分佈監控

經過以上模塊採集的監控信息，基本能夠描述在 Kubernetes 上運行的 HBase 集羣的狀態信息，並可以輔助運維管理人員對故障進行定位排除。

Future Work

隨着公司業務的快速發展，知乎的 HBase 平臺業務同時也在不斷的迭代優化。

短時間內咱們會從如下幾個方向進一步提高知乎 HBase 平臺的管理服務能力：

• 提高集羣安全穩定性。加入 HBase 權限支持，進一步提高多租戶訪問下的安全隔離性。

• 用戶集羣構建定製化。經過提供用戶數據管理系統，向業務用戶開放 HBase 構建接口，這樣業務用戶能夠自行構建 HBase 集羣，添加 Phoniex 等插件的支持。

• 運維檢測自動化。自動對集羣擴容，自動熱點檢測以及轉移等。