HBase是一個(gè)基于Hadoop面向列的非關(guān)系型分布式數(shù)據(jù)庫(kù)(NoSQL)，設(shè)計(jì)概念來(lái)源于谷歌的BigTable模型，面向?qū)崟r(shí)讀寫(xiě)、隨機(jī)訪(fǎng)問(wèn)大規(guī)模數(shù)據(jù)集的場(chǎng)景，是一個(gè)高可靠性、高性能、高伸縮的分布式存儲(chǔ)系統(tǒng)，在大數(shù)據(jù)相關(guān)領(lǐng)域應(yīng)用廣泛。

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

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

• 伴隨著知乎這兩年的發(fā)展，知乎核心架構(gòu)團(tuán)隊(duì)基于開(kāi)源容器調(diào)度平臺(tái)Kubernetes打造了一整套HBase服務(wù)平臺(tái)管理系統(tǒng);
• 經(jīng)過(guò)近兩年的研發(fā)迭代，目前已經(jīng)形成了一套較為完整的HBase自動(dòng)化運(yùn)維服務(wù)體系，能夠完成HBase集群的快捷部署、平滑擴(kuò)縮容、HBase組件細(xì)粒度監(jiān)控、故障跟蹤等功能。

背景

知乎對(duì)HBase的使用經(jīng)驗(yàn)不算太長(zhǎng)，在2017年初的時(shí)候，HBase服務(wù)主要用于離線(xiàn)算法、推薦、反作弊，還有基礎(chǔ)數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)的存儲(chǔ)計(jì)算，通過(guò)MapReduce和Spark來(lái)進(jìn)行訪(fǎng)問(wèn)。而在當(dāng)時(shí)知乎的在線(xiàn)存儲(chǔ)主要采用MySQL和Redis系統(tǒng)，其中：

• MySQL：支持大部分的業(yè)務(wù)數(shù)據(jù)存儲(chǔ)，當(dāng)數(shù)據(jù)規(guī)模增大后有一些需要進(jìn)行擴(kuò)容的表，分表會(huì)帶來(lái)一定的復(fù)雜性，有些業(yè)務(wù)希望能屏蔽這個(gè)事情，還有一些是因?yàn)闅v史原因在表設(shè)計(jì)的時(shí)候用rmsdb的形式存了一些本該由列存儲(chǔ)的數(shù)據(jù)，希望做一下遷移。此外MySQL基于SSD，雖然性能很好，花銷(xiāo)也比較大;
• Redis：可以提供大規(guī)模的緩存，也可以提供一定的存儲(chǔ)支持。Redis性能極好，主要的局限是做數(shù)據(jù)Resharding較為繁瑣，其次是內(nèi)存成本較高。

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

選型期間我們也考慮過(guò)Cassandra，早期一些業(yè)務(wù)曾嘗試使用Cassandra作為存儲(chǔ)，隔壁團(tuán)隊(duì)在運(yùn)維了一段時(shí)間的Cassandra系統(tǒng)之后，遇到不少的問(wèn)題，Cassandra系統(tǒng)可操作性沒(méi)有達(dá)到預(yù)期，目前除了Tracing相關(guān)的系統(tǒng)，其他業(yè)務(wù)已經(jīng)放棄使用Cassandra。

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

一、HBase On Kubernetes

• 初期知乎只有一套進(jìn)行離線(xiàn)計(jì)算的集群，所有業(yè)務(wù)都跑在一個(gè)集群上，并且HBase集群和其他離線(xiàn)計(jì)算yarn以及Impala混合部署，HBase的日常離線(xiàn)計(jì)算和數(shù)據(jù)讀寫(xiě)都嚴(yán)重受到其他系統(tǒng)影響;
• 并且HBase的監(jiān)控都只停留在主機(jī)層面的監(jiān)控，出現(xiàn)運(yùn)行問(wèn)題時(shí)，進(jìn)行排查很困難，系統(tǒng)恢復(fù)服務(wù)時(shí)間較長(zhǎng)，這種狀態(tài)下，我們需要重新構(gòu)建一套適用于在線(xiàn)服務(wù)的系統(tǒng)。

在這樣的場(chǎng)景下，我們對(duì)在線(xiàn)HBase服務(wù)的需求是明確的：

隔離性

