HBase balancer原理解析和一些优化方案

Balancer简介

Balancer是HBase非常重要的一个模块，属于Master功能的一部分，主要通过均衡RS上的region分布来规避一些热点问题。集群规模大，用户数量多，业务种类多时，balancer的重要性愈发明显。不及时的balance或未知问题的balance执行中断，都有可能使线上热点问题影响范围变大。社区在2021年，有多个开发者对balancer做了大量优化，这表明balancer的问题在各个公司中都很突出和重要。
##Balancer背景
目前balancer主要分两种：SimpleLoadBalancer和StochasticLoadBalancer。

SimpleLoadBalancer保证每个RS的Region个数基本上都相等，确切来说，假设一共有n个RS，第i个RS有Ai个Region，记average=sigma(Ai)/n , 那么这种策略能够保证所有的RS的Region个数都在[floor(average), ceil(average)]之间。这种策略的实现简单，应用广泛。但是，这种策略考虑的因素比较单一， 没有考虑到每台RS的负载压力，数据locality等。

StochasticLoadBalancer考虑因素有多种，以减小代价值为标准，生成Region move的方案。

StochasticLoadBalancer

这是目前各大公司使用最多的balancer算法（RSGroupLoadBalancer底层基于他）。
以计算集群当前状态的代价值为基础，确定是否需要执行balance，以及如何移动region。
计算代价考虑的因素较多，主要综合权衡以下因素：
RegionLoadCostFunction：RS上所有Region的负载差值
ReadRequestCostFunction：Region读请求数
WriteRequestCostFunction：Region写请求数
StoreFileCostFunction：Store file 大小；
MemStoreSizeCostFunction：Memstore 大小；
RegionCountSkewCostFunction：每台RS的Region个数差值
MoveCostFunction：移动代价
LocalityCostFunction：数据locality
TableSkewCostFunction：每张表在RS上的最大Region数量
对于cluster的每一种region分布， 采用6个因素加权的方式算出一个代价值，这个代价值就用来评估当前Region分布是否均衡，越均衡则代价值越低。然后通过成千上万次随机迭代来找到一组RegionMove的序列，使得最终的代价值严格递减。 得到的这一组RegionMove就是HMaster最终执行的Region迁移方案。生成RegionMove的方法随机从以下三种中选择：

随机选择两个RS, 从每个RS中随机选择两个Region，然后生成一个Action, 这个Action有一半概率做RegionMove（从Region多的RS迁移到Region少的RS）, 另一半概率做RegionSwap(两个RS之间做Region的交换)。
选择Region最多的RS和Region最少的RS，然后生成一个Action, 这个Action一半概率做RegionMove, 一半概率做RegionSwap。

随机找一个RS，然后找到该RS上数据locality最差的Region，再找到Region locality最好的RS，然后生成一个Action，该Action用来把Region迁移到它应该所在的RS，用来提高locality.

优化方案

1. 某些情况下，将StochasticLoadBalancer降级为SimpleLoadBalancer。避免不必要的上述复杂算法计算，先快速恢复region数量的均衡，以减少压力不均带来的性能影响。
   https://issues.apache.org/jira/browse/HBASE-25768

• 至少一台RS有重启过，且整体region分布不均；
• region数量分布不均的表的数量占整体表数量的至少一半；（可涵盖第一种情况）

2. 将社区的balancer计算方法优化，加入Read/WriteRequestSize计算函数。
   社区目前仅根据memstore大小和storefileCount来推测可能size较大的region，但是热点region可能仅写入量/s大，而非size大。
   https://issues.apache.org/jira/browse/HBASE-25727
3. 为了解决表region压力不均的问题，可以给RS增加定期的region split检查（类似Compaction Checker），此检查在split policy之外，增加RS实时load情况判断和region实时压力的计算。
   HBase目前的方法仅能依赖region自己的size大小split，无法根据RS的实际状况判断，所以导致split policy并不灵敏。