弥补MySQL和Redis短板：看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的运行数量和健康，并能够弹性伸缩。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!