固定链接 HBase 的 RegionServer Group 特性在滴滴的应用

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

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

一、背景

目前滴滴 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 能力以及存储空间,我们就可以大致计算出某一个表需要多少的机器了。

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

四、具体应用

  1. HBase meta Group:
    用来存放 HBase 本身的 meta 表,HBase:meta、HBase:acl、HBase:rsgroup、HBase:namespace 等,当集群个别表出现性能问题时,至少不会影响 HBase 本身的元数据,这样才能保证其他表的服务正常。
  2. Phoenix meta Group:
    用来存放 Phoenix 的 meta 表,Phoenix 的 meta 表本身也有挂载了 coprocessor,某些特殊情况下,部分操作也会对 meta 表有一定压力.

    • SYSTEM.CATALOG
    • SYSTEM.SEQUENCE
    • SYSTEM.FUNCTION
    • SYSTEM.MUTEX
    • SYSTEM.STATS
  3. 特定业务 Group:
    用来存放压力比较大 / 对响应时间有一定要求的表.

  4. 公共 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 的管理
    1. 信息统计:如果公共池有机器压力大,如果找到具体的用户?我们在 RegionServer 端,增加了采样的 log,输出一小部分用户的请求 IP、账号名、请求类型,请求体大小等信息,来统计用户行为的占比。
    2. 资源限制:增加 Quota 机制进行用户行为的控制。用户在接入 HBase 之前会提供自己的请求量峰值,我们在用户填写的峰值基础之上设置 Quota 限制并预留一定 buffer 给用户。

七、总结

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

本文作者: 姚靖怡

您的留言将激励我们越做越好