数据仓库与建模基础理论

数据仓库与建模基础理论

数据仓库的基本概念

• 数据仓库是一个面向主题、集成的、非易失的且随时间变化的数据集合
• 主要用于组织积累的历史数据，并使用分析方法（OLAP、数据分析）进行分析整理，进而辅助决策，为管理者、企业系统提供数据支持、构建商业智能

数据仓库的特点

• 面向主题：为数据分析提供服务，根据主题将原始数据集合在一起

• 集成：原始数据来源于不同的数据源，要整合成最终数据，需要经过抽取、清洗、转换的过程

• 非易失：保存的数据是一系列的历史快照，不允许修改，只通过工具进行查询、分析

• 时变性：数据仓库定期接收、集成新的数据，从而反映数据的最新变化

数据仓库 VS 数据库

数据库面向事务设计，属于OLTP（在线事务处理）系统，主要操作是随机读写；在设计时尽量避免冗余，常采用范式规范来设计；

数据仓库面向主题设计，属于OLAP（在线分析处理）系统，主要操作是批量读写；关注数据整合，以及分析、处理性能；会有意引入冗余，采用反范式来设计；

	数据库	数据仓库
面向	事务	主题
数据	细节、业务	经过综合、清洗、转换过的数据
数据特点	当前的、最新的	历史的、跨时间维护
目的	日常操作	决策支持
设计模型	基于ER模型、面向应用	基于星形/雪花模型，面向主题
操作	随机读/写操作	大多数情况下为批量读操作
数据规模	GB—>TB	>=TB

数据仓库的两种形式

传统数据仓库

由关系数据库组成MPP（大规模并行处理）集群，由单机关系型数据库改造的，完全兼容原有的SQL语法，业务迁移方便，继承了单机关系型数据库的优异性能。

对于扩展性问题，传统数据仓库是从单机架构发展过来的，每一个节点还是一个数据库，它们是独立进行运算的，如果要和其他数据库交换数据，则需要通过高速网络连接来交换数据，从而限制了节点的上限。

对于热点问题，假设一张大表有1000w行数据，存储的时候分成了10份，一份有100w行，如果前100w行数据是热点数据，又恰好都被存储到某个节点中，那么这个节点承受的压力是其他节点的数倍，这样的话这个节点可能会出现宕机或者超时的情况，一旦它成为了集群的瓶颈，整个系统的性能就会降低。当我们的技巧的规模越大，节点就会越多，节点出现问题的频率也会越高，整个集群的可用性就会降低。

MPP架构

• 将单机数据节点组成集群，提升整体处理性能
• 节点间为非共享架构，每个节点都有独立的磁盘存储系统和内存系统
• 每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供服务
• 对于CAP理论，在设计上依次优先考虑C、A、P

架构的特点：

• 运算方式精细，延迟低、吞吐量低

• 适合中小规模的结构化数据处理

• 存储位置不明确，通过Hash确定数据所在的物理位置

• 并行计算时，单点瓶颈会成为整个系统的短板

• 分布式事务的实现会导致扩展性降低

大数据数据仓库

采用分布式架构；利用大数据天然的扩展性，完成海量数据的存放；将SQL转换为大数据计算引擎任务，完成数据分析

分布式架构

• 各节点可以单独运行局部应用，数据在集群中透明共享
• 每个节点通过局域网或者广域网相连，节点间的通信开销大，在运算时，数据移动少
• 对于CAP理论，在设计上依次优先考虑的是P、A、C

架构的特点：

• 解决了单点故障问题，会将出错的任务调度到其他副本节点
• 数据吞吐量大
• 扩展性强，适合处理非结构化、半结构化的数据
• 对于存储，需要将中间结果进行存储，数据移动开销大

数据仓库架构

架构图

ETL------抽取（Extract）、转换（Transform）、加载（Load）

• 将数据从来源端经过抽取、转换、加载至目的端的过程
• 是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照定义好的数据仓库模型，将数据加载进去
• ETL规则的设计和事实约占整个数据仓库搭建工作量的60%~80%

数据抽取

• 数据源分为结构化、非结构化、半结构化数据
• 结构化数据一般采用JDBC，数据库日志方式，非|半结构化数据会监听文件变动

抽取方式

数据抽取方式有全量同步，增量同步两种方式

• 全量同步将全部数据进行抽取，一般用于初始化数据装载
• 增量同步方式会检测数据的变动，抽取发生变动的数据，一般用于更新数据

数据转换

要经历数据清洗和转换两个阶段

