一、负载均衡的目标与触发机制
HBase 将大表按行键范围切分成多个 Region，每个 Region 由某一台 RegionServer 负责读写。Region 的分布并不是一成不变的，随着写入增长、表拆分和集群扩容，不同 RegionServer 上承载的 Region 数量、请求压力、内存占用会出现明显差异。如果某台 RegionServer 被分配了过多热点 Region，该节点的 CPU、内存和网络都会成为瓶颈，而其他节点却处于空闲状态。
负载均衡的核心目标是在不中断服务的前提下，将 Region 从高负载节点迁移到低负载节点，使集群整体资源利用率更加均匀。HBase Master 中的 LoadBalancer 组件负责计算迁移计划，并通过 Region 下线、重新分配、上线等步骤完成移动。自动均衡由参数 hbase.balancer.period 控制，默认值为 300000 毫秒，即每 5 分钟检查一次。管理员也可以随时通过 HBase Shell 执行 balancer 命令手动触发一次均衡，或者用 balance_switch false 暂时关闭自动均衡。
需要注意的是，Region 迁移并不是零成本的。迁移期间目标 Region 会经历短暂的不可用，同时会产生 WAL 复制和 StoreFile 搬运开销。因此均衡策略不能只关注 Region 数量绝对相等，还需要考虑迁移代价、数据本地性以及业务访问模式。
二、内置负载均衡策略的对比与选择
HBase 内置了多个 LoadBalancer 实现，最常用的是 SimpleLoadBalancer 和 StochasticBalancer。SimpleLoadBalancer 的逻辑比较直接，它根据每台 RegionServer 上的 Region 数量计算平均值，然后从 Region 数最多的节点选择 Region 移动到最少的节点，直到数量差小于给定阈值。该策略计算快，适合 Region 数量不多且访问模式均匀的小集群，但它忽略了表之间的差异、数据量以及读写热度，可能把一张大表的多个热点 Region 集中到同一台服务器。
StochasticBalancer 是 HBase 默认的负载均衡策略，从 1.0 版本开始成为标准选择。它的思路不是简单地比较数量，而是随机生成大量候选的 Region 移动组合，然后用一个综合成本函数为每个候选方案打分，最后选择总分最低的方案执行。成本函数由多个维度加权构成，包括集群整体 Region 数量方差、单表 Region 倾斜度、Region 本地性比率、MemStore 内存占用、StoreFile 磁盘大小以及 Region 移动成本。
下表对比了两种策略的主要差异：
| 策略 | 均衡依据 | 计算开销 | 适用场景 |
|---|---|---|---|
| SimpleLoadBalancer | Region 数量 | 低 | 小集群、压力均匀 |
| StochasticBalancer | 多维度综合成本 | 较高 | 生产环境、热点突出 |
在 hbase-site.xml 中可以指定负载均衡策略类名。例如想要使用 SimpleLoadBalancer，可以配置：
<property> <name>hbase.master.loadbalancer.class</name> <value>org.apache.hadoop.hbase.master.balancer.SimpleLoadBalancer</value> </property>
如果没有显式配置该参数，HBase 会使用 StochasticBalancer。在集群规模较大或业务热点明显的场景下，建议保持默认策略，并通过调整成本权重来贴合实际负载特征。
三、StochasticBalancer 成本函数与参数调优
StochasticBalancer 的决策过程可以概括为三步：生成候选状态、计算加权成本、选择最优移动。候选状态并不是完全随机枚举，而是基于当前 Region 分布进行有限的 Swap、Move 操作，例如将某个 Region 从高负载节点移动到低负载节点，或者交换两个 Region 的位置。通过多次迭代，算法会保留成本最低的候选方案。
成本权重通过 hbase.master.balancer.stochastic.*Cost 系列参数配置，常用项包括：
hbase.master.balancer.stochastic.regionCountCost：Region 数量均衡成本，默认值 500。hbase.master.balancer.stochastic.tableSkewCost：表倾斜成本，避免同一张表的 Region 过度集中，默认值 35。hbase.master.balancer.stochastic.localityCost：数据本地性成本，尽量把 Region 放到 HDFS 数据所在节点，默认值 25。hbase.master.balancer.stochastic.memStoreSizeCost：MemStore 内存成本，默认值 5。hbase.master.balancer.stochastic.storeFileSizeCost：StoreFile 大小成本，默认值 5。
这些权重值越大，对应因素在最终决策中越重要。举例来说，如果业务写入非常频繁，MemStore 内存经常成为瓶颈，可以适当提高 memStoreSizeCost 的权重；如果主要压力来自大范围扫描，则应提高 storeFileSizeCost。调整配置后需要重启 Master 才能生效。
<property> <name>hbase.master.balancer.stochastic.memStoreSizeCost</name> <value>20</value> </property> <property> <name>hbase.master.balancer.stochastic.storeFileSizeCost</name> <value>15</value> </property>
另外，StochasticBalancer 还有一个最大移动步数参数 hbase.master.balancer.stochastic.maxRunningTime 和 hbase.master.balancer.stochastic.numRegionLoadsToRemember，前者限制单次均衡计算的最大运行时间，后者控制历史负载采样数量。合理的运行时间限制可以避免均衡计算本身占用 Master 过多 CPU。
四、RS Group 隔离与自定义负载均衡器
HBase 自 1.4 版本引入 RegionServer Group，简称 RS Group。它允许管理员将多张表绑定到特定的 RegionServer 集合，负载均衡只会在同一个 Group 内部进行，不会跨组移动 Region。这种方式非常适合多租户场景，例如把在线业务放在一组高性能节点上，把离线分析放在另一组大存储节点上，互相之间不争抢资源。
通过 HBase Shell 可以创建 RS Group 并移动 RegionServer。首先要启用 RS Group 功能，然后将表与 Group 关联：
# 创建 RS Group create_rsgroup 'online_group' move_servers_rsgroup 'online_group', ['rs1.ippipp.com','rs2.ippipp.com'] move_tables_rsgroup 'online_group', ['order_table','user_table']
普通负载均衡器在启用 RS Group 后会对每个 Group 分别执行均衡计算，从而实现隔离。除此之外，HBase 还支持通过实现 LoadBalancer 接口来编写自定义均衡逻辑。自定义类需要继承 BaseLoadBalancer 并实现 balanceCluster 方法，返回一个 Region 移动计划。
下面是一个简化示例，展示如何按 Region 数量差生成基本的移动计划：
import org.apache.hadoop.hbase.master.balancer.BaseLoadBalancer;
import org.apache.hadoop.hbase.master.balancer.ClusterInfoProvider;
import org.apache.hadoop.hbase.master.balancer.RegionPlan;
import org.apache.hadoop.hbase.master.region.ServerName;
import java.util.ArrayList;
import java.util.List;
public class SimpleCountBalancer extends BaseLoadBalancer {
@Override
public List<RegionPlan> balanceCluster(ClusterInfoProvider provider) {
List<RegionPlan> plans = new ArrayList<>();
// 获取所有 RegionServer 的 Region 数量
// 选择 Region 数最多的源节点和最少的目�节点
// 构造 RegionPlan 并添加到 plans
return plans;
}
}
将编译后的 jar 包放到 Master 的 classpath 下，然后在 hbase-site.xml 中设置 hbase.master.loadbalancer.class 为该自定义类全限定名即可。自定义均衡器需要小心处理边界条件，避免生成无效计划导致 Region 下线后无法重新上线。
五、监控、排障与最佳实践
要验证负载均衡是否生效，可以通过 Master Web UI 查看每台 RegionServer 上承载的 Region 数量及请求量分布。HBase 也暴露了 JMX 指标，例如 balancer.regionCount 等。若发现某些节点长时间 Region 数量偏高，可以手动执行 balancer 命令，同时观察 Master 日志中输出的迁移计划。
常见问题包括均衡命令执行后没有明显效果、Region 移动期间读写延迟升高、以及频繁均衡导致网络抖动。第一个问题通常是因为 Region 数差小于阈值或者当前存在 Region 处于过渡状态，Master 会跳过本次均衡。第二和第三个问题则与 Region 迁移的固有开销有关。建议在生产环境中将自动均衡安排在业务低峰期，并通过 hbase.balancer.max.balancing.regions 控制单次最大移动 Region 数。
还需要注意，负载均衡只是缓解热点的一种手段。如果某个 Region 持续过热，更有效的办法是进行预分区或热点 Region 手动拆分，从源头降低单 Region 的访问压力。负载均衡策略的选择、成本权重的调整以及 RS Group 的规划应当结合集群实际监控数据持续优化。
HBaseRegion负载均衡StochasticBalancer修改时间：2026-08-21 06:32:18