近期Apache Kylin Meetup上，贝壳找房高级研发工程师冯亮分享了Kylin在贝壳找房的实践，从性能调优上向大家介绍如何通过对 HBase 的优化来保障重点业务的查询性能，实现 Kylin 千万级/天的查询量下，3s 内查询占比达到99.7%。
哔哩哔哩，，，
Kylin 在贝壳的实践及 HBase 优化
小程序
Kylin 在贝壳的使用情况介绍
Kylin从2017年开始作为贝壳公司级OLAP引擎对外提供服务，目前有100多台Kylin实例；有800多个Cube；有300多T的单副本存储；在贝壳 Kylin 有两套HBase集群，30多个节点，Kylin每天的查询量最高2000+万。
我们负责 Kylin同事张如松在2018年Kylin Meetup上分享过Kylin在贝壳的实践，当时每天最高请求量是100多万，两年的时间里请求量增加了19倍；我们对用户的查询响应时间承诺是3秒内的查询占比要达到99.7%，我们最高是达到了99.8%。在每天2000+W查询量的情况下，Kylin遇到很多的挑战，接下来我将为大家介绍一下我们遇到的一些问题，希望能给社区的朋友提供一些参考。
Kylin HBase优化
表/Region不可访问
1）现象：
凌晨构建Cube期间，会出现重要表的某个region不可访问导致构建失败的情况，右上角的图是HBase的meta表不可访问的日志；白天查询时也有部分查询因为数据表某个Region不可访问导致查询超时的情况，右下角的图是查询数据表Region超时的日志；另外一个现象是老的Kylin集群Region数量达到16W+，平均每台机器上1W+个Region，这导致Kylin HBase集群建表和删表都非常慢，凌晨构建会出现建表卡住的现象，同时清理程序删除一张表需要三四分钟的时间，面对这样的情况，我们做了一些改进。
2）解决方案：
删除无用表减少Region。通过刚才的介绍HBase集群平均每台机器上1W+个Region，这对于HBase来说是不太合理的，另外由于删除一张表需要三四分钟的时间，清理程序也执行的异常缓慢，最后我们不得不使用了一些非常规手段删除了10W+个Region。
缩短清理周期，从之前的一周清理一次HBase表到每天清理一次，除此之外Kylin会每周合并一次Cube来减少HBase表数量从而减少Region数量，最终16W+的Region删到了不到6万，至此我们解决了一部分问题，还会存在构建时重点表的Region不可访问的情况。
将HBase从1.2.6升到1.4.9，主要是想要利用RSGroup的能力来做重点表和数据表的计算隔离；
关闭HBase自动Balance的功能，仅在夜间业务低峰期开启几个小时；
使用HBase自带的Canary定期的检测Region的可能性，如果发现某些Region不可用马上发送告警
使用RSGroup单独隔离重点表来屏蔽了计算带来干扰，这些重点表包括HBase Meta表、Acl表、Namespace表、Kylin_metadata表。
经过了这一系列的改进之后表/Region不可访问的问题基本上解决了，现在基本上没有再出现Region不可访问的情况。解决这个问题我们花费了很长时间，经历了升级重启和删了大量的表后，我们遇到了另外一个问题。
RS数据本地性提升
1）现象
Kylin HBase集群的RegionServer数据本地性非常低，只有20%不能很好的利用HDFS短路读，这样对查询响应时间产生了一定影响，我们三秒内的查询占比出现了下降。了解HBase的朋友都知道如果RS的数据本地性较低，有一种解决方案就是做Compact把数据拉到RegionServer对应的Datanode上，考虑到大规模的做Compact会对查询造成很大影响，我们没有这么做，跟Kylin的同学沟通后发现绝大多数的Cube每天会使用最新构建的表，查旧表的可能系不是特别大，所以提升每天新建表的数据本地性就可以了， 具体我们是这样做的。
2）解决方案
我们发现Kylin用到的是HFileOutputFormat3跟HBase的HFileOutputFormat2是有一些差别的，我们在HFileOutputFormat3里面加入了HBASE—12596的特性，这个特性主要是生成HFile的时候会写一份数据的副本到Region所在的RegionServer对应的Datanode上。下面是一些代码细节，程序会先取到这个Region所在的机器，然后再获取Writer时，把这台节点的信息传递过去，最后写数据的时候会写一个副本到这个Region对应的Datanode上，这样逐渐我们的数据稳定性就提上来了，现在看了一下基本上在80%多左右。
RegionServer IO瓶颈
1）现象
我们发现在构建早高峰时，HBase响应时间的P99会随之升高的，通过监控发现是由于 RegionServer机器的IO Wait偏高导致的。
还有一种场景是用户构建时间范围选择过大，导致网卡被打满，之前有个用户构建了一年的数据，还有构建三四个月数据，这两种情况都会造成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的信息。这个功能已经反馈给社区了，见：https://issues.apache.org/jira/browse/KYLIN-4788