• 数据清洗主要是对出现的重复、二义性、不完整、违反业务或逻辑规则等问题的数据进行统一的处理
• 数据转换主要是对数据进行标准化处理，进行字段、数据类型、数据定义的转换
• 结构化数据在转换的过程中的逻辑较为简单，非|半结构化的数据的转换较为复杂

数据加载

将最后的处理完的数据导入到对应的目标源

结构化数据ETL工具

Kettle、Sqoop、Kafka等

非|半结构化数据ETL工具

Flume

ODS（操作数据层）

数据与原业务数据保持一致，可以增加字段用来进行数据管理

存储的历史数据是只读的，提供业务系统查询使用

业务系统对历史数据完成修改后，将update_type字段更新为UPDATE，追加回ODS中

在离线数仓中，业务数据定期通过ETL流程导入到ODS中，导入方式有全量、增量两种

• 全量导入，数据第一次导入采用此种方式
• 增量导入，只导入新增、更改后的数据，用外连接或者全连接

DWD（数据明细层）

• DWD对ODS的数据进行清洗、标准化、维度退化（时间、分类、地域）
• 数据仍然满足3NF，为分析运算做准备

DWS（数据汇总层）

• DWS的数据对数据明细的数据，按照分析主题进行计算汇总，存放便于分析的宽表
• 存储模型并非3NF，而是注重数据聚合，复杂查询、处理性能更优的数仓模型，如维度模型
• 是数据仓库的核心

ADS（数据应用层）

• 数据应用层也被称为数据集市
• 存储数据分析结果，为不同业务场景提供接口，减轻数据仓库的负担（如果直接开放业务查询接口，会加重其负担）

建模方法

基本概念

OLTP系统建模方法

• OLTP（在线事务处理）系统中，主要操作是随机读写
• 为了保证数据的一致性，减少冗余，常使用关系模型
• 在关系模型中，使用3NF规则来减少冗余

OLAP系统建模方法

• OLAP（在线联机分析处理）系统中，主要操作是复杂分析查询、关注数据整合，以及分析、处理性能
• OLAP根据数据存储的方式不同，又分为ROLAP、MOLAP、HOLAP

OLAP的分类

• ROLAP（关系型OLAP）：使用关系模型构建，存储系统一般为关系数据库管理系统（RDBMS）
• MOLAP（多维型OLAP）：预先聚合计算，使用多维数组的形式保存数据结果，加快查询分析时间
• HOLAP（混合架构的OLAP）：ROLAP和MOLAP两者的集成，查询效率低于MOLAP，高于ROLAP

ROLAP系统建模方法

典型的数据仓库建模方法有ER模型、维度模型、Data Value、Anchor。其中Data Value和Anchor是ER模型的衍生，适用于业务稳定、成熟的场景；维度模型为分析需求服务，能更快的完成需求分析，具有较好的大规模复杂查询相应性能，是最流行的数仓建模经典

维度模型

基本概念：

• 维度模型中，表被分为维度表、事实表，维度是对事实的一种组织
• 维度一般包含分类、时间、地域等
• 比如 在网上购物商城中，物品就是一个事实，物品的类别就是一个维度。同一个类别下有很多个物品即维度是对事实的一种组织。

维度模型建立后，方便对数据进行多维分析，维度模型分为三种，分别是星型模型、雪花模型、星座模型。

1. 星型模型

   标准的星型模型，维度只有一层，分析性能最优

   

2. 雪花模型

   雪花模型具有多层维度，接近3NF，较为灵活

   

3. 星座模型

   • 星座模型基于多个事实表，事实表之间会共享一些维度表
   • 是大型数据仓库中的常态，是业务增长的结果，与模型设计无关

​

宽表模型

• 宽表模型是维度模型的衍生，适合join性能不佳的数据仓库产品

• 宽表模型将维度冗余到事实表中，形成宽表，以此减少join操作

  

MOLAP系统建模方法

• MOLAP将数据进行预结算，并将聚合结果存储到CUBE模型中
• CUBE模型以多维数组的形式，物化到存储系统中，加快后续的查询
• 生成的CUBE需要大量的时间、空间，维度预处理可能会导致数据膨胀
• 常见的MOLAP产品Kylin、Druid

OLAP多维分析

• OLAP主要操作是复杂查询，可以多表关联，使用count、sum、avg等聚合函数
• OLAP对复杂查询操作做了直观的定义，包括钻取、切片、切块、旋转

钻取

1. 对维度不同层次的分析，通过改变维度的层次来变换分析的粒度
2. 钻取包括上卷、下钻；上卷指的是从低层次到高层次的切换，下钻指的是从高层次到低层次的切换

切片

1. 选择某个维度进行分割称为切片
2. 按照多个维度进行切片称为切块

