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

作者:冯亮@贝壳找房
来源:微信公众号:apachekylin
出处:;mid=2653081715 --tt-darkmode-bgcolor: #131313;">近期Apache Kylin Meetup上，贝壳找房高级研发工程师冯亮分享了Kylin在贝壳找房的实践，从性能调优上向大家介绍如何通过对 HBase 的优化来保障重点业务的查询性能，实现 Kylin 千万级/天的查询量下， 3s 内查询占比达到99.7% 。
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%多左右。