数仓理论-汇总

1. 数仓分层和规范

1.1 分层

分层在不同的公司会有不同的形式，命名也有不同。但是大体上是差不多。 据说，阿里是分了4层，美团分了5层，京东分了9层。一般情况下分为下面的几层。

ODS: Operation Data Store 原始数据层，存放原始数据，不做任何处理。
DWD: data warehouse detail 对ods层数据清洗，去除脏数据，空值等，维度退化，脱敏等。
DWS: data warehouse service 按天进行轻度汇总。
DWT: data warehouse topic 按主题进行汇总。
ADS: application data store 为各种报表提供数据。

而我所在的公司是这么分的：

模型分层	名称
缓存层	ods	原始日志，不可直接使用
基础层	fact	将ods层全量解析，统一字段命名和时间格式
	dim	维度信息，衍生维度表
	attr	需要完成清洗、命名一致性、逻辑关系合并即按照主题做成宽表
聚合层	aggr	轻度聚合计算：基于业务事实衍生出标签、状态等所需辅助指标，去重类计算、逻辑赛选计算、预cube计算。 累计聚合计算：累计周期类标签计算、排序累计、复杂过滤逻辑计算。
应用层	app	面向定制化报表、邮件、数据产品服务类数据源表。
对外接口	export	数据外供接口、数据服务接口

快照层表，宽表，聚合表：
快照是将原始数据解析之后的数据；宽表是包含了很多明细的数据；而聚合表是进行了一些统计的表，可以从快照表出聚合，也可以从宽表聚合出

分层的好处：
1）复杂的问题简单化；每一层只处理简单的任务，方便定位问题
2）减少重复开发；通过中间层，将一次的计算结果复用
3）隔离原始数据；将统计数据和原始数据隔离开
4）统一数据的口径，即按照一个标准出数据

1.2 数据集市

各个公司，书上对集市的定义也有点差异。一般可以认为， 是微型的数据仓库，更少的数据，更少的主题，是部门级别的，只为局部的人服务。
数据仓库是面向全公司的，企业级的，为各个部门运行提供决策。

1.3 命名规范

这点也是根据自家公司的规范来的。通常的做法是：是什么层，表名就以该层缩写开头。
ods层： ods_表名
dwd层：dwd_dim/fact_表名

