HBase的RegionServer Group 特性在滴滴的应用

最新推荐文章于 2022-11-09 14:32:00 发布

Hadoop技术博文

最新推荐文章于 2022-11-09 14:32:00 发布

阅读量476

点赞数

本文转载自：https://zhuanlan.zhihu.com/p/51635980

一、背景

目前滴滴 HBase 集群接入了几百个项目，近千张表，上层有用户自己的业务实现以及 Phoenix（HBase SQL 引擎）和 GeoMesa（基于 HBase 的时空索引实现）。

不同用户间请求方式，业务逻辑，以及要求的响应时间都不同，如何减少用户之间的影响，及时发现特定业务问题？

我们在社区的 HBase 版本基础上增加了 RegionServer Group 的功能 (HBASE-6721)。

此功能用于将一个大 HBase 集群的 RegionServer 划分为多个分组，管理员可以将不同的表放入不同分组进行隔离，避免无关系的业务之间互相影响。

二、原理

HBase 是一个分布式存储的集群，那么首先肯定有很多 server 进行具体的数据存储和读写 RPC 的处理。HBase 将一个表通过 split 方式分成多个 Region。然后将这些 Region 分配到不同的机器，达到将请求分散的目的。

我们来看看集群是通过什么方式进行表 Region 的管理。

既然有这么多 server，那么一般都需要有一个管理者来进行管理，这个管理者就是 HMaster。HMaster 通过 Balancer 来将一个表的 N 个 split 之后的 N 个 Region 均衡到不同的 RegionServer 上。

由浅入深

先来看看只有一个表的情况。

比如现在我们有一个表 A 在集群上创建，如下图，根据默认的 Balance 权重，每个机器上基本上 Region 数量很平均。做好 rowkey 的散列之后，每个机器的请求压力也很平均了，看上去还不错，下面我们看看创建了多个表的情况。

进阶，增加了新的表

旧的 Region 分配策略当表 B 也在这个集群创建之后，表 A 和表 B 的 Region 是混合分配在多个 RegionServer 上的，当 Table_B 有很多请求给服务器造成压力时，本来稳定的 Table_A 也会受到影响。

RegionServer Group 的应用

将 RegionServer Group 特性应用之后的策略：

增加两个 Group A 和 B。Table_A 有两台机器，Table_B 有两台机器。

这样两个表如果其中一个表的请求量增大，也不会对另外一个表所在机器的 CPU、内存和 JVM 有影响。

三、资源规划

不过目前同一个集群底层的 HDFS 还是一套磁盘的流量，IO 压力还是要注意。有独立分组的用户也不是无限制的去使用集群资源的。

应用 RegionServer Group 之后，资源分配计算我们总结了方案，通过以下方法来大致判断用户的流量以及需要分配多少资源。

下图中是蓝色部分是读操作，绿色部分是写操作，由操作次数和每次操作 Size 大小，我们可以得到对应的 IO 流量；通过写流量和存储 TTL，我们可以预估出存储大小。

当然集群内部的 compaction 机制和 load 文件的 Bulkload 操作，也会带来一定的流量和计算量，不过这两项操作都可以通过参数进行限流，也都是可控的。

再通过压测的单机读写流量 + IO 能力以及存储空间，我们就可以大致计算出某一个表需要多少的机器了。

虽然是大致的估算，但是我们把目前能统计和限制的地方都做了相应的计算和限制，也已经解决了不少问题。

四、具体应用

HBase meta Group：

用来存放 HBase 本身的 meta 表，HBase:meta、HBase:acl、HBase:rsgroup、HBase:namespace 等，当集群个别表出现性能问题时，至少不会影响 HBase 本身的元数据，这样才能保证其他表的服务正常。

Phoenix meta Group：

用来存放 Phoenix 的 meta 表，Phoenix 的 meta 表本身也有挂载了 coprocessor，某些特殊情况下，部分操作也会对 meta 表有一定压力.

SYSTEM.CATALOG

SYSTEM.SEQUENCE

SYSTEM.FUNCTION

SYSTEM.MUTEX

SYSTEM.STATS

特定业务 Group：

用来存放压力比较大 / 对响应时间有一定要求的表.

公共 Group：

专享的 Group，有了以上隔离方案进行支持，看上去非常完美，是否公共的 Group 就没有存在必要呢？

经过和用户的沟通我们发现，有一部分用户有以下特征：

资源划分：部分用户的请求量比较低，独立分组至少要 2~3 台机器，如果这种用户也专门有一个分组，比较浪费 HBase 的存储和读写能力。

响应时间：用来存放对响应时间没有明确要求的业务表。

这部分用户放在公共 Group。能比较好的合理利用公共 Group 的资源，使机器提高一定利用率。

五、进一步的优化

特殊 Group 的利用率：

业务专享的 Group 利用率和公共 Group 利用率提升了，但是集群整体排查一遍，运维同事提出 meta 表的两个 Group请求量日常还是很低，也基本不占用什么存储量。这两个机器和业务表的机器使用相同机型又浪费了。

因此，meta 表的 Group 在和运维同事的共同讨论下，我们选择了存储量，内存都相对小一些的机器。

最终，每个集群减少了 4 台机器的成本。

六、后期管理

监控，报警的增加，发现了哪些问题，如何处理？

专享 Group 的管理

对于重点业务分别进行监控：每个 Group 不同的 Rpc P99 监控、请求量、compact 时长等 metric 的监控，每个业务的 metric 有不同的报警阈值。

尝试在 RegionServer Group 基础上改进更多功能.

专享 Group 是比较好统计的，那么共享 Group 的表如何进行控制，有问题如何进行排查呢？

公共 Group 的管理

信息统计：如果公共池有机器压力大，如果找到具体的用户？我们在 RegionServer 端，增加了采样的 log，输出一小部分用户的请求 IP、账号名、请求类型，请求体大小等信息，来统计用户行为的占比。

资源限制：增加 Quota 机制进行用户行为的控制。用户在接入 HBase 之前会提供自己的请求量峰值，我们在用户填写的峰值基础之上设置 Quota 限制并预留一定 buffer 给用户。

七、总结

分布式集群在管理时经常遇到资源分配和占用的问题，最好的方案就是进行资源限制和隔离，比如 Hadoop 集群的 Yarn 可以通过 label 进行节点的管理，通过 cgroup 进行内存、CPU 等资源的限制。HBase 则是通过 RegionServer Group 和 Quota 来进行隔离和限制。