16-数据仓库之数据建模、数据建模表的分类、数据建模步骤、数据分层的原因和优点

九、数据仓库

9.1 数据处理方式

9.1.1 OLTP

1. 定义理解
   • OLTP的全称是On-line Transaction Processing，中文名称是联机事务处理
2. 特点
   • 主要用于管理事物，用来处理高并发且数据量级不大的查询
   • 此类系统专注于short on-line-tansactions，如insert、update、delete、query操作
   • 通常存在此系统中的数据都是以实体对象模型来存储的，并且满足3NF
3. 应用场景
   • 由于OLTP主要是为了操作数据而设计（操作系统），用于处理已知的任务和负载
   • 常见的优化在于主码索引和散列，检索特定的记录。去优化某一些特定的查询语句。

9.1.2 OLAP

1. 定义理解
   • OLAP的全称是 On-line Analytical Processing,中文名称是联机分析处理
2. 特点
   • 查询频率比OLTP系统低，但通常会涉及到非常复杂的聚合计算
   • OLAP系统以维度模型来存储历史数据，其主要存储描述性的数据并且在结构上都是同质的
3. 应用场景
   • OLAP则是为了分析数据而设计（数据仓库）的，其查询的方式往往是复杂且未知的，通常会涉及大量数据在汇总后的计算
   • 这种需要基于多维视图的数据操作在OLTP上执行的时候性能将是非常差的，并且也是极其危险的

9.1.3 OLTP和OLAP的区别总结

1. OLTP 和 OLAP：这两个术语看起来很相似，但指的是不同类型的数据处理系统
   • 联机事物处理（OLTP）可以实时捕获、存储和处理来自事物的数据。
   • 联机分析处理（OLAP）使用复杂查询来分析来自OLTP系统的聚合历史数据
2. 对于这两种系统的使用
   • 问题不在于选择哪一种，而在于如何针对您的情况充分利用这两种处理类型
   • 在线分析处理（OLAP）和在线事务处理（OLTP）。主要区别在于，一个使用数据来获得有价值的见解，而另一个则纯粹是操作性的。但是，有一些有意义的方法可以使用这两个系统来解决数据问题

	OLTP	OLAP
特性	处理大量小额交易	通过复杂的查询处理大量数据
查询类型	简单的标准化查询	复杂查询
操作	基于插入、更新、删除命令	基于 SELECT 命令聚合数据以进行报告
响应时间	毫秒	秒、分钟或小时，具体取决于要处理的数据量
设计	特定于行业，例如零售、制造或银行业	特定于主题，例如销售、库存或市场营销
源	交易	来自交易的聚合数据
目的	实时控制和运行基本业务运营	规划、解决问题、支持决策、发现隐藏的见解
数据更新	由用户发起的简短、快速更新	使用计划的、长时间运行的批处理作业定期刷新数据
空间要求	如果存档了历史数据，则通常很小	由于聚合大型数据集，通常很大
备份和恢复	需要定期备份以确保业务连续性并满足法律和公司治理要求	可以根据需要从 OLTP 数据库重新加载丢失的数据，以代替常规备份
生产力	提高最终用户的工作效率	提高业务经理、数据分析师和高管的工作效率
数据视图	列出日常业务交易	企业数据的多维视图
用户示例	面向客户的人员、文员、在线购物者	知识工作者，如数据分析师、业务分析师和高管
数据库设计	规范化数据库以提高效率	用于分析的非规范化数据库

9.2 数据建模

1. 数据建模的理解

   • 数据建模是指对现实世界各类数据的抽象组织，确定数据库需要管辖的范围、数据的组织形式等直至转化为现实的数据库

2. 数据建模的目标（将经过系统分析后抽象出来的概念模型转化为物理模型需要注意的方面）

   • 访问性能：良好的模型能帮我们快速查询需要的数据，减少数据的IO吞吐
   • 数据成本：减少数据冗余、计算结果复用、从而降低存储和计算成本
   • 使用效率：改善用户使用数据的体验，提高使用数据的效率
   • 数据质量：改善统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台

   综上，大数据的数仓建模需要通过建模的方法更好地组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点

9.2.1 ER建模

1. 定义理解

   • 把数据抽象成二维表，将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述
   • ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式，且该建模方法需要满足3NF
   • 从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，站在企业高度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象
     • 简而言之，第一范式就是无重复的列。
     • 简而言之，第二范式就是非主属性完全依赖于主关键字。
     • 简而言之，第三范式就是属性不依赖于其它非主属性。

