数据仓库Data Warehouse

数仓是一种思想，数仓是一种规范，数仓是一种解决方案

1. 数据处理方式

数据处理大致可以分成两大类：
- 联机事务处理OLTP（on-line transaction processing）
- 联机分析处理OLAP（On-Line Analytical Processing）

在这里插入图片描述

1.1. OLTP

OLTP的全称是On-line Transaction Processing，中文名称是联机事务处理。其特点是会有高并发
且数据量级不大的查询，是主要用于管理事务（transaction-oriented)的系统。此类系统专注于
short on-line-tansactions 如INSERT, UPDATE, DELETE操作。通常存在此类系统中的数据都是以
实体对象模型来存储数据，并满足3NF(数据库第三范式)。
由于OLTP主要是为了操作数据而设计（操作系统），用于处理已知的任务和负载：常见的优化在
于主码索引和散列，检索特定的记录。去优化某一些特定的查询语句。

1.2. OLAP

OLAP的全称是 On-line Analytical Processing,中文名称是联机分析处理。其特点是查询频率较
OLTP系统更低，但通常会涉及到非常复杂的聚合计算。 OLAP系统以维度模型来存储历史数据，其
主要存储描述性的数据并且在结构上都是同质的。
OLAP则是为了分析数据而设计（数据仓库)，其查询的方式往往是复杂且未知的，通常会涉及大量
数据在汇总后的计算，这种需要基于多维视图的数据操作在OLTP上执行的时候性能将是非常差
的，并且是也是极其危险的。

在这里插入图片描述

OLAP基本操作
- 上卷:roll-up drill-up
  - 通过一个维的概念分层向上攀升或者通过维归约在数据立方体上进行聚集。
  - 比如城市统计数据维度到省级统计数据维度。
- 下钻:drill-down
  - 下钻是上卷的逆操作，由不太详细的数据到更详细的数据。
  - 下钻可以通过沿维的概念分层向下或引入附加的维来实现。
- 切片:slice
  - 在给定的立方体的一个维上进行选择，从而定义一个子立方体。
- 切块 dice
  - 通过两个或多个维上进行选择，定义一个子立方体。
- 转轴:pivot
  - 是一种目视操作，就像是一个二维表的行列转换，两个维度的互换。
- 钻过:drill-across
  - 其执行会涉及多个事实表的查询
- 钻透:drill-through
  - 下钻透过多维数据立方直达RDMS表

在这里插入图片描述

2. 数据建模

数据建模指的是对现实世界各类数据的抽象组织，确定数据库需管辖的范围、数据的组织形式等直至转
化成现实的数据库。

性能：良好的模型能帮我们快速查询需要的数据，减少数据的IO吞吐
成本：减少数据冗余、计算结果复用、从而降低存储和计算成本
效率：改善用户使用数据的体验，提高使用数据的效率
改善统计口径的不一致性，减少数据计算错误的可能性

在这里插入图片描述

2.1. 关系建模

在这里插入图片描述

数据仓库之父Bill Inmon推崇
从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范
式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系
抽象。
它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。
优缺点
- 优点：规范性较好，冗余小，数据集成和数据一致性方面得到重视
- 缺点：需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力
要求也非常高，容易烂尾。

在这里插入图片描述

2.2. 维度建模

在这里插入图片描述

数据仓库领域大师Ralph Kimball 倡导
维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户
如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。
优缺点
- 优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模
复杂查询的响应性能
- 缺点：维度表的冗余会较多，视野狭窄

在这里插入图片描述

3. 维度表分类

在维度建模中，将度量称为“事实” ，将环境描述为“维度”。
在这里插入图片描述

3.1. 维度表

一般是对事实的描述信息。每一张维度表对应现实世界中的一个对象或者概念。
维度表特征
- 维度表的范围很宽（具有多个属性、列比较多）
- 跟事实表相比，行数较少，（通常小于10万条）
- 内容相对固定
维度建模四部曲
- 选择业务处理过程 > 定义粒度 > 选择维度 > 确定事实
- 选择业务：选择感兴趣的业务线，如下单，支付，退款，活动。
- 声明粒度：一行代表信息：一条订单？一天的订单？一周的订单？选择最小粒度
- 确认维度：维度退化：谁。什么时间什么地点
- 确认事实：度量值：如个数，件数，金额
设计原则
- 维度属性尽量丰富，为数据使用打下基础
  比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基
  础。
- 给出详实的、富有意义的文字描述
  - 属性不应该是编码，而应该是真正的文字。在间里巴巴维度建模中，一般是编码和文字
    同时存在，比如商品维度中的商品 ID 和商品标题、类目 ID 和类目名称等。 ID 一般用
    于不同表之间的关联，而名称一般用于报表标签
- 区分数值型属性和事实
  - 数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约
    束条件或分组统计，则是作为维度属性;如果通常用于参与度量的计算，则是作为事
    实。比如商品价格，可以用于查询约束条件或统计价格区间的商品数量，此时是作为维
    度属性使用的;也可以用于统计某类目下商品的平均价格，此时是作为事实使用的。另
    外，如果数值型字段是离散值，则作为维度属性存在的可能性较大;如果数值型宇段是
    连续值，则作为度量存在的可能性较大，但并不绝对，需要同时参考宇段的具体用途。
- 沉淀出通用的维度属性，为建立一致性维度做好铺垫
  - 有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通
    过单表的不同宇段混合处理得到，或者通过对单表的某个字段进行解析得到。此时，需
    要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少
    复杂度;另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。
- 退化维度（DegenerateDimension）
  - 在维度类型中，有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的
    维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度
    建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。
- 缓慢变化维（Slowly Changing Dimensions）
  - 维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生
    变化的维度我们一般称之为缓慢变化维（SCD），缓慢变化维一般使用代理健作为维度
    表的主健。

在这里插入图片描述

*冗余维度：为了提升效率，把常用的维度冗余到事实表

3.2. 事实表

表中的每行数据代表一个业务事件。“事实”表示的是业务事件的度量值（可以统计次数、个数、金额等）
事实表特征
- 非常的大
- 内容相对的窄
- 经常发生变化，每天新增很多。
事实表分类
- 事务型事实表
  - 以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的
    一行数据。
  - 一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
- 周期型快照事实表
  - 周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，以具有规律性
    的、可预见的时间间隔记录事实。
  - 例如每天或每月的总销售金额，或每月的账户余额等。
- 累积型快照事实表
  - 累积快照事实表用于跟踪业务事实的变化，覆盖过程的整个生命周期，通常具有多个日
    期字段来记录关键时间点。
  - 例如数据仓库中可能需要累积或者存储订单从下单开始，到订单商品被打包、运输、签
    收等各个业务阶段的时间点数据，来跟踪订单生