• ods_原库名_原表名（_时间后缀day|week|month）–原始数据层
• 中间表：fact_主题_大意_mid_时间后缀(day|week|month) --快照层(清洗)
• fact_主题_大意_时间后缀(day|week|month) --快照层(清洗)
• attr_主题_大意_时间后缀(day|week|month) --宽表层(标签）
• 中间表：aggr_主题_统计维度_mid_时间后缀(day|week|month) --聚合层
• aggr_主题_统计维度_时间后缀(day|week|month) --聚合层
• app_项目_统计维度_时间后缀(day|week|month) --应用层
• mail_项目_统计维度_时间后缀(day|week|month) --邮件 DB每日全量表：后缀
• ‘full(day|week|month)’ 视图表：后缀 ‘view_full(day|week|month)’ 或者
• 'view

(day|week|month)’

2. 数仓理论

2.1 范式理论

范式可以理解为在设计一张表的结构的规范和要求。
在关系数据库设计的时，目的是为了降低数据的冗余性。随之导致的问题是在查询数据的时候需要join关联出最后的数据。join时会降低执行效率。

2.2 范式分类

业界现在存在， 第一范式，第二范式，第三范式，巴斯-科德范式，第四范式，第五范式。企业中主要满足的时前三个范式。

2.3 函数依赖

1）完全函数依赖
举例：知道学号和课程才能知道这人的某学科的分数，缺一不可。即，同时知道A和B，才能推出C，则C完全依赖A和B。

2）部分函数依赖
通过A能得出C，或者B也能得出C， 则C是部分依赖A和B。

3）传递函数依赖
A能得出B，B能得出C，但是C得不出A，不能反着推出来。则C是传递依赖于A。

2.4 三范式的区分

三范式就是不停的拆字段，尽可能的拆出最细的。

2.4.1 第一范式

第一范式核心原则：属性不可切分

图中的商品， 是明显可以再切分为数量和商品名 。

2.4.2 第二范式

原则：不能存在部分函数依赖

2.4.3 第三范式

原则： 不能存在传递函数依赖

2.5 关系建模和维度建模

维度建模：维度建模文章
关系建模：关系建模文章

雪花模型和星型模型主要区别在于外围的维度层级，星型模型外围只有一层。雪花模型外围不止一层。

2.5.1 维度退化

维度退化 ： 即提前将多个维表进行关联，处理成一个维表， 这样在事实表来关联该维度表的时候，就是星型模型。保证事实表周围只有一层维度表。

2.6 维度表和事实表

2.6.1 维度表

维度表： 一般是对事实的描述信息，每个维表对应世界中的一个对象或者概念。例如：用户，商品，日期，地区等。可以理解为是名词命名的表。

维表特征：

• 范围比较宽，多个属性，列比较多。
• 和事实表相比，函数较小。
• 内容变化的不是很多

2.6.2 事实表

事实表中的每行数据代表一个业务事件（ 下单、 支付、 退款、 评价等） 。 “事实” 这个术语表示的是业务事件的度量值（ 可统计次数、 个数、 件数、 金额等） ， 例如， 订单事件中的下单金额。

• 非常的大
• 内容相对的窄： 列数较少
• 经常发生变化， 每天会新增加很多

简单说，事实表中放的是：

1. 可度量的值，次数，金额；
2. 维度表的id，关联维度信息

事实表的分类：
1）事物型事实表；
2）周期型快照表，可以理解为进行的轻度聚合的聚合表；
3）累积型快照事实表：累计快照事实表用于跟踪业务事实的变化。 例如， 数据仓库中可能需要累积或者存储
订单从下订单开始， 到订单商品被打包、 运输、 和签收的各个业务阶段的时间点数据来跟踪
订单声明周期的进展情况。 当这个业务过程进行时， 事实表的记录也要不断更新。

2.7 建模分层

2.7.1 ods层

• 保持数据原貌不做任何修改， 起到备份数据的作用。
• 数据采用压缩， 减少磁盘存储空间，例如： 原始数据 100G可以压缩到 10G 左右
• 创建分区表， 防止后续的全表扫描

2.7.2 dwd层

dwd层需要构建维度建模，一般采用星型建模，呈现的状态是星座模型；因为实际中是多个事实表，都会不断的管理相同的维表。所有事实表的周围只有一层一级维度。
维度建模一般按照以下四个步骤：选择业务过程→声明粒度→确认维度→确认事实

维度建模的4个步骤：

1. 选择业务过程
2. 声明粒度， 选择最小粒度
3. 确认维度 ，在确认维度的时候也需要对维度就行聚合，整合维表，让事实表在使用的时候只关联一个维表；减少join。
4. 确认事实，确认度量值。

在dwd层数仓的维度建模已经完毕， DWS、 DWT 和 ADS 和维度建模已经没有关系了。DWS 和 DWT 都是建宽表， 宽表都是按照主题去建。 主题相当于观察问题的角度。 对应着维度表

2.7.3 对主题的理解

主题是 dws层和dwt层都是宽表，宽表都是按照主题建的。
主题就是观察问题的角度，对应着维度**。站在维度表的角度，关联出与该维度所有相关的信息。**
举例子：
想建一个商品主题的宽表，那就站在商品维度表的角度，想一下，跟商品有关的表有哪些
哪些商品添加到了商品订单了； --> 订单事实表
哪些商品加到购物车了； --> 加购事实表
哪些商品被收藏了； --> 收藏事实表
哪些商品被评价了； --> 评价事实表
哪些商品被退款了了； --> 退款事实表

其余的用户主题，活动主题，购物券主题，都是类似。

2.7.4 dws层 和dwt层

dws： data warehouse service 基于dwd层，按天进行轻度汇总。处理主题相关的当天的行为，即按天分，
dwt：data warehouse topic 基于dws， 按主题进行汇总，累计一定时间周期的结果。

2.8 拉链表

3. Hive函数

3.1 str_to_map函数

将字符串类型的转换为map格式。要求是必须得格式统一。
str_to_map(text[, delimiter1, delimiter2])

第一个分隔符：分割字符串，
第二个分隔符：分割键和值的符号

select str_to_map('aaa=11&bbb:22', '&', '=')
-- 得出的结果：{"bbb":"22","aaa":"11"}  

N. Notes

ETL工具：hive hql， mr ， spark sql， python， kettle