一图览

数据仓库OLAP

基础

数据库类型

OLTP（联机事务处理）
- 操作型数据库的主要应用，更侧重于基本的、日常的事务处理，包括数据的增删改查。
OLAP（联机分析处理）
- 就是分析型数据库的主要应用，以多维度的方式分析数据，这个后续会整理。

why OLAP

如果用OLTP的表，业务复杂时，会发现结构复杂，数据脏乱，难以理解，缺少历史，大规模查询缓慢这些问题。
业务型数据库是为了支撑业务设计的，不是为了查询和分析数据。

数据仓库结构

数据流向

数据仓库各个层面简介

ETL

E-- extract抽取
- 从数据来源提取指定数据，数据是需要指定的，不是所有的数据都要抽取过来
- 某些源数据对于分析而言没有价值，或者其可能产生的价值，远低于储存这些数据所需要的数据仓库的实现和性能上的成本，就不会抽取了。
T -- transfer 变形
- 将数据转换为指定格式并进行数据清洗保证数据质量。
- 数据转换
  - eg：编码转换(m/f->男/女)，字段转换(balance->bal)，度量单位的转换(cm->m)
数据清洗
- 如：会对不完整数据，错误数据和重复数据等脏数据进行清洗
L -- load 加载
- 全量加载
  - 一次对全部数据进行加载。
增量加载
- 一般首先对数据进行全部加载
- 在第二次周期或者第三次周期的时候仍然全量加载的话，耗费了极大的物理和时间资源。有可能部分数据源并未发生变化，而有的数据源可能只是增加了少量的数据。对数据源中的数据只考虑新修改的记录和新插入的记录就是增量加载。

ODS

Operational Data Store ，操作数据存储
基本上就是数据从源表拉过来，进行etl，比如mysql 映射到hive，那么到了hive里面就是ods层。
编码统一等处理后保留的细节数据，符合 3 范式
存储各大业务型数据库ETL后的数据，是最接近数据源中数据的一层，主要目的是为了数据集中。
总体上是按照源业务系统的分类方式而分类的，因此会有鲜明的业务数据库特征，甚至还有一定的关系数据库中的数据范式的组织形式
但是不是原始数据，是经过简单清洗的

DW

Data Warehouse 数据仓库层
数据仓库的主体。从ODS层中获得的数据按照主题建立各种数据模型
这一层和维度建模有较深的联系
数据变化形式：原始细节数据-->当前细节数据（清洗后的数据）-->轻度汇总数据-->高度汇总数据
子层
- dws 和dwd 是并行，而不是先后顺序
- dwd 主要是对 ods 层做一些数据清洗和规范化的操作
- dws 主要是对 ods 层数据做一些轻度的汇总
STAGE 层
- 与原始业务数据完全相同，临时性的
DWD
- Data Warehouse Detail 数据明细层
- 数据仓库的细节数据层
- 是对stage层数据进行沉淀，减少了抽取的复杂性
- 解决了一些数据质量问题和完整度问题
DWM
- Data WareHouse Middle 数据中间层
- 对DWD层的生产数据进行轻度综合和汇总统计
- 与DWD 主要区别
  - 二者应用领域不同
  - DWD数据来源于生产型的系统，并未满足一些不可预见的需求而进行沉淀
  - DWM 则面向分析型应用进行细粒度的统计和沉淀
生成方式
- 由 DWD 按照一定的业务需求生成轻度汇总表
- 明细层需要复杂其清晰的数据和需要MR处理的数据也经过处理后接入到轻度汇总层
DWS
- Data WareHouse Service 数据服务层
- 又称数据集市或者宽表
- 按照业务划分，如流量、订单、用户等
- 生成字段较多的宽表，用于提供后续业务查询，OLAP 分析，数据分发等
- 数据生成方式
  - 由轻度汇总层和明细数据计算生成

数据仓库模型

关系模型

是基于数据库的关系模型推广到数据仓库，符合第三范式

维度模型

是从业务需求角度出发，通过事实和维度来描述业务数据，使的分析快速规范和明确
类型
- 星型模型
  - 星型模式由事实表和维度表组成
  - 一个星型模式中可以有一个或多个事实表
  - 每个事实表引用任意数量的维度表。
雪花模型
- 该模型也是由一个中央事实表和一组成员维度表组成，这些维度表可进一步规范化为子维度表。
维度类型
- 事实
  - 是指业务的度量值
  - 通常是数字类型的，可以进行聚合和计算
  - 事实表由维度的ID 和度量值
  - 事实表建成之后，永远都是追加记录，不会更改也不会删除。（除非重新加载）
  - 事实表类型
    - 事务事实表：记录事件的事实，例如一条检测记录，字段的值是动态的。
    - 快照事实表：记录给定时间点的事实，例如每日0时的检测快照表，字段值在此刻固定下来了。
    - 累积事实表：记录给定时间点的聚合事实，一般是按日、周、月累积的事实。
维度
- 观察数据的角度
- 通常是一组层次关系或描述信息，用来定义事实
- 维度表的属性是可以更新的
  - 维度属性更新问题叫做缓慢变化维
  - 三种方式
    - 1.直接 update，「旧属性值」彻底丢失不可以找回
    - 2.新增一条使用「新属性值」记录，新记录与老记录有各自的有效时间，在事实表中引用维度表的代理码
    - 3.在维度表中添加字段，用多个字段记录变化，譬如，当前城市、以往城市。
设计步骤
- 选择业务流程
  - 确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础
  - 建模的第一个步骤是描述需要建模的业务流程。
声明粒度
- 粒度是指确定事实的最小单位
  确定了业务流程后，下一步是声明维度模型的粒度。粒度是指确定事实的最小单位，例如，检测业务流程中的检测单，成交业务流程的车源ID。在确认维度和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。从给定的业务流程获取数据时，原始粒度是最低级别的粒度。建议从原始粒度数据开始设计，因为原始记录能够满足用户的个性化查询需求。汇总后的数据粒度对优化查询性能很重要，但这样的粒度往往不能满足对细节数据的查询需求。一个业务流程可能会有多个粒度，检测业务中统计车源，则车源ID也是一个粒度。
- 在确认维度和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。
- 建议从原始粒度数据开始设计，因为原始记录能够满足用户的个性化查询需求。汇总后的数据粒度对优化查询性能很重要，但这样的粒度往往不能满足对细节数据的查询需求。
确认维度
- 维度的粒度必须和第二步所声明的粒度一致
- 维度表是事实表的基础。
确认事实
- 这一步识别数字化的度量，构成事实表的记录
- 大部分事实表的度量都是数字类型的