HBase 是一個基于 Hadoop 面向列的非關(guān)系型分布式數(shù)據(jù)庫(NoSQL)，設(shè)計概念來源于谷歌的 BigTable 模型。

它面向?qū)崟r讀寫、隨機(jī)訪問大規(guī)模數(shù)據(jù)集的場景，是一個高可靠性、高性能、高伸縮的分布式存儲系統(tǒng)，在大數(shù)據(jù)相關(guān)領(lǐng)域應(yīng)用廣泛。

HBase 系統(tǒng)支持對所存儲的數(shù)據(jù)進(jìn)行透明切分，從而使得系統(tǒng)的存儲以及計算具有良好的水平擴(kuò)展性。

知乎從 2017 年起開始逐漸采用 HBase 系統(tǒng)存儲各類在線業(yè)務(wù)數(shù)據(jù)，并在 HBase 服務(wù)之上構(gòu)建各類應(yīng)用模型以及數(shù)據(jù)計算任務(wù)。

伴隨著知乎這兩年的發(fā)展，知乎核心架構(gòu)團(tuán)隊基于開源容器調(diào)度平臺 Kubernetes 打造了一整套 HBase 服務(wù)平臺管理系統(tǒng)。

經(jīng)過近兩年的研發(fā)迭代，目前已經(jīng)形成了一套較為完整的 HBase 自動化運(yùn)維服務(wù)體系，能夠完成 HBase 集群的快捷部署、平滑擴(kuò)縮容、HBase 組件細(xì)粒度監(jiān)控、故障跟蹤等功能。

知乎對 HBase 的使用經(jīng)驗(yàn)不算太長，在 2017 年初的時候，HBase 服務(wù)主要用于離線算法、推薦、反作弊，還有基礎(chǔ)數(shù)據(jù)倉庫數(shù)據(jù)的存儲計算，通過 MapReduce 和 Spark 來進(jìn)行訪問。

而在當(dāng)時知乎的在線存儲主要采用 MySQL 和 Redis 系統(tǒng)，其中：

• MySQL：支持大部分的業(yè)務(wù)數(shù)據(jù)存儲，當(dāng)數(shù)據(jù)規(guī)模增大后有一些需要進(jìn)行擴(kuò)容的表，分表會帶來一定的復(fù)雜性。

有些業(yè)務(wù)希望能屏蔽這個事情，還有一些是因?yàn)闅v史原因在表設(shè)計的時候用 rmsdb 的形式存了一些本該由列存儲的數(shù)據(jù)，希望做一下遷移。此外 MySQL 基于 SSD，雖然性能很好，花銷也比較大。

• Redis：可以提供大規(guī)模的緩存，也可以提供一定的存儲支持。Redis 性能極好，主要的局限是做數(shù)據(jù) Resharding 較為繁瑣，其次是內(nèi)存成本較高。

針對以上兩種在線存儲所存在的一些問題，我們希望建立一套在線存儲 NoSQL 服務(wù)，對以上兩種存儲作為一個補(bǔ)充。

選型期間我們也考慮過 Cassandra，早期一些業(yè)務(wù)曾嘗試使用 Cassandra 作為存儲。

隔壁團(tuán)隊在運(yùn)維了一段時間的 Cassandra 系統(tǒng)之后，遇到不少的問題，Cassandra 系統(tǒng)可操作性沒有達(dá)到預(yù)期，目前除了 Tracing 相關(guān)的系統(tǒng)，其他業(yè)務(wù)已經(jīng)放棄使用 Cassandra。

我們從已有的離線存儲系統(tǒng)出發(fā)，在衡量了穩(wěn)定性、性能、代碼成熟度、上下游系統(tǒng)承接、業(yè)界使用場景以及社區(qū)活躍度等方面之后，選擇了 HBase，作為知乎在線存儲的支撐組件之一。

HBase On Kubernetes

初期知乎只有一套進(jìn)行離線計算的集群，所有業(yè)務(wù)都跑在一個集群上，并且 HBase 集群和其他離線計算 Yarn 以及 Impala 混合部署，HBase 的日常離線計算和數(shù)據(jù)讀寫都嚴(yán)重受到其他系統(tǒng)影響。

