彌補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 平臺管理方式也在這個過程中進行了進一步升級，開始構建多機房管理的管理方式。
多 IDC 訪問方式
基本架構如上圖所示：
- 業務 HBase 集群分別在多個 IDC 上運行，由業務確定 IDC 機房的主從方式，業務的從 IDC 集群數據通過平臺方的數據同步組件進行數據同步。
- 各 IDC 的 Kubas 服務主要負責對本地 K8S 集群的具體操作，包括 HBase 集群的創建刪除管理，Regionserver 的擴容等 HBase 組件的管理操作，Kubas 服務部署與機房相關，僅對接部署所在機房的 K8S 集群。
- 各 IDC 的 Kubas 服務向集群發現服務上報本機房集群信息，同時更新相關集群主從相關信息。
- 業務方通過平臺方封裝的 ClientSDK 對多機房的 HBase 集群進行訪問，客戶端通過集群發現服務可以確定 HBase 集群的主從關系，從而將相關的讀寫操作分離，寫入修改訪問可以通過客戶端指向主 IDC 的集群。
- 跨機房間的數據同步采用了自研的 HBaseReplicationWALTransfer 來提供增量數據的同步。
數據同步
在各類業務場景中，都存在跨 HBase 集群的數據同步的需求，比如數據在離線 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 等插件的支持。
- 運維檢測自動化。自動對集群擴容，自動熱點檢測以及轉移等。
參考資料：
- [1]知乎基于 Kubernetes 的 Kafka 平臺的設計和實現
https://zhuanlan.zhihu.com/ p/36366473
- [2]知乎容器平臺演進及與大數據融合實踐
- [3]Kubernetes
http://link.zhihu.com/?target=https%3A//kubernetes.io/
- [4]Building online hbase cluster of zhihu based on kubernetes
