第1个回答 2022-07-18
易扩展性，准确来说是易横向扩展性，一直是HBase引以为豪的优点之一，所以理论上HBase的集群规模可以做到很大，多个产品和业务的数据可以存在一个HBase中统一管理，节省运维资源和成本。
但是集群规模大了，数据量多了，处理负载变高了，加上各个产品和业务之间优先级不同，负载不同，对不同资源的敏感性也不同，使得简单粗暴的共用一个集群的效果并不是很好，面对这种业务场景早期的HBase版本并没有相关的解决方案，所以更多的就是各自为战，各自用各自的集群，这样不仅使得HBase集群重复建设，增加硬件投入以及运维成本外，更是埋没了HBase的易扩展型的特点，所以后续的HBase版本中慢慢加入了多租户以及业务资源隔离相关的解决方案。
下面就从硬件资源隔离以及业务资源隔离两个方面来说明下HBase的实现：
此功能用于将统一的大HBase 集群的 RegionServer 划分为多个分组，管理员可以将不同的表放入不同分组进行资源隔离，避免无关系的业务之间互相影响。
同样也可以根据不同的业务需求提供不同的硬件资源。对于于重点业务，可以分配更多的regionserver的机器，降低负载；而对于非重点业务，则可以更少的机器承担负更多的业务。
目前datanode已经支持了分级存储，甚至可以将重点业务使用不同的介质，比如SSD，从而达到硬件资源利用率和业务执行效率双提升的目的。
下图就是HBase中RsGroup的实现方式：
从上图以及上面的描述可以看出，RsGroup的特点如下：
启用过程修改所有节点的hbase-site.xml, 并重启master即可，配置修改如下：
生产系统中的RsGroup的使用需要兼顾到很多硬件成本以及业务需求相关的限制，下面给出几个相对通用的原则供大家参考：
最后说说RsGroup使用过程中相关的管理以及注意事项：
RegionServer 默认情况下只提供一个请求队列给所有业务使用，该队列处理所有的读写请求，导致部分延迟较高的请求影响其他对延迟敏感的业务，大量的写请求影响了读请求。针对这种情况，HBase 提供了读写队列隔离方案。
HBase 有四种典型的数据API操作类型，分别为 get、scan 和put、delete，其中 get 和 scan 属于 read 类型，put、delete属于write类型。默认场景下，HBase 只提供一个队列，所有请求都会进入该队列进行优先级排序。在一些场景下，我们要求这四种类型的访问尽可能的互相不影响，那么就需要在线上配置读写分离。
首先，我们可以根据HBase的业务特点，即读多写少还是写多读少来分配读写的比例：
HBase 中的相关配置如下：
该值在HBase中默认为0，代表读写资源不分离。如果将 hbase.ipc.server.callqueue.read.ratio 设置为0.5，则表示有50%的线程数处理读请求，剩余50%用于接收写请求。如果读多写少，则将该值设置为0.5-1之间；如果写多读少，则将该值设置为0-0.5之间。
其次，在某些场景下，读操作scan以及get也需要进行隔离，HBase也同样提供scan以及get的比例：
HBase 中的相关配置如下：
该值在HBase中默认为0，代表scan和get资源不分离。如果将 hbase.ipc.server.callqueue.scan.ratio 设置为0.5，则代表在50%的读线程之中，再有50%的线程处理 scan，也就是全部线程的25%。如果scan多get少，则将该值设置为0.5-1之间；如果get多scan少，则将该值设置为0-0.5之间。