37

弥补MySQL和Redis短板：看HBase怎么确保高可用

 5 years ago
source link: http://stor.51cto.com/art/201903/593841.htm?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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])。

EjMfiue.jpg!web

第一代架构

模块定义

在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(可选);

四、高可用以及故障恢复

作为面向在线业务服务的系统，高可用和故障转移是必需在设计就要考虑的事情，在整体设计中，我们分别考虑组件级别、集群级别和数据存储级别的可用性和故障恢复问题。

1、组件级别

HBase本身已经考虑了很多故障切换和恢复的方案：

  • Zookeeper集群：自身设计保证了可用性;
  • Master：通过多个Master注册在Zookeeper集群上来进行主节点的HA和更新;
  • RegionServer：本身就是无状态的，节点失效下线以后会把上面的Region自动迁走，对服务可用性不会有太大影响;
  • Thriftserver：当时业务大多数是Python和Golang，通过用Thrift对HBase的进行，Thriftserver本身是单点的，这里我们通过HAProxy来代理一组Thriftserver服务;
  • HDFS：本身又由Namenode和DataNode节点组成，Namenode我们开启HA功能，保证了HDFS的集群可用性;

2、集群级别

  • Pod容器失效：Pod是通过Replication Controller维护的，K8S的Controller Manager会在它的存储etcd去监听组件的失效情况，如果副本少于预设值会自动新的Pod容器来进行服务;
  • Kubernetes集群崩溃：该场景曾经在生产环境中出现过，针对这种情况，我们对SLA要求较高的业务采用了少量物理机搭配容器的方式进行混合部署，极端场景出现时，可以保证重要业务收到的影响可控;

3、数据级别

所有在K8S上构建的HBase集群都共享了一套HDFS集群，数据的可用性由HDFS集群的多副本来提供。

五、实现细节

1、资源分配

初期物理节点统一采用2*12核心的cpu，128G内存和4T的磁盘，其中磁盘用于搭建服务的HDFS，CPU和内存则在K8S环境中用于建立HBase相关服务的节点。

Master组件的功能主要是管理HBase集群，Thriftserver组件主要承担代理的角色，所以这两个组件资源都按照固定额度分配。

在对Regionserver组件进行资源分配设计的时候，考虑两种方式去定义资源：

fe67Zjq.jpg!web

资源分配方式

按照业务需求分配：

  • 根据业务方对自身服务的描述，对相关的QPS以及SLA进行评估，为业务专门配置参数，包含blockcache，region大小以及数量等;
  • 优点是针对业务优化，能够充分的利用资源，降低业务的资源占用成本;
  • 管理成本增加，需要对每一个业务进行评估，对平台维护人员非常不友好，同时需要业务同学本身对HBase有理解;

统一规格的资源分配：

  • CPU以及MEM都按照预先设定好的配额来分配，提供多档的配置，将CPU和MEM的配置套餐化;
  • 方便之处在于业务扩容时直接增加Regionserver的个数，配置稳定，运维成本较低，遇到问题时排障方便;
  • 针对某些有特有访问方式的业务有局限性，如CPU计算型，大KV存储，或者有MOB需求的业务，需要特殊的定制;
  • 介于当时考虑接入的在线业务并不多，所以采用了按业务定制的方式去配置Regionserver，正式环境同一业务采用统一配置的一组Regionserver，不存在混合配置的Regionserver组。

2、参数配置

基础镜像基于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参数等，这些配置都需要根据传入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 

3、网络通信

