慢查询治理-队列堆积定位
1）现象
有一天我们发现Kylin HBase RegionServer队列堆积非常严重，RegionServer的P99的响应时间已经达到了10多分钟的级别，大家看右上角是HBase关于队列的监控情况，一些机器的堆积已将近3W。我们当时非常疑惑，因为Kylin和HBase之间RPC的超时时间是10秒，在10秒之后Kylin和HBase的连接都已经断开了，HBase到底处理什么查询，右下角是HBase RegionServer UI页面的截图，在这个截图里我们发现一些查询其实已经执行了快半个小时了，这半个小时是在执行什么呢？
2）解决方案
我们当时的解决方案是去任务堆积的有队列推积的RegionServer上去看日志，通过查询开始时间结束时间做差值，找出查询时间最长的Top10的查询，通过QureyID匹配出Cube和具体的SQL，最终我们发现一般这种查询时间特别长都是因为查询方式的变化与原来Cube设置的Rowkey不相符导致了全表扫描。最终的方案其实查出来之后Kylin的同学会去调整Cube的Rowkey设置，然后重新构建。
这种离线的定位的方式其实不是特别好，一开始我们想基于日志做实时报警，这样能帮助我们更快的发现和定位问题，但是后来想想这也是比较被动的一种方式，这只是发现问题，不能彻底解决这个问题。
我们后来想的一个方案是SQL作执行之前可以为SQL打分，评分过低的就拒绝执行，这个功能还没有实现。有这个想法是因为当我们找到SQL信息后， Kylin的同学是可以看出来查询是不是不合理，是不是跟Rowkey设置不符，我们想以后做这样一个功能，把人为判断的经验程序化，在SQL没有执行之前就把潜在的风险化解掉。
慢查询治理 – 主动防御
慢查询治理还有一个举措是Kylin的主动防御。我们发现有大量的耗时较长的查询会占据请求队列，影响其他查询的响应时间。
解决方案是通过Kafka收集Kylin的日志，经过天眼系统实时清洗后写入Druid，通过Druid做统计分析，如果某个业务方/Cube在一定时间内超过3秒的查询到达一定的阀值，主动防御系统会把这个业务方/Cube的查询超时时间设置为1s，让较慢的查询尽快超时，避免对正常查询的干扰。右边就是我们整个流程的一个架构图，主动防御对慢查询治理有一定的作用，但全表扫描的情况还是没有办法完全避免。
重点指标查询性能保障
1）现象
另外一个举措是对重点指标的查询性能保障。早期HBase集群只有HDD一种存储介质，重点指标和普通指标都存储在HDD上，非常容易受到其他查询和HDD性能的影响，重点指标响应时间无法保障。
2）解决方案
我们的解决方案是利用了HDFS的异构存储，给一部分DataNode插上SSD，将重点Cube的数据存储在SSD上，提升吞吐的同时与普通指标数据做存储隔离，这样就既避免了受到其他查询的影响，也可以通过SSD的性能来提升吞吐。引入SSD只是做了存储的隔离，还可以通过RSGroup做计算隔离，但由于重点指标的请求量占到了集群总请求量的90%以上，单独隔离出几台机器是不足以支撑这么大请求量的，所以最终我们并没有这么做。
最后是我们得出的一些经验，SSD对十万以上扫描量查询性能提升40%左右，对百万以上扫描量性能提升20%左右。
这是我们用SSD做的一些改动，数据存储在SSD是可针对Cube设置的。我们可以指定哪些Cube存在SSD上，构建任务建表时会读取Cube的配置，按照Cube配置来设置HBase表的属性和该表的HDFS路径存储策略。在DistCp拷贝之前也要先读取Cube的配置，如果Cube的配置是ALL_SSD，程序需要设置DistCp的目的路径存储策略为ALL_SSD，设置完成后再进行数据拷贝。
这样做的目的是为了避免Bulkload后数据还需要从HDD移动到SSD，移动数据会带来什么影响呢？我们发现如果不先设置DistCp目的路径存储策略的话，数据会被先写到HDD上，Bulkload后由于表的HDFS存储路径存储策略是ALL_SSD，Hadoop的Mover程序会把数据从HDD移动到SSD，当一个数据块的三个副本都移动到SSD机器上后，RegionServer不能从其缓存该数据块的三台DataNode上读取到数据，这时RegionServer会随机等待几秒钟后去向NameNode获取该数据块最新的DataNode信息，这会导致查询响应时间变长，所以需要在DistCp拷贝数据之前先设置目的路径的存储策略。
JVM GC瓶颈
1）现象
我们遇到的下一个问题就是RegionServer的JVM GC瓶颈。在查询高峰期Kylin HBase JVM Pause报警特别频繁，从这张图里面可以看到有一天已经超过1200个。Kylin对用户的承诺是三秒内查询占比在99.7%，当时已经达到了99.8%，于是我们就想还需要优化哪一块能让3秒内查询占比达到99.9%，这个JVM Pause明显成为我们需要改进的一个点，大家做JAVA基本都知道JVM怎么去优化呢？
2）解决方案
首先可能会想到调整参数，其次就是换一种GC算法，我们采用了后者。之前我们用的是JDK1.8，GC算法是G1，后来我们了解到JDK11推出了一个新的算法叫ZGC。最终,我们把JDK从1.8升级到JDK13，采用ZGC替代了原有的G1。右上角的图是ZGC上线后，这套集群RegionServer 的JVM Pause的次数几乎为0，右下角的GC时间也是相比之前降低特别多。ZGC有一个设计目标是Max JVM Pause的时间在几毫秒，这个效果当时看着是比较明显的，左边的图是天眼系统的报警的趋势图，ZGC上线后JVM Pause报警数量明显降低。关于ZGC我本月会发一篇文章介绍ZGC算法和我们做了哪些改动来适配JDK13，这里就不详细介绍了。
