HBase的Split机制
Region的分裂策略
HBase中的Region存储的是一张表的数据。当Region中的数据条数过多时，会直接影响查询效率，过大的Region会被拆分为两个Region，HMaster会将这些分裂的Region分配到不同的RegionServer上，最终达到负载均衡的目的，这是HBase的一个优点。
常见的Region分裂策略：
-
ConstantSizeRegionSplitPolicy
- 0.94版本前是HBase默认的Region切分策略。
- 当Region中最大的Store大小超过某个阈值（
hbase.hregion.max.filesize=10G）时，触发Region的切分。 - 然而，这种策略对大表和小表没有明显区分：
- 大表：阈值设置较大时对大表友好，但小表可能不会触发分裂。
- 小表：阈值设置较小时对小表友好，但会在集群中产生大量的Region，增加资源管理和failover的负担。
-
IncreasingToUpperBoundRegionSplitPolicy
- 0.94版本到2.0版本是HBase的默认切分策略。
- 切分阈值基于Region的数量动态调整，随着Region数量的增加，切分阈值逐渐增大，避免大量小Region的产生。
- 该策略更加自适应大表、小表，但对小表不太友好，可能导致大量小Region分布在不同RegionServer上。
-
SteppingSplitPolicy
- 2.0版本后默认的切分策略。
- 简单高效。根据Region数量调整切分阈值：
- 当Region数目为1时，使用较小的阈值（
128M*2）。 - 否则，使用最大Region文件大小（
MaxRegionFileSize）。
- 当Region数目为1时，使用较小的阈值（
- 对大集群的适应性好，不会导致大量的小Region，并且较适用于小表。
-
KeyPrefixRegionSplitPolicy
- 根据RowKey的前缀进行数据分区，例如RowKey是16位，指定前5位作为前缀进行切分。
-
DelimitedKeyPrefixRegionSplitPolicy
- 与
KeyPrefixRegionSplitPolicy类似，但切分时使用指定的分隔符，例如RowKey格式为userid_eventtype_eventid，指定_为分隔符进行切分。
- 与
-
BusyRegionSplitPolicy
- 依据Region是否“繁忙”来判断是否需要拆分。如果系统常常会出现热点Region，并且对性能有较高要求，可以考虑使用此策略。
-
DisabledRegionSplitPolicy
- 不启用自动拆分，需要手动拆分Region。
RowKey设计的原则
1. RowKey唯一原则
- RowKey必须保证唯一性，HBase是按照字典顺序存储数据的，因此设计RowKey时应充分利用这种特性，将常访问的数据存储在同一区域。
2. RowKey长度原则
- RowKey的长度一般建议不超过100字节。过长的RowKey会占用更多的内存和存储空间，影响HFile的存储效率，同时减少MemStore和BlockCache的缓存效率，降低检索效率。
3. RowKey散列原则
- 如果RowKey按照时间戳等递增模式设计，可能导致热点问题。为了避免这种问题，可以将RowKey的高位设计为散列字段，低位放置时间戳等字段，这样可以将数据均衡分布到不同RegionServer上，避免热点。
HBase热点问题
1. 什么是热点问题？
- 在HBase中，数据按照RowKey排序并存储。如果某些RowKey频繁被访问，数据会集中存储在同一个Region，可能导致：
- 某个Region的负载过高。
- 某个RegionServer被过度请求，成为瓶颈。
- 集群负载不均，造成资源浪费和性能瓶颈。
2. 导致热点问题的原因
- 顺序写入：如使用递增的ID或时间戳，导致写入操作集中在同一个Region。
- 过度集中在某些RowKey范围：某些特定的RowKey频繁被访问，导致特定Region频繁被请求。
- RowKey缺乏随机性：如果RowKey设计缺乏随机性，访问会集中在某个Region，导致负载不均。
3. 如何避免和解决热点问题
- 随机化RowKey：例如在RowKey前加上随机数，或者使用逆序时间戳来避免顺序写入带来的热点问题。
- 使用时间区间分区（预分裂）：在表创建时进行预分裂，将RowKey按时间或其他特征进行分区，避免数据集中在某个Region。
- 更复杂的RowKey设计：例如使用复合型RowKey，结合多种字段（如用户ID、时间戳等）进行设计，从而实现数据的均匀分布。
- 动态扩展与负载均衡：通过Region Split或Region Merge操作，及时调整Region的分布，解决热点问题。
- 监控与调优：实时监控RegionServer的负载情况，通过调整策略解决热点问题。
HBase的Flush机制
触发条件
- Region中的MemStore占用内存超过阈值：如果MemStore的占用内存超过
hbase.hregion.memstore.flush.size（默认为128MB），会触发Flush操作。 - RegionServer的MemStore占用内存超过阈值：当RegionServer中所有Region的MemStore占用内存超过阈值时，Flush操作会被触发。
- WAL数量超过阈值：如果RegionServer的WAL数量或大小超过某个阈值，MemStore会被触发Flush。
- 定期自动刷写：通过定期检查MemStore，触发定时的Flush操作。
触发操作
常见的操作，如put、delete、append、incr等，会触发Flush操作。此外，Region的分裂、Merge操作、bulkLoad HFiles、快照等操作也会触发Flush。
Flush策略
- FlushAllStoresPolicy：每次刷写都会触及Region中的所有MemStore。
- FlushAllLargeStoresPolicy：首先判断MemStore是否超过某个阈值，如果超过则触发刷写。
- FlushNonSloppyStoresFirstPolicy：优先刷写内存占用大的、非Sloppy类型的MemStore。
HBase的Compaction机制
Minor Compaction
Minor Compaction指的是将相邻的小StoreFile合并为更大的StoreFile，不会处理已删除或过期的数据。结果是StoreFile变少，文件更大。
Major Compaction
Major Compaction会将所有StoreFile合并为一个StoreFile，并清理无效数据（如已删除的数据、过期数据）。这一过程消耗大量资源，通常会在低峰时手动触发。
二级索引
- 基于一级索引之上构建的索引。
- 为什么构建二级索引：HBase默认的RowKey是唯一且只能做前缀匹配查询，查询条件如果不是RowKey的前缀，查询效率较低。通过二级索引可以提高查询性能，尤其是当查询条件不包含RowKey时。