网络方面，采用了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运行在一个单独的ReplicationController(以下简称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集群部署的灵活性，架构如下图所示：

UrMfuq6.jpg!web

二代架构图

1、Deployment&ConfigMap

Deployment

  • Deployment(部署)是Kubernetes中的一个概念，是Pod或者ReplicaSet的一组更新对象描述，用于取代之前的ReplicationController。Deployment继承了ReplicationController的所有功能，并拥有更多的管理新特性;
  • 在新的Kubas管理系统中，新设计用Deployment代替Replication Controller做Pod的管理，使用一个Deployment部署一组Region Servers的方式来代替单Regionserver对应一个Replication Controller的设计，提升集群部署扩缩容管理的灵活性;
  • 每一组Deployment都会注入各类信息维度的标签，如相关集群的信息就，服务类型，所属应用等。

buqYveF.jpg!web

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和对应的集群和应用关联上。

BrAfiuZ.jpg!web

ConfigMap存档

2、组件参数配置

在引入了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 

3、构建流程

结合之前对Deployment以及ConfigMap的引入，以及对Dockerfile的修改，整个HBase构建流程也有了改进：

6vqumeI.jpg!web

HBaseonKubernetes构建流程

  • 编制相关的Dockerfile并构建基础的HBase组件镜像;
  • 为将要创建的HBase构建基础属性配置模板，订制基础资源，这部分可以通过KubasAPI在Kubernetes集群中创建ConfigMap;
  • 具体创建部署集群时，通过调用KubasAPI，结合之前构建的ConfigMap模板，渲染出HBase集群中各类组件的详细ConfigMap，然后在Kubernetes集群中构建Deployment;
  • 最终通过之前构建好的镜像加载组件ConfigMap中的配置，完成在KubernetesNode中运行的一个HBase组件容器。

通过结合K8S的ConfigMap功能的配置模板，以及KubasAPI调用，我们就可以在短时间部署出一套可用的HBase最小集群(2Master + 3Region Server + 2Thriftserver)，在所有宿主机Host都已经缓存Docker镜像文件的场景下，部署并启动一整套HBase集群的时间不超过15秒。

同时在缺少专属前端控制台的情况下，可以完全依托Kubernetesdashboard完成HBase集群组件的扩容缩容，以及组件配置的查询修改更新以及重新部署。

八、资源控制

在完成重构之后，HBase服务面向知乎内部业务进行开放，短期内知乎HBase集群上升超过30+集群，伴随着HBase集群数量的增多，有两个问题逐渐显现：

  • 运维成本增高：需要运维的集群逐渐增高;
  • 资源浪费：这是因为很多业务的业务量并不高，但是为了保证HBase的高可用，我们至少需要提供2个Master+3个RegionServer，而往往Master的负载都非常低，这就造成了资源浪费。

为了解决如上的两个问题，同时又不能打破资源隔离的需求，我们将HBaseRSGroup功能加入到了HBase平台的管理系统中。

优化后的架构如下：

U36RRjJ.jpg!web

RSGroup的使用

由于平台方对业务HBase集群的管理本身就具有隔离性，所以在进行更进一步资源管理的时候，平台方采用的是降级的方式来管理HBase集群。

通过监听每个单独集群的指标，如果业务集群的负载在上线一段时间后低于阈值，平台方就会配合业务方，将该HBase集群迁移到一套MixedHBase集群上。

同时如果在MixedHBase集群中运行的某个HBase业务负载增加，并持续一段时间超过阈值后，平台方就会考虑将相关业务提升至单独的集群。

九、多IDC优化

随着知乎业务的发展和扩大，知乎的基础架构逐渐升级至多机房架构，知乎HBase平台管理方式也在这个过程中进行了进一步升级，开始构建多机房管理的管理方式;基本架构如下图所示：

Zb2qQfE.jpg!web

多IDC访问方式

  • 业务HBase集群分别在多个IDC上运行，由业务确定IDC机房的主从方式，业务的从IDC集群数据通过平台方的数据同步组件进行数据同步;
  • 各IDC的Kubas服务主要负责对本地Kubernetes集群的具体操作，包括HBase集群的创建删除管理，regionserver的扩容等HBase组件的管理操作，Kubas服务部署与机房相关，仅对接部署所在机房的K8S集群;
  • 各IDC的Kubas服务向集群发现服务上报本机房集群信息，同时更新相关集群主从相关信息;
  • 业务方通过平台方封装的ClientSDK对多机房的HBase集群进行访问，客户端通过集群发现服务可以确定HBase集群的主从关系，从而将相关的读写操作分离，写入修改访问可以通过客户端指向主IDC的集群;
  • 跨机房间的数据同步采用了自研的HBaseReplicationWALTransfer来提供增量数据的同步。

十、数据同步

在各类业务场景中，都存在跨HBase集群的数据同步的需求，比如数据在离线HBase集群和在线集群同步、多IDC集群数据同步等，对于HBase的数据同步来说，分为全量复制和增量复制两种方式。

muqQnyJ.jpg!web

HBase数据同步

在知乎HBase平台中，我们采用两种方式进行HBase集群间的数据同步：

HBase Snapshot

全量数据复制我们采用了HBaseSnapshot的方式进行;主要应用在离线数据同步在线数据的场景;

WALTransfer

主要用于HBase集群之间的的增量数据同步;增量复制我们没有采用HBaseReplication，相关同步方式我们通过自研的WALTransfer组件来对HBase数据进行增量同步;

WALTransfer通过读取源数据HBase集群提供WAL文件列表，于HDFS集群中定位对应的WAL文件，将HBase的增量数据按序写入到目的集群，相关的细节我们会在以后的文章中详细解析。

十一、监控

从之前重构后的架构图上我们可以看到，在Kubas服务中我们添加了很多模块，这些模块基本属于HBase平台的监控管理模块。

1、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，磁盘占用等来自主机监控：

aEFvYru.jpg!web

HBase部分监控

2、Kubas-Region-Inspector组件

  • 采集HBase表Region信息，通过HBaseAPI接口，获取每个HBaseRegion的数据统计信息，并将Region数据聚合成数据表信息;
  • 通过调用开源组件形成HBase集群Region分布的图表，对Region热点进行定位;

NjueIvj.jpg!web

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

iuQ3e2E.png!web


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK