在众多SQL On Hadoop的解决方案中,Kylin采用了Cube的思路来加速多维分析型查询,Cube是传统数据仓库常用的一种技术,本文简单讨论Kylin多维分析的原理以及Kylin的缺点。
基于大数据的快速分析已经有不少存在的技术,如Hive/Spark SQL/Presto/Drill/Impala,但这些技术关于查询的优化,聚焦于:
如何使查询更好的并行化
如何有效降低扫描的数据量
Kylin定位于解决千亿条、万亿条记录的秒级查询问题,它关于查询加速的思路,称得上"简单粗暴": 将查询结果做"预聚合"处理,将一些复杂的分析型查询进行简化。Kylin关于OLAP型查询做了如下两点假设:
查询大多是为了获取多条记录聚合之后的统计值
聚合按维度进行,而且有意义的维度聚合组合是有限的,而且随着数据量的不断增长而相对固定
那么,什么是维度?下面举一个简单的例子来理解维度组合:
时间:
地区:
那么,基于「时间+地区」的维度组合共有4*4=16种
Cube的维度组合,可以由用户结合实际的业务查询场景进行自定义。所谓的"预聚合",就是将这16种组合的统计结果预先计算出来并存储起来。为了加速这种聚合之后的结果的查询,可以将这些结果存储在HBase/Cassandra这类NoSQL系统中,使用组合维度值作为Key。这种"预聚合"的思路,对比传统的查询加速的思路,可以看出来,只要组合的维度相对固定,那么,不会随着数据量的增长而出现明显的性能恶化。
Kylin选择了以标准SQL作为查询接口,它采用了Calcite进行查询语法分析。标准SQL要求以关系模型作为支撑,因此,Kylin选择了最简单的"星型模型":
事实表:存储事实记录的表,数据量通常很大
维度表:维度的属性表,可以跟事实表关联,数据量通常很小,且数据相对固定。这些信息如果存储在事实表中,会导致大量的数据冗余。一个维度表可以被多个事实表重用
一个事实表可以关联零个或多个维度表
Kylin主要应对的是离线型OLAP型查询,不能支持数据的实时插入、更新,但可以支持准实时增量导入。Kylin虽然选择了支持标准SQL接口,但在SQL的完整性语法支持上却是相对较弱的。因此,总的来看,不能支持实时更新与SQL语法兼容性过弱,是最大的短板。
Reference:
Apache Kylin权威指南
关于"NoSQL漫谈"
NoSQL主要泛指一些分布式的非关系型数据存储技术,这其实是一个非常广泛的定义,可以说涉及到分布式系统技术的方方面面。随着人工智能、物联网、大数据、云计算以及区块链技术的不断普及,NoSQL技术将会发挥越来越大的价值。
请长按下面的二维码关注我们
更多NoSQL技术分享,敬请期待!
领取专属 10元无门槛券
私享最新 技术干货