Kylin 在贝壳的性能挑战和 HBase 优化实践( 二 ) 作者:冯亮@贝壳找房来源:微信

RegionServer IO瓶颈1）现象我们发现在构建早高峰时， HBase响应时间的P99会随之升高的，通过监控发现是由于 RegionServer机器的IO Wait偏高导致的。
【Kylin 在贝壳的性能挑战和 HBase 优化实践】还有一种场景是用户构建时间范围选择过大，导致网卡被打满，之前有个用户构建了一年的数据，还有构建三四个月数据，这两种情况都会造成RegionServer机器IO出现瓶颈导致Kylin查询超时。
文章插图
上图是Cube数据构建流程，首先HBase集群和公司大的Hadoop集群是独立的两套HDFS集群，每天构建是从大集群的HDFS去读取Hive的数据，构建任务直接输出HFile到HBase的HDFS集群，最后执行Bulkload操作。由于HBase HDFS集群机器较少，构建任务写数据过快导致DataNode/RegionServer机器IO Wait升高，怎么解决这个问题呢？
2）解决方案
文章插图
我们想用HBase比较常用的方式就是DistCp来解决这个问题，左下角这张图是我们的改进方案，就是我们设置构建任务的输出路径到Hadoop的大集群，而不是到HBase的HDFSB及群，再通过DistCp限流的拷贝HFile到HBase的HDFS集群，最后做Bulkload操作。之前提到我们有800多个Cube ，并不是所有的Cube都需要走这套流程，因为限流拷贝的话肯定会影响数据的产出时间，我们设计了针对Project或者是Cube设置开启这个功能，我们通常会对数据量比较大的Cube开启DistCp限流拷贝，其他Cube还是使用之前的数据流程。
中间这个图是一个构建任务的截图，第一步是生成HFile ，第二步是DistCp ，最后再Bulkload ，这个功能我们新增了一些配置项，比如说第一个是否开启DictCp ，第二个是每个Map带宽是多少，再有就是最大有多少Map 。通过这个功能我们基本上解决了构建高峰IOWait会变高的情况。
慢查询治理–超时定位链路优化1）现象
文章插图
慢查询治理遇到的第一个问题就是超时定位链路特别长。我们收到Kylin报警时首先会想知道：

是哪个Cube超时了？
Cube对应的HBase表是哪个？
是Region不可用还是查询方式变了？

之前提到有一段时间经常出现Region不可用的情况，一旦出现超时我们查询链路是什么样的呢？可能我们先去看HBase日志里看有没有Deadline has passed的警告日志，有这种报警的话我们会拿到它的QueryID ，然后去ES或者是Mysql里面去查询这个QureyID对应的Cube信息和SQL ，知道这些信息之后，还需要去到超时的Kylin节点上去查询日志，从日志里面才能找到是查询哪个HBase表的哪个Region超时，然后再去判断是不是Region不可用了，或者是查询方式改变。这个链路非常长，每次都需要HBase和Kylin的同学一块儿来查。
2）解决方案

文章插图
针对这个痛点给我们做了如下改进：我们直接把Cube信息和Region的信息打在HBase的日志里。中间这个黑色的部分就是HBase的日志，我们可以看到这个查询已经终止了， Cube的名字是什么， Region的名字是什么，下面的白色部分是通过天眼系统配置的报警信息，这个报警是直接报到企业微信的，我们能马上知道这个Deadline涉及的Cube和Region ，能马上做一个检测是这个表不可用了还是查询方式改变了，大大节省了定位问题的时间。

文章插图
这个是为了解决超时链路过长我们对Kylin做的一些代码改动，首先我们在Protobuf文件中加了一个segmentName字段，然后在协处理器类中获取了Region名字，在协处理器调用checkDeadLine方法检查时传入segmentName和regionName ，最后日志会打印出来segment名称和Region的信息。这个功能已经反馈给社区了，见：
慢查询治理-队列堆积定位1）现象

文章插图
有一天我们发现Kylin HBase RegionServer队列堆积非常严重， RegionServer的P99的响应时间已经达到了10多分钟的级别，大家看右上角是HBase关于队列的监控情况，一些机器的堆积已将近3W 。我们当时非常疑惑，因为Kylin和HBase之间RPC的超时时间是10秒，在10秒之后Kylin和HBase的连接都已经断开了， HBase到底处理什么查询，右下角是HBase RegionServer UI页面的截图，在这个截图里我们发现一些查询其实已经执行了快半个小时了，这半个小时是在执行什么呢？