Hbase_三大内部原理

Hbase三大内部原理

1.memstore flush

Flush操作就是将memstore内存当中的数据持久化到磁盘,也就是Hfire上,Flush后的文件都是小文件

• 自动触发
  2.0之前

  • region的memstore的触发
    达到memstore的阈值就自动触发

  hbase.hregion.memstore.flush.size=128M

  • 当memstore数据写入速度很快时：4倍的flush.size,也就是512M
  • regionserver的触发级别：所有region所占用的memstore达到阈值，就会 触发整个regionserver中memstore的溢写，从memstore占用最多的Regin开始flush
  • region分区数据占 rs的jvm内存的40%
    2.0之后
    设置flush的最小阈值

  memstore的判断发生了改变：
  max(
  "hbase.hregion.memstore.flush.size / column_family_number",
  hbase.hregion.percolumnfamilyflush.size.lower.bound.min
  )
  其中：
  hbase.hregion.memstore.flush.size=128M
  hbase.hregion.percolumnfamilyflush.size.lower.bound.min=16M

  相当于 水位线 = max(128/列族个数 , 16M) 进行对比

• 工作当中 手动触发,为了避免 flush过程当中大量的资源消耗在服务器io的高峰期,我们一般在工作中手动flush

自动Flush的阈值

---

2.StoreFile Compaction

• minor compaction 小合并
  1.将规定数量的StoreFile==合并成一个StoreFile==,简单的数量合并
  2.占用资源不多

hbase.hstore.compaction.min=3

• maxor 大合并
  1.将所有的StoreFile==文件合并成一个大的StoreFile,整体有序
  2.合并过程,会清理过期数据,和已经被删除的数据
  3.占用资源量巨大
  所以Hbase当中真正的数据删除发生在大合并的时候
• 2.0之后 In-memory compaction。
  在内存中进行数据合并,将存入memstore的数据化成,一个个 segment然后将其合并

hbase.hregion.compacting.memstore.type=None|basic|eager|adaptive

basic 基础型
不清除多余版本,适用于大数据量写模式
eager（饥渴型）
过滤重复的数据，清理多余的版本，这会带来额外的开销

adaptive（适应型）

adaptive compaction根据数据的重复情况来决定是否使用eager策略
找出cell个数最多的一个，然后计算一个比例，如果比例超出阈值，则使用eager策略，否则使用basic策略

工作当中 手动选择合并
在工作中要避免自动触发major compaction，影响业务，所以禁用自动进行major compaction。

hbase.hregion.majorcompaction=0

---

3.region split

当一个region内的数据量特别大的时候,region就会分裂成两个region

• region阈值

hbase.hregion.max.filesize=10GB
达到这个阈值后,region会分裂成两个5g的region

-0.94开始：如果region个数在0 ` 100之间
-2.x 开始 判断region的个数是否为1,为1安256m分 不唯一按照10gb分

• region 预分区
  建表的时候 手动的指定分割端 实现预分区

create 'itcast:t6','cf1',SPLITS =>['a','b','c']
#这样建表 直接就有了4个分区  叫做预分区
#再结合rowkey的设计 把不同的数据存储在不同的region中  

工作当中建议手动操作