HBase详细介绍及原理解析！( 五 ) _HBase

这种切分策略对于大集群中的大表。

小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小Region，而是适可而止。

KeyPrefixRegionSplitPolicy：

根据RowKey的前缀对数据进行分组，这里是指定RowKey的前多少位作为前缀，比如RowKey都是16位的，指定前5位是前缀。
那么前5位相同的RowKey在进行region split的时候会分到相同的Region中。

DelimitedKeyPrefixRegionSplitPolicy：

保证相同前缀的数据在同一个Region中，例如RowKey的格式为：userid_eventtype_eventid，指定的delimiter为_ 。
则split的的时候会确保userid相同的数据在同一个Region中。

DisabledRegionSplitPolicy:

不启用自动拆分，需要指定手动拆分。

预分区当一个table刚被创建的时候，HBase默认的分配一个Region给table 。

这时所有的读写请求都会访问到同一个RegionServer的同一个Region中。
这个时候就达不到负载均衡的效果了，集群中的其他RegionServer就可能会处于比较空闲的状态。

解决办法：

可以用预分区（pre-splitting），在创建table的时候就配置好，生成多个Region 。

如何预分区？

每一个Region维护着startRow与endRowKey 。
如果加入的数据符合某个Region维护的RowKey范围，则该数据交给这个Region维护。

手动指定预分区:
create 'person','info1','info2',SPLITS => ['1000','2000','3000','4000']

Region定位HBase 支持 put，get ， delete 和 scan 等基础操作，所有这些操作的基础是 region 定位。
region 定位基本步骤:
客户端与 ZooKeeper 交互，查找 hbase:meta 系统表所在的 Regionserver 。
hbase:meta 表维护了每个用户表中 rowkey 区间与 Region 存放位置的映射关系，具体如下:

rowkey : table name ， start key，region id 。
value : RegionServer 对象(保存了 RegionServer 位置信息等) 。

客户端与 hbase:meta 系统表所在 RegionServer 交互，获取 rowkey 所在的 RegionServer 。
客户端与 rowkey 所在的 RegionServer 交互，执行该 rowkey 相关操作。
需要注意:

客户端首次执行读写操作时才需要定位 hbase:meta 表的位置。
之后会将其缓存到本地，除非因 region 移动导致缓存失效，客户端才会重新读取 hbase:meta 表位置，并更新缓存。

文章插图
读写流程读操作：
首先从 ZooKeeper 找到 meta 表的 region 位置，然后读取hbase:meta 表中的数据，hbase:meta 表中存储了用户表的 region 信息。
根据要查询的 namespace 、表名和 rowkey 信息，找到写入数据对应的 Region 信息。
找到这个 Region 对应的 RegionServer ，然后发送请求。
查找对应的 Region 。
先从 MemStore 查找数据，如果没有，再从 BlockCache 上读取。