hbase的bulk load一个小改造(续)

之前写了一篇文章hbase的bulk load一个小改造，最近在这个改造的基础上做了一些性能测试，呵呵，在这期间发现了新的问题，对此也有了一些新的认识，在这里分享一下，欢迎大家拍砖。

之前提到hbase的bulk load是一个mapreduce任务，其中reduce的数目是表的region数目来决定的，这一点一直没有理解hbase为什么要这么做。呵呵，前两天对一个有200多个region的表进行入库，按照bulk load的原有策略reduce应该是200，不过我将这一块改成了按照输入文件大小来进行计算reduce数目，这样问题就出现了：当一个表的region数目很多，且每个rowkey对应的数据很多的时候，每个region的startKey和endKey的区间就很小，在bulk load生成的每个hfile的区间大于region的区间，这样completebulkload时检查每个hfile的区间不在region的区间范围内，就去split这个hfile，这样需要重写hfile，所以入库的效率就降下来了，呵呵，这也是hbase为什么要用region的数目来设置reduce的数目了。

结合这个问题和上一篇文章hbase的bulk load一个小改造中提到的问题，我想到了两个方案来解决：

方案1：bulk load的数目还是根据region的数目来计算，在创建表的时候预先创建几个region（如果每次入库的文件比较大，可以考虑多创建几个region），这样reduce的数目是大于1的，效率一定有所提高，这样也不会导致split生成的hfile；

方案2：对一张没有region的表入库，可以按照输入文件的大小来计算region的数目，这个策略根据自己的场景需要来定，我们为了避免频繁的compact操作，所以reduce数目是根据输入文件大小和region的大小来计算的；对有region的表入库，那么就按照region数目来设置reduce个数。