第一章 数仓概念
数据仓库(Data Warehouse), DW或DWH, 数据仓库是
为企业所有决策制定过程, 提供所有系统数据支持的战略集合.
通过对数据仓库中数据的分析, 可以帮助企业,改进业务流程, 控制成本,提高产品质量等
数据仓库, 并不是数据的最终目的地, 而是为数据最终的目的地做好准备, 这些准备包括对数据的:清洗, 转义, 分类, 重组, 合并, 拆分, 统计等等
可以看出: 数仓的数据来源主要有用户的行为数据, 还有业务数据. 这些数据经过数据清洗之后进入数据仓库, 然后再在数据仓库中经过一系列准备工作, 转义, 分类, 重组, 合并, 拆分, 统计等等. ,为其他基于大数据的业务服务.
第二章 数仓分层
2.0 为什么要分层
2.1 ODS(原始数据层)
原始数据层，存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理。
2.2 DWD(明细数据层)
结构和粒度与ODS层保持一致，对ODS层数据进行清洗（
去除空值，脏数据，超过极限范围的数据），也有公司叫DWI。
2.3 DWS(服务数据层)
以DWD为基础，进行
轻度汇总。一般聚集到以用户当日，设备当日，商家当日，商品当日等等的粒度。
在这层通常会有以某一个维度为线索，组成跨主题的宽表，比如，一个用户的当日的签到数、收藏数、评论数、抽奖数、订阅数、点赞数、浏览商品数、添加购物车数、下单数、支付数、退款数、点击广告数组成的多列表。
2.4 ADS(数据应用层)
数据应用层，也有公司或书把这层命名为APP层、DAL层等。
面向实际的数据需求，以DWD或者DWS层的数据为基础，组成的各种统计报表。
统计结果最终同步到RDS以供BI或应用系统查询使用。
第三章 数仓理论
3.1 表的分类
3.1.1 实体表
一般是指一个现实存在的业务对象，比如用户，商品，商家，销售员等等。
3.1.2 维度表
一般是指对应一些业务状态，代码的解释表。也可以称之为码表。
比如地区表，订单状态，支付方式，审批状态，商品分类等等。
3.1.3 事务性事实表
一般指随着业务发生不断产生的数据。特点是
一旦发生不会再变化。
一般比如，交易流水，操作日志，出库入库记录等等。
3.1.4 周期型事实表
一般指随着业务发生不断产生的数据。
与事务型不同的是，数据会随着业务周期性的推进而变化。
比如订单，其中订单状态会周期性变化。再比如，请假、贷款申请，随着批复状态在周期性变化。
3.2 同步策略
数据同步策略的类型包括：全量表、增量表、新增及变化表、拉链表
- 全量表：存储完整的数据。
- 增量表：存储新增加的数据。
- 新增及变化表：存储新增加的数据和变化的数据。
- 拉链表：对新增及变化表做定期合并。
3.2.1 实体表同步策略
实体表：比如用户，商品，商家，销售员等
实体表数据量比较小：通常可以做每日全量，就是
每天存一份完整数据。即每日全量。
3.2.2 维度表同步策略
维度表：比如订单状态，审批状态，商品分类
维度表数据量比较小：通常可以做每日全量，就是
每天存一份完整数据。即每日全量。
说明：
- 针对可能会有变化的状态数据可以存储每日全量。
- 没变化的客观世界的维度（比如性别，地区，民族，政治成分，鞋子尺码）可以就存一份固定值。
3.2.3 事务型事实表同步策略
事务型事实表：比如，交易流水，操作日志，出库入库记录等。
因为数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，所以可以做成
每日增量表，即每日创建一个分区存储。
3.3.4 周期型事实表同步策略
周期型事实表：比如，订单、请假、贷款申请等
这类表从数据量的角度，存每日全量的话，数据量太大，冗余也太大。如果用每日增量的话无法反应数据变化。
每日新增及变化量可以用，包括了当日的新增和修改。一般来说这个表，足够计算大部分当日数据的。但是这种依然无法解决能够得到某一个历史时间点（时间切片）的切片数据。
所以要用利用每日新增和变化表，制作一张拉链表，以方便的取到某个时间切片的快照数据。所以我们需要得到每日新增及变化量。
3.3 范式理论
3.3.0 函数依赖
3.3.0.1 完全函数依赖
3.3.0.2 部分函数依赖
3.3.0.3 传递函数依赖
3.3.1 第一范式
3.3.2 第二范式
3.3.3 第三范式
3.4 关系建模与维度建模
3.4.1 关系模型
关系模型主要应用与
OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
3.4.2 维度模型
维度模型主要应用于
OLAP系统中，因为关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。
所以把相关各种表整理成两种：事实表和维度表两种。所有维度表围绕着事实表进行解释。
3.5 雪花模型 星型模型和星座模型
模型的选择
- 首先就是星座不星座这个只跟数据和需求有关, 跟设计没关系, 不用选择
- 星型还是雪花, 取决于
性能优先(星型), 还是灵活更优先(雪花)- 目前实际开发中, 不会绝对选择一种, 根据情况灵活组合, 甚至并存(一层维度和多层维度都保存).
- 但是整体来看,
更倾向于维度更少的星型模型,尤其是Hadoop体系, 减少Join就是减少Shuffle, 性能差距很大(关系型数据库可以依靠强大的主键索引)
