一个region就是表一段RowKey的集合，当Region太大的时候Hbase会拆分它；
因为某个Region太大的时候读取效率太低了。查询的本质是遍历key，当数据量太大的时候，遍历一遍的时间实在是太长了，为了提高效率，Hbase会拆分Region。
自动拆分
对于切分点是如何让定位呢
region切分策略会触发region切分，切分开始之后的第一件事是寻找切分点－splitpoint。所有默认切分策略，无论是ConstantSizeRegionSplitPolicy、IncreasingToUpperBoundRegionSplitPolicy抑或是SteppingSplitPolicy，对于切分点的定义都是一致的。当然，用户手动执行切分时是可以指定切分点进行切分的，这里并不讨论这种情况。
那切分点是如何定位的呢？整个region中最大store中的最大文件中最中心的一个block的首个rowkey。这是一句比较消耗脑力的语句，需要细细品味。另外，HBase还规定，如果定位到的rowkey是整个文件的首个rowkey或者最后一个rowkey的话，就认为没有切分点。
什么情况下会出现没有切分点的场景呢？最常见的就是一个文件只有一个block，执行split的时候就会发现无法切分。很多新同学在测试split的时候往往都是新建一张新表，然后往新表中插入几条数据并执行一下flush，再执行split，奇迹般地发现数据表并没有真正执行切分。原因就在这里，这个时候仔细的话你翻看debug日志是可以看到这样的日志滴:
除了前面的自动拆分，还可以手动拆分；
Hbase的热点问题
连续的rowkey的数据会进入到一个region里面，如果有多个region，但是其中一个region例rowkey范围的数据太多了，那么就会出现热点问题，可以在每条数据前面加上一个hash值，让它进入到不同的region里面去。
因为region的split很消耗性能，我们可以提前把分区定好，这里就涉及到根据业务的实际需求，设计合理的rowkey和分区间隔点
如果预先分区好了，但是某一个分区数据太大，自己分裂，但是分裂了就违背了我们预先分区的初衷（我们可能需要使一些区段连续的rowkey在一起）。创建表的时候我们也可以指定自动的分区策略！
那么可以进行 新建表，规划更细的预分区，重新导入数据
随机分布加预分区也不是一劳永逸的。因为数据是不断地增长的，随着时间不断地推移，已经分好的区域，或许已经装不住更多的数据，当然就要进一步进行split了，同样也会出现性能损耗问题，所以我们还是要规划好数据增长速率，观察好数据定期维护，按需分析是否要进一步分行手工将分区再分好，也或者是更严重的是新建表，做好更大的预分区然后进行数据迁移。小吴只是菜鸟，运维方面也只是自已这样认为而已，供大家作简单的参考吧。如果数据装不住了，对于partition方式预分区的话，如果让它自然分裂的话，情况分严重一点。因为分裂出来的分区号会是一样的，所以计算到partitionId的话，其实还是回到了顺序写年代，会有部分热点写问题出现，如果使用partition方式生成主键的话，数据增长后就要不断地调整分区了，比如增多预分区，或者加入子分区号的处理.(我们的分区号为long型，可以将它作为多级partition)
