1.  在Hbase的运维过程中，我们经常需要做如下操作：

  • 移动 regionserver 到其他的 regionserver group中
  • 下线一台机器
  • 增加一台机器
  • 移动 table 到其他 regionserver group中。 

2.  在进行上述操作的过程中，一个 regionserver 上的 regions，或者一个 table 的 regions 都会重新进行分配，这样的分配过程是 HBase 控制的，我们无法控制一个 region 会移动到哪一个 regionserver 上。

3.  在 region 提供服务的过程中，影响服务质量的因素有：

  • regionserver的负载情况，一般来说，region 的数目越多，如果不考虑热键的话regionserver的负载也会越高。
  • regionserver机器的性能，性能越好的机器，可以提供越多的服务，在异构的HBase集群中，尤其明显。对于一些比较重要的表我们会把它们放在性能比较好的机器上。
  • region的cache locality，region在服务的过程中，会通过memstore&blockcache缓冲机制来提高服务的速度，当region迁移后，region会丢失缓冲。
  • data locality，data locality用来衡量region服务的数据即region的HFile位于本地的程度，在region写HFile的时候，根据HDFS的replica策略，至少会有一个备份存储在本地，因此随着时间的推移，region的locality会逐渐趋于1。region迁移的时候，不一定能移动到正好有这个region数据备份的机器上，因此，数据就会从其他节点获取，造成网络开销增加，延迟增加。 

4.  考虑上面情况，我们希望可以人工干预region的迁移，比如下线一台机器之前，我们可以先把它上面的region移动到最合适的位置，然后再把机器下线。我们的移动策略有:

  • cache locality：尽可能保证region的位置不发生移动。
  • data locality：尽可能把region迁移到data locality高的节点。
  • region count：尽可能使得region的数目分配均衡，不给单一节点造成较大的压力。
  • Ability and responsibility：性能越好的机器，需要承担更多的责任。 

5.  总结以上需求，我们需要这样一个工具：

  • 输入1——table 我们需要balance的表，这是我们操作的基本单位。
  • 输入2——server list，我们需要把表中的数据balance到那些机器上，通过用户提供列表可以非常方便实现机器的增加和减少，以及把table上的region移动到指定机器上。在提供server list的时候可以指定机器的性能参数。
  • 输入3——balance的策略 

6.  具体实现可见github：git@github.com:LiuPeien/hbase-balance-util.git