并且 HBase 的監(jiān)控都只停留在主機(jī)層面的監(jiān)控，出現(xiàn)運(yùn)行問題時，進(jìn)行排查很困難，系統(tǒng)恢復(fù)服務(wù)時間較長，這種狀態(tài)下，我們需要重新構(gòu)建一套適用于在線服務(wù)的系統(tǒng)。

在這樣的場景下，我們對在線 HBase 服務(wù)的需求是明確的：

①隔離性：從業(yè)務(wù)方的視角來說，希望相關(guān)的服務(wù)做到環(huán)境隔離，權(quán)限收歸業(yè)務(wù)，避免誤操作和業(yè)務(wù)相互影響。

對于響應(yīng)時間，服務(wù)的可用性，都可以根據(jù)業(yè)務(wù)的需要指定 SLA;對于資源的分配和 blockcache 等參數(shù)的配置也能夠更加有適應(yīng)性，提供業(yè)務(wù)級別的監(jiān)控和報警，快速定位和響應(yīng)問題。

②資源利用率：從運(yùn)維的角度，資源的分配要合理，盡可能的提升主機(jī) CPU，內(nèi)存包括磁盤的有效利用率。

③成本控制：團(tuán)隊用最小的成本去得到最大的運(yùn)維收益，所以需要提供便捷的調(diào)用接口，能夠靈活的進(jìn)行 HBase 集群的申請、擴(kuò)容、管理、監(jiān)控。

同時成本包括機(jī)器資源，還有工程師。當(dāng)時我們線上的這套系統(tǒng)是由一位工程師獨(dú)立去進(jìn)行維護(hù)。

綜合以上需求，參考我們團(tuán)隊之前對基礎(chǔ)設(shè)施平臺化的經(jīng)驗(yàn)，最終的目標(biāo)是把 HBase 服務(wù)做成基礎(chǔ)組件服務(wù)平臺提供給上游業(yè)務(wù)。

這個也是知乎技術(shù)平臺部門工作思路之一，盡可能的把所有的組件對業(yè)務(wù)都黑盒化，接口化，服務(wù)化。

同時在使用和監(jiān)控的粒度上盡可能的準(zhǔn)確，細(xì)致，全面。這是我們構(gòu)建在線 HBase 管理運(yùn)維系統(tǒng)的一個初衷。

Why Kubernetes?

前文說到我們希望將整個 HBase 系統(tǒng)平臺服務(wù)化，那就涉及到如何管理和運(yùn)維 HBase 系統(tǒng)，知乎在微服務(wù)和容器方面的工作積累和經(jīng)驗(yàn)是相當(dāng)豐富的：

• 在當(dāng)時我們所有的在線業(yè)務(wù)都已經(jīng)完成了容器化的遷移工作，超萬級別的業(yè)務(wù)容器平穩(wěn)運(yùn)行在基于 Mesos 的容器管理平臺 Bay 上(參見[1])。
• 與此同時，團(tuán)隊也在積極的做著 Infrastructure 容器化的嘗試，已經(jīng)成功將基礎(chǔ)消息隊列組件 Kafka 容器化運(yùn)行于 Kubernetes 系統(tǒng)之上(參見[2])，因此我們決定也將 HBase 通過 Kubernetes 來進(jìn)行資源的管理調(diào)度。

Kubernetes 是谷歌開源的容器集群管理系統(tǒng)，是 Google 多年大規(guī)模容器管理技術(shù) Borg 的開源版本。

Kubernetes 提供各種維度組件的資源管理和調(diào)度方案，隔離容器的資源使用，各個組件的 HA 工作，同時還有較為完善的網(wǎng)絡(luò)方案。

Kubernetes 被設(shè)計作為構(gòu)建組件和工具的生態(tài)系統(tǒng)平臺，可以輕松地部署、擴(kuò)展和管理應(yīng)用程序。有著 Kubernetes 大法的加持，我們很快有了最初的落地版本([4])。

初代架構(gòu)

最初的落地版本架構(gòu)見下圖，平臺在共享的物理集群上通過 Kubernetes(以下簡稱 K8S)API 建立了多套邏輯上隔離的 HBase 集群。

