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

r囧r小猫 2021-09-17 22:04 356阅读 0赞

一、背景

目前滴滴 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 的散列之后，每个机器的请求压力也很平均了，看上去还不错，下面我们看看创建了多个表的情况。

![f36e813c42bf44148409d84a02ac39a9][]

**进阶，增加了新的表**

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

![350851432a1b4dffa4ffb30cc7381558][]

**RegionServer Group 的应用**

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

增加两个 Group A 和 B。Table\_A 有两台机器，Table\_B 有两台机器。

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

![62f26472ad5448d49dff40b6b18e8141][]

**三、资源规划**

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

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

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

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

![171ee56eb89d44e58af3d8aaa477cd42][]

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

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

![11ac30d3984e4a9a86ef2b7f2f5cd3ae][]

**四、具体应用**

**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 来进行隔离和限制。

小编我整理了一些大数据资料可以领取（Hadoop，Spark，flink，hbase，es等等，更有源码级的视频讲解资料），一个大数据的交流群：[\[\*\*878761222\*\*\]][878761222].欢迎大家进群交流讨论，学习交流，共同进步。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70][]  
  
当真正开始学习的时候难免不知道从哪入手，导致效率低下影响继续学习的信心。  
  
但最重要的是不知道哪些技术需要重点掌握，学习时频繁踩坑，最终浪费大量时间，所以有有效资源还是很有必要的。

[f36e813c42bf44148409d84a02ac39a9]: /images/20210724/e90f69d49b3c42e796c5b12996a528c7.png
[350851432a1b4dffa4ffb30cc7381558]: /images/20210724/e5868d499e424158ba4bfbc4ddafbe98.png
[62f26472ad5448d49dff40b6b18e8141]: /images/20210724/acf45bba0ec9461aa64e32e05dd04d24.png
[171ee56eb89d44e58af3d8aaa477cd42]: /images/20210724/d7b673a401204db08d8ea6c793cb4291.png
[11ac30d3984e4a9a86ef2b7f2f5cd3ae]: /images/20210724/914607a4677a4b18a46f2f8f5fd2ff80.png
[878761222]: http://shang.qq.com/wpa/qunwpa?idkey=42be6ba8447390a954623d99d0fcbf5030219b7eb3734345fecbced8663803df
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqMTMxNDI1MA_size_16_color_FFFFFF_t_70]: /images/20210724/d47dca4123314ba087fba7122af90bcb.png