数据仓库分层

一.数据仓库分层

• ODS(Operation Data Store)层：原始数据层，存放加载原始日志、数据，数据保持原貌不做处理。
• DWD(Data warehouse detail)层：对ODS层数据进行清洗（去除空值，超过极限范围的数据）、维度退化、脱敏等。
• DWS（data warehouse service）层：以DWD为基础，按天进行轻度汇总。
• DWT（data warehouse Topic）层：以DWS为基础，按主题进行汇总。
• ADS（Application Data Store）层：为各种统计报表提供数据。

二.数据仓库为什么要分层？

• 把复杂问题简单化：将复杂的任务分解成多层来完成，每一层只处理简单的任务，方便定位问题。
• 减少重复开发：规范数据分层，通过的中间层数据，能够减少极大的重复计算，增加一次计算结果的复用性
• 隔离原始数据：不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。

三. 作用

ODS：关系建模
DWD：

• 数据清洗：过滤脏数据（去空值，把不符合要求的数据过滤），把数据分类，给某些数据添加必要字段。
• 维度建模

DWS：需要按照主题建模，主题是一个分析问题的角度，圈定了一个分析的范围，计算出这个主题各种指标，而我们的指标主要都是汇总，在DWS里面只汇总过去一天的数据，得到以天为粒度的指标。
DWT：实际的工作中，需要计算某个App，过去1天、1周、1月、1个季度、1年，上线以来的新增用户。
ADS：给领导，给产品经理需要各种统计结果，直接从DWS和DWT很快得到。

四.数据集市与数据仓库

区别

• 数据集市（Data Market）：是一种微型的数据仓库，通常有更少的数据，更少的主题区域，以及更少的历史数据，因此是部门级别的，一般只能为某个局部范围内的管理人员服务。
• 数据仓库是企业级别的，能为整个企业各个部门的运行提供决策支持手段。

五.数据仓库命名规范

表命名

• ODS层命名为ods_表名 ods_payinfo
• DWD层命名为dwd_dim/fact_表名（dim指的是维度表，fact指的是事实表）
  dwd_dim_user dwd_fact_pay ----> dwd_表
• DWS层命名为dws_表名
• DWT层命名为dwt_表名
• ADS层命名为ads_表名
• 临时表命名为xxx_tmp，为了得到一些结果临时数据，随时的删除，一般建的是内部表
• 用户行为表，以log为后缀。如果不加就是db

六.数仓范式概念

定义：范式可以理解为设计一张数据表的表结构，符合的标准级别，规范和要求
优点
关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性。
为什么要降低冗余性？

• 为了减少磁盘存储
• 以前没有分布式系统，都是单机，只能增加磁盘，磁盘的个数也是有限的
• 一次修改，需要修改多个表，很难保证数据的一致性
• 方便增删数据

缺点
获取数据时，需要通过Join拼接出最后的数据，主要因为这个业务数据要对单条或者几条数据的随机读写，这样Join成本不会太高，大量的Join就会导致处理速度非常的慢。

七.范式的分类

目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

八.范式的分区

• 第一范式的核心原则就是：属性不可切割。是所有关系型数据库的最基本要求，如果数据表的设计不符合这个最基本的要求，那么操作一定不能成功。
• 第二范式的核心原则就是：不能存在“部分函数依赖”
• 第三范式的核心原则就是：不能存在传递函数依赖

九.关系建模与维度建模（重点）

数据处理大概可以分为两类：

• 联机事务处理OLTP（on-line transaction processing）：是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理。
• 联机分析处理OLAP（on-line analytical processing）：数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

区别：

对比属性	OLTP	OLAP
读写性	每次查询只返回少量记录	对大量记录进行汇总
写特性	随机、低延时写入用户的输入	批量导入
使用场景	用户，Java EE后端项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据规模	GB、分表分库	TB到PB

关系建模

关系建模如图所示，严格遵守第三范式，由于数据分布于众多的表中，这些数据可以更为灵活的被应用，功能性较强，关系模型主要应用与OLAP系统中，为了保证数据的一致性以及避免冗余，大部分业务系统的表都是遵循第三范式的。

维度建模如图所示，主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据，大大减少了Join操作，提升了查询的执行效率。
关系模型虽然冗余少，但在大规模数据，跨表分析统计查询过程中，会造成多表类关联，这会大大降低执行效率，所以通常采用维度建模建模，把相关各种表整理成两种：事实表和维度表

维度建模

在维度建模的基础上分为三种：

• 星型建模：它与雪花建模区别在于维度的层级，标准的星型模型只有一层，而雪花会涉及多层。
• 雪花建模：比较靠近3NF，但是无法完全遵守，因为遵循3NF的性能成本太高
• 星座建模：与其他两种区别是事实表的数量，星型模型是基于多个事实表，基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的，所以星座不星座知识反应是否有多个事实表，它们之间是否共享一些维度表，并不起冲突

十.维度表和事实表（重点）

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或概念。

维表的特征

• 维度的范围很宽（具有多个属列比较多）
• 跟事实表相比，行数相对较小：通常<10万条
• 内容相对固定：编码表

维度是看待事实的角度，在设计的时候并不知道后续的分析业务有哪些，为了减少关联操作（join），提升性能，就会在一个维度表里面搞很多字段。

事实表

事实表中的每行数据代表一个业务事件（一个业务事件对应一个事实表），“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等）
每一个事实表的行包括：具有可加性的数值型的度量值、与维度相连接的外键，通常具有两个或两个以上的外键、外键之间表示维度之间多对多的关系。

特征

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

事务性事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新

周期型快照事实表

周期型快照事实表中不会保留所有数据（不会保留每条数据的明细），只保留固定时间间隔的数据，中间的变化明细不关心，每天做一个全量。（加入购物车是一个典型的周期性快照事实表，后续统计的主要是某个商品被加入了购物车多少件，多少人加入了购物车，我们关心的是用户是怎么把这个加入的购物车）

累积型快照事实表

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

周期快照事实表与 累计快照事实表的区别？

• 周期快照事实表记录的是重复的可预测到的时间间隔的事实，例如账户月结余事实表，用来记录每个月末的账户结余信息，一般周期快照的数据会按报表需要的周期进行记录，比较适合周期长一点的情况。
• 累计快照适用于较短周期，有着明确的开始和结束状态的过程，如一个订单执行的过程，并记录过程中每个步骤的执行时间，使分析人员对执行的过程有整体的把握，周期快照事实表记录上每一个步骤的执行时间是逐步建立的，随着执行的过程逐步更新的事实表中