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数目为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时。
