HBase基于region数目和data locality来balance regions

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