最近一次发现导入10几T数据到HBase(自动分配regions模式)表中，该表只占用55个resions匪夷所思, 根据每个resions存储文件的大小10G（ hbase.hregion.max.filesize设置的值是10G）, hbase表压缩方式为：“SNAPPY”格式.此类压缩比在60%左右. 根据以上计算，数据表最少分配600个resions. 实际通过查看hbase表各个resion的文件大小，发现有的regions文件有600G的数据量，这种数据存储严重异常.
通过数天排查（每个resionServer最大可以分配的resions个数），测试环境的集群中各种尝、验证，最终使用指定分隔点个数去分配regions的方式成功导入数据,并且数据分配也很均衡. (分隔点如何确定：根据全量的rowkey分割600份，然后抽取每份的最后一个rowkey值作为分割点)
此次排查思路主要参考了之前成功导入数据表的meta信息,
查看某个表的meta信息：echo "scan 'hbase:meta'" | hbase shell | grep 'hbase_table_name' , 然后观察每个regions的 startKey 及 endKey
根据hbase的建表手册， 创建hbase表时预分regions有俩种方式：
1、如果整个导入的数据集是已知的，并且也知道所有Hbase表的Rowkey的分布情况，通过Region的startkey和endkey的方式预分区,此种方式完全可以满足存储在每个regions上的数据均衡分布, 这种方式有2种建表方式, 如果分割点比较少，可以在建表语句中直接指定，
1.1、例如：
create 'card_active_quota', {NAME =>'n',VERSIONS => 1, COMPRESSION => 'SNAPPY'}, {SPLITS => ['10', '20', '30', '40']}
以上的分割点是：第一resions是 startkey=>'' endKey=>'10'，第二个regions的startKey => '10' endKey => '20'依次类推, 第五个regions的startkey=>'40' endKey=>''. 规律是第一个region是没有startkey的，最后一个region是没有stopkey的
如果分割点比较多,可以通过splits_file的文件行数预分区regions个数，例如像我们此次通过计算可能需要599个分割点，那么通过把分割点（文件中每一行代表一个分割点）写入文件中，创建表时直接引用分割文件即可，
1.2、例如：
create 'card_active_quota', {NAME =>'n',VERSIONS => 1, COMPRESSION => 'SNAPPY'}, {SPLITS_FILE => '/home/part/splits.txt'}
注意：splits.txt 内容格式：
每一行都认为是分隔点:
400258AD77AD659C7D9B8BB2D718488A016D9074DD39F2AC391AB573C2908017
7FF9001D147A700B73BDD18378C62C47C8D22680718503A7F6E078186086029A
BFEDF91AFE392EDF60CE378C8D2E5CAFDB8D6F0B249CC9A8AF4962788B1D8108
.......
注意：如果 进入hbase shell 是包含 splits.txt 的目录下，那么可以在建表语句中使用
SPLITS_FILE => 'splits.txt' ,同样也可以指定本地文件的绝对路径.
2、导入的数据集是规则的,那么可以通过Hbase的分区算法方式进行分割：目前系统有2种：1、HexStringSplit,2、UniformSplit,3 或在自定义一个实现类的方式进行预分区.如果将来的数据存储是十六进制的那么比较使用 “HexStringSplit”，作为pre-split的算法.
建表语句：
create 'card_active_quota', {NAME => 'n', VERSIONS => 1, COMPRESSION => 'SNAPPY'}, {NUMREGIONS => 3, SPLITALGO => 'HexStringSplit'}".
