数仓理论- 03 数据仓库建模

Posted 2022-06-07 ：Concerto

4 建模

4.1 OLTP系统建模方式

1. OLTP(Online Transaction Process )在线事务处理，一般业务数据库使用，目的是为业务提供存储以及数据操作，主要是面向数据的随机读写

2. 减少冗余，保证数据的移植性，通常使用关系模型(ER模型)，ER模型的原则是把这个表拆分，拆分的越细越好，拆分后满足三范式规则，减少冗余，如下图

4.2 OLAP系统建模方式

4.2.1 OLAP内容

1. 英文全称Online Analysis Process，是在线分析联机的系统，更加关注分析性能，分析常会用到group by，即聚合，所以呢，就会更加关注数据整合、以及分析、处理性能
2. 根据数据存储方式不同分为：ROLAP、MOLAP、HOLAP,不论如何分类目的还是为了加快数据分析计算的一个性能的

4.2.2 OLAP分类

1. ROLAP(Relation OLAP),属于关系型OLAP,一般关系型数据库就更倾向做事务操作，例如建立了ER模型，更偏向为一种随机读写，分析性能一般，为了提升性能，考虑换一种模型，于是关系型数据库中建模理论便诞生了，模型的学习就集中在ROLAP上了
2. MOLAP(Multidimension OLAP),多维OLAP,针对group by预先聚合计算一下，再使用多维数组的方式保存，加快查询分析时间(查询后不用group by，直接从结果拿),更依赖产品的底层实现
3. HOLAP(Hybird OLAP),混合架构的OLAP,是ROLAP和MOLAP的两者的集合，低层是关系型的，高层是多维矩阵型的，查询效率高于ROLAP,低于MOLAP
4. 总结:只有ROLAP是依赖我们模型设计的，另外的MOLAP和HOLAP是依赖数仓产品的选型， 即产品的底层设计，MOLAP一般存聚合过的结果，因此不存明细数据，HOLAP底层是关系型的，因此底层可以存储明细数据(原始数据)，然后把预计算的结果存储放在上层，又或是，如果查询的SQL很复杂，在上层没找到对应聚合过的结果，还可以落到底层去关系型数据库中再查询计算

4.2.3 ROLAP系统建模方式

1. 分类:ER模型(非OLTP的ER模型),，此ER非ER，纬度模型，Data Value模型，Anchor模型
2. 说明：维度模型最常用，除纬度建模的其他三种模型，其实是同源，由ER模型衍生出另外两种，这三种更适合比较成熟的数仓，成熟的标志是：数据表结构不会频繁变动了，适合传统的互联网行业，互联网行业选择纬度建模为主(阿里)，纬度建模灵活，具有多变性

4.2.4 维度模型

1. 纬度模型中，表被分为维度表，事实表。纬度是对事实的一种组织，纬度一般包括分类，时间，地域等,可筛选，事实是他的本质属性

2. 星型模型

• 标准的星型模型:是有一层事实表，带着一层维度表

• 优点:分析性能最优，只要找到维度表对事实表进行聚合

3. 雪花模型

• 纬度会细分纬度出来，形成多层纬度，比较接近三范式，性能会差一些

​ 例如街道维度，上层还会有街道维度，后续还会有省份维度

4. 星座模型

• 在大规模的生产环境中，根据业务的增长，是会存在很多星型模型，即纬度共用，多个星型形成也可以是星座模型，多个雪花模型也可能形成星座模型。

左边是一个星型，右边也是一个星型，中间的location维度是可以公用的，于是形成了星座模型

5. 宽表模型

• 诞生背景:在大数据的数据仓库中，因为需要把数据拆成事实表和维度表，在做分析计算的时候会需要与产生很多的join，传统数仓因为有索引，所以性能还好比较优异，有精细化的操作，但是在大数据的数仓，消耗是很大的，所以出现了宽表模型，即把纬度冗余到事实表中来，形成宽表，减少join，对应数仓的DWS层形成一张大宽表

  4.2.5 MOLAP系统建模方式

1. 原理:以空间换时间的方式，满足快速的复杂分析查询，性能影响体现在了多重纬度的组合还有聚合上，与其查询进行计算，不如将结果预算出来，进行存储，可以提升查询性能，但是需要大量的空间进行存储，只存预计算结果(以多维数组形式)，不存原始数据。

2. 多维数组概念:多维数组就叫cube，是一个数据立方体，每一个边是一个纬度，预计算好的数据只存在魔方的各个节点，例如group by好多个，可以直接从cube中间取，然后返回回去，生成cube需要大量的时间，因为需要花时间在原来的计算上，纬度越多，排列组合的数量也就越多，结果就越多，导致计算出来的数据会膨胀

例如：需要计算第一季度的书籍做一个group by，做一个count的统计，结果已经存在这个魔方的各个节点里面，直接取即可。

3. 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 多维分析

1. OLAP主要操作是复杂查询，可以多表关联，并使用Count，Sum，Avg等聚合函数

2. OLAP对复杂查询做了直观的定义，包括钻取，切片，切块，旋转

• 钻取:对纬度不同层次的分析，通过改变纬度的层次来变化分析的粒度，分为上卷和下钻

• 切片/切块:选择某个纬度进行分割称作切片，按照多维进行的切片成为切块，多个纬度筛选

• 旋转:实际上对纬度方向的一个互换，反应在sql里面就是前后的顺序做了一个变化