HBase根本知识分享(二)

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，而且较适用于小表。
    
  
  
• 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时。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。