• 從業(yè)務(wù)方的視角來(lái)說(shuō)，希望相關(guān)的服務(wù)做到環(huán)境隔離，權(quán)限收歸業(yè)務(wù)，避免誤操作和業(yè)務(wù)相互影響;
• 對(duì)于響應(yīng)時(shí)間，服務(wù)的可用性，都可以根據(jù)業(yè)務(wù)的需要指定SLA;
• 對(duì)于資源的分配和blockcache等參數(shù)的配置也能夠更加有適應(yīng)性，提供業(yè)務(wù)級(jí)別的監(jiān)控和報(bào)警，快速定位和響應(yīng)問(wèn)題;

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

成本控制：團(tuán)隊(duì)用最小的成本去得到相對(duì)較大的運(yùn)維收益，所以需要提供便捷的調(diào)用接口，能夠靈活的進(jìn)行HBase集群的申請(qǐng)、擴(kuò)容、管理、監(jiān)控。同時(shí)成本包括機(jī)器資源，還有工程師。當(dāng)時(shí)我們線(xiàn)上的這套系統(tǒng)是由一位工程師獨(dú)立去進(jìn)行維護(hù)。

綜合以上需求，參考我們團(tuán)隊(duì)之前對(duì)基礎(chǔ)設(shè)施平臺(tái)化的經(jīng)驗(yàn)，最終的目標(biāo)是把HBase服務(wù)做成基礎(chǔ)組件服務(wù)平臺(tái)向提供給上游業(yè)務(wù)，這個(gè)也是知乎技術(shù)平臺(tái)部門(mén)工作思路之一，盡可能的把所有的組件對(duì)業(yè)務(wù)都黑盒化，接口化，服務(wù)化。同時(shí)在使用和監(jiān)控的粒度上盡可能的準(zhǔn)確，細(xì)致，全面。這是我們構(gòu)建在線(xiàn)HBase管理運(yùn)維系統(tǒng)的一個(gè)初衷。

二、Why Kubernetes?

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

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

Kubernetes[3]是谷歌開(kāi)源的容器集群管理系統(tǒng)，是Google多年大規(guī)模容器管理技術(shù)Borg的開(kāi)源版本。Kubernetes提供各種維度組件的資源管理和調(diào)度方案，隔離容器的資源使用，各個(gè)組件的HA工作，同時(shí)還有較為完善的網(wǎng)絡(luò)方案。

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

三、初代

最初的落地版本架構(gòu)見(jiàn)下圖，平臺(tái)在共享的物理集群上通過(guò)Kubernetes(以下簡(jiǎn)稱(chēng)K8S)API建立了多套邏輯上隔離的HBase集群，每套集群由一組Master和若干個(gè)Regionserver(以下簡(jiǎn)稱(chēng)RS)構(gòu)成，集群共享一套HDFS存儲(chǔ)集群，各自依賴(lài)的Zookeeper集群獨(dú)立;集群通過(guò)一套管理系統(tǒng)Kubas服務(wù)來(lái)進(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的控制器，通過(guò)其能夠確保pod的運(yùn)行數(shù)量和健康，并能夠彈性伸縮。

結(jié)合之前Kafka on K8S的經(jīng)驗(yàn)，出于高可用和擴(kuò)展性的考慮，我們沒(méi)有采用一個(gè)Pod里帶多個(gè)容器的部署方式，統(tǒng)一用一個(gè)ReplicationController定義一類(lèi)HBase組件，就是上圖中的Master，Regionserver還有按需創(chuàng)建的Thriftserver;通過(guò)以上概念，我們?cè)贙8S上就可以這樣定義一套最小HBase集群：

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

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

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

1、組件級(jí)別

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

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

2、集群級(jí)別

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

3、數(shù)據(jù)級(jí)別

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

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

1、資源分配

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

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

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

資源分配方式

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

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

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

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

2、參數(shù)配置

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

# 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/ 

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

通過(guò)上面的參數(shù)KubasService啟動(dòng)Docker時(shí)，在啟動(dòng)命令中利用hadoop_xml_conf.sh和env-init.py修改hbase-site.xml和hbase-env.sh來(lái)完成配置注入，如下所示：

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 

3、網(wǎng)絡(luò)通信

網(wǎng)絡(luò)方面，采用了Kubernetes上原生的網(wǎng)絡(luò)模式，每一個(gè)Pod都有自己的IP地址，容器之間可以直接通信，同時(shí)在Kubernetes集群中添加了DNS自動(dòng)注冊(cè)和反注冊(cè)功能，以Pod的標(biāo)識(shí)名字作為域名，在Pod創(chuàng)建和重啟和銷(xiāo)毀時(shí)將相關(guān)信息同步全局DNS。