每套集群由一組 Master 和若干個 Regionserver(以下簡稱 RS)構(gòu)成，集群共享一套 HDFS 存儲集群，各自依賴的 Zookeeper 集群獨(dú)立;集群通過一套管理系統(tǒng) Kubas 服務(wù)來進(jìn)行管理([4])。

 

初代架構(gòu)

模塊定義：在 K8S 中如何去構(gòu)建 HBase 集群，首先需要用 K8S 本身的基礎(chǔ)組件去描述 HBase 的構(gòu)成。

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

• Node：定義主機(jī)節(jié)點(diǎn)，可以是物理機(jī)，也可以是虛擬機(jī);
• Pod：一組緊密關(guān)聯(lián)的容器集合，是 K8S 調(diào)度的基本單位;
• ReplicationController：一組 Pod 的控制器，通過其能夠確保 Pod 的運(yùn)行數(shù)量和健康，并能夠彈性伸縮。

結(jié)合之前 Kafka on K8S 的經(jīng)驗(yàn)，出于高可用和擴(kuò)展性的考慮，我們沒有采用一個 Pod 里帶多個容器的部署方式。

而是統(tǒng)一用一個 ReplicationController 定義一類HBase組件，就是上圖中的 Master，Regionserver 還有按需創(chuàng)建的 Thriftserver。

通過以上概念，我們在 K8S 上就可以這樣定義一套最小 HBase 集群：

• 2*MasterReplicationController
• 3*RegionserverReplicationController
• 2*ThriftserverReplicationController(可選)

高可用以及故障恢復(fù)

作為面向在線業(yè)務(wù)服務(wù)的系統(tǒng)，高可用和故障轉(zhuǎn)移是必需在設(shè)計就要考慮的事情，在整體設(shè)計中，我們分別考慮組件級別、集群級別和數(shù)據(jù)存儲級別的可用性和故障恢復(fù)問題。

①組件級別

HBase 本身已經(jīng)考慮了很多故障切換和恢復(fù)的方案：

• Zookeeper 集群：自身設(shè)計保證了可用性。
• Master：通過多個 Master 注冊在 Zookeeper 集群上來進(jìn)行主節(jié)點(diǎn)的 HA 和更新。
• RegionServer：本身就是無狀態(tài)的，節(jié)點(diǎn)失效下線以后會把上面的 Region 自動遷走，對服務(wù)可用性不會有太大影響。
• Thriftserver：當(dāng)時業(yè)務(wù)大多數(shù)是 Python 和 Golang，通過用 Thrift 對 HBase 的進(jìn)行，Thriftserver 本身是單點(diǎn)的，這里我們通過 HAProxy 來代理一組 Thriftserver 服務(wù)。
• HDFS：本身又由 Namenode 和 DataNode 節(jié)點(diǎn)組成，Namenode 我們開啟 HA 功能，保證了 HDFS 的集群可用性。

②集群級別

關(guān)于集群級別：

• Pod 容器失效：Pod 是通過 Replication Controller 維護(hù)的，K8S 的 Controller Manager 會在它的存儲 etcd 去監(jiān)聽組件的失效情況，如果副本少于預(yù)設(shè)值會自動新的 Pod 容器來進(jìn)行服務(wù)。
• Kubernetes 集群崩潰：該場景曾經(jīng)在生產(chǎn)環(huán)境中出現(xiàn)過，針對這種情況，我們對 SLA 要求較高的業(yè)務(wù)采用了少量物理機(jī)搭配容器的方式進(jìn)行混合部署，極端場景出現(xiàn)時，可以保證重要業(yè)務(wù)受到的影響可控。

③數(shù)據(jù)級別

所有在 K8S 上構(gòu)建的 HBase 集群都共享了一套 HDFS 集群，數(shù)據(jù)的可用性由 HDFS 集群的多副本來提供。

實(shí)現(xiàn)細(xì)節(jié)

資源分配

