大数据学习笔记--一些数据仓库里的基本概念

一些数据仓库的基本概念

数仓分层：

数据仓库一半都是默认分4层：

• ODS(Operation Data Store)层（原始数据层
  • 原始数据层，直接加载原始日志、数据，数据保存原貌不做处理
• DWD(Data Warehouse Detail)层（明细数据层
  • 明细数据层，结构和粒度与原始表保持一致，对ODS层数据进行清洗，也叫DWI层
• DWS(Data Warehouse service)层（服务数据层
  • 服务数据层，以DWD为基础，进行轻度汇总，一般聚集到以用户当日、设备当日、商家当日、商品当日等等的粒度
  • 这层通常会以某一个维度作为线索，组成跨主题的宽表，比如一个用户当日的签到数、收藏数、评论数等明细数据组成的多列表
• ADS(Application Data Store)层（数据应用层
  • 数据应用层，为各种统计报表提供数据，也有公司或者书把这层命名为APP层、DM层等

为什么要分层

1. 复杂问题简单化
   • 将一个复杂的任务拆解成多个步骤完成，每一层只处理单一的步骤，比较简单且容易定位问题
2. 减少重复开发
   • 规范数据分层，通过中间层的数据，能够极大减少重复计算，增加一次计算结果的复用性
3. 隔离原始数据
   • 将各级数据分开存放，可以使真实数据与统计数据解耦开

一些常见的命名规范

• ODS层表以ods开头
• DWD层表以dwd开头
• DWS层表以dws开头
• ADS层表以ads开头
• 临时数据表命名为xxx_tmp
• 备份数据数据库命名为xxx_bak

数据集市与数据仓库的区别

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

表的分类

• 实体表：一般指一个现实存在的业务对象，比如用户、商品等等
• 维度表：一般是对应一些业务状态，编号的解释表。也称为码表，比如地区表、订单状态等等
• 事务型事实表：一般指随着业务发生不断产生数据，特点是一旦发生不会再变化，比如交易流水、操作日志等等
• 周期型事实表：一般指随着业务发生不断产生变化（更新、新增）的数据，与事务型事实表的区别在于数据会随着业务周期性的推进而变化，比如订单数据，或者贷款申请等随着批复状态在周期性变化的数据

同步策略

​ 数据同步策略的类型包括如下：

• 全量表：存储完整的数据
• 增量表：存储新增加的数据
• 新增及变化表：存储新增加的数据和变化的数据
• 拉链表：对新增及变化表做定期合并

实体表同步策略

​ 实体表：如用户、商品、商家、销售员等

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

维度表同步策略

​ 维度表：比如订单状态、审批状态、商品分类

​ 维度表数据量比较小，通常可以做每日全量，但是也分情况：

• 针对可能会有变化的状态数据可以存储每日全量
• 没变化的客观世界的维度（比如性别、地区、民族、政治成分、鞋子尺码等等）可以只存一份固定值（因为基本不会产生变化）

事务型事实表同步策略

​ 事务型事实表：如交易流水、操作日志、出库入库记录等

​ 因为数据不会变化、且数据量巨大，所以每天只同步新增数据即可，即做成每日新增表、每日创建一个发呢去存储

周期型事实表同步策略

​ 周期型事实表：比如订单、请假、贷款申请等

​ 这类表从数据量的角度，存每日全量的话、数据量太大、冗余也很大。如果用每日增量的话无法反应数据变化

​ 每日新增及变化量的同步策略包括了当日的新增以及修改，一般来说这个表足够计算大部分当日的数据的，但是这种方法依旧无法解决能够得到某一个历史时间点（时间切片）的切片数据

​ 因此要利用每日新增和变化表制作一张拉连表，以方便的取到某个时间切片的快照数据

范式理论

范式的概念

​ 关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性，目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)

​ 范式可以理解为设计一张数据表的表结构时要符合的标准级别。

​ 使用范式的根本目的在于：

• 减少数据冗余，尽量让每个数据只出现一次
• 保证数据的一致性

使用范式规范的缺点在于获取数据时需要通过join拼接出最后的数据，会一定程度的影响查询性能

三范式的区分

• 第一范式：属性符合原子性，即不可切割，第一范式是所有关系型数据库的最基本要求，不符合第一范式的数据表在关系型数据库中其创建操作是一定不会成功的
• 第二范式：不存在部分函数依赖
• 第三范式：不存在传递函数依赖

关系建模与维度建模

• 关系模型

  • 关系模型主要应用于OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第二范式的。
  • 虽然关系型模型冗余少，但是当进行大规模数据处理的时候，因为跨表分析统计的过程中会造成多表关联，导致执行效率被大大降低

• 维度模型

  • 维度模型主要应用与OLAP系统中，主要将相关的各种表整理成两种，即事实表和维度表，所有的维度表都围绕着事实表进行解释

• OLAP与OLTP的对比

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

雪花模型、星型模型和星座模型

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

• 星型模型：对每个维度的展开都只有一层，与雪花模型的区别主要就在于维度的层级
• 雪花模型：即比星型模型的维度层级更高，雪花模型比较靠近第三范式，但是无法完全遵守
• 星座模型：星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表的。
  • 星座模型实际上是很多数据仓库的常态，因为很多数据仓库都是有多个事实表的
  • 星座模型实际反映的只有是否有多个事实表以及他们之间是否共享一些维度表

对模型的选择：

• 星座模型取决于实际的数据和需求，与设计无关，不需要选择
• 星型模型和雪花模型之间的选择取决于性能优先还是灵活性优先
  • 在实际的企业开发中，不会绝对选择某一种模型，而是两者混用甚至并存
  • 但是整体来说，更倾向于维度更少的星型模型，特别是hadoop体系，减少join就是减少shuffle，性能体现很明显