HBase基础知识分享(二)

HBase的Split机制

Region的分裂策略

HBase中的Region存储的是一张表的数据。当Region中的数据条数过多时，会直接影响查询效率，过大的Region会被拆分为两个Region，HMaster会将这些分裂的Region分配到不同的RegionServer上，最终达到负载均衡的目的，这是HBase的一个优点。

常见的Region分裂策略：

1. ConstantSizeRegionSplitPolicy

   • 0.94版本前是HBase默认的Region切分策略。
   • 当Region中最大的Store大小超过某个阈值（hbase.hregion.max.filesize=10G）时，触发Region的切分。
   • 然而，这种策略对大表和小表没有明显区分：
     • 大表：阈值设置较大时对大表友好，但小表可能不会触发分裂。
     • 小表：阈值设置较小时对小表友好，但会在集群中产生大量的Region，增加资源管理和failover的负担。

2. IncreasingToUpperBoundRegionSplitPolicy

   • 0.94版本到2.0版本是HBase的默认切分策略。
   • 切分阈值基于Region的数量动态调整，随着Region数量的增加，切分阈值逐渐增大，避免大量小Region的产生。
   • 该策略更加自适应大表、小表，但对小表不太友好，可能导致大量小Region分布在不同RegionServer上。

3. SteppingSplitPolicy

   • 2.0版本后默认的切分策略。
   • 简单高效。根据Region数量调整切分阈值：
     • 当Region数目为1时，使用较小的阈值（128M*2）。
     • 否则，使用最大Region文件大小（MaxRegionFileSize）。
   • 对大集群的适应性好，不会导致大量的小Region，并且较适用于小表。

4. KeyPrefixRegionSplitPolicy

   • 根据RowKey的前缀进行数据分区，例如RowKey是16位，指定前5位作为前缀进行切分。

5. DelimitedKeyPrefixRegionSplitPolicy

   • 与KeyPrefixRegionSplitPolicy类似，但切分时使用指定的分隔符，例如RowKey格式为userid_eventtype_eventid，指定_为分隔符进行切分。

6. BusyRegionSplitPolicy

   • 依据Region是否“繁忙”来判断是否需要拆分。如果系统常常会出现热点Region，并且对性能有较高要求，可以考虑使用此策略。

7. 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时。