HBASE升级导致OpenTSDB服务不可用问题分析

背景

望京机房CDH由5.12 升级到6.0.0 ，其中对应的hbase 版本由1.2.0升级到2.0.0。由于升级前的测试主要围绕hdfs，kerberos认证等功能，hbase 只进行了简单的升级测试（升级过程测试，数据可靠性以及升级之后读写操作测试）没有进行压力测试。 结果当升级完成，重启相关服务的时候发现依赖望京hbase集群的openTSDB 服务启动失败。

解决过程

查看日志发现报错信息：

Caused by: org.hbase.async.RemoteException: org.apache.hadoop.hbase.exceptions.UnknownProtocolException: Is this a pre-hbase-1.0.0 or asynchbase client? Client is invoking getClosestRowBefore removed in hbase-2.0.0 replaced by reverse Scan.
    at org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2438)
    at org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41998)
    at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
    at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
    at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
    at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)

分析原因是线上OpenTSDB的AsyncHBase 版本不支持HBASE 2.0。

AsyncHBase 是什么？

HBASE的原生API 是完全同步的，如果使用原生API进行大量的写操作，每个动作都会有一个短暂的阻塞，这对于一些长时间大吞吐量的流程比较不利。幸好，HBASE还提供了另外一种实现了完全异步以及考虑线程安全的API--async hbase。

OpenTSDB使用async hbase ,这是个完全异步、非阻塞、线程安全、HBase api，使用更少的线程、锁以及内存可以提供更高的吞吐量，特别对于大量的写操作。

通过查询官方文档发现， OpenTSDB 2.3.1  版本支持HBASE 2.0。

• Upgrade to AsyncHBase 1.8.2 for compatibility with HBase 1.3 and 2.0。

于是，开始尝试下载并编译 opentsdb 2.3.1 版本的openTSDB，完成测试后开始替换线上老版本的openTSDB。在经历了令人煎熬的几十秒的等待后，opentsdb成功启动，读写正常 ，grafana 显示正常。这令我们一度认为问题已经成功解决...

直到后续观察期，我们发现hbase集群regionServer节点开始出现压缩队列（达到了1000+），并触发长时间的GC 导致regionServer与master/zk 心跳失败，被认定是异常regionServer。 我们只能继续尝试修改hbase/opentsdb参数配置，优化性能。但是效果一直不理想，最后认定hbase2.0版本不稳定，性能达不到opentsdb要求。于是我们回滚OpenTSDB到之前版本，将OpenTSDB所依赖的hbase 改到沙河机房1.0版本的集群。重启后发现服务恢复正常。 不过后续观察运行一个小时之后，相对于升级前环境，grafana部分指标刷新缓慢。尝试多种办法优化，问题没有得到解决，恢复工作一度停滞。最后，部门同事通过log发现opentsdb 的compact操作是导致性能下降的直接原因。关闭opentsdb的compact 选，周期性的数据读取缓慢 导致grafana 页面刷新缓慢的问题得到解决。至此，升级导致的OpenTSDB/grafana服务不可用问题完全解决。

OpenTSDB的compact操作有什么用？

OpenTSDB的compact操作，其实质为将一个小时的3600秒数据（对应于HBase中3600个KeyValue），合并为一个KeyValue（包括qualifier以及value），来节约存储资源。因为在HBase中，rowkey的大量重复是低效的，因此compact显得很有必要。

具体而言，OpenTSDB中，采用了ConcurentSkipListMap这一数据结构作为CompactionQueue，该队列存储了所有的插入HBase的DataPoint所对应的rowkey，CompactionThread周期性地(tsd.storage.compation.flush_interval）从这个队列中进行compact操作。执行compact操作还需要满足队列大小大于tsd.storage.compaction.min_flush_threshold，以及只有old enough的row才会被compact.关于Old enough的衡量，在OpenTSDB中被写死为1个小时，注意，这里并非为整点，而是距离当前系统时间的1个小时。

思考

沙河hbase 达不到望京升级前habse 性能要求的原因分析：

• 望京集群升级前hbase 为1.2.0 版本，沙河集群是1.0.0 版本，望京集群版本高，性能好

• 沙河机房服务器性能较低（沙河hbase 机器部分为24核心或32核心， 望京 服务器为40核心）。

• 沙河hdfs 业务压力大，响应延迟高，对habse 读取有影响。

对后续工作的思考：

• 后续升级工作要充分测试，尤其是性能测试。保证没有问题之后才进行升级

• 深入开源社区，保证基础服务稳定，提高基础架构的容灾能力和灾后快速恢复能力

参考资料：

1. https://www.jianshu.com/p/5888d44e6803

2. https://github.com/OpenTSDB/opentsdb/releases

3. http://opentsdb.github.io/asynchbase/index.html