A股上市公司传智教育(股票代码 003032)旗下技术交流社区北京昌平校区

 找回密码
 加入黑马

QQ登录

只需一步,快速开始

© 梦缠绕的时候 黑马粉丝团   /  2018-10-9 09:38  /  985 人查看  /  1 人回复  /   0 人收藏 转载请遵从CC协议 禁止商业使用本文

在传统的关系型数据库中通过预计算预缓存来实现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, 必定和它的上一层年份连用.
---------------------本文来自 爱知菜 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/rav009/art ... 733?utm_source=copy

1 个回复

倒序浏览
奈斯
回复 使用道具 举报
您需要登录后才可以回帖 登录 | 加入黑马