初期物理節(jié)點(diǎn)統(tǒng)一采用 2*12 核心的 CPU，128G 內(nèi)存和 4T 的磁盤，其中磁盤用于搭建服務(wù)的 HDFS，CPU 和內(nèi)存則在 K8S 環(huán)境中用于建立 HBase 相關(guān)服務(wù)的節(jié)點(diǎn)。

Master 組件的功能主要是管理 HBase 集群，Thriftserver 組件主要承擔(dān)代理的角色，所以這兩個組件資源都按照固定額度分配。

在對 Regionserver 組件進(jìn)行資源分配設(shè)計的時候，考慮兩種方式去定義資源：

 

資源分配方式

按照業(yè)務(wù)需求分配：

• 根據(jù)業(yè)務(wù)方對自身服務(wù)的描述，對相關(guān)的 QPS 以及 SLA 進(jìn)行評估，為業(yè)務(wù)專門配置參數(shù)，包含 Blockcache，Region 大小以及數(shù)量等。
• 優(yōu)點(diǎn)是針對業(yè)務(wù)優(yōu)化，能夠充分的利用資源，降低業(yè)務(wù)的資源占用成本。
• 管理成本增加，需要對每一個業(yè)務(wù)進(jìn)行評估，對平臺維護(hù)人員非常不友好，同時需要業(yè)務(wù)同學(xué)本身對 HBase 有理解。

統(tǒng)一規(guī)格的資源分配：

• CPU 以及 MEM 都按照預(yù)先設(shè)定好的配額來分配，提供多檔的配置，將 CPU 和 MEM 的配置套餐化。
• 方便之處在于業(yè)務(wù)擴(kuò)容時直接增加 Regionserver 的個數(shù)，配置穩(wěn)定，運(yùn)維成本較低，遇到問題時排障方便。
• 針對某些有特有訪問方式的業(yè)務(wù)有局限性，如 CPU 計算型，大 KV 存儲，或者有 MOB 需求的業(yè)務(wù)，需要特殊的定制。
• 介于當(dāng)時考慮接入的在線業(yè)務(wù)并不多，所以采用了按業(yè)務(wù)定制的方式去配置 Regionserver，正式環(huán)境同一業(yè)務(wù)采用統(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/ 

基礎(chǔ)鏡像基于 cdh5.5.0-hbase1.0.0 構(gòu)建：

• 固定的環(huán)境變量，如 JDK_HOME，HBASE_HOME，都通過 ENV 注入到容器鏡像中。
• 與 HDFS 相關(guān)的環(huán)境變量，如 hdfs-site.xml 和 core-site.xml 預(yù)先加入 Docker 鏡像中，構(gòu)建的過程中就放入了 HBase 的相關(guān)目錄中，用以確保 HBase 服務(wù)能夠通過對應(yīng)配置訪問到 HDFS。
• 與 HBase 相關(guān)的配置信息，如組件啟動依賴的 Zookeeper 集群地址， HDFS 數(shù)據(jù)目錄路徑，堆內(nèi)存以及 GC 參數(shù)等，這些配置都需要根據(jù)傳入 KubasService 的信息進(jìn)行對應(yīng)變量的修改。

一個典型的傳入?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)絡(luò)通信

網(wǎng)絡(luò)方面，采用了 Kubernetes 上原生的網(wǎng)絡(luò)模式，每一個 Pod 都有自己的 IP 地址，容器之間可以直接通信。

同時在 Kubernetes 集群中添加了 DNS 自動注冊和反注冊功能，以 Pod 的標(biāo)識名字作為域名，在 Pod 創(chuàng)建和重啟和銷毀時將相關(guān)信息同步全局 DNS。

在這個地方我們遇到過問題，當(dāng)時我們的 DNS 解析不能在 Docker 網(wǎng)絡(luò)環(huán)境中通過 IP 反解出對應(yīng)的容器域名。

這就使得 Regionserver 在啟動之后向 Master 注冊和向 Zookeeper 集群注冊的服務(wù)名字不一致。

導(dǎo)致 Master 中對同一個 Regionserver 登記兩次，造成 Master 與 Regionserver 無法正常通信，整個集群無法正常提供服務(wù)。

