数仓理论-汇总

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

N. Notes

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