数仓理论- 03 数据仓库建模
Posted :Concerto
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数仓理论- 03 数据仓库建模相关的知识,希望对你有一定的参考价值。
4 建模
4.1 OLTP系统建模方式
-
OLTP(Online Transaction Process )在线事务处理,一般业务数据库使用,目的是为业务提供存储以及数据操作,主要是面向数据的随机读写
- 减少冗余,保证数据的移植性,通常使用关系模型(ER模型),ER模型的原则是把这个表拆分,拆分的越细越好,拆分后满足三范式规则,减少冗余,如下图
4.2 OLAP系统建模方式
4.2.1 OLAP内容
- 英文全称Online Analysis Process,是在线分析联机的系统,更加关注分析性能,分析常会用到group by,即聚合,所以呢,就会更加关注数据整合、以及分析、处理性能
- 根据数据存储方式不同分为:ROLAP、MOLAP、HOLAP,不论如何分类目的还是为了加快数据分析计算的一个性能的
4.2.2 OLAP分类
- ROLAP(Relation OLAP),属于关系型OLAP,一般关系型数据库就更倾向做事务操作,例如建立了ER模型,更偏向为一种随机读写,分析性能一般,为了提升性能,考虑换一种模型,于是关系型数据库中建模理论便诞生了,模型的学习就集中在ROLAP上了
- MOLAP(Multidimension OLAP),多维OLAP,针对group by预先聚合计算一下,再使用多维数组的方式保存,加快查询分析时间(查询后不用group by,直接从结果拿),更依赖产品的底层实现
- HOLAP(Hybird OLAP),混合架构的OLAP,是ROLAP和MOLAP的两者的集合,低层是关系型的,高层是多维矩阵型的,查询效率高于ROLAP,低于MOLAP
- 总结:只有ROLAP是依赖我们模型设计的,另外的MOLAP和HOLAP是依赖数仓产品的选型, 即产品的底层设计,MOLAP一般存聚合过的结果,因此不存明细数据,HOLAP底层是关系型的,因此底层可以存储明细数据(原始数据),然后把预计算的结果存储放在上层,又或是,如果查询的SQL很复杂,在上层没找到对应聚合过的结果,还可以落到底层去关系型数据库中再查询计算
4.2.3 ROLAP系统建模方式
- 分类:ER模型(非OLTP的ER模型),,此ER非ER,纬度模型,Data Value模型,Anchor模型
- 说明:维度模型最常用,除纬度建模的其他三种模型,其实是同源,由ER模型衍生出另外两种,这三种更适合比较成熟的数仓,成熟的标志是:数据表结构不会频繁变动了,适合传统的互联网行业,互联网行业选择纬度建模为主(阿里),纬度建模灵活,具有多变性
4.2.4 维度模型
-
纬度模型中,表被分为维度表,事实表。纬度是对事实的一种组织,纬度一般包括分类,时间,地域等,可筛选,事实是他的本质属性
- 星型模型
- 标准的星型模型:是有一层事实表,带着一层维度表
- 优点:分析性能最优,只要找到维度表对事实表进行聚合
- 雪花模型
- 纬度会细分纬度出来,形成多层纬度,比较接近三范式,性能会差一些
例如街道维度,上层还会有街道维度,后续还会有省份维度
- 星座模型
- 在大规模的生产环境中,根据业务的增长,是会存在很多星型模型,即纬度共用,多个星型形成也可以是星座模型,多个雪花模型也可能形成星座模型。
左边是一个星型,右边也是一个星型,中间的location维度是可以公用的,于是形成了星座模型
- 宽表模型
-
诞生背景:在大数据的数据仓库中,因为需要把数据拆成事实表和维度表,在做分析计算的时候会需要与产生很多的join,传统数仓因为有索引,所以性能还好比较优异,有精细化的操作,但是在大数据的数仓,消耗是很大的,所以出现了宽表模型,即把纬度冗余到事实表中来,形成宽表,减少join,对应数仓的DWS层形成一张大宽表
4.2.5 MOLAP系统建模方式
-
原理:以空间换时间的方式,满足快速的复杂分析查询,性能影响体现在了多重纬度的组合还有聚合上,与其查询进行计算,不如将结果预算出来,进行存储,可以提升查询性能,但是需要大量的空间进行存储,只存预计算结果(以多维数组形式),不存原始数据。
- 多维数组概念:多维数组就叫cube,是一个数据立方体,每一个边是一个纬度,预计算好的数据只存在魔方的各个节点,例如group by好多个,可以直接从cube中间取,然后返回回去,生成cube需要大量的时间,因为需要花时间在原来的计算上,纬度越多,排列组合的数量也就越多,结果就越多,导致计算出来的数据会膨胀
例如:需要计算第一季度的书籍做一个group by,做一个count的统计,结果已经存在这个魔方的各个节点里面,直接取即可。
- OLAP产品:
- Kylin:MOLAP开源产品的代表,更多使用
①Kylin设计:从Hadoop,Hive,Kafka等数据源获取数据,然后由Kylin加工成cube,加工的时候会进行多种维度的组合,计算出来最终的一个成果会放在Hbase(满足并发查询性能的),,需要用到的前端直接跟Kylin查询即可
②Kylin适用场景:一般是ADS层,主要作用是为了加快查询的一个速度,传统的ROLAP面向的是DWS层,传统数仓本质还是以二维表形式存储的原数据,即使底层是大数据的数仓,也是用元数据把以文件形式存储的数据还原成二维表
③Kylin算法补充:
以下内容为全文引用,有兴趣的小伙伴可以去参考作者dafei1288如何构建更好的数据立方体系统(Cube)_飞翔的天空的技术博客_51CTO博客查看原文。
在MP上的算法:Layer Cubing算法
也可称为“逐层算法”,通过启动N+1轮MapReduce计算。第一轮读取原始数据(RawData),去掉不相关的列,只保留相关的。同时对维度列进行压缩编码,第一轮的结果,我们称为Base Cuboid,此后的每一轮MapReuce,输入是上一轮的输出,以重用之前的计算结果,去掉要聚合的维度,计算出新的Cuboid,以此向上,直到最后算出所有的Cuboid。
此算法的Mapper和Reducer都比较简单。Mapper以上一层Cuboid的结果(Key-Value对)作为输入。由于Key是由各维度值拼接在一起,从其中找出要聚合的维度,去掉它的值成新的Key,并对Value进行操作,然后把新Key和Value输出,进而Hadoop MapReduce对所有新Key进行排序、洗牌(shuffle)、再送到Reducer处;Reducer的输入会是一组有相同Key的Value集合,对这些Value做聚合计算,再结合Key输出就完成了一轮计算。
每一轮的计算都是一个MapReduce任务,且串行执行;一个N维的Cube,至少需要N次MapReduce Job
在Spark上的算法:By-layer Spark Cubing算法
多维立方体的集合可以很好地描述为RDD,N维立方体将具有N + 1个RDD。这些RDD具有Parent/Child关系,因为parent RDD可用于生成child RDD。通过将父RDD缓存在内存中,子RDD的生成可以比从磁盘读取更有效。
Kylin使用HiveContext读取中间Hive表,然后执行一个一对一映射的“map”操作将原始值编码为KV字节。完成后Kylin得到一个中间编码的RDD。中间RDD用一个“ReduceByKey”操作聚合以获得RDD-1,这是Base Cuboid。接下来,在RDD-1上做一个“flatMap”(一对多map),因为Base Cuboid有N个子Cuboid。以此类推,各级RDD得到计算。在完成时,这些RDD将完整地保存在分布式文件系统,但可以缓存在内存中用于下一级的计算。当生成子Cuboid时,它将从缓存中删除
- Druid:时空数据库
4.3 多维分析
-
OLAP主要操作是复杂查询,可以多表关联,并使用Count,Sum,Avg等聚合函数
- OLAP对复杂查询做了直观的定义,包括钻取,切片,切块,旋转
-
钻取:对纬度不同层次的分析,通过改变纬度的层次来变化分析的粒度,分为上卷和下钻
-
切片/切块:选择某个纬度进行分割称作切片,按照多维进行的切片成为切块,多个纬度筛选
- 旋转:实际上对纬度方向的一个互换,反应在sql里面就是前后的顺序做了一个变化
以上是关于数仓理论- 03 数据仓库建模的主要内容,如果未能解决你的问题,请参考以下文章