經(jīng)過我們對源碼的研究和實(shí)驗(yàn)之后，我們在容器啟動 Regionserver 服務(wù)之前修改 /etc/hosts 文件，將 Kubernetes 對注入的 hostname 信息屏蔽。

這樣的修改讓容器啟動的 HBase 集群能夠順利啟動并初始化成功，但是也給運(yùn)維提升了復(fù)雜度。

因?yàn)楝F(xiàn)在 HBase 提供的 Master 頁現(xiàn)在看到的 Regionserver 都是 IP 形式的記錄，給監(jiān)控和故障處理帶來了諸多不便。

存在問題

初代架構(gòu)順利落地，在成功接入了近十個集群業(yè)務(wù)之后，這套架構(gòu)面臨了以下幾個問題。

管理操作業(yè)務(wù) HBase 集群較為繁瑣：

• 需要手動提前確定 HDFS 集群的存儲，以及申請獨(dú)立 Zookeeper 集群，早期為了省事直接多套 HBase 共享了一套 Zookeeper 集群，這和我們設(shè)計的初衷不符合。
• 容器標(biāo)識符和 HBaseMaster 里注冊的 Regionserver 地址不一致，影響故障定位。
• 單 Regionserver 運(yùn)行在一個單獨(dú)的 Replication Controller(以下簡稱 RC)，但是擴(kuò)容縮容為充分利用 RC 的特性，粗暴的采用增加或減少 RC 的方式進(jìn)行擴(kuò)容縮容。

HBase 配置：

• 最初的設(shè)計缺乏靈活性，與 HBase 服務(wù)配置有關(guān)的 hbase-site.xml 以及 hbase-env.sh 固化在 DockerImage 里，這種情況下，如果需要更新大量配置，則需要重新 build 鏡像。
• 由于最初設(shè)計是共享一套 HDFS 集群作為多 HBase 集群的存儲，所以與 HDFS 有關(guān)的 hdfs-site.xml 和 core-site.xml 配置文件也被直接配置進(jìn)了鏡像。

如果需要在 Kubasservice 中上線依賴其他 HDFS 集群的 HBase，也需要重新構(gòu)建鏡像。

HDFS 隔離：

• 隨著接入 HBase 集群的增多，不同的 HBase 集群業(yè)務(wù)對 HDFS 的 IO 消耗有不同的要求，因此有了分離 HBase 依賴的 HDFS 集群的需求。
• 主要問題源自 Docker 鏡像對相關(guān)配置文件的固化，與 HDFS 有關(guān)的 hdfs-site.xml 和 core-site.xml 配置文件與相關(guān) Docker 鏡像對應(yīng)。

而不同 Docker 鏡像的版本完全由研發(fā)人員自己管理，最初版本的實(shí)現(xiàn)并未考慮到這些問題。

監(jiān)控運(yùn)維：

• 指標(biāo)數(shù)據(jù)不充分，堆內(nèi)堆外內(nèi)存變化，Region 以及 Table 的訪問信息都未有提取或聚合。
• Region 熱點(diǎn)定位較慢，無法在短時間內(nèi)定位到熱點(diǎn) Region。
• 新增或者下線組件只能通過掃 KubasService 的數(shù)據(jù)庫來發(fā)現(xiàn)相關(guān)變更，組件的異常如 RegionServer 掉線或重啟，Master 切換等不能及時反饋。

重構(gòu)

為了進(jìn)一步解決初版架構(gòu)存在的問題，優(yōu)化 HBase 的管控流程，我們重新審視了已有的架構(gòu)。

并結(jié)合 Kubernetes 的新特性，對原有的架構(gòu)進(jìn)行升級改造，重新用 Golang 重寫了整個 Kubas 管理系統(tǒng)的服務(wù)(初版使用了 Python 進(jìn)行開發(fā))。

并在 Kubas 管理系統(tǒng)的基礎(chǔ)上，開發(fā)了多個用于監(jiān)控和運(yùn)維的基礎(chǔ)微服務(wù)，提高了在 Kubernetes 上進(jìn)行 HBase 集群部署的靈活性。

架構(gòu)如下圖所示：

 

二代架構(gòu)圖

Deployment&ConfigMap

