数仓为什么要分层？
1.把复杂问题简单化 把复杂的任务分解成多层来完成，每一层只处理简单的任务，方便定位。
2.减少重复开发 规范数据分层，通过中间层数据，能够减少极大的重复计算，增加一次结果的重复性
3.隔离原始数据 不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。
数据仓库分层：
ODS层:原始数据层，存放原始数据，直接加载原始日志，数据保持原貌不做处理。
DWD层：对ODS层数据进行清洗（去空值，脏数据，超过极限范围的数据），维度退化（小表和成大表），脱敏（手机号中加入****）等
DWS层：以DWD为基础，按天进行轻度汇总。需要按照主题建模，主题就是分析问题的一个角度，圈定了一个分析的范围，计算出这个主题的各种指标，而我们的指标只要是汇总，在dws里面我们只汇总了过去一天的数据，得到以天为粒度的指标。
DWT层：以DWS为基础，按主题进行汇总。实际工作中，需要算某个app，过去1天，过去一周，过去一个月，过去一个季度，过去一年上线以来的新增用户。
ADS层：给领导，给产品经理上交的统计结果。直接通过DWS和DWT很快获得
数据仓库粒度理解：
确定表的最大值和最小值，表的细化程度越高，粒度越小；细化程度越低，粒度越大
数据集市和数据仓库的概念：
数据集市是一种微型的数据仓库，它通常有更少的数据，更少的主题领域，以及更少的历史数据，因此是部门级的，一般来说只能为某个局部范围内的管理人员服务。
数据仓库：是企业级的，能为整个企业各个部门的运行提供决策支持手段。
命名规范：
表命名：层名_表名，
临时表：***_tmp（为得到一些结果，临时数据随时删除，一般建的内部表）
用户行为表：以log为后缀，如果不加就是db
脚本命名：驼峰命名（AaBb），蛇形命名(aa_bb)
范式：
理解为设计一张数据表的表结构，符合的标准级别，规范和要求
范式的优点：关系型数据库设计时，遵守一定的规范要求，目的在于降低数据的冗余。数据一致性，方便增删数据
缺点;缺点就是要多次join，只需要对两条数据进行join，不用对两个整表，数据量比较小，影响不大。
分类：第一范式，第二范式，第三范式，第四第五范式
函数依赖：
完全函数依赖：分数完全依赖于学号，课程
部分函数依赖：姓名部分依赖学号，课程
传递函数依赖：学号退出系名，系名推出系主任，反过来退不出来；
三范式区分：
第一范式：属性不可分割，原子性
第二范式：不存在“部分函数依赖”
第三范式：不能存在传递函数依赖
关系建模和维度建模：
数据处理大致分为：联机事务处理（OLTP），联机分析处理((OLAP)
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果
区别：
| 对比属性 |
OLTP |
OLAP |
| 读特性 |
每次查询只返回少量记录 |
对大量记录进行汇总 |
| 写特性 |
随机、低延时写入用户的输入 |
批量导入 |
| 使用场景 |
用户，Java EE后端项目 |
内部分析师，为决策提供支持 |
| 数据表征 |
最新数据状态 |
随时间变化的历史状态 |
| 数据规模 |
GB, 分库分表 |
TB到PB |
关系建模和维度建模的区别：
维度模型 主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据，大大减少了join操作，提升了查询的执行效率。
关系模型 虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。
在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。
维度表和事实表（重点）
1.维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 它是一个名词。 例如：用户、商品、日期、地区，商家等。（一个事件）
维度表的特征：
- 维度表的范围很宽（具有多个属性、列比较多）
- 跟事实表相比，行数相对较小：通常< 10万条
- 内容相对固定：编码表
维度表为什么需要这样设计？
维度是看待事实的角度，我们在设计的时候并不知道后续的分析业务有哪些，为了减少关联操作（join）,提升性能，就会在一个维度表里面搞很多的字段。
2.事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），事实表是一个动词。例如，订单事件中的下单金额。
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。
事实表的特征：
- 非常的大，条数比较多
- 内容相对的窄：列数较少，具体多少看场景经常发生变化，每天会新增加很多。
1）事务型事实表
以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
2）周期型快照事实表
周期型快照事实表中不会保留所有数据（不会保留每条数据的明细），只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等，中间的变化明细不关心，每天做一个全量。加入购物车是一个典型的周期性快照事实表，我们后续统计的主要是某个商品被加入了购物车多少件，多少人把这个商品加入了购物车，我们并需要关心用户是怎么样把这个购物车加进去的...
3）累积型快照事实表
累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
周期快照事实表与 累计快照事实表的区别？
周期快照事实表记录的是重复的可预测到的时间间隔的事实，例如帐户月结余事实表，用来记录每个月末的帐户结余信息。一般周期快照的数据会按报表需要的周期进行记录，比较适合周期长一些的情况。
而累计快照适用于较短周期，有着明确的开始和结束状态的过程，如一个订单执行的过程，并记录过程中每个步骤的执行时间，使分析人员对执行的过程有整体的把握。周期快照事实表记录上每个步骤的执行时间是逐步建立的，随着执行的过程逐步更新的事实表中。
数据仓库建模（绝对重点）
ODS层
（1）保持数据原貌不做任何修改，起到备份数据的作用，外部表。
（2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
（3）创建分区表，日期分区，防止后续的全表扫描
建模方式：关系建模，业务数据遵循三范式，日志数据就是一个字段,字符串类型...
DWD层（重点中的重点的重点）
DWD层需构建维度模型：一般采用星型模型，呈现的状态一般为星座模型。
维度建模一般按照以下四个步骤：选择业务过程→声明粒度→确认维度→确认事实
降维：需要关联一些维度表，关联的方式就是维度表的外键id，维度表会做一些维度退化，扁平化处理
（1）选择业务过程
在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
（2）粒度：
数据粒度：指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。你可以这样操作，之前是什么粒度，不变即可，原始数据是什么样，你就是什么样，这样就是最小粒度，粒度只会不断变大，没法自己拆分。
典型的粒度声明如下：
订单中，每个商品项作为下单事实表中的一行，粒度为每次下单
每周的订单次数作为一行，粒度就是每周下单。
每月的订单次数作为一行，粒度就是每月下单
（3）确定维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时，因为什么，采用什么方式”等信息。
按照数仓工具箱里面的说法是“谁，什么，，何处何时，为何，如何”等信息。
（4）确定事实
此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理，我们把公共维度抽取出来，取数的时候用外键关联，但是如果某些维度是私有维度，那么你可以把这些维度写入事实表，或者是就是为不join，提升取数的速度，也可以写入事实表，但是这样会存在数据冗余与一致性的问题。