2. 优点

   • 规范性好、冗余小、数据集成和数据一致性方面得到重视

3. 缺点

   • 需要全面了解企业业务、数据和关系；实施周期非常长、成本昂贵；对建模人员的能力要求也非常高，容易烂尾

9.2.2 维度建模

1. 维度建模出现的原因
   • 逐渐随着企业数据的高增长，复杂化，数仓全部使用ER模型建模显得越来越不合时宜。为什么呢，因为其按部就班的步骤，三范式等，不适合现代化复杂，多变的业务组织
2. 定义理解
   • 维度建模以分析决策的需求出发来构建模型，构建的数据模型为分析需求服务，因此他的重点在于解决用户如何快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务
3. 维度建模中的两种类型的表
   • 事实表
     • 发生在显示世界中的操作型事件，都是发生在实体之间的，伴随着这种操作所产生的的可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。从最低的粒度级别来看，事实表对应一个度量事件，反之亦然
   • 维度表
     • 每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境与事实表行完全对应
     • 维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性
   • 度量值
     • 度量值是对一次行为的度量
4. 优点
   • 技术要求不高，快速上手，敏捷迭代，快速交付；
   • 更快的完成分析需求，较好的大规模复杂查询的响应性能
5. 缺点
   • 维度表的冗余会较多，视野狭窄

9.2.3 ER建模和维度建模的比较

9.3 维度建模表分类

✔️维度模型思维导图

在维度建模中，将度量称为“事实”，将环境描述为“维度”

例：今天张三买了一瓶两块的矿泉水
在这里：”今天“、“张三”、“买”、”矿泉水“是维度，“一瓶”，“两块”是事实

9.3.1 维度表

维度表中存放了具有独立属性和层次结构的数据，一般由维度编码和对应的维度说明组成

1. 维度表的概念

1. 维度

   • 维度是维度建模的基础和灵魂，对观察数据的角度

   • 在维度建模中，将度量称为“事实”，将环境描述为“维度”，维度是用于分析事实所需要的多样环境

   • 表示时间：日期-年-月-日-季-周（是不是有点像日期表）
     表示地点：国-省/州-市-区县-镇-村
     品类：用途-品牌-包装
     …………

     类似上面这些具有独立属性或层次结构的信息，我们将其称之为数据的维度

2. 维度属性

   • 维度所包含的表示维度的列，称为维度属性
   • 维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键

3. 维度表的特征

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

2. 维度表的设计原则

1. 维度属性尽量丰富，为数据使用打下基础
   • 比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。
2. 给出详实的、富有意义的文字描述
   • 属性不应该是编码，而应该是真正的文字

9.3.2 事实表

事实表示对业务数据的度量，通常是数字类型的，可以进行聚合和计算

事实表中存储里能体现实际数据或者详细数值，一般由维度编码和事实数据组成

9.4 维度建模模型的分类

维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。

9.4.1 星型模型

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MY1FiXom-1656602010386)(https://typora-js.oss-cn-shanghai.aliyuncs.com/imgs/2022/06/30/20220630175040)]

1. 定义理解
   • 是一种多维的数据关系，由一个事实表和一组维表组成，每个维表都有一个维作为主键，所有这些维的主键组合成事实表的组件
   • 星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实上，呈星型分布
2. 特点（缺点）
   • 星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一点的冗余
   • 维表只和事实表关联，维表之间没有关联

9.4.2 雪花模型

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DVczDv2h-1656602010387)(https://typora-js.oss-cn-shanghai.aliyuncs.com/imgs/2022/06/30/20220630175300)]

1. 定义理解
   • 雪花模型，是在星型模型的基础上，维度表上又关联了其他维度表
2. 特点
   • 这种模型维护成本高，性能方面也较差，所以一般不建议使用，尤其是基于Hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
3. 星型模型和雪花模型主要区别就是对维度表的拆分
   • 对于雪花模型，维度表的涉及更加规范（一个维度被规范化成多个关联的维度表，星型模型中每个维度由单一的维度表所表示），一般符合3NF，有效降低数据冗余，维度表之间不会相互关联，
   • 但是而星型模型，一般采用降维的操作，反规范化，不符合3NF,利用冗余来避免模型过于复杂，提高易用性和分析效率，效率相对较高。

3. 星座模型

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Uo46toWP-1656602010387)(https://typora-js.oss-cn-shanghai.aliyuncs.com/imgs/2022/06/30/20220630175854)]

1. 定义理解
   • 是对星型模型的扩展延伸，多张事实表共享维度表，数仓模型建设后期，大部分维度建模都是星座模型
   • 星座模型需要多个事实表共享维度表，因而可以视为星型模型的集合，故被称为星座模型

9.5 维度建模步骤

选择业务处理过程 > 声明粒度 > 选择维度 > 确定事实

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gun6bZxx-1656602010388)(C:/Users/18446/AppData/Roaming/Typora/typora-user-images/image-20220630224317468.png)]