Deployment：

• Deployment(部署)是 Kubernetes 中的一個概念，是 Pod 或者 ReplicaSet 的一組更新對象描述，用于取代之前的 ReplicationController。

Deployment 繼承了 ReplicationController 的所有功能，并擁有更多的管理新特性。

• 在新的 Kubas 管理系統(tǒng)中，新設(shè)計用 Deployment 代替 Replication Controller 做 Pod 的管理。

使用一個 Deployment 部署一組 Region Servers 的方式來代替單 Regionserver 對應(yīng)一個 Replication Controller 的設(shè)計，提升集群部署擴(kuò)縮容管理的靈活性。

• 每一組 Deployment 都會注入各類信息維度的標(biāo)簽，如相關(guān)集群的信息，服務(wù)類型，所屬應(yīng)用等。

 

Deployment 部署

ConfigMap：

• ConfigMap 是 Kubernetes 用來存儲配置文件的資源對象，通過 ConfigMap 可以將外部配置在啟動容器之前掛載到容器中的指定位置，并以此為容器中運(yùn)行的程序提供配置信息。
• 重構(gòu)之后管理系統(tǒng)中，所有 HBase 的組件配置都存放至 ConfigMap 之中，系統(tǒng)管理人員會根據(jù)需要預(yù)先生成若干 HBase 的配置模板存放到 K8S 系統(tǒng)的 ConfigMap 中。
• 在業(yè)務(wù)方提供出 HBase 服務(wù)申請時，管理人員通過業(yè)務(wù)資源的需求結(jié)合配置模板，為申請的 HBase 集群組件渲染具體的 hbase-site。
• xml 以及 hbase-env，sh 等 HBase 配置相關(guān)的文件再存放到 ConfigMap 中。
• 最后在容器啟動時，K8S 會根據(jù) Deployment 將 ConfigMap 中的配置文件 Mount 到配置中指定的路徑中。
• 和 Deployment 的操作類似，每一份 ConfigMap 也都會標(biāo)記上標(biāo)簽，將相關(guān)的 ConfigMap 和對應(yīng)的集群和應(yīng)用關(guān)聯(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 集群有關(guān)的組件配置都由該配置模板渲染出具體配置。

config_template 中還預(yù)先約定了 HBase 組件的基礎(chǔ)運(yùn)行配置信息，如組件類型，使用的啟動命令，采用的鏡像文件，初始的副本數(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 功能，在預(yù)先約定的路徑方式存放配置文件信息，同時在真正的 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 

構(gòu)建流程

 

HBase on Kubernetes 構(gòu)建流程

結(jié)合之前對 Deployment 以及 ConfigMap 的引入，以及對 Dockerfile 的修改，整個 HBase 構(gòu)建流程也有了改進(jìn)：

• 編制相關(guān)的 Dockerfile 并構(gòu)建基礎(chǔ)的 HBase 組件鏡像。
• 為將要創(chuàng)建的 HBase 構(gòu)建基礎(chǔ)屬性配置模板，訂制基礎(chǔ)資源，這部分可以通過 KubasAPI 在 Kubernetes 集群中創(chuàng)建 ConfigMap。
• 具體創(chuàng)建部署集群時，通過調(diào)用 KubasAPI，結(jié)合之前構(gòu)建的 ConfigMap 模板，渲染出 HBase 集群中各類組件的詳細(xì) ConfigMap，然后在 Kubernetes 集群中構(gòu)建 Deployment。
• 最終通過之前構(gòu)建好的鏡像加載組件 ConfigMap 中的配置，完成在 KubernetesNode 中運(yùn)行的一個 HBase 組件容器。

通過結(jié)合 K8S 的 ConfigMap 功能的配置模板，以及 KubasAPI 調(diào)用，我們就可以在短時間部署出一套可用的 HBase 最小集群(2 Master + 3 Region Server + 2 Thriftserver)。

在所有宿主機(jī) Host 都已經(jīng)緩存 Docker 鏡像文件的場景下，部署并啟動一整套 HBase 集群的時間不超過 15 秒。

同時在缺少專屬前端控制臺的情況下，可以完全依托 Kubernetesdashboard 完成 HBase 集群組件的擴(kuò)容縮容，以及組件配置的查詢修改更新以及重新部署。

資源控制

在完成重構(gòu)之后，HBase 服務(wù)面向知乎內(nèi)部業(yè)務(wù)進(jìn)行開放，短期內(nèi)知乎 HBase 集群上升超過 30+ 集群。

伴隨著 HBase 集群數(shù)量的增多，有兩個問題逐漸顯現(xiàn)：

• 運(yùn)維成本增高：需要運(yùn)維的集群逐漸增高。
• 資源浪費(fèi)：這是因?yàn)楹芏鄻I(yè)務(wù)的業(yè)務(wù)量并不高，但是為了保證 HBase 的高可用，我們至少需要提供 2 個 Master+3 個 RegionServer，而往往 Master 的負(fù)載都非常低，這就造成了資源浪費(fèi)。

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

優(yōu)化后的架構(gòu)如下：

 

RSGroup 的使用

由于平臺方對業(yè)務(wù) HBase 集群的管理本身就具有隔離性，所以在進(jìn)行更進(jìn)一步資源管理的時候，平臺方采用的是降級的方式來管理 HBase 集群。

通過監(jiān)聽每個單獨(dú)集群的指標(biāo)，如果業(yè)務(wù)集群的負(fù)載在上線一段時間后低于閾值，平臺方就會配合業(yè)務(wù)方，將該 HBase 集群遷移到一套 MixedHBase 集群上。

同時如果在 MixedHBase 集群中運(yùn)行的某個 HBase 業(yè)務(wù)負(fù)載增加，并持續(xù)一段時間超過閾值后，平臺方就會考慮將相關(guān)業(yè)務(wù)提升至單獨(dú)的集群。

多 IDC 優(yōu)化

隨著知乎業(yè)務(wù)的發(fā)展和擴(kuò)大，知乎的基礎(chǔ)架構(gòu)逐漸升級至多機(jī)房架構(gòu)，知乎 HBase 平臺管理方式也在這個過程中進(jìn)行了進(jìn)一步升級，開始構(gòu)建多機(jī)房管理的管理方式。

 

多 IDC 訪問方式

基本架構(gòu)如上圖所示：

• 業(yè)務(wù) HBase 集群分別在多個 IDC 上運(yùn)行，由業(yè)務(wù)確定 IDC 機(jī)房的主從方式，業(yè)務(wù)的從 IDC 集群數(shù)據(jù)通過平臺方的數(shù)據(jù)同步組件進(jìn)行數(shù)據(jù)同步。
• 各 IDC 的 Kubas 服務(wù)主要負(fù)責(zé)對本地 K8S 集群的具體操作，包括 HBase 集群的創(chuàng)建刪除管理，Regionserver 的擴(kuò)容等 HBase 組件的管理操作，Kubas 服務(wù)部署與機(jī)房相關(guān)，僅對接部署所在機(jī)房的 K8S 集群。
• 各 IDC 的 Kubas 服務(wù)向集群發(fā)現(xiàn)服務(wù)上報本機(jī)房集群信息，同時更新相關(guān)集群主從相關(guān)信息。
• 業(yè)務(wù)方通過平臺方封裝的 ClientSDK 對多機(jī)房的 HBase 集群進(jìn)行訪問，客戶端通過集群發(fā)現(xiàn)服務(wù)可以確定 HBase 集群的主從關(guān)系，從而將相關(guān)的讀寫操作分離，寫入修改訪問可以通過客戶端指向主 IDC 的集群。
• 跨機(jī)房間的數(shù)據(jù)同步采用了自研的 HBaseReplicationWALTransfer 來提供增量數(shù)據(jù)的同步。

數(shù)據(jù)同步

在各類業(yè)務(wù)場景中，都存在跨 HBase 集群的數(shù)據(jù)同步的需求，比如數(shù)據(jù)在離線 HBase 集群和在線集群同步、多 IDC 集群數(shù)據(jù)同步等，對于 HBase 的數(shù)據(jù)同步來說，分為全量復(fù)制和增量復(fù)制兩種方式。

 

HBase 數(shù)據(jù)同步

在知乎 HBase 平臺中，我們采用兩種方式進(jìn)行 HBase 集群間的數(shù)據(jù)同步：

• HBase Snapshot。全量數(shù)據(jù)復(fù)制我們采用了 HBaseSnapshot 的方式進(jìn)行;主要應(yīng)用在離線數(shù)據(jù)同步在線數(shù)據(jù)的場景。
• WALTransfer。主要用于 HBase 集群之間的的增量數(shù)據(jù)同步;增量復(fù)制我們沒有采用 HBaseReplication，相關(guān)同步方式我們通過自研的 WALTransfer 組件來對 HBase 數(shù)據(jù)進(jìn)行增量同步。

WALTransfer 通過讀取源數(shù)據(jù) HBase 集群提供 WAL 文件列表，于 HDFS 集群中定位對應(yīng)的 WAL 文件，將 HBase 的增量數(shù)據(jù)按序?qū)懭氲侥康募骸?/p>

