Hbase多租户机制简析.docxVIP

Hbase多租户机制简析 范欣欣 2021-07-14 背景引见 在HBase1.1.0发布之前，HBase同一集群上的用户、表都是公平的，没有优劣之分。这种’大同’社会看起来完善，实际上有很多问题。最麻烦的次要有这么两个，其一是某些业务较其他业务重要，需要在资源有限的情况下优先保证核心重要业务的正常运转，其二是有些业务在某些场景下会时常’抽风’，QPS经常居高不下，严峻消耗系统资源，导致其他业务无法正常运转。这实际上是典型的多租户问题，社区针对这个问题提出了相应的应对措施，次要有如下三点： （1）资源限制，次要针对用户、namespace以及表的QPS和恳求大小进行限制，详见HBase-11598（2）资源调度，次要针对任务进行优先级调度，通常会优先调度实时交互而且小的任务，而批量操作任务或者长时间操作任务（大scan）优先级相对较低，详见HBase-10993（3）资源隔离，将不同表通过物理隔离的方式分布到不同的RegionServer上，详见HBase-6721 本文将会重点引见HBase中的资源限制方案 – Quotas，次要对其使用方式、实现原理进行引见，并对其实际效果通过实践进行验证。另外，本文还会对HBase的资源调度原理进行简约引见，并对次要配置进行讲解。 资源限制－Quotas Quotas使用条件 （1）HBase版本在1.1.0以上，或者低版本HBase应用了对应的Patch（HBase-11598）（2）Quotas功能默认是关闭的，需要在配置文件hbase-site.xml中通过设置hbase.quota.enabled为true打开。设置完成之后，需要重启HMaster才能生效。 Quotas语句详解 hbase set_quota TYPE = THROTTLE, THROTTLE_TYPE = READ, USER = u1, TABLE = t2, LIMIT = 10req/sec （1）Quotas分别支持表级别以及用户级别资源限制，或者同时支持表级别和用户级别，如示例所示（2）THROTTLE_TYPE可以取值READ / WRITE，分别对随机读和随机写进行限制（3）LIMIT 可以从两个维度对资源进行限制，分别为req/time 和 size/time，前者限制单位时间内的恳求数，后者限制单位时间内的恳求数据量。需要指明的是time的单位可以是sec | min | hour | day，size的单位可以是B(bytes) | K | M | G | T | P，因而LIMIT可以表示为’1000req/min’或者’100G/day’，分别表示’限制1分钟的恳求数在1000次以内’，’限制每天的数据量为100G’ 常用Quotas语句 hbase set_quota TYPE = THROTTLE, TABLE = t1, LIMIT = 1000req/sec hbase set_quota TYPE = THROTTLE, THROTTLE_TYPE = WRITE, USER = u1, LIMIT = 10M/sec 留意事项 （1）set_quota命令执行的限制都是针对单个RegionServer来说的，并不是针对整个集群（2）set_quota命令默认执行后并不会马上生效，需要等待一段时间才会生效，等待时间默认为5min。可以通过参数 hbase.quota.refresh.period 进行设置，比如可以通过设置hbase.quota.refresh.period = 60000将生效时间缩短为1min（3）可以通过命令list_quotas查看当前全部执行的set_quota命令 Quotas – 实现原理 原理很简约，假如恳求数超过设置的Quota数，就抛出特别！有同学会说也没在日志中看到任何特别嘛，这是由于这类特别日志级别是debug，而默认的日志输出级别为info，可以通过调整log4j来查看。但是这类特别实在太多，没有必要输出。 Quotas – 实践效果 了解了Quotas的使用方法以及基本原理，是不是很想试一试它的功效，笔者在测试环境做了如下的测试： 1. 测试硬件情况 集群规模 RS JVM内存配置 硬盘 HBase版本 YCSB版本 4台RegionServer 72G 12 * 3.6T 1.1.2 0.8.0 2. 测试环境新建两张表，分别称为A和B。两张表的数据构成都相同，10亿条数据，每条数据500Bytes，总大小500G左右。3. 分别使用两个YCSB客户端分别对这两张表执行读写混合操作（读写比为1:1），再然后对B表不断执行set_quota操作，对该表QPS进行限制。再分别观看A表和B表的QPS以