文章目录

  • 基于 MemStore flush触发的生产调优
  • memstore级别限制:
  • region级别限制：
  • RegionServer 级别限制 （影响最大）：
  • Hlog级别限制
  • 定期级别限制
  • 手动级别
  • HBase 合并
  • 合并 Compaction
  • 影响：
  • 触发条件:



hbase meta可以多大 hbase memstore大小_hbase meta可以多大

hbase meta可以多大 hbase memstore大小_数据_02

基于 MemStore flush触发的生产调优

memstore其实是一个内存结构存储，一个CF对应一个memstore。HBase触发flush操作有memstore级别，region级别，RegionServer级别。但是memstore的flush最小单元是Region，而不是单纯的Memstore,所以如果一个Region 中Memstore过多的话，每一次flush的开销会很大，所以要尽量减少CF的个数，一般生产上一个表中CF的个数不超过3个。

memstore级别限制:

当region的任意一个memstore的size ，达到
hbase.hregion.memstore.flush.size 128M(默认)，会触发flush
建议调至：
hbase.hregion.memstore.flush.size 512M (建议调大到128的倍数 如256M，512M)

region级别限制：

当region所有的memstore的size和达到某个值会触发flush
参数默认：
hbase.hregion.memstore.block.multipiler * hbase.hregion.memstore.flush.size = 2 * 128M=256
建议调至：
hbase.hregion.memstore.block.multipiler * hbase.hregion.memstore.flush.size = 4 * 512M=2G

RegionServer 级别限制 （影响最大）：

一旦触发Region Server级别限制导致flush，就会对用户请求产生较大的影响。会阻塞所有落在该Region Server上的更新操作，阻塞时间很长，甚至可以达到分钟级别。

当regionserver的所有的memstore的size之和，超过低水位线 ,RS强制flush,先从memstore最大的region开始，以此类推，直到总的memstore大小下降到低水位线

Java Heap Size of HBase RegionServer in Bytes 50M -Xmx
RS使用的总堆内存大小，默认为50M，需要提高，但是不推荐超过32G(要不然 指针压缩失效)除非生产上是实打的物理机，性能强悍，且是GPU的哪种资源配置。
这里我司调整到了 48G，别问为啥，因为性能强悍 有钱。

hbase.regionserver.global.memstore.size
hbase.regionserver.global.memstore.upperLimit 0.4 (默认0.4，不用调)
========> 每个RS的memstore使用的默认情况下最大为 50M * 0.4 =20M
hbase.regionserver.global.memstore.size.lower.limit 0.95(默认) ==> 0.91 (可以稍微调小到0.91目的是使得 低水位线到达最高点的水位线空间增大，说白了也就是使得低水位线再往下移一点）
hbase.regionserver.global.memstore.lowerLimit

========> 50M * 0.4 = 20M * 0.95 = 19M 默认不调之前

========> 48G * 0.4 * 0.91=17.47 G

如果此时继续繁忙写，导致regionserver就会阻塞读写请求，并且强制flush,直到总的memstore大小下降到低水位线

Hlog级别限制

当一个Region Server中HLog数量达到上限，系统会选取最早的一个HLog对应的一个或多个Region进行flush
hbase.regionserver.maxlogs 32 * 128M=4G （系统默认） 但是一般也是不用调

定期级别限制

默认周期为1小时，确保Memstore不会长时间没有持久化

手动级别

用户可以通过shell命令flush 'tablename’或者flush 'region name’分别对一个表或者一个Region进行flush，也可以写定时脚本进行调度执行。

HBase 合并

hbase meta可以多大 hbase memstore大小_hbase meta可以多大_03

合并 Compaction

flush将memstore数据形成一个hfile(storefile),
hdfs上会形成很多hfile，对读请求不是很友好。
所以设计上需要去合并（小文件合并）

  • 小合并：minor compaction
    选取部分小的 相邻的hfile文件，形成一个较大的hfile
  • 大合并：major compaction 将一个Store中的所有的StoreFile（HFile)合并成一个StoreFile
    清理以下数据:
    TTL过期数据
    put 多版本中超过设定版本的数据
    delete 的数据
影响：

Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发。
少做大合并 ，因为大合并持续时间较长。会消耗集群的 带宽和磁盘io

所以 生产上 不要自动大合并
hbase.hregion.majorcompaction 7天 （默认是7） 将此参数设置为0 就是禁止自动合并
hbase.hregion.majorcompaction.jitter 0.5，
6.5-7.5
改为手动：
major_compact ‘namespace:table’

触发条件:
  • memstore flush之后，都要对当前的store的文件数量进行判断,一旦大于 hbase.hstore.compactionThreshold =3 ，就触发 合并操作
  • 后台定期检查

hbase meta可以多大 hbase memstore大小_hbase 生产调优_04