監(jiān)控

從之前重構(gòu)后的架構(gòu)圖上我們可以看到，在 Kubas 服務(wù)中我們添加了很多模塊，這些模塊基本屬于 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 準(zhǔn)確和缺失次數(shù)。
• Blockcache 的信息，例如 Blockcache 中使用多少、空閑多少、累計的缺失率等。
• 讀寫請求的統(tǒng)計信息，例如：讀寫的表分布、讀寫數(shù)據(jù)量、讀寫失敗次數(shù)等。
• Compact 與 Split 的操作信息，例如隊列的長度、操作次數(shù)和時間等。
• Handler的信息，例如隊列長度、處于活躍 Handler 的數(shù)量以及活躍的 Reader 數(shù)量。

其他維度的指標(biāo)如容器 CPU 以及 Mem 占用來自 Kubernetes 平臺監(jiān)控，磁盤 IO，磁盤占用等來自主機(jī)監(jiān)控：

 

HBase 部分監(jiān)控

Kubas-Region-Inspector 組件

采集 HBase 表 Region 信息，通過 HBaseAPI 接口，獲取每個 HBaseRegion 的數(shù)據(jù)統(tǒng)計信息，并將 Region 數(shù)據(jù)聚合成數(shù)據(jù)表信息。

通過調(diào)用開源組件形成 HBase 集群 Region 分布的圖表，對 Region 熱點(diǎn)進(jìn)行定位。

 

