知乎 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[3] 是谷歌開源的容器集群管理系統，是 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 * Master ReplicationController;

3 * Regionserver ReplicationController;

2 * Thriftserver ReplicationController (可選);

高可用以及故障恢復

作為面向在線業務服務的系統，高可用和故障轉移是必需在設計就要考慮的事情，在整體設計中，我們分別考慮組件級別，集群級別和數據存儲級別的可用性和故障恢復問題.

組件級別

HBase 本身已經考慮了很多故障切換和恢復的方案：

• Zookeeper 集群：自身設計保證了可用性；

• Master: 通過多個master註冊在 Zookeeper 集群上來進行主節點的 HA 和更新；

• RegionServer: 本身就是無狀態的，節點失效下線以後會把上面的 region 自動遷走，對服務可用性不會有太大影響；

• Thriftserver: 當時業務大多數是 Python 和 Golang，通過用 Thrift 對 HBase 的進行，Thriftserver 本身是單點的，這裡我們通過 HAProxy 來代理一組 Thriftserver 服務；

• HDFS：本身又由 Namenode 和 DataNode 節點組成，Namenode 我們開啟 HA 功能, 保證了 HDFS 的集群可用性;

  
  

集群級別

• Pod 容器失效: Pod 是通過 ReplicationController 維護的， K8S 的 ControllerManager 會在它 的存儲 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 組.

參數配置

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

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

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

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

• 與 HBase 相關的配置信息, 如組件啟動依賴的 Zookeeper 集群地址，HDFS 數據目錄路徑, 堆內存以及GC 參數等，這些配置都需要根據傳入 Kubas Service 的信息進行對應變量的修改, 一個典型的傳入參數示例:

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",

}

通過上面的參數 Kubas Service 啟動 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 集群，這和我們設計的初衷不符合;

• 容器標識符和 HBase Master 裡註冊的 regionserver 地址不一致，影響故障定位；

• 單 Regionserver 運行在一個單獨的 ReplicationController (以下簡稱 RC ), 但是擴容縮容為充分利用 RC 的特性，粗暴的採用增加或減少 RC 的方式進行擴容縮容;

HBase 配置：

• 最初的設計缺乏靈活性，與 HBase 服務配置有關的 hbase-site.xml 以及 hbase-env.sh固化在 Docker Image 裡，這種情況下， 如果需要更新大量配置，則需要重新 build 鏡像;

• 由於最初設計是共享一套 HDFS 集群作為多 HBase 集群的存儲，所以與 HDFS 有關的 hdfs-site.xml 和 core-site.xml 配置文件也被直接配置進了鏡像. 如果需要在 Kubas service 中上線依賴其他 HDFS 集群的 HBase，也需要重新構建鏡像;

HDFS 隔離:

• 隨著接入 HBase 集群的增多，不同的 HBase 集群業務對 HDFS 的 IO 消耗有不同的要求，因此有了分離 HBase 依賴的 HDFS 集群的需求；

• 主要問題源自 Docker 鏡像對相關配置文件的固化，與 HDFS 有關的 hdfs-site.xml 和 core-site.xml 配置文件與相關 Docker 鏡像對應，而不同 Docker 鏡像的版本完全由研發人員自己管理，最初版本的實現並未考慮到這些問題;

監控運維:

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

• region 熱點定位較慢，無法在短時間內定位到熱點 region;

• 新增或者下線組件只能通過掃 kubas service 的數據庫來發現相關變更，組件的異常如 regionserver 掉線或重啟，master 切換等不能及時反饋;

重構

為了進一步解決初版架構存在的問題，優化 HBase 的管控流程，我們重新審視了已有的架構，並結合 Kubernetes 的新特性，對原有的架構進行升級改造，重新用 Golang 重寫了整個 Kubas 管理系統的服務 (初版使用了 Python 進行開發) ，並在 Kubas 管理系統的基礎上，開發了多個用於監控和運維的基礎微服務，提高了在 Kubernetes 上進行 HBase 集群部署的靈活性，架構如下圖所示：

二代架構圖

Deployment & Config Map

Deployment

• Deployment (部署) 是 Kubernetes 中的一個概念，是 Pod 或者 ReplicaSet 的一組更新對象描述，用於取代之前的 ReplicationController. Deployment 繼承了 ReplicationController 的所有功能，並擁有更多的管理新特性；

• 在新的 Kubas 管理系統中，新設計用 Deployment 代替 ReplicationController 做 Pod 的管理，使用一個 Deployment 部署一組 Regionservers 的方式來代替單Regionserver 對應一個 ReplicationController 的設計，提升集群部署擴縮容管理的靈活性;

• 每一組 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

構建流程

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

HBase on Kubernetes 構建流程

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

• 為將要創建的 HBase 構建基礎屬性配置模板，訂製基礎資源，這部分可以通過 Kubas API 在 Kubernetes 集群中創建 ConfigMap;

• 具體創建部署集群時，通過調用 Kubas API, 結合之前構建的 ConfigMap 模板，渲染出 HBase 集群中各類組件的詳細 ConfigMap, 然後在 Kubernetes 集群中構建 Deployment;

• 最終通過之前構建好的鏡像加載組件 ConfigMap 中的配置，完成在 Kubernetes Node 中運行的一個 HBase 組件容器;

通過結合 K8S 的 ConfigMap 功能的配置模板，以及 Kubas API 調用，我們就可以在短時間部署出一套可用的 HBase 最小集群 (2Master + 3RegionServer + 2Thriftserver), 在所有宿主機 Host 都已經緩存 Docker 鏡像文件的場景下，部署並啟動一整套 HBase 集群的時間不超過 15 秒.

