维度建模

ODS：数据来源：一部分是来自关系型数据库，符合ER模型。一部分来自日志，清洗成二维表

DWD：把所有的数据清理整合，规范化。脏数据清理，命名不规范的。最后拿到的是干净的，一致性的数据。

把公共维度抽取出来，如区域

DWS：维度建模，通用的汇总层，为了避免重复计算。 DWS的表底层可能依赖DWD或ODS层的几十张表。所以从ETL性能出发要考虑DWS层表的数量和依赖。

DM：指标库，集市是面向分析的

清洗过程： ODS清洗脏数据到DWD, DWD汇总到DWS，DWD到DM做指标。

维度：

维度，顾名思义，看待事物的角度。比如时间日期、区域、部门、客户、应用程序等维度，而省、市、县又叫维度的粒度，粒度可以是一组组合：比如我要看某个省某个市下某个县年龄在28岁以下的购买能力。
维度表一般为单一主键，在ER模型中，实体为客观存在的事物，会带有自己的
描述性属性，属性一般为文本性、描述性的，这些描述被称为维度
比如商品，单一主键：商品ID，属性包括产地、颜色、材质、尺寸、单价等，
但并非属性一定是文本，比如单价、尺寸，均为数值型描述性的，日常主要的维
度抽象包括：时间维度表、地理区域维度表等

维度设计：
代理键
缓慢渐变维
事实表设计：
明细事实表
聚合事实表

代理键：
维度表中必须有一个能够唯一标识一行记录的列，通过该列维护维度表与事实表之间的关系，一般维度表中业务主键符合条件可以当作维度主键。

当整合多个数据源的维度时，不同数据源的业务主键重复怎么办？

比如下图：

原有业务主键id,整合后发生重复。此时引入一个新的和业务无关的键（代理建），并且在整个维度表中是全局唯一的，而且通常情况下自增的方式来做的

传统数据库有自增id默认功能，但hive中怎么生成自增的代理键？

表命名规则:
-i结尾: 流水型的纯增量的
-d结尾: 快照的
-a结尾: 全量没有任何分区

维度有分为:
1/ 稳定维度:
如时间,区域等,不发生变化或很少发生变化.针对这种维度,设计维度表时,仅需要完整的数据,不需要天的快照数据,因为当前数据状态即是历史数据状态.
2/ 缓慢渐变纬度
维度数据会随着时间发生变化,变化速度比较缓慢.由于数据仓库需要追溯历史变化,尤其是一些重要的数据,所以历史状态也需要采取一定的措施进行保存.
两种方法:
a. 每天保存等钱数据的全量快照数据,适合数据量较小的维度,使用简单.
b. 在维度表中添加官军属性值的历史字段,仅保留上一个的状态值. (复杂,不常用)
c. 拉链表
当维度数据发生变化时,将旧数据置为失效,将更改后的数据当作新的记录,插入到维度表中,并开始生效,这样就记录了数据在某种粒度上的变化历史.

比如: 员工的部门变化

因为是对维度表做拉链,所以同一维度实体必然存在多条记录,此时维度表的原子性主键就不存在了.如上表中的两条记录id都是1

那么拉链表怎么和事实表关联?

引入代理键:

问题：事实表来源于业务事务表，代理键和业务本身没有关系，那么怎么在事实表中装载代理键？

D:\数据仓库\PART3\09 数据仓库维度建模\数据仓库维度建模2.mp4

小结:
代理键是维度建模中极力推荐的方式,它的应用能有效隔离源端变化带来的数仓结构不稳定问题,同时也能提高数据检索性能.
但,代理键维护代价非常高,尤其是数据装载过程中,对事实表带来较大的影响,如代理键的生成、事实表中关联键的装载、不支持非等值关联等问题，带来ETL过程更加复杂。
所以，谨慎使用代理键，同时对缓慢渐变维场景，可以考虑每天保留维表全量快照，但这样会带来存储成本，根据实际情况衡量。

案例:

一个事实表，可以拆分成为多个不同的维度 ==》针对不同的维度进行分析。这就叫多维分析

中间的是主表,右边是财务关心的,左边是技术部关心的

时间维度用户维度金额维度 ==》可以组合出来多少个不同的分析的角度？？？

不同的纬度表可以组合关联分析。

kylin其实就是在做多维的分析 : 通过各种不同的维度都来做聚合的分析

事实表设计：
1/ 明细事实表，一般在dwd层
2/ 聚合事实表，一般在dws(轻度汇总)和DM

明细事实表：
事实表有粒度大小之分，一般在dwd层，该层事实表设计部进行聚合、汇总动作，只做数据规范化、数据降维动作，同时数据保持业务事务粒度，确保数据信息无丢失。
数据降纬：
为了提高模型易用性，将常规维度表中的常用的属性数据冗余到相应的事实表中，从而在使用时避免维表关联的方式，

如下图,中间就是事实表，如果要做区域商品购买力分析，把常住地等也放到事实表中，这就是降维的过程。以后在使用事实表时就不用再和维度表再做关联。