HBaseRegion 分布監(jiān)控

通過以上模塊采集的監(jiān)控信息，基本可以描述在 Kubernetes 上運(yùn)行的 HBase 集群的狀態(tài)信息，并能夠輔助運(yùn)維管理人員對故障進(jìn)行定位排除。

Future Work

隨著公司業(yè)務(wù)的快速發(fā)展，知乎的 HBase 平臺業(yè)務(wù)同時也在不斷的迭代優(yōu)化。

短期內(nèi)我們會從以下幾個方向進(jìn)一步提升知乎 HBase 平臺的管理服務(wù)能力：

• 提升集群安全穩(wěn)定性。加入 HBase 權(quán)限支持，進(jìn)一步提升多租戶訪問下的安全隔離性。
• 用戶集群構(gòu)建定制化。通過提供用戶數(shù)據(jù)管理系統(tǒng)，向業(yè)務(wù)用戶開放 HBase 構(gòu)建接口，這樣業(yè)務(wù)用戶可以自行構(gòu)建 HBase 集群，添加 Phoniex 等插件的支持。
• 運(yùn)維檢測自動化。自動對集群擴(kuò)容，自動熱點(diǎn)檢測以及轉(zhuǎn)移等。

參考資料：

• [1]知乎基于 Kubernetes 的 Kafka 平臺的設(shè)計和實(shí)現(xiàn)

https://zhuanlan.zhihu.com/ p/36366473

• [2]知乎容器平臺演進(jìn)及與大數(shù)據(jù)融合實(shí)踐
• [3]Kubernetes

http://link.zhihu.com/?target=https%3A//kubernetes.io/

• [4]Building online hbase cluster of zhihu based on kubernetes