同時在缺少專屬前端控制檯的情況下，可以完全依託 Kubernetes dashboard 完成 HBase 集群組件的擴容縮容，以及組件配置的查詢修改更新以及重新部署.

資源控制

在完成重構之後，HBase 服務面向知乎內部業務進行開放，短期內知乎 HBase 集群上升超過30+ 集群，伴隨著 HBase 集群數量的增多，有兩個問題逐漸顯現：

1. 運維成本增高: 需要運維的集群逐漸增高;

2. 資源浪費：這是因為很多業務的業務量並不高，但是為了保證 HBase 的高可用，我們至少需要提供 2 個 Master + 3 個 Region Server，而往往 Master 的負載都非常低，這就造成了資源浪費.

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

優化後的架構如下:

RSGroup 的使用

由於平臺方對業務 HBase 集群的管理本身就具有隔離性，所以在進行更進一步資源管理的時候，平臺方採用的是降級的方式來管理 HBase 集群，通過監聽每個單獨集群的指標，如果業務集群的負載在上線一段時間後低於閾值，平臺方就會配合業務方，將該 HBase 集群遷移到一套 Mixed HBase 集群上.

同時如果在 Mixed HBase 集群中運行的某個 HBase 業務負載增加，並持續一段時間超過閾值後，平臺方就會考慮將相關業務提升至單獨的集群.

多 IDC 優化

隨著知乎業務的發展和擴大，知乎的基礎架構逐漸升級至多機房架構，知乎 HBase 平臺管理方式也在這個過程中進行了進一步升級，開始構建多機房管理的管理方式；基本架構如下圖所示:

多 IDC 訪問方式

• 業務 HBase 集群分別在多個 IDC 上運行，由業務確定 IDC 機房的主從方式，業務的從 IDC 集群數據通過平臺方的數據同步組件進行數據同步;

• 各 IDC 的 Kubas 服務主要負責對本地 Kubernetes 集群的具體操作，包括 HBase 集群的創建刪除管理，regionserver 的擴容等 HBase 組件的管理操作，Kubas 服務部署與機房相關，僅對接部署所在機房的 K8S 集群;

• 各 IDC 的 Kubas 服務向集群發現服務上報本機房集群信息，同時更新相關集群主從相關信息;

• 業務方通過平臺方封裝的 Client SDK 對多機房的 HBase 集群進行訪問，客戶端通過集群發現服務可以確定 HBase 集群的主從關係，從而將相關的讀寫操作分離，寫入修改訪問可以通過客戶端指向主 IDC 的集群;

• 跨機房間的數據同步採用了自研的 HBase Replication WALTransfer 來提供增量數據的同步;

數據同步

在各類業務場景中，都存在跨 HBase 集群的數據同步的需求，比如數據在離線 HBase 集群和在線集群同步，多 IDC 集群數據同步等；對於 HBase 的數據同步來說，分為全量複製和增量複製兩種方式;

HBase 數據同步

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

HBase Snapshot：

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

WALTransfer:

主要用於 HBase 集群之間的的增量數據同步；增量複製我們沒有采用 HBase Replication，相關同步方式我們通過自研的 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 信息，通過 HBase API 接口，獲取每個 HBase Region 的數據統計信息，並將 Region 數據聚合成數據表信息;

• 通過調用開源組件形成 HBase 集群 Region 分佈的圖表，對 Region 熱點進行定位;

HBase Region 分佈監控

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

Future Work

隨著公司業務的快速發展，知乎的 HBase 平臺業務同時也在不斷的迭代優化，短期內我們會從以下幾個方向進一步提升知乎 HBase 平臺的管理服務能力:

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

• 用戶集群構建定製化. 通過提供用戶數據管理系統，向業務用戶開放 HBase 構建接口，這樣業務用戶可以自行構建 HBase 集群，添加 Phoniex 等插件的支持；

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

寫在最後

HBase 在知乎的推廣應用從 2017 年開始，平臺架構經過了若干個版本的迭代最終穩定，在這裡感謝 @bzy 在前期的鋪墊，感謝 @高勳 為資源隔離化和資源利用率優化所做的工作. 特別感謝 @王政英 在使用 HBase 服務期間給我們提供的建議和 downtime.

知乎核心架構團隊負責解決知乎業務複雜度和併發規模提升給核心資源調度以及數據存儲架構帶來的問題以及挑戰，隨著知乎用戶和業務規模的快速增長，以及基礎架構複雜度的持續提升，團隊面臨的技術挑戰也越來越多，目前正在持續實施多機房異地多活的架構改造和資源的優化，努力保障和提升知乎核心架構的質量和穩定性，歡迎對技術感興趣、渴望技術挑戰的小夥伴與 [email protected] /[email protected] 聯繫.

Reference

[1] 知乎基於 Kubernetes 的 Kafka 平臺的設計和實現

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

[2] 知乎容器平臺演進及與大數據融合實踐

https://mp.weixin.qq.com/s/lt3kr4iFi8hk44hT6HzPag

[3] Kubernetes

http://kubernetes.io/

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

http://www.slideshare.net/HBaseCon/hbaseconasia2017-building-online-hbase-cluster-of-zhihu-based-on-kubernetes

相關閱讀：

• 知乎社區核心業務 Golang 化實踐

• Redis作者：近期核心功能的一些思考和澄清

• Kubernetes實戰——談談微博應對春晚等突發峰值流量的經驗

• MySQL性能突發事件問題排查技巧

  
  

技術原創及架構實踐文章，歡迎通過公眾號菜單「聯繫我們」進行投稿。轉載請註明來自高可用架構「ArchNotes」微信公眾號及包含以下二維碼。

高可用架構

改變互聯網的構建方式

長按二維碼 關注「高可用架構」公眾號