旋转

对维度方向的互换，类似于交换坐标轴上卷

表的分类

维度建模中的表类型

• 事实表
• 维度表
• 事务事实表
• 周期快照事实表
• 累积快照事实表

事实表

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

用户ID	姓名	生日	性别	邮箱	用户等级	创建时间
1	张三	2000-01-03	男	123@163.com	3	2000-01-03
2	李四	2000-01-02	男	1234@163.com	2	2000-01-02
3	王五	2000-01-01	男	1235@163.com	1	2000-01-01

维度表

• 一般是指对应一些业务状态，代码的解释表。也可以称之为码表
• 通常使用维度对事实表中的数据进行统计、聚合运算

订单状态	状态名称
1	未支付
2	已支付
3	发货中
4	已发货
5	已完成

商品编号	分类名称
1	生活
2	科技
3	少儿

事务事实表

• 随着业务不断产生的数据，一旦产生不会再变化，如交易流水、操作日志、出库入库记录

编号	对外业务编号	订单编号	用户编号	支付交易流水编号	支付金额	交易内容	支付类型	交易时间
1	56123	1	021	Qyy1q12	300.5	火锅底料	alipay	2022-2-20
2	56124	2	012	Qyy1q13	188.0	烤鱼	alipay	2022-2-20
1	56125	3	102	Qyy1q14	20.0	鸭肠	alipay	2022-2-20

周期快照事实表

随着业务周期型的推进而变化，完成间隔周期内的度量统计，如年、季度累计

使用周期+状态度量的组合，如年累计订单数、年是周期，订单总数是量度

业务ID	卖家ID	年累计下单金额	年累计买家数	年累计支付金额	年累计支付买家数	……
1	001	308900	123	299801	119
2	002	427890	212	419800	207
3	003	689120	341	678801	310

累积快照事实表

记录不确定周期的度量统计，完全覆盖一个事实的生命周期，如订单状态表

通常有多个时间字段，用于记录生命周期中的关键时间点

只有一条记录，针对此记录不断更新

订单编号	订单金额	订单状态	用户ID	下单时间	支付时间	确认收货时间	相关事实
1	300	1	021	2022-02-20	NULL	NULL
1	300	1	021	2022-02-20	2022-02-20	NULL
1	300	1	021	2022-02-20	2022-02-20	2020-02-23

订单编号	订单金额	订单状态	用户ID	下单时间	支付时间	确认收货时间	相关事
1	300	1	021	2022-02-20	2022-02-20	2020-02-23

三种实现方式

方法一：

1. 使用日期分区表，全量数据记录，每天的分区存储昨天全量数据与当天增量数据合并的结果
2. 数据量大会导致全量表膨胀，存储大量永远不更新的冷数据，对性能影响较大
3. 使用与数据量少的情况

方法二：

1. 使用日期分区表，推测数据最长生命周期，存储周期内的数据；周期外的冷数据存储到归档表
2. 需要保留多天的分区数据，存储消耗依然很大

方法三：

1. 使用日期分区表，以业务实体的结束时间分区，每天的分区存放当天结束的数据；设计一个时间很大的分区，如9999-12-31，存放截止当前未结束的数据；
2. 已结束的数据存放到相应分区，存放未结束数据的分区，数据量也不会很大，ETL性能好
3. 无存储浪费，数据全局唯一
4. 业务系统可能无法标识业务实体的结束时间，可以使用其他相关业务系统的结束标志作为此业务系统的结束，也可以使用最长生命周期或前端系统的数据归档时间

拉链表（非维度建模）

拉链表记录每条信息的生命周期，用于保留数据的所有历史（变更）状态

拉链表将表数据的随机修改方式，变为顺序追加

订单编号	订单金额	订单状态	生效开始日期	生效结束日期
1	300	已支付	2022-02-20	9999-99-99
2	2000	待支付	2022-02-20	9999-99-99

订单编号	订单金额	订单状态	生效开始日期	生效结束日期
1	300	已支付	2022-02-20	9999-99-99
2	2000	待支付	2022-02-20	9999-99-99
3	2000	已支付	2022-02-21	9999-99-99

ETL策略

全量同步

1. 数据初始化装载一定使用全量同步的方式
2. 使用全量同步的方式做周期数据更新，直接覆盖原有数据即可

增量同步

• 传统数据整合方案中，大多采用合并方式（update+insert）
• 大多采用全外连接+数据全量覆盖方式

任务调度

任务调度解决任务单元间的依赖关系，自动化完成任务的定时执行

常见的任务类型：shell、java程序、mapreduce程序、sql脚本

工具：Azkaban、Oozie