一文快速理解Kylin的Cube

基于大数据的快速分析已经有不少存在的技术，如Hive/Spark SQL/Presto/Drill/Impala，但这些技术关于查询的优化，聚焦于：

• 如何使查询更好的并行化

• 如何有效降低扫描的数据量

Kylin定位于解决千亿条、万亿条记录的秒级查询问题，它关于查询加速的思路，称得上"简单粗暴"： 将查询结果做"预聚合"处理，将一些复杂的分析型查询进行简化。Kylin关于OLAP型查询做了如下两点假设：

• 查询大多是为了获取多条记录聚合之后的统计值

• 聚合按维度进行，而且有意义的维度聚合组合是有限的，而且随着数据量的不断增长而相对固定

那么，什么是维度？下面举一个简单的例子来理解维度组合：

时间： {2017Q1, 2017Q2, 2017Q3, 2017Q4}
地区：{北京，上海，深圳，广州}
那么，基于「时间+地区」的维度组合共有4*4=16种

Cube的维度组合，可以由用户结合实际的业务查询场景进行自定义。所谓的"预聚合"，就是将这16种组合的统计结果预先计算出来并存储起来。为了加速这种聚合之后的结果的查询，可以将这些结果存储在HBase/Cassandra这类NoSQL系统中，使用组合维度值作为Key。这种"预聚合"的思路，对比传统的查询加速的思路，可以看出来，只要组合的维度相对固定，那么，不会随着数据量的增长而出现明显的性能恶化。

Kylin选择了以标准SQL作为查询接口，它采用了Calcite进行查询语法分析。标准SQL要求以关系模型作为支撑，因此，Kylin选择了最简单的"星型模型"：

• 事实表：存储事实记录的表，数据量通常很大

• 维度表：维度的属性表，可以跟事实表关联，数据量通常很小，且数据相对固定。这些信息如果存储在事实表中，会导致大量的数据冗余。一个维度表可以被多个事实表重用

• 一个事实表可以关联零个或多个维度表

Kylin主要应对的是离线型OLAP型查询，不能支持数据的实时插入、更新，但可以支持准实时增量导入。Kylin虽然选择了支持标准SQL接口，但在SQL的完整性语法支持上却是相对较弱的。因此，总的来看，不能支持实时更新与SQL语法兼容性过弱，是最大的短板。

Reference:

1. Apache Kylin权威指南

本文转载自微信公众号【Nosql漫谈】。

原文链接：https://mp.weixin.qq.com/s/Wz4ggtO-gTEziBA19dfhcw