美团点评基于 Druid 的 Kylin 存储引擎实践

8月11日，由 Kyligence 主办、美团点评协办的 Apache Kylin Meetup@北京，在美团公司总部圆满落幕。本文整理自当天美团大数据工程师、Apache Kylin Committer 康凯森的演讲实录，全文共6,600字，阅读时间大约15分钟。

或点击以下视频

观看 Meetup 现场实录

本次分享会分为三个部分的内容，首先会介绍 Kylin On Hbase 的问题，引入我们为什么要给 Kylin 增加新存储引擎的问题；接下来介绍Kylin新存储引擎的过程，以此来说明为什么选择 Druid 作为我们新的存储引擎；最后给大家介绍 Kylin On Druid 的核心架构、核心原理、性能和我们的初步成果，以下分享中将 Kylin On Druid 简称 KOD。

进入正式主题前，我先介绍下Kylin在美团点评的现状。 目前我们线上 Cube 数有近1000个，Cube 单副本存储近1PB；每天查询量380多万次，查询的 TP50 时延在200ms左右，TP90时延在1.2s左右。目前 Kylin 已经覆盖了美团点评所有主要业务线。

随着 Kylin 在我司的大规模使用和我们对Kylin的深入优化改进，我们发现了 Kylin 本身的一些痛点和问题，其中之一便是 Kylin On HBase 的性能问题。如图：我们用同一  SQL  在同一集群查询同一 Cube，前后性能相差上千倍。 两次查询的唯一不同点就是 Kylin 维度在 HBase 的 RowKey 中位置不同， 耗时90ms的查询中维度dt和poi_id 在 RowKey 前两位，耗时100多s的查询中维度dt和 poi_id 在 RowKey 后两位。

下面我们来看下Kylin On HBase中前后缀过滤性能相差巨大的原因：如图所示：Kylin中会将Cuboid+所有维度拼接成HBase的Rowkey，Kylin默认会将所有普通指标拼接成HBase一个Column Family中同一列的Value。HBase只有单一Rowkey索引，所以只有查询能够匹配Rowkey的前缀时，查询性能会十分高效，反之，查询性能会比较低下，甚至会出现全表Scan。此外，即使只需要查询一个指标，Kylin在HBase侧也需要Scan所有指标列，相比列存性能也会有较大差距。 总的来说，HBase在Kylin的查询场景下Scan和Filter效率较低下。

对于Kylin On HBase Scan和Filter效率低下的问题，我们比较自然会想到的解法是： 用列存加速Scan，用索引来加速Filter 。

这里我简单介绍下列存的优点，主要包含以下3点：

1. 因为只需要读取必需访问的列，所以 列存有高效的IO

2. 因为每列数据的类型一致，格式一致，所以 列存可以进行高效的编码和压缩

3. 列存更容易实现向量化执行 ，而向量化执行相比传统的火山模型，函数调用次数更少，对CPU Cache和SIMD更加友好。 总的来说，列存相比HBase的KV模型更适合Kylin的查询场景。

所以，要解决 Kylin On HBase Scan 和 Filter 效率低下的问题, 我们就需要为 Kylin 增加一个列存，有高效索引的存储引擎。