关于Kylin结果缓存的思考

由来

Apache Kylin定位是大数据量的秒级SQL查询引擎，原理是通过预计算所有可能的维度组合存储在Hbase中，查询时解析SQL获取维度和度量信息，然后再从hbase中扫描获取数据返回，个人认为Kylin最强大的地方在于实现了SQL引擎，如果使用自定义的格式化查询语言也可以完成相应的数据访问操作，无非是指定查询的维度、度量、聚合函数、过滤条件，排序列等等。

但是这种描述较之于SQL太弱了，SQL很灵活的将一些复杂的语义转换，例如kylin中不支持select xxx where xx in (selext xxx)的语句，但是可以通过子查询join的方式实现，这样的局限导致了大量复杂的SQL。除此之外，由于Kylin中可能存在某几个维度的cardinality比较大，当使用该列进行group by的时候会导致需要从hbase中读取大量的记录进行聚合运算甚至排序。Kylin中SQL引擎使用的是Calcite进行SQL解析、优化和部分算子的运算，Calcite的计算是完全基于内存的，所以当Kylin中一个查询需要从hbase中获取大量记录的情况下，内存逐渐会成为瓶颈。

OLAP查询往往是基于历史数据的，历史数据最重要的特性是不可变的，即便偶尔由于程序BUG导致数据需要修复，对这种不经常会变化的数据的查询，并且每一个查询可能消耗大量资源的情况下，缓存是最常用也是最有效的提升性能的办法。

现状

Kylin并不是不对查询结果进行缓存的，对于每一个查询会根据该查询扫描的记录总数是否超过阀值（以此判断是否值的缓存）判断是否缓存结果。但是这部分缓存是基于本机内存的，并且是实例间不可共享的，而一般Kylin查询服务器的架构是多个独立的服务器通过前面的负载均衡器进行请求转发，如下图，所以这部分缓存是无法共享的。由此目前Kylin的缓存机制存在一下几种弊端：

• 缓存在本机内存，对查询最需要的内存资源就是一种消耗。
• 机器间无法共享，导致查询可能时快时慢，并且造成不必要的资源浪费。
• 无法自动过期，build完成之后需要手动清理，否则结果可能出现错误。例如查询select count(1) from xxx;当一个新的segment build完成之前和之后两次查询的结果是相同的，明显第二次是使用缓存的，并且build成功之后并没有将缓存清理，需要手动清除。