前言：在系统中向hbase中插入数据时，常常通过设置region的预分区来防止大数据量插入的热点问题，提高数据插入的效率，同时可以减少当数据猛增时由于Region split带来的资源消耗。大量的预分区数量会导致hbase客户端缓存大量的分区地址，导致内存的增长，某些系统中一个JVM进程中会开启几十个独立的hbase客户端对象，同时会查询多张Hbase表，这样JVM进程就会缓存 (预分区数 X 表数 X Hbase客户端数=条记录)。

　　有没有这种情况?有的，在本人的storm项目中，采用结合spring注入的方式来结合Hbase向hbase存入数据，storm中的每一个线程都会创建一个XmlBeanDefinitionReader对象来加载spring的配置文件，所以一个线程就有一个hbse客户端对象了，同时Hbase表设置102预分区，一个topology会操作最少8张表，一个worker会走20个task。所以一个work会缓存大约102*8*20=16320条记录，每一条记录的数据格式大致就是hbase.meta的一条数据格式，经过我计算16000多条记录一个JVM中占用内存也就5M多，对内存的消耗是完全可以忽略不计的。这就很尴尬了。这种优化只是对于大规模的集群来说有效果，小规模集群考虑这种情况是过度设计了。比如那种Hbase客户端会有缓存一整张hbase.meta表数据的系统又或者那种hbase表分区达到上万的系统，那么一个woeker中地址的缓存会达到几百兆，这个时候从原理上就可以进行设计了来节省资源消耗，想想可以省好多台服务器。

　　说了这么多，如何来进行系统资源优化？可以结合storm的自定义分区，不再使用storm提供的分组策略，我们把作用于hbase的散列算法来作为storm的分组策略，就可以得到storm的task与hbase的预分区一一对应了。

以前的系统：

　　

　　消息进来了以后，由spout均匀的发送到各个intsmaze-bolt节点上，每一个bolt节点再使用三楼算法把该消息存入对应的hbase表分区中。

现在的系统:

　　

　　消息进来了以后，spout在进行发送给intsmaze-bolt的时候，在分组策略中使用与hbase同样的散列算法，然后把同一范围内的消息发送给对应的intsmaze-bolt的taske,这样就可以保证bolt的并行度与hbase的预分区一一对应，每一个taske中的hbase客户端只会缓存对应的几个hbase的表预分区的地址信息。

　　关于storm的自定义分组的实现可以百度，这里不给出代码实现，只给出实现方案。补充一句，散列算法设计的好，是可以保证消息在storm的bolt里的task分发中不会发生数据倾斜的。

看看Hbase1.1.2的客户端源码吧:

会先到zookeeper中拿到hbase.meta的地址信息，hbase.meta里面存储着所有用户表各个分区的地址已经rowkey的范围：

locations= [region=hbase:meta,,1.1588230740, hostname=centos-reall-132,16020,1490876417048, seqNum=0]

这里就好把表名和该表的地址等元数据缓存下来，下次就不用走网络去获取了。下面就会第一次缓存hbse.meta表的数据信息。

当大量的向某个分区表插入数据后，metaCache中就有下面的数据:

{hbase:meta={[B@e09300c=[region=hbase:meta,,1.1588230740, hostname=centos-reall-132,16020,1490876417048, seqNum=0]}, t_regin_demo={[B@f01dde6=[region=t_regin_demo,10|,1480171499299.e94245285fb3fbfe3dd3bb7e9c632be8., hostname=centos-reall-132,16020,1490876417048, seqNum=50], [B@438f2ebc=[region=t_regin_demo,20|,1480171499299.b9bee9aad30185f682d943172136966b., hostname=centos-reall-132,16020,1490876417048, seqNum=50], [B@6d455b4a=[region=t_regin_demo,30|,1480171499299.144c892d9a29739d46c3561c431326ac., hostname=centos-reall-132,16020,1490876417048, seqNum=53], [B@646c8f51=[region=t_regin_demo,40|,1480171499299.f5c53075ed5f26cf1001ffd7d12101d1., hostname=centos-reall-132,16020,1490876417048, seqNum=50], [B@13354259=[region=t_regin_demo,50|,1480171499299.2d3eff976bd362e338be87e6eb8b8e42., hostname=centos-reall-132,16020,1490876417048, seqNum=50], [B@d96eae9=[region=t_regin_demo,60|,1480171499299.67c0711ff634ad63a81e2d3c753cf9f6., hostname=centos-reall-132,16020,1490876417048, seqNum=50], [B@2f186df7=[region=t_regin_demo,70|,1480171499299.78c04fabbb1fb9aebc4600ff653eb3d8., hostname=centos-reall-132,16020,1490876417048, seqNum=47], [B@6cdb8b48=[region=t_regin_demo,80|,1480171499299.b7ae8e09ddea0faea2360897add9b18f., hostname=centos-reall-132,16020,1490876417048, seqNum=56], [B@41955bcd=[region=t_regin_demo,90|,1480171499299.8ac30f51ea6143b509b84e62ed62db7a., hostname=centos-reall-132,16020,1490876417048, seqNum=50]}}