在這個(gè)地方我們遇到過(guò)問(wèn)題，當(dāng)時(shí)我們的DNS解析不能在Docker網(wǎng)絡(luò)環(huán)境中通過(guò)IP反解出對(duì)應(yīng)的容器域名，這就使得Regionserver在啟動(dòng)之后向Master注冊(cè)和向Zookeeper集群注冊(cè)的服務(wù)名字不一致，導(dǎo)致Master中對(duì)同一個(gè)Regionserver登記兩次，造成Master與Regionserver無(wú)法正常通信，整個(gè)集群無(wú)法正常提供服務(wù)。

經(jīng)過(guò)我們對(duì)源碼的研究和實(shí)驗(yàn)之后，我們?cè)谌萜鲉?dòng)Regionserver服務(wù)之前修改/etc/hosts文件，將Kubernetes對(duì)注入的hostname信息屏蔽。

這樣的修改讓容器啟動(dòng)的HBase集群能夠順利啟動(dòng)并初始化成功，但是也給運(yùn)維提升了復(fù)雜度，因?yàn)楝F(xiàn)在HBase提供的Master頁(yè)現(xiàn)在看到的Regionserver都是IP形式的記錄，給監(jiān)控和故障處理帶來(lái)了諸多不便。

六、存在問(wèn)題

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

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

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

HBase配置

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

HDFS隔離

• 隨著接入HBase集群的增多，不同的HBase集群業(yè)務(wù)對(duì)HDFS的IO消耗有不同的要求，因此有了分離HBase依賴(lài)的HDFS集群的需求;
• 主要問(wèn)題源自Docker鏡像對(duì)相關(guān)配置文件的固化，與HDFS有關(guān)的hdfs-site.xml和core-site.xml配置文件與相關(guān)Docker鏡像對(duì)應(yīng)，而不同Docker鏡像的版本完全由研發(fā)人員自己管理，最初版本的實(shí)現(xiàn)并未考慮到這些問(wèn)題。

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

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

七、重構(gòu)

為了進(jìn)一步解決初版架構(gòu)存在的問(wèn)題，優(yōu)化HBase的管控流程，我們重新審視了已有的架構(gòu)，并結(jié)合Kubernetes的新特性，對(duì)原有的架構(gòu)進(jìn)行升級(jí)改造，重新用Golang重寫(xiě)了整個(gè)Kubas管理系統(tǒng)的服務(wù)(初版使用了Python進(jìn)行開(kāi)發(fā))。

并在Kubas管理系統(tǒng)的基礎(chǔ)上，開(kāi)發(fā)了多個(gè)用于監(jiān)控和運(yùn)維的基礎(chǔ)微服務(wù)，提高了在Kubernetes上進(jìn)行HBase集群部署的靈活性，架構(gòu)如下圖所示：

二代架構(gòu)圖

1、Deployment&ConfigMap

Deployment

• Deployment(部署)是Kubernetes中的一個(gè)概念，是Pod或者ReplicaSet的一組更新對(duì)象描述，用于取代之前的ReplicationController。Deployment繼承了ReplicationController的所有功能，并擁有更多的管理新特性;
• 在新的Kubas管理系統(tǒng)中，新設(shè)計(jì)用Deployment代替Replication Controller做Pod的管理，使用一個(gè)Deployment部署一組Region Servers的方式來(lái)代替單Regionserver對(duì)應(yīng)一個(gè)Replication Controller的設(shè)計(jì)，提升集群部署擴(kuò)縮容管理的靈活性;
• 每一組Deployment都會(huì)注入各類(lèi)信息維度的標(biāo)簽，如相關(guān)集群的信息就，服務(wù)類(lèi)型，所屬應(yīng)用等。

Deployment部署

ConfigMap

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

ConfigMap存檔

2、組件參數(shù)配置

在引入了ConfigMap功能之后，之前創(chuàng)建集群的請(qǐ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)行配置信息，如組件類(lèi)型，使用的啟動(dòng)命令，采用的鏡像文件，初始的副本數(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ù)先約定的路徑方式存放配置文件信息，同時(shí)在真正的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 

3、構(gòu)建流程

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

HBaseonKubernetes構(gòu)建流程

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

