1. 背景
HBase建表时默认只有一个region，这个region的rowkey是没有边界的，即没有startkey和endkey。在数据写入时，所有数据都会写入这个默认的region。随着数据量的不断增加，这个默认的region会越来越大，当达到某个阈值会自动split成为2个region。此外，频繁的region split操作会严重影响Hbase集群的性能。
所以，一般推荐在建表时进行预分区，充分考虑rowkey的分布做出合理的预分区方案。
2. 不使用预分区存在的问题
2.1 写热点问题（所有新数据都往一个region上写）；
首先，是热点写，我们总是会往最大的start-key所在的region写东西，因为我们的rowkey总是会比之前的大，并且hbase的是按升序方式排序的。所以写操作总是被定位到无上界的那个region中。
其次，由于写热点，我们总是往最大start-key的region写记录，之前分裂出来的region不会再被写数据，有点被打进冷宫的赶脚，它们都处于半满状态，这样的分布也是不利的。
2.2 region split会消耗宝贵的集群I/O资源
如果在写比较频率的场景下，数据增长快，split的次数也会增多，由于split是比较耗时耗资源的，所以我们并不希望这种事情经常发生。
3. Hbase预分区
Hbase预分区是指，在建表的时候创建多个空region，并确定每个region的start-key和end-key，这样只需保证rowkey能够均匀的分布在每个Region中，就能有效避免写热点问题。例如，使用随机散列与预分区结合的方式，预分区一开始就预建好了一部分region，这些region都维护着自已的start-end keys，再配合上随机散列，写数据能均等地命中这些预建的region，就能解决上面的问题，大大地提高性能。
4. 预分区的设计
4.1 设计原则
Hbase的预分区主要根据Rowkey的分布情况来确认，结合Hbase集群配置情况来确定。
4.2 Region个数上限
RegionServer的region数目取决于memstore的内存使用。memstore的数量由hstore决定，Hstore的数据由创建表时的指定的列族个数决定。所以，每个region的memstore的个数 = 表的列族的个数 。可以通过配置来修改memstore占用内存的大小，一般设置在 128 M – 256M之间，默认为128M。
每一个Region都存储着一些列(a set of rows)。根据其列族的不同，将这些列数据存储在相应的列族中(Column Family，简写CF)。不同的CFs中的数据存储在各自的HStore中，HStore由一个Memstore及一系列HFile组成。Memstore位于RS的主内存中，而HFiles被写入到HDFS中。
大数据量情况下越发需要并行处理，因此我们往往希望源表的region的个数多一些。但是同时也要考虑集群的承载能力，HBase的region个数上限可以参考官网给出的如下公式：
((RS Xmx) *hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size *(# column families))
((RS memory) * (total memstore fraction)) / ((memstore size)*(# column families))
其中，RS Xmx是regionserver的内存堆栈大小，官网建议每台20~24或更小，因为过大的内存会导致GC时间过长。
注意：
实际测试发现大于这个数一两倍也没太大的问题。 一个HBase表包含一至多个region，那么表的数目上限也是可以估算出来的。
例如：
如果 一个RegionServer配置的内存是16G，使用默认配置（ hbase默认regionserver分给memstore的比例是0.4 ， 默认的menstore的占用128M内存 ）， 一个列族，那么这个regionServer下的region的个数大约为 16384 * 0.4 / （128*1） = 51个，实际测试大于这个数一两倍也没太大的问题。 一个HBase表包含一至多个region，那么表的数目上限也是可以估算出来的。
4.3 Region的大小
对于生产场景中大表，最大的region大小主要是受compactions 的限制，大量大HFile的compact会降低群集性能。目前，该建议的最大region大小为10-20GB，而5-10GB是最优。