9.5.1 选择业务处理过程

1. 选择感兴趣的业务线，如下单，支付，退款，活动

   • 可以选择单一业务分析

   • 也可以选择组合业务分析

2. 深入理解

   • 维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。
   • 比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户的购买情况等，我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。

9.5.2 声明粒度

1. 声明粒度：

   • 一行代表信息：一条订单？一天的订单？一周的订单？ 选择最小粒度

   • 先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。

2. 使用相同粒度的原因

   • 为什么要提相同粒度呢，因为维度建模中要求我们，在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。

3. 使用最细粒度的原因

   • 并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。
   • 但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我
     们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度

9.5.3 确认维度

1. 如何确认维度：
   • 维度退化：谁 什么时间 什么地点
     • 退化维度的维度表可以被剔除，从而简化维度数据仓库的模式
   • 维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性，数仓工具箱中告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一

9.5.4 确认事实

1. 确认事实：
   • 确认事实：度量值：如个数，件数，金额
   • 事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度
2. 维度建模的核心之一
   • 维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实

9.6 数据仓库分层⭐️

面试常问知识

9.6.1 数仓分层原因

1. 用空间换时间

   • 通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量的冗余数据；

2. 增强扩展性

   • 不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大

3. 分层管理

   • 简化数据清洗过程

     • 通过数据分层管理可以把原来的一步工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，所以简化了数据清洗的过程

   • 简化处理逻辑

     • 同时数据分层使每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误时，我们只需要调整某个步骤即可

9.6.2 数仓分层优点

1. 清晰数据结构
   • 每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便的定位和理解
2. 方便数据血缘追踪
   • 简单来说，我们最终给业务呈现的是一个能直接使用的业务表，但是它的来源有很多，如果有一张来源表出问题了，我们能够能够快速准确地定位到问题，并清楚它的危害范围
3. 减少重复开发
   • 规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
4. 把复杂问题简单化
   • 将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
5. 屏蔽原始数据的异常
   • 屏蔽业务的影响，不必改一次业务就需要重新接入数据

9.6.3 数仓分层明细

数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层：1 ODS层; 2 DW层; 3 ADS层

1. ODS原始数据层

1. 定义理解

   • ODS（Operate data store），操作数据存储层
   • 该层最接近数据源中数据的一层，或者只对原始数据进行了少量的操作
   • 数据源中的数据，经过抽取、洗净、传输后，也就是经过ETL之后，转入ODS层

2. 存储的数据种类

   • 业务数据

     • 表结构数据直接从原来的表结构拉取，保持了ER模型

   • 行为数据

     • 日志采集到什么就存储什么，有可能只会稍微做一点点适配于Hive表的修改

   • 本层的数据，总体上多是按照源头业务系统的分类方式而分类的

     • 例如：MySQL里面的一张表可以通过sqoop之间抽取到ODS层

2. DW数据仓库层

1. 定义理解
   • Data warehouse（数据仓库）
   • 使用维度建模按照主题重新整理ODS层的数据
   • 例如以研究人的旅游消费为主题的数据集中，可以结合航空公司的登机出行信息和银联系统的刷卡记录进行结合分析，产生数据集。
2. 四个概念
   • 维度（dimension）
     • 维度表是事实表不可或缺的组成部分。维度表包含业务过程度量事件有关的文本环境。他用来描述与"谁、什么、哪里、何时、如何、为什么"有关的事件。
   • 事实（Fact）
     • 事实涉及来自业务过程的度量，基本都以数量值表示。一个事实表行与粒度存在一对一关系。
   • 指标（Index）
     • 指标是业务流程节点上的一个数值。比如销量、价格、成本等
   • 粒度（Granularity）
     • 粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。

3. ADS数据服务层

1. 定义理解
   • Application Data Service(应用数据服务)
   • 该层主要是提供数据产品和数据分析使用的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用
     • 该层数据都是直接展示给老板看的数据–报表数据–BI数据
   • 绝对不要在ADS层进行第二次的数据计算，对应指标的结果应该在进入到ADS层之前就已经算好了
   • 例如：我们经常说的报表数据，一般就放在这里

4. 数仓分层明细图解