Hbase1.2.0-cdh5.16.2使用PREFIX_TREE编码导致集群压缩队列异常

本篇文章大概1700字，阅读时间大约5分钟

Hbase1.X版本中PREFIX_TREE作为BlockEncoding存在bug，会造成RegionServer节点compaction queue持续升高，甚至影响flush，最终阻塞写入。本文记录了整个RegionServer异常的故障定位过程。

集群环境

• CDH - 5.16.2
• Hbase - 1.2.0 - cdh5.16.2

1.问题描述

• Hbase RegionServer多节点出现压缩队列异常告警
• dn3和dn4出现大量的HFile Compaction，并且压缩队列持续升高并无下降趋势

2.Compaction异常原因定位

检查异常节点写入

cat /var/log/hbase/hbase-cmf-hbase-REGIONSERVER-dn3.changan.com.cn.log.out | grep "Blocking update on"

• 检查日志确定MemStore占用内存是否达到RegionServer Flush阈值

• MemStore未达阈值
• 检查Region Server是否存在太多HFile

cat /var/log/hbase/hbase-cmf-hbase-REGIONSERVER-dn3.changan.com.cn.log.out | grep "too many store files"

• 出现错误日志，基本确定是因为该表的HFile过多导致异常
• 确定集群的hbase.hstore.blockingStoreFiles阈值，检查异常Region的StoreFile数量

hbase.hstore.blockingStoreFiles = 50

• 异常Region的StoreFile数量达到275个，手动对该Region执行major_compact发现，该Region的HFile数量没有变化，证明该RegionServer存在compaction阻塞
• 查看该Region的HFile大小，发现才500+M，compaction居然几个小时都做不完，有毒

Arthas分析Hbase RS线程

• 在RegionServer节点上启动arthas，选中RegionServer的PID

sudo -u hbase /usr/java/bin/java -jar arthas-boot.jar

• 打印线程信息，thread，发现有3个compaction线程的TIME非常的长

• 查看详细的线程信息：thead 326，发现该问题可能和hbase的codec有关，prefixtree是什么鬼？？？
• 查了一下prefixtree是Hbase在0.96版本中引入的新的BlockEncoding算法，检索Hbase issue后发现了prefixtree会造成compaction阻塞，和bug报告中的情况一毛一样
• issue链接：https://issues.apache.org/jira/browse/HBASE-12959

• 检查该表的属性，发现Block Encoding采用了PREFIX_TREE，故障点已找到

3.故障原因分析

• 某业务上线的时候，新建的几张表采用了PREFIX_TREE编码，根据HBASE-12959，该Blocking Encoding会造成compaction线程阻塞，其他表的compaction请求只能在压缩队列上阻塞，现象就是异常Region所在的RegionServer上压缩队列异常增加，丝毫没有下降趋势

可能存在的影响

• compaction线程耗尽，memstore flush的小文件无法合并，整个HFile的数量增加，导致flush操作阻塞，造成memstore占用内存升高，如果memstore达到RegionServer的高阈值，该RegionServer上的所有写入都会阻塞

解决方案

• 故障处理方案
  • 确定环境上使用到PREFIX_TREE编码的表，建立去除PREFIX_TREE属性的备表，进行数据迁移
• 需要新增的Hbase监控项
  • 监控Hbase的StoreFile数量，发现存在数量异常，及时告警