数仓理论

1 数仓分层

1.1 为什么要分层

1、把复杂问题简单化：

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。

2、清晰数据结构：

每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

3、减少重复开发：

规范数据分层，通过中间层数据能够减少大量重复计算，增加计算结果的复用性。

4、隔离原始数据：

使真实数据与统计数据解耦开。

1.2 分层结构

1、ODS层（原始数据层）：不做处理，存放原始数据

原始数据层，存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理。

2、DWD层（明细数据层）：进行简单数据清洗，降维

结构和粒度与ODS层保持一致，对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据），也有公司叫DWI。

3、DWS层（服务数据层）：进行轻度汇总（做宽表）

以DWD为基础，进行轻度汇总。一般聚集到以用户当日，设备当日，商家当日，商品当日等等的粒度。在这层通常会有以某一个维度为线索，组成跨主题的宽表，比如，一个用户的当日的签到数、收藏数、评论数、抽奖数、订阅数、点赞数、浏览商品数、添加购物车数、下单数、支付数、退款数、点击广告数组成的多列表。

4、 ADS层（数据应用层）：为报表提供数据

数据应用层，也有公司把这层命名为APP层、DAL层等。面向实际的数据需求，以DWD或者DWS层的数据为基础，组成的各种统计报表。统计结果最终同步到RDS（Relational Database Service关系型数据库服务）以供BI（Business Intelligence商业智能）或应用系统查询使用。

2 表的分类

实体表：一般是指一个现实存在的业务对象，比如用户表，商品表，商家表，销售员表等等。

维度表：一般是指对应一些业务状态，代码的解释表。也可以称之为码表。比如地区表，订单状态表，商品分类表，支付方式表，审批状态表等等。

事实表：一般指随着业务发生不断产生的数据。

事务型事实表一旦发生不会再变化，比如交易流水表，操作日志表，出库入库记录表等等。

周期型事实表数据会随着业务周期性的推进而变化。 比如订单表，其中订单状态会周期性变化。再比如，请假、贷款申请，随着批复状态在周期性变化。

3 同步策略

数据同步策略的类型包括全量表、增量表、新增及变化表、拉链表

全量表：存储完整的数据。

增量表：存储新增加的数据。

新增及变化表：存储新增加的数据和变化的数据。

拉链表：对新增及变化表做定期合并。拉链表的记录以每条信息的生命周期为单位，一旦该记录的生命周期结束，就重新开始一条新的记录，并把当前日期放入生效开始日期。如果当前信息至今有效，在生效结束日期中填入一个极大值（如9999-99-99或者9999-12-31)。

实体表数据量比较小：通常可以做每日全量表，就是每天存一份完整数据。

维度表数据量比较小：通常可以做每日全量表，就是每天存一份完整数据。

说明：

1）针对可能会有变化的状态数据可以存储每日全量。

2）没变化的客观世界的维度（比如性别，地区，民族，政治成分，鞋子尺码）可以就存一份固定值。

事务型事实表因为数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，可以做成每日增量表，即每日创建一个分区存储。

周期型事实表

不能做成每日全量表：从数据量的角度，存每日全量的话，数据量太大，冗余也太大。

不能做成每日增量表：如果用每日增量的话无法反应数据变化。

所以要做每日新增及变化表：每日新增及变化量可以用，包括了当日的新增和修改。一般来说这个表足够计算大部分当日数据，但是这样依然无法解决能够得到某一个历史时间点（时间切片）的切片数据。 为了解决这个问题，可以利用每日新增和变化表，制作一张拉链表，以方便的取到某个时间切片的快照数据。

4.1 函数依赖

某个属性集决定另一个属性集时，称另一个属性集依赖于该属性集。这种依赖性包括完全函数依赖、部分函数依赖、传递函数依赖。

完全函数依赖：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。即X可以推出Y，但是任意X的真子集不能推出Y。

部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

传递函数依赖：设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

4.2 三范式

传统数据库设计遵循三范式，而数仓反三范式。

概念：符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。通俗地讲，范式可以理解为一张数据表的表结构所符合的某种设计标准的级别。

目的：

  1）减少数据冗余，尽量让每个数据只出现一次。

  2）保证数据一致性

缺点：获取数据时，需要通过join拼接出最后的数据。

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

第一范式1NF核心原则就是：属性不可切割。实际上，1NF是所有关系型数据库的最基本要求，在关系型数据库管理系统(RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据的设计不符合这个最基本的要求，都么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。

第二范式2NF核心原则：在第一范式的基础上，消除“部分函数依赖”

第三范式3NF核心原则：在第二范式的基础上，消除“传递函数依赖”

5 模型

5.1 关系建模

关系模型主要应用于OLTP系统中，为了保证数据的一致性以及避免冗余，大部分业务系统的表都是遵循第三范式的。On-Line Transaction Processing联机事务处理过程(OLTP)，也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一，应用于飞机订票、股票交易、超市销售等。

5.2 维度建模

维度模型主要应用于OLAP系统中。因为关系模型虽然冗余少，但是在大规模数据 跨表分析统计查询过程中 会造成多表关联，这会大大降低执行效率，所以需要把各种相关表整理成事实表和维度表两种，所有维度表围绕着事实表进行解释。On-Line Analysis Processing联机分析处理(OLAP)，是以数据仓库为基础的，其最终数据来源与OLTP一样均来自底层的 数据库系统，它使分析人员、管理人员或执行人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。

5.2.1 星型模型

性能优先，选星型模型。

当所有维度表都直接连接到“事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。

星型架构是一种非正规化的结构，标准的星型模型维度只有一层，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，比如在地域维度表中，存在国家 A 的省 B 的城市 C 以及国家 A 的省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。

在冗余可以接受的前提下，实际运用中，星型模型使用得更多，也更有效率（以空间换时间）。

5.2.2 雪花模型

灵活优先，选雪花模型。

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。

雪花模型是对星型模型的扩展，会涉及多级，介于关系模型和星座模型之间，比较靠近3NF，但是无法完全遵守，因为遵循3NF的性能成本太高。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。比如将地域维表又分解为国家，省份，城市等维表。

雪花型结构去除了数据冗余，最大限度地减少数据存储量，但是要进行多表关联，在Hadoop体系中会增加shuffle，降低性能。

5.2.3 星座模型

星座模型有多个事实表，并且这些事实表共享一些维度表。星型模型和雪花模型都只有一个事实表，多个星型模型和雪花模型可组成一个星座模型。