彌補MySQL和Redis短板：看HBase怎么確保高可用
HBase 是一個基于 Hadoop 面向列的非關系型分布式數(shù)據(jù)庫(NoSQL)，設計概念來源于谷歌的 BigTable 模型。
它面向實時讀寫、隨機訪問大規(guī)模數(shù)據(jù)集的場景，是一個高可靠性、高性能、高伸縮的分布式存儲系統(tǒng)，在大數(shù)據(jù)相關領域應用廣泛。
HBase 系統(tǒng)支持對所存儲的數(shù)據(jù)進行透明切分，從而使得系統(tǒng)的存儲以及計算具有良好的水平擴展性。
知乎從 2017 年起開始逐漸采用 HBase 系統(tǒng)存儲各類在線業(yè)務數(shù)據(jù)，并在 HBase 服務之上構建各類應用模型以及數(shù)據(jù)計算任務。
伴隨著知乎這兩年的發(fā)展，知乎核心架構團隊基于開源容器調度平臺 Kubernetes 打造了一整套 HBase 服務平臺管理系統(tǒng)。
經(jīng)過近兩年的研發(fā)迭代，目前已經(jīng)形成了一套較為完整的 HBase 自動化運維服務體系，能夠完成 HBase 集群的快捷部署、平滑擴縮容、HBase 組件細粒度監(jiān)控、故障跟蹤等功能。
知乎對 HBase 的使用經(jīng)驗不算太長，在 2017 年初的時候，HBase 服務主要用于離線算法、推薦、反作弊，還有基礎數(shù)據(jù)倉庫數(shù)據(jù)的存儲計算，通過 MapReduce 和 Spark 來進行訪問。
而在當時知乎的在線存儲主要采用 MySQL 和 Redis 系統(tǒng)，其中：
- MySQL：支持大部分的業(yè)務數(shù)據(jù)存儲，當數(shù)據(jù)規(guī)模增大后有一些需要進行擴容的表，分表會帶來一定的復雜性。
有些業(yè)務希望能屏蔽這個事情，還有一些是因為歷史原因在表設計的時候用 rmsdb 的形式存了一些本該由列存儲的數(shù)據(jù)，希望做一下遷移。此外 MySQL 基于 SSD，雖然性能很好，花銷也比較大。
- Redis：可以提供大規(guī)模的緩存，也可以提供一定的存儲支持。Redis 性能極好，主要的局限是做數(shù)據(jù) Resharding 較為繁瑣，其次是內存成本較高。
針對以上兩種在線存儲所存在的一些問題，我們希望建立一套在線存儲 NoSQL 服務，對以上兩種存儲作為一個補充。
選型期間我們也考慮過 Cassandra，早期一些業(yè)務曾嘗試使用 Cassandra 作為存儲。
隔壁團隊在運維了一段時間的 Cassandra 系統(tǒng)之后，遇到不少的問題，Cassandra 系統(tǒng)可操作性沒有達到預期，目前除了 Tracing 相關的系統(tǒng)，其他業(yè)務已經(jīng)放棄使用 Cassandra。
我們從已有的離線存儲系統(tǒng)出發(fā)，在衡量了穩(wěn)定性、性能、代碼成熟度、上下游系統(tǒng)承接、業(yè)界使用場景以及社區(qū)活躍度等方面之后，選擇了 HBase，作為知乎在線存儲的支撐組件之一。
HBase On Kubernetes
初期知乎只有一套進行離線計算的集群，所有業(yè)務都跑在一個集群上，并且 HBase 集群和其他離線計算 Yarn 以及 Impala 混合部署，HBase 的日常離線計算和數(shù)據(jù)讀寫都嚴重受到其他系統(tǒng)影響。
并且 HBase 的監(jiān)控都只停留在主機層面的監(jiān)控，出現(xiàn)運行問題時，進行排查很困難，系統(tǒng)恢復服務時間較長，這種狀態(tài)下，我們需要重新構建一套適用于在線服務的系統(tǒng)。
在這樣的場景下，我們對在線 HBase 服務的需求是明確的：
①隔離性：從業(yè)務方的視角來說，希望相關的服務做到環(huán)境隔離，權限收歸業(yè)務，避免誤操作和業(yè)務相互影響。
對于響應時間，服務的可用性，都可以根據(jù)業(yè)務的需要指定 SLA;對于資源的分配和 blockcache 等參數(shù)的配置也能夠更加有適應性，提供業(yè)務級別的監(jiān)控和報警，快速定位和響應問題。
②資源利用率：從運維的角度，資源的分配要合理，盡可能的提升主機 CPU，內存包括磁盤的有效利用率。
③成本控制：團隊用最小的成本去得到最大的運維收益，所以需要提供便捷的調用接口，能夠靈活的進行 HBase 集群的申請、擴容、管理、監(jiān)控。
同時成本包括機器資源，還有工程師。當時我們線上的這套系統(tǒng)是由一位工程師獨立去進行維護。
綜合以上需求，參考我們團隊之前對基礎設施平臺化的經(jīng)驗，最終的目標是把 HBase 服務做成基礎組件服務平臺提供給上游業(yè)務。
這個也是知乎技術平臺部門工作思路之一，盡可能的把所有的組件對業(yè)務都黑盒化，接口化，服務化。
同時在使用和監(jiān)控的粒度上盡可能的準確，細致，全面。這是我們構建在線 HBase 管理運維系統(tǒng)的一個初衷。
Why Kubernetes?
前文說到我們希望將整個 HBase 系統(tǒng)平臺服務化，那就涉及到如何管理和運維 HBase 系統(tǒng)，知乎在微服務和容器方面的工作積累和經(jīng)驗是相當豐富的：
- 在當時我們所有的在線業(yè)務都已經(jīng)完成了容器化的遷移工作，超萬級別的業(yè)務容器平穩(wěn)運行在基于 Mesos 的容器管理平臺 Bay 上(參見[1])。
- 與此同時，團隊也在積極的做著 Infrastructure 容器化的嘗試，已經(jīng)成功將基礎消息隊列組件 Kafka 容器化運行于 Kubernetes 系統(tǒng)之上(參見[2])，因此我們決定也將 HBase 通過 Kubernetes 來進行資源的管理調度。
Kubernetes 是谷歌開源的容器集群管理系統(tǒng)，是 Google 多年大規(guī)模容器管理技術 Borg 的開源版本。
Kubernetes 提供各種維度組件的資源管理和調度方案，隔離容器的資源使用，各個組件的 HA 工作，同時還有較為完善的網(wǎng)絡方案。
Kubernetes 被設計作為構建組件和工具的生態(tài)系統(tǒng)平臺，可以輕松地部署、擴展和管理應用程序。有著 Kubernetes 大法的加持，我們很快有了最初的落地版本([4])。
初代架構
最初的落地版本架構見下圖，平臺在共享的物理集群上通過 Kubernetes(以下簡稱 K8S)API 建立了多套邏輯上隔離的 HBase 集群。
每套集群由一組 Master 和若干個 Regionserver(以下簡稱 RS)構成，集群共享一套 HDFS 存儲集群，各自依賴的 Zookeeper 集群獨立;集群通過一套管理系統(tǒng) Kubas 服務來進行管理([4])。
初代架構
模塊定義：在 K8S 中如何去構建 HBase 集群，首先需要用 K8S 本身的基礎組件去描述 HBase 的構成。
K8S 的資源組件有以下幾種：
- Node：定義主機節(jié)點，可以是物理機，也可以是虛擬機;
- Pod：一組緊密關聯(lián)的容器集合，是 K8S 調度的基本單位;
- ReplicationController：一組 Pod 的控制器，通過其能夠確保 Pod 的運行數(shù)量和健康，并能夠彈性伸縮。
結合之前 Kafka on K8S 的經(jīng)驗，出于高可用和擴展性的考慮，我們沒有采用一個 Pod 里帶多個容器的部署方式。
而是統(tǒng)一用一個 ReplicationController 定義一類HBase組件，就是上圖中的 Master，Regionserver 還有按需創(chuàng)建的 Thriftserver。
通過以上概念，我們在 K8S 上就可以這樣定義一套最小 HBase 集群：
- 2*MasterReplicationController
- 3*RegionserverReplicationController
- 2*ThriftserverReplicationController(可選)
高可用以及故障恢復
作為面向在線業(yè)務服務的系統(tǒng)，高可用和故障轉移是必需在設計就要考慮的事情，在整體設計中，我們分別考慮組件級別、集群級別和數(shù)據(jù)存儲級別的可用性和故障恢復問題。
①組件級別
HBase 本身已經(jīng)考慮了很多故障切換和恢復的方案：
- Zookeeper 集群：自身設計保證了可用性。
- Master：通過多個 Master 注冊在 Zookeeper 集群上來進行主節(jié)點的 HA 和更新。
- RegionServer：本身就是無狀態(tài)的，節(jié)點失效下線以后會把上面的 Region 自動遷走，對服務可用性不會有太大影響。
- Thriftserver：當時業(yè)務大多數(shù)是 Python 和 Golang，通過用 Thrift 對 HBase 的進行，Thriftserver 本身是單點的，這里我們通過 HAProxy 來代理一組 Thriftserver 服務。
- HDFS：本身又由 Namenode 和 DataNode 節(jié)點組成，Namenode 我們開啟 HA 功能，保證了 HDFS 的集群可用性。
②集群級別
關于集群級別：
- Pod 容器失效：Pod 是通過 Replication Controller 維護的，K8S 的 Controller Manager 會在它的存儲 etcd 去監(jiān)聽組件的失效情況，如果副本少于預設值會自動新的 Pod 容器來進行服務。
- Kubernetes 集群崩潰：該場景曾經(jīng)在生產環(huán)境中出現(xiàn)過，針對這種情況，我們對 SLA 要求較高的業(yè)務采用了少量物理機搭配容器的方式進行混合部署，極端場景出現(xiàn)時，可以保證重要業(yè)務受到的影響可控。
③數(shù)據(jù)級別
所有在 K8S 上構建的 HBase 集群都共享了一套 HDFS 集群，數(shù)據(jù)的可用性由 HDFS 集群的多副本來提供。
實現(xiàn)細節(jié)
資源分配
初期物理節(jié)點統(tǒng)一采用 2*12 核心的 CPU，128G 內存和 4T 的磁盤，其中磁盤用于搭建服務的 HDFS，CPU 和內存則在 K8S 環(huán)境中用于建立 HBase 相關服務的節(jié)點。
Master 組件的功能主要是管理 HBase 集群，Thriftserver 組件主要承擔代理的角色，所以這兩個組件資源都按照固定額度分配。
在對 Regionserver 組件進行資源分配設計的時候，考慮兩種方式去定義資源：
資源分配方式
按照業(yè)務需求分配：
- 根據(jù)業(yè)務方對自身服務的描述，對相關的 QPS 以及 SLA 進行評估，為業(yè)務專門配置參數(shù)，包含 Blockcache，Region 大小以及數(shù)量等。
- 優(yōu)點是針對業(yè)務優(yōu)化，能夠充分的利用資源，降低業(yè)務的資源占用成本。
- 管理成本增加，需要對每一個業(yè)務進行評估，對平臺維護人員非常不友好，同時需要業(yè)務同學本身對 HBase 有理解。
統(tǒng)一規(guī)格的資源分配：
- CPU 以及 MEM 都按照預先設定好的配額來分配，提供多檔的配置，將 CPU 和 MEM 的配置套餐化。
- 方便之處在于業(yè)務擴容時直接增加 Regionserver 的個數(shù)，配置穩(wěn)定，運維成本較低，遇到問題時排障方便。
- 針對某些有特有訪問方式的業(yè)務有局限性，如 CPU 計算型，大 KV 存儲，或者有 MOB 需求的業(yè)務，需要特殊的定制。
- 介于當時考慮接入的在線業(yè)務并不多，所以采用了按業(yè)務定制的方式去配置 Regionserver，正式環(huán)境同一業(yè)務采用統(tǒng)一配置的一組 Regionserver，不存在混合配置的 Regionserver 組。
參數(shù)配置
- # 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 構建：
- 固定的環(huán)境變量，如 JDK_HOME，HBASE_HOME，都通過 ENV 注入到容器鏡像中。
- 與 HDFS 相關的環(huán)境變量，如 hdfs-site.xml 和 core-site.xml 預先加入 Docker 鏡像中，構建的過程中就放入了 HBase 的相關目錄中，用以確保 HBase 服務能夠通過對應配置訪問到 HDFS。
- 與 HBase 相關的配置信息，如組件啟動依賴的 Zookeeper 集群地址， HDFS 數(shù)據(jù)目錄路徑，堆內存以及 GC 參數(shù)等，這些配置都需要根據(jù)傳入 KubasService 的信息進行對應變量的修改。
一個典型的傳入?yún)?shù)示例：
- 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",
- }
通過上面的參數(shù) 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
網(wǎng)絡通信
網(wǎng)絡方面，采用了 Kubernetes 上原生的網(wǎng)絡模式，每一個 Pod 都有自己的 IP 地址，容器之間可以直接通信。
同時在 Kubernetes 集群中添加了 DNS 自動注冊和反注冊功能，以 Pod 的標識名字作為域名，在 Pod 創(chuàng)建和重啟和銷毀時將相關信息同步全局 DNS。
在這個地方我們遇到過問題，當時我們的 DNS 解析不能在 Docker 網(wǎng)絡環(huán)境中通過 IP 反解出對應的容器域名。
這就使得 Regionserver 在啟動之后向 Master 注冊和向 Zookeeper 集群注冊的服務名字不一致。
導致 Master 中對同一個 Regionserver 登記兩次，造成 Master 與 Regionserver 無法正常通信，整個集群無法正常提供服務。
經(jīng)過我們對源碼的研究和實驗之后，我們在容器啟動 Regionserver 服務之前修改 /etc/hosts 文件，將 Kubernetes 對注入的 hostname 信息屏蔽。
這樣的修改讓容器啟動的 HBase 集群能夠順利啟動并初始化成功，但是也給運維提升了復雜度。
因為現(xiàn)在 HBase 提供的 Master 頁現(xiàn)在看到的 Regionserver 都是 IP 形式的記錄，給監(jiān)控和故障處理帶來了諸多不便。
存在問題
初代架構順利落地，在成功接入了近十個集群業(yè)務之后，這套架構面臨了以下幾個問題。
管理操作業(yè)務 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 集群業(yè)務對 HDFS 的 IO 消耗有不同的要求，因此有了分離 HBase 依賴的 HDFS 集群的需求。
- 主要問題源自 Docker 鏡像對相關配置文件的固化，與 HDFS 有關的 hdfs-site.xml 和 core-site.xml 配置文件與相關 Docker 鏡像對應。
而不同 Docker 鏡像的版本完全由研發(fā)人員自己管理，最初版本的實現(xiàn)并未考慮到這些問題。
監(jiān)控運維：
- 指標數(shù)據(jù)不充分，堆內堆外內存變化，Region 以及 Table 的訪問信息都未有提取或聚合。
- Region 熱點定位較慢，無法在短時間內定位到熱點 Region。
- 新增或者下線組件只能通過掃 KubasService 的數(shù)據(jù)庫來發(fā)現(xiàn)相關變更，組件的異常如 RegionServer 掉線或重啟，Master 切換等不能及時反饋。
重構
為了進一步解決初版架構存在的問題，優(yōu)化 HBase 的管控流程，我們重新審視了已有的架構。
并結合 Kubernetes 的新特性，對原有的架構進行升級改造，重新用 Golang 重寫了整個 Kubas 管理系統(tǒng)的服務(初版使用了 Python 進行開發(fā))。
并在 Kubas 管理系統(tǒng)的基礎上，開發(fā)了多個用于監(jiān)控和運維的基礎微服務，提高了在 Kubernetes 上進行 HBase 集群部署的靈活性。
架構如下圖所示：
二代架構圖
Deployment&ConfigMap
Deployment：
- Deployment(部署)是 Kubernetes 中的一個概念，是 Pod 或者 ReplicaSet 的一組更新對象描述，用于取代之前的 ReplicationController。
Deployment 繼承了 ReplicationController 的所有功能，并擁有更多的管理新特性。
- 在新的 Kubas 管理系統(tǒng)中，新設計用 Deployment 代替 Replication Controller 做 Pod 的管理。
使用一個 Deployment 部署一組 Region Servers 的方式來代替單 Regionserver 對應一個 Replication Controller 的設計，提升集群部署擴縮容管理的靈活性。
- 每一組 Deployment 都會注入各類信息維度的標簽，如相關集群的信息，服務類型，所屬應用等。
Deployment 部署
ConfigMap：
- ConfigMap 是 Kubernetes 用來存儲配置文件的資源對象，通過 ConfigMap 可以將外部配置在啟動容器之前掛載到容器中的指定位置，并以此為容器中運行的程序提供配置信息。
- 重構之后管理系統(tǒng)中，所有 HBase 的組件配置都存放至 ConfigMap 之中，系統(tǒng)管理人員會根據(jù)需要預先生成若干 HBase 的配置模板存放到 K8S 系統(tǒng)的 ConfigMap 中。
- 在業(yè)務方提供出 HBase 服務申請時，管理人員通過業(yè)務資源的需求結合配置模板，為申請的 HBase 集群組件渲染具體的 hbase-site。
- xml 以及 hbase-env，sh 等 HBase 配置相關的文件再存放到 ConfigMap 中。
- 最后在容器啟動時，K8S 會根據(jù) Deployment 將 ConfigMap 中的配置文件 Mount 到配置中指定的路徑中。
- 和 Deployment 的操作類似，每一份 ConfigMap 也都會標記上標簽，將相關的 ConfigMap 和對應的集群和應用關聯(lián)上。
ConfigMap 存檔
組件參數(shù)配置
在引入了 ConfigMap 功能之后，之前創(chuàng)建集群的請求信息也隨之改變：
- 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 組件的基礎運行配置信息，如組件類型，使用的啟動命令，采用的鏡像文件，初始的副本數(shù)等。
- 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 組件鏡像。
- 為將要創(chuàng)建的 HBase 構建基礎屬性配置模板，訂制基礎資源，這部分可以通過 KubasAPI 在 Kubernetes 集群中創(chuàng)建 ConfigMap。
- 具體創(chuàng)建部署集群時，通過調用 KubasAPI，結合之前構建的 ConfigMap 模板，渲染出 HBase 集群中各類組件的詳細 ConfigMap，然后在 Kubernetes 集群中構建 Deployment。
- 最終通過之前構建好的鏡像加載組件 ConfigMap 中的配置，完成在 KubernetesNode 中運行的一個 HBase 組件容器。
通過結合 K8S 的 ConfigMap 功能的配置模板，以及 KubasAPI 調用，我們就可以在短時間部署出一套可用的 HBase 最小集群(2 Master + 3 Region Server + 2 Thriftserver)。
在所有宿主機 Host 都已經(jīng)緩存 Docker 鏡像文件的場景下，部署并啟動一整套 HBase 集群的時間不超過 15 秒。
同時在缺少專屬前端控制臺的情況下，可以完全依托 Kubernetesdashboard 完成 HBase 集群組件的擴容縮容，以及組件配置的查詢修改更新以及重新部署。
資源控制
在完成重構之后，HBase 服務面向知乎內部業(yè)務進行開放，短期內知乎 HBase 集群上升超過 30+ 集群。
伴隨著 HBase 集群數(shù)量的增多，有兩個問題逐漸顯現(xiàn)：
- 運維成本增高：需要運維的集群逐漸增高。
- 資源浪費：這是因為很多業(yè)務的業(yè)務量并不高，但是為了保證 HBase 的高可用，我們至少需要提供 2 個 Master+3 個 RegionServer，而往往 Master 的負載都非常低，這就造成了資源浪費。
為了解決如上的兩個問題，同時又不能打破資源隔離的需求，我們將 HBaseRSGroup 功能加入到了 HBase 平臺的管理系統(tǒng)中。
優(yōu)化后的架構如下：
RSGroup 的使用
由于平臺方對業(yè)務 HBase 集群的管理本身就具有隔離性，所以在進行更進一步資源管理的時候，平臺方采用的是降級的方式來管理 HBase 集群。
通過監(jiān)聽每個單獨集群的指標，如果業(yè)務集群的負載在上線一段時間后低于閾值，平臺方就會配合業(yè)務方，將該 HBase 集群遷移到一套 MixedHBase 集群上。
同時如果在 MixedHBase 集群中運行的某個 HBase 業(yè)務負載增加，并持續(xù)一段時間超過閾值后，平臺方就會考慮將相關業(yè)務提升至單獨的集群。
多 IDC 優(yōu)化
隨著知乎業(yè)務的發(fā)展和擴大，知乎的基礎架構逐漸升級至多機房架構，知乎 HBase 平臺管理方式也在這個過程中進行了進一步升級，開始構建多機房管理的管理方式。
多 IDC 訪問方式
基本架構如上圖所示：
- 業(yè)務 HBase 集群分別在多個 IDC 上運行，由業(yè)務確定 IDC 機房的主從方式，業(yè)務的從 IDC 集群數(shù)據(jù)通過平臺方的數(shù)據(jù)同步組件進行數(shù)據(jù)同步。
- 各 IDC 的 Kubas 服務主要負責對本地 K8S 集群的具體操作，包括 HBase 集群的創(chuàng)建刪除管理，Regionserver 的擴容等 HBase 組件的管理操作，Kubas 服務部署與機房相關，僅對接部署所在機房的 K8S 集群。
- 各 IDC 的 Kubas 服務向集群發(fā)現(xiàn)服務上報本機房集群信息，同時更新相關集群主從相關信息。
- 業(yè)務方通過平臺方封裝的 ClientSDK 對多機房的 HBase 集群進行訪問，客戶端通過集群發(fā)現(xiàn)服務可以確定 HBase 集群的主從關系，從而將相關的讀寫操作分離，寫入修改訪問可以通過客戶端指向主 IDC 的集群。
- 跨機房間的數(shù)據(jù)同步采用了自研的 HBaseReplicationWALTransfer 來提供增量數(shù)據(jù)的同步。
數(shù)據(jù)同步
在各類業(yè)務場景中，都存在跨 HBase 集群的數(shù)據(jù)同步的需求，比如數(shù)據(jù)在離線 HBase 集群和在線集群同步、多 IDC 集群數(shù)據(jù)同步等，對于 HBase 的數(shù)據(jù)同步來說，分為全量復制和增量復制兩種方式。
HBase 數(shù)據(jù)同步
在知乎 HBase 平臺中，我們采用兩種方式進行 HBase 集群間的數(shù)據(jù)同步：
- HBase Snapshot。全量數(shù)據(jù)復制我們采用了 HBaseSnapshot 的方式進行;主要應用在離線數(shù)據(jù)同步在線數(shù)據(jù)的場景。
- WALTransfer。主要用于 HBase 集群之間的的增量數(shù)據(jù)同步;增量復制我們沒有采用 HBaseReplication，相關同步方式我們通過自研的 WALTransfer 組件來對 HBase 數(shù)據(jù)進行增量同步。
WALTransfer 通過讀取源數(shù)據(jù) HBase 集群提供 WAL 文件列表，于 HDFS 集群中定位對應的 WAL 文件，將 HBase 的增量數(shù)據(jù)按序寫入到目的集群。
監(jiān)控
從之前重構后的架構圖上我們可以看到，在 Kubas 服務中我們添加了很多模塊，這些模塊基本屬于 HBase 平臺的監(jiān)控管理模塊。
Kubas-Monitor 組件
基本的監(jiān)控模塊，采用輪詢的方式發(fā)現(xiàn)新增 HBase 集群，通過訂閱 Zookeeper 集群發(fā)現(xiàn) HBase 集群 Master 以及 Regionserver 組。
采集 Regionserver Metric 中的數(shù)據(jù)，主要采集數(shù)據(jù)包括：
- Region 的信息，上線 Region 數(shù)量，Store 的數(shù)量、Storefile 的大小、Storefileindex 的大小，讀取時 Memstore 準確和缺失次數(shù)。
- Blockcache 的信息，例如 Blockcache 中使用多少、空閑多少、累計的缺失率等。
- 讀寫請求的統(tǒng)計信息，例如：讀寫的表分布、讀寫數(shù)據(jù)量、讀寫失敗次數(shù)等。
- Compact 與 Split 的操作信息，例如隊列的長度、操作次數(shù)和時間等。
- Handler的信息，例如隊列長度、處于活躍 Handler 的數(shù)量以及活躍的 Reader 數(shù)量。
其他維度的指標如容器 CPU 以及 Mem 占用來自 Kubernetes 平臺監(jiān)控，磁盤 IO，磁盤占用等來自主機監(jiān)控：
HBase 部分監(jiān)控
Kubas-Region-Inspector 組件
采集 HBase 表 Region 信息，通過 HBaseAPI 接口，獲取每個 HBaseRegion 的數(shù)據(jù)統(tǒng)計信息，并將 Region 數(shù)據(jù)聚合成數(shù)據(jù)表信息。
通過調用開源組件形成 HBase 集群 Region 分布的圖表，對 Region 熱點進行定位。
HBaseRegion 分布監(jiān)控
通過以上模塊采集的監(jiān)控信息，基本可以描述在 Kubernetes 上運行的 HBase 集群的狀態(tài)信息，并能夠輔助運維管理人員對故障進行定位排除。
Future Work
隨著公司業(yè)務的快速發(fā)展，知乎的 HBase 平臺業(yè)務同時也在不斷的迭代優(yōu)化。
短期內我們會從以下幾個方向進一步提升知乎 HBase 平臺的管理服務能力：
- 提升集群安全穩(wěn)定性。加入 HBase 權限支持，進一步提升多租戶訪問下的安全隔離性。
- 用戶集群構建定制化。通過提供用戶數(shù)據(jù)管理系統(tǒng)，向業(yè)務用戶開放 HBase 構建接口，這樣業(yè)務用戶可以自行構建 HBase 集群，添加 Phoniex 等插件的支持。
- 運維檢測自動化。自動對集群擴容，自動熱點檢測以及轉移等。
參考資料：
- [1]知乎基于 Kubernetes 的 Kafka 平臺的設計和實現(xiàn)
https://zhuanlan.zhihu.com/ p/36366473
- [2]知乎容器平臺演進及與大數(shù)據(jù)融合實踐
- [3]Kubernetes
http://link.zhihu.com/?target=https%3A//kubernetes.io/
- [4]Building online hbase cluster of zhihu based on kubernetes
