在HBase中，表的行键按字节序排序，数据被切分成若干Region，每个Region由对应RegionServer负责读写。如果建表时不指定预分区，HBase默认只创建一个Region，所有写入都会落到同一个RegionServer。随着写入量增加，该Region虽然会触发自动分裂，但分裂时机和分裂点来自已有数据分布，难以保证均匀。预分区Pre-splitting的核心价值在于提前划定Region边界，把热点压力从表创建之初就分散开。
实施预分区并不是简单地把行键范围等分。SplitKey是Region的起始行键边界，必须与RowKey设计协同考虑。如果行键本身带有单调递增属性，例如时间戳或自增ID，即使预分区也会出现最后一个Region承担全部新写入的问题。更合理的做法是先对行键做哈希或加盐处理，再用固定长度的十六进制或数字边界进行切分。
一、自动分裂为什么不能替代预分区
HBase的自动分裂策略根据Region中StoreFile大小触发，但早期版本默认使用IncreasingToUpperBoundRegionSplitPolicy。当一个表的Region数量较少时，分裂阈值会随着Region数量增加而逐步放大。例如只有一个Region时，要等到StoreFile达到1GB甚至更大才会分裂。这意味着在较长一段时间内，所有写入压力都集中在同一个RegionServer上，其他节点处于空闲状态。
自动分裂的另一个问题是分裂点由实际写入数据分布决定。假设行键设计不理想，写入大部分集中在某个前缀范围内，自动分裂可能只是在热点Region内部继续切分，无法把压力均匀迁移到其他节点。预分区则允许从建表开始就指定若干边界，让每个Region覆盖相近的行键区间。对于可预测的写入规模，人工规划的成本远小于事后频繁调优。
此外，Region分裂过程并非零开销。父Region需要先下线，然后生成两个子Region，同时更新hbase:meta元数据。这个过程中读取和写入可能出现短暂延迟，如果分裂频繁发生在热点数据上，对在线业务影响更明显。预分区能减少初期不必要的自动分裂次数，让集群负载更平稳地增长。
二、SplitKey生成策略与RowKey设计配合
SplitKey定义一组按字典序递增的字节数组，每个元素作为Region的起始行键。例如三个SplitKey可以把表切成四个Region：第一个Region覆盖小于10000000的行键，第二个覆盖10000000到20000000之间的行键，依此类推。边界数组必须严格递增，一旦出现乱序或重复，建表命令会直接抛出IllegalArgumentException。
RowKey设计要优先保证写入的离散性。如果直接使用手机号或用户ID等分布较离散的字段，可以截取其哈希值的高位作为前缀。例如RowKey采用MD5(userId)的前4字节加原始用户ID，这样连续用户ID经过哈希后会被打散分布到不同Region。HBase Shell可以使用SPLITS参数手动传入边界：
create 'orders','info',SPLITS=>['10000000','20000000','30000000','40000000']
如果行键已经做了十六进制哈希，HBase还提供了HexStringSplit和UniformSplit算法。前者会在00000000到FFFFFFFF之间均匀生成边界，后者在00到FF之间生成边界。对于自定义业务前缀，建议先通过采样统计实际行键分布，再生成精确的SplitKey数组。Java API方式如下：
byte[][] splitKeys = new byte[][] {
Bytes.toBytes("10000000"),
Bytes.toBytes("20000000"),
Bytes.toBytes("30000000"),
Bytes.toBytes("40000000")
};
TableDescriptor desc = TableDescriptorBuilder
.newBuilder(TableName.valueOf("orders"))
.setColumnFamily(ColumnFamilyDescriptorBuilder.of("info"))
.build();
admin.createTable(desc, splitKeys);
三种方式各有适用场景：HexStringSplit适合行键经过哈希后呈均匀十六进制分布的情况；UniformSplit适合小范围行键且能接受边界粒度较粗的场景；自定义SplitKey数组则最灵活，但需要提前了解数据分布，通常用于生产环境。
三、HBase Shell实施步骤与效果验证
完整实施预分区时，首先要根据预估数据量和Region目标大小计算分区数。假设单Region目标大小为10GB，预估总数据量为200GB，则至少需要20个Region。根据RowKey前缀规则生成19个递增的SplitKey，然后执行建表命令。除了直接传入SPLITS数组，还可以使用NUMREGIONS配合SPLITALGO：
create 'orders','info',{NUMREGIONS=>16,SPLITALGO=>'HexStringSplit'}
建表后需要验证Region是否按照预期划分。HBase Shell中的list_regions命令可以查看表对应的所有Region起始键和所在RegionServer，输出中能看到每个Region覆盖的行键区间。不同版本可能没有提供该命令，此时可以直接扫描hbase:meta表，观察Region的startKey和endKey。若发现Region数量与预期不符，说明边界设置存在遗漏或错误。
验证写入是否均匀同样重要。可以构造一批符合RowKey规则的测试数据，通过批量写入后观察各RegionServer请求量和Region大小变化。一般通过HBase Web UI查看RegionServer的读写请求数分布，或者使用status 'detailed'命令查看Region负载。如果某个Region写入量仍然远高于其他Region，需要检查RowKey设计是否存在热点前缀，而不是继续增加分区。
四、分区数量规划与常见误区
分区数量并非越多越好。预分区后每个Region都会占用RegionServer内存，Region过多会导致元数据管理和Compaction开销上升。通常建议单Region数据量维持在5GB到20GB之间，同时保证每个RegionServer管理的Region数量不超过200个左右。假设集群有5个RegionServer，总预估数据量为500GB，可先按每Region 10GB计算得到50个Region，再结合节点数量调整，避免过度细分。
一个常见误区是只做预分区但忽略RowKey顺序性问题。例如直接以时间戳作为RowKey，即使建表时预设了20个Region，新写入仍然集中在最后一个Region，因为时间戳单调递增，所有新数据的行键都大于最后一个SplitKey。正确方法是对时间戳取模或反转，或者在其前面拼接哈希前缀。还有人在升级表结构时只改了预分区数，却没有同步调整写入端RowKey生成规则，导致分区边界与数据分布脱节。
如果需要生成一组均匀的自定义边界，可以参考下面的Python脚本。它按两位十六进制生成15个中间边界，将行键空间切分为16个区间：
# 生成15个均匀分布的split keys，切分16个Region
splits = []
for i in range(1, 16):
key = format(i * 16, '02x')
splits.append(key)
print(splits)
预分区实施后如果发现数据倾斜仍然存在，可以先评估是否扩容RegionServer或采用加盐前缀重新设计行键。生产环境一般不会频繁重建表，因此前期结合业务增长趋势做好规划，远比重建表迁移数据更划算。
可以。