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

张小渔 2019-03-26 10:49:35
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*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组件进行资源分配设计的时候,考虑两种方式去定义资源:

 

资源分配方式

 

按照业务需求分配:

 

  • 根据业务方对自身服务的描述,对相关的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集群部署的灵活性,架构如下图所示:

 

二代架构图

 

1、Deployment&ConfigMap
 

 

Deployment

 

  • Deployment(部署)是Kubernetes中的一个概念,是Pod或者ReplicaSet的一组更新对象描述,用于取代之前的ReplicationController。Deployment继承了ReplicationController的所有功能,并拥有更多的管理新特性;

  • 在新的Kubas管理系统中,新设计用Deployment代替Replication Controller做Pod的管理,使用一个Deployment部署一组Region Servers的方式来代替单Regionserver对应一个Replication Controller的设计,提升集群部署扩缩容管理的灵活性;

  • 每一组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存档

 

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构建流程也有了改进:

 

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平台的管理系统中。

 

优化后的架构如下:

 

RSGroup的使用

 

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

 

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

 

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

 

九、多IDC优化

 

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

 

多IDC访问方式

 

  • 业务HBase集群分别在多个IDC上运行,由业务确定IDC机房的主从方式,业务的从IDC集群数据通过平台方的数据同步组件进行数据同步;

 

  • 各IDC的Kubas服务主要负责对本地Kubernetes集群的具体操作,包括HBase集群的创建删除管理,regionserver的扩容等HBase组件的管理操作,Kubas服务部署与机房相关,仅对接部署所在机房的K8S集群;

 

  • 各IDC的Kubas服务向集群发现服务上报本机房集群信息,同时更新相关集群主从相关信息;

 

  • 业务方通过平台方封装的ClientSDK对多机房的HBase集群进行访问,客户端通过集群发现服务可以确定HBase集群的主从关系,从而将相关的读写操作分离,写入修改访问可以通过客户端指向主IDC的集群;

 

  • 跨机房间的数据同步采用了自研的HBaseReplicationWALTransfer来提供增量数据的同步。

 

十、数据同步

 

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

 

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,磁盘占用等来自主机监控:

 

HBase部分监控

 

2、Kubas-Region-Inspector组件
 

 

  • 采集HBase表Region信息,通过HBaseAPI接口,获取每个HBaseRegion的数据统计信息,并将Region数据聚合成数据表信息;

  • 通过调用开源组件形成HBase集群Region分布的图表,对Region热点进行定位;

 

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

 

作者:张小渔

来源:https://zhuanlan.zhihu.com/p/57739371

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

最新评论
访客 2019年04月17日

总结的真cool

访客 2019年04月17日

非常不错 受用。

访客 2019年04月13日

作者根本就没用过pg吧,两个数据库都用过一年以上再来…

访客 2019年04月09日

niubility!!!!! 大赞贺大佬

访客 2019年03月27日

Spark2.x+Python大数据机器学习实战视频教程 学习:p…

活动预告