Tag - HBase

HBase    2019-04-20 07:51:28    23    0    0

1. 场景

推荐相关业务数据存储在HBase中,由线上接口进行实时读写。在推荐系统项目初期,通常采用的是离线规则推荐,数据量少,T+1更新,不会对线上HBase有压力。随着实时推荐和千人千面的开展,大量的HBase读写导致HBase读取出现毛刺,影响线上业务稳定性,需要进行针对性调优。

如图,虽然平均读取时间(蓝色)相对稳定,但经常有个别client出现读取毛刺,导致读取熔断(橙色):
图片标题

2. 目标

在支持后续qps继续上升的基础上,消除90%毛刺

3. 瓶颈分析

调优的第一要素:

无监控不调优

首先需要通过监控分析出当前系统的瓶颈所在,常见的HBase瓶颈指标有:

  1. 磁盘读写、IOPS
  2. GC暂停
  3. 排队时间
  4. BlockCache命中率,逐出率
  5. 热点region

通过查看CDH以及HBase自身的监控指标基本可以确认HBase的性能瓶颈所在,针对性进行调优即可。

4. 性能瓶颈及解决

通过监控发现了一些性能瓶颈,通过调优基本得以解决。

4.1. 磁盘读写峰值导致读写延迟

因为Memstore和BlockCache的存在,磁盘通常不会导致性能出现大幅下降,但在某些极端情况下确实会出现。

场景1
CDH监控发现多个Memstore同时flush,且并未达到默认最大值128M,导致磁盘占用高,检查后发现由于

  1. hbase.regionserver.maxlogs=32

大量写入时WAL文件很快写满,导致写入阻塞和memstore刷写。

场景2
部分离线任务启动后HBase磁盘占用骤增,检查后发现写入HBase使用的是put,换用BulkLoad后解决。

这类问题通常考虑减少或避免集中读写磁盘即可解决。

4.2 GC暂停

GC暂停时工作线程无法工作,导致操作延迟。通常由于Memstore和BlockCache的存在,RegionServer的堆内存都比较大,所以GC优化往往效果明显。

场景1
随着实时写入的数据越来越多,GC时间不断增长,slow read和slow write越来越多。

GC的优化可以考虑以下几种方式:

  1. 对8G以上的大堆使用G1收集器
  2. 使用Buck