大数据OLAP Kylin

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/rav009/article/details/82423733

在传统的关系型数据库中通过预计算预缓存来实现OLAP分析查询并不新鲜, 微软的SSAS就是典型的代表.

不过由于SSAS在国外兴起的时候, 国内的大公司还没有意识到SSAS对于企业管理和业务支持的作用, 加上SSAS的正版售价问题. 这项技术在中国国内并不是很流行.

现在大数据炙手可热, 通过预计算预缓存的手段来提高大数据的OLAP能力变得自然而然. 于是Kylin应运而生.

Kylin的默认数据源是Hive, 聚合缓存结果默认存放在HBase中, 但是这些只是默认配置, Kylin有灵活性, 可以底层的依赖系统: 比如用Spark替换MR, 用cassandra替换HBase.

所谓预计算其实就是把某个维度上的聚合值预先计算好的意思, 这里的聚合值可以是最大(小)值也可以是平均值或者总和值等等.

比如有一个维度叫 婚姻状况, 其选项有3个: 未婚/已婚/离异. 聚合值是数量(count), 那么就是预先计算未婚的人数, 已婚的人数, 离异人数. 3个选项又可以说这个维度的基数(cardinality)是3.

对于一个星型模型, 假设其维度有3个, 那么我们要统计2^3=8个不同的层次(cuboid). 怎么理解?

假设这三个维度分别是 年份,地点,婚姻状况:

1.不同年份的聚合值

2.不同地点的聚合值

3.不同婚姻状况的聚合值

4.不同年份中各个地点的聚合值

5.不同年份中各个婚姻状况的聚合值

6.不同地点中各个婚姻状况的聚合值

7.不同年份中各个地点中的各中婚姻状况的聚合值

8.以及一个总聚合值

所以这个cuboid总是等于2^n, 其中n是维度个数

可想而知当维度一多, 要预计算预缓存的cuboid数量呈指数上升, 对Process时间和缓存空间都是极大的挑战. 所以kylin提供了一些概念来避免过多的cuboid.

mandatory dimension: 这个维度总会被聚合.假设上例中年份是一个mandatory dimension. 那么序号2,3,7,8的聚合就不必计算了, 因为将来的查询总是要年份这个聚合值的, cuboid变成了2^(n-m), 其中n为维度个数, m是mandatory dimension个数.

derived dimension: 不同维度互相之间有层级关系, 可以合并成一个维度, 比如年/月/日. 最低粒度是"日". 当我们的查询在"年"上聚合时, 可以利用 预先计算好的 "日"粒度的聚合结果. 所以没有必要特地为"年"预先计算聚合值了

hierarchy dimension: 这个比derived dimension更进一层, 表示聚合总是发生在整个hierarchy上. 还是以年月日为例, 比如月份是属于一个hierarchy dimension的(层级关系是年月日), kylin不会单独去预先计算月份上的聚合, 而总是计算年/月的聚合值. 所以keylin的缓存结果中不会有所有3月份的聚合值, 而只有各个年份上3月的聚合值, 因为月份属于一个hierarchy dimension, 必定和它的上一层年份连用.

参考: 

https://mail-archives.apache.org/mod_mbox/kylin-dev/201507.mbox/%[email protected]%3E

https://blog.csdn.net/u010708577/article/details/79072873

猜你喜欢

转载自blog.csdn.net/rav009/article/details/82423733