通過(guò)結(jié)合K8S的ConfigMap功能的配置模板，以及KubasAPI調(diào)用，我們就可以在短時(shí)間部署出一套可用的HBase最小集群(2Master + 3Region Server + 2Thriftserver)，在所有宿主機(jī)Host都已經(jīng)緩存Docker鏡像文件的場(chǎng)景下，部署并啟動(dòng)一整套HBase集群的時(shí)間不超過(guò)15秒。

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

八、資源控制

在完成重構(gòu)之后，HBase服務(wù)面向知乎內(nèi)部業(yè)務(wù)進(jìn)行開(kāi)放，短期內(nèi)知乎HBase集群上升超過(guò)30+集群，伴隨著HBase集群數(shù)量的增多，有兩個(gè)問(wèn)題逐漸顯現(xiàn)：

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

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

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

RSGroup的使用

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

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

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

九、多IDC優(yōu)化

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

多IDC訪(fǎng)問(wèn)方式

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

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

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

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

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

HBase Snapshot

全量數(shù)據(jù)復(fù)制我們采用了HBaseSnapshot的方式進(jìn)行;主要應(yīng)用在離線(xiàn)數(shù)據(jù)同步在線(xiàn)數(shù)據(jù)的場(chǎng)景;

WALTransfer

主要用于HBase集群之間的的增量數(shù)據(jù)同步;增量復(fù)制我們沒(méi)有采用HBaseReplication，相關(guān)同步方式我們通過(guò)自研的WALTransfer組件來(lái)對(duì)HBase數(shù)據(jù)進(jìn)行增量同步;

WALTransfer通過(guò)讀取源數(shù)據(jù)HBase集群提供WAL文件列表，于HDFS集群中定位對(duì)應(yīng)的WAL文件，將HBase的增量數(shù)據(jù)按序?qū)懭氲侥康募?，相關(guān)的細(xì)節(jié)我們會(huì)在以后的文章中詳細(xì)解析。

十一、監(jiān)控

從之前重構(gòu)后的架構(gòu)圖上我們可以看到，在Kubas服務(wù)中我們添加了很多模塊，這些模塊基本屬于HBase平臺(tái)的監(jiān)控管理模塊。

1、Kubas-Monitor組件

基本的監(jiān)控模塊，采用輪詢(xún)的方式發(fā)現(xiàn)新增HBase集群，通過(guò)訂閱Zookeeper集群發(fā)現(xiàn)HBase集群Master以及Regionserver組。

采集Regionserver Metric中的數(shù)據(jù)，主要采集數(shù)據(jù)包括：

• Region的信息，上線(xiàn)region數(shù)量，store的數(shù)量、storefile的大小、storefileindex的大小，讀取時(shí)memstore缺失次數(shù);
• blockcache的信息，例如blockcache中使用多少、空閑多少、累計(jì)的缺失率等;
• 讀寫(xiě)請(qǐng)求的統(tǒng)計(jì)信息，例如讀寫(xiě)響應(yīng)時(shí)間，讀寫(xiě)的表分布、讀寫(xiě)數(shù)據(jù)量、讀寫(xiě)失敗次數(shù)等;
• compact與split的操作信息，例如隊(duì)列的長(zhǎng)度、操作次數(shù)和時(shí)間等;
• handler的信息，例如隊(duì)列長(zhǎng)度、處于活躍handler的數(shù)量以及活躍的reader數(shù)量。

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

HBase部分監(jiān)控

2、Kubas-Region-Inspector組件

• 采集HBase表Region信息，通過(guò)HBaseAPI接口，獲取每個(gè)HBaseRegion的數(shù)據(jù)統(tǒng)計(jì)信息，并將Region數(shù)據(jù)聚合成數(shù)據(jù)表信息;
• 通過(guò)調(diào)用開(kāi)源組件形成HBase集群Region分布的圖表，對(duì)Region熱點(diǎn)進(jìn)行定位;

HBaseRegion分布監(jiān)控

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

十二、Future Work

隨著公司業(yè)務(wù)的快速發(fā)展，知乎的HBase平臺(tái)業(yè)務(wù)同時(shí)也在不斷的迭代優(yōu)化，短期內(nèi)我們會(huì)從以下幾個(gè)方向進(jìn)一步提升知乎HBase平臺(tái)的管理服務(wù)能力：

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

參考

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

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

[2]知乎容器平臺(tái)演進(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