【离线数仓-3-数仓建模方法理论汇总】
离线数仓-3-数仓建模方法理论汇总
- 离线数仓-3-数仓建模方法理论汇总
- 1.数仓概述
- 2.数据仓库核心架构（Hive）
- 3.数据仓库建模概述
- 4.数据仓库建模方法论
- 1.ER（Entity Relationship）模型
- 2.维度模型
- 1.维度建模理论-事实表
- 1. 事实表概述
- 2.事实表分类
- 1.事务事实表
- 2.周期型快照事实表
- 3.累计型快照事实表
- 2.维度建模理论-维度表
- 1.维度表概述
- 2.维度表设计步骤
- 3.维度表设计要点
- 3.各种表格同步策略
离线数仓-3-数仓建模方法理论汇总
1.数仓概述
- 数据仓库具备能力：数据存储能力、管理数据能力、数据分析计算能力。
- 官方介绍：数据仓库是一个为数据分析而设计的企业级数据管理系统。
- 数仓存在意义：数据仓库可集中、整合多个信息源的大量数据，借助数据仓库的分析能力，企业可从数据中获取宝贵的信息进而改进决策。
2.数据仓库核心架构（Hive）
- 重点：数仓建模+写sql
3.数据仓库建模概述
- 数据模型：是数据组织和存储方法，他强调从业务、数据存储和使用角度合理存储数据。
- 数据仓库建模的意义：只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。
- 高性能：良好的数据模型能够帮助我们快速查询所需要的数据。
- 低成本：良好的数据模型能减少重复计算，实现计算结果的复用，降低计算成本。
- 高效率：良好的数据模型能极大的改善用户使用数据的体验，提高使用数据的效率。
- 高质量：良好的数据模型能改善数据统计口径的混乱，减少计算错误的可能性。
4.数据仓库建模方法论
1.ER（Entity Relationship）模型
数据仓库之父Bill Inmon提出的建模方法是从全企业的高度，用实体关系（Entity Relationship，ER）模型来描述企业业务，并用规范化的方式表示出来，在范式理论上符合3NF。
3范式（3NF）实体关系模型将复杂的数据抽象为两个概念——实体和关系。实体表示一个对象，例如学生、班级，关系是指两个实体之间的关系，例如学生和班级之间的从属关系。
数据库规范化是使用一系列范式设计数据库（通常是关系型数据库）的过程，其目的是减少数据冗余，增强数据的一致性。
- 这一系列范式就是指在设计关系型数据库时，需要遵从的不同的规范。关系型数据库的范式一共有六种，分别是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF）。遵循的范式级别越高，数据冗余性就越低。
ER模型方法的出发点是整合数据，其目的是将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。这种模型并不适合直接用于分析统计。
ER模型的样例：
2.维度模型
维度模型将复杂的业务通过事实和维度两个概念进行呈现。
- 事实通常对应业务过程；
- 维度通常对应业务过程发生时所处的环境；
- 注：业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等，都是业务过程。
维度建模以数据分析作为出发点，为数据分析服务，因此他关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。
维度模型的样例：
1.维度建模理论-事实表
1. 事实表概述
- 事实表作为数据仓库维度建模的核心，仅仅围绕着业务过程来设计。其包含与该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型字段） 。
- 事实表有两大核心字段类型：维度外键，度量值
- 特点：事实表通常比较“细长”，列比较少，行比较多，并且行增速快。
2.事实表分类
事实表分为三类：事务事实表、周期快照事实表、累计快照事实表，每种表格适应的场景不同，其中事务事实表应用最普遍。
1.事务事实表
- 1.概述：
- 事务事实表用来记录各业务过程，它保存的是各个业务过程的原子操作事件，即最细粒度的操作事件。
- 粒度：指事实表中一行数据所表达的业务细节程度。
- 事务事实表 用于分析各业务过程 相关的各项统计指标，由于其保存了最细粒度的记录，可提供最大限度的灵活性，这样就可以支持无法预期的各种细节层次的统计需求。
- 事务事实表用来记录各业务过程，它保存的是各个业务过程的原子操作事件，即最细粒度的操作事件。
- 2.设计流程
事实事务表设计流程大概分为4步：选择业务过程 --> 声明粒度 --> 确认维度–> 确认事实1.选择业务过程
在业务系统中，挑选我们感兴趣的业务过程，业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等，都是业务过程。通常情况下，一个业务过程对应一张事务型事实表。2.声明粒度
业务过程确定后，需要为每个业务过程声明粒度。即精确定义每张事务型事实表的每行数据表示什么，应该尽可能选择最细粒度，以此来应各种细节程度的需求。3.确认维度
确定维度具体是指，确定与每张事务型事实表相关的维度有哪些。
确定维度时应尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度。4.确认事实
此处的“事实”一词，指的是每个业务过程的度量值（通常是可累加的数字类型的值，例如：次数、个数、件数、金额等）。经过上述四个步骤，事务型事实表就基本设计完成了。第一步选择业务过程可以确定有哪些事务型事实表，第二步可以确定每张事务型事实表的每行数据是什么，第三步可以确定每张事务型事实表的维度外键，第四步可以确定每张事务型事实表的度量值字段。
- 3.事务事实表的不足之处
- 对于存量型指标这种场景的数据进行计算的时候，有时候会涉及到全表的全部记录，性能消耗比较大，不建议使用事务事实表来对存量型指标进行计算。
- 对于多事务关联统计，这样的指标，不建议使用事务事实表，因为两个表进行关联的时候，就是大表跟大表进行join，尽量避免这种情况。
2.周期型快照事实表
- 1.概述
- 周期快照事实表，实际上类似于Hive中按天做分区，然后全量拉取mysql中数据，这样就会形成mysql的快照。
- 主要用于分析一些存量型（商品库存、账户余额）或状态型（空气温度、行驶速度）指标，对于存量型指标的查询，直接查询mysql同步来的快照数据中关于存量数据的表，不需要再进行事务事实表之间的关联。
- 对于商品库存、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合了。
- 对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表。
- 2.设计流程
- 1）确定粒度
周期型快照事实表的粒度可由采样周期和维度描述，故确定采样周期和维度后即可确定粒度。
采样周期通常选择每日。
维度可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则可确定维度为仓库和商品。
确定完采样周期和维度后，即可确定该表粒度为每日-仓库-商品。 - 2）确认事实
事实也可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则事实为商品库存。
- 1）确定粒度
- 3.事实类型
此处的事实类型是指度量值的类型，而非事实表的类型。事实（度量值）共分为三类，分别是可加事实，半可加事实和不可加事实。- 1）可加事实
可加事实是指可以按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实。 - 2）半可加事实
半可加事实是指只能按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例，这张表中的库存事实可以按照仓库或者商品维度进行累加，但是不能按照时间维度进行累加，因为将每天的库存累加起来是没有任何意义的。 - 3）不可加事实
不可加事实是指完全不具备可加性，例如比率型事实。不可加事实通常需要转化为可加事实，例如比率可转化为分子和分母。
- 1）可加事实
3.累计型快照事实表
1.概述
- 累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。
- 累积型快照事实表通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程（里程碑）。
- 累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。
2.设计流程
- 1）选择业务过程
选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累积型快照事实表。 - 2）声明粒度
精确定义每行数据表示的是什么，尽量选择最小粒度。 - 3）确认维度
选择与各业务过程相关的维度，需要注意的是，每各业务过程均需要一个日期维度。 - 4）确认事实
选择各业务过程的度量值。
- 1）选择业务过程
2.维度建模理论-维度表
1.维度表概述
维度表是维度建模的基础和灵魂。前文提到，事实表紧紧围绕业务过程进行设计，而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段，维度字段称为维度属性。
2.维度表设计步骤
- 1）确定维度（表）
在设计事实表时，已经确定了与每个事实表相关的维度，理论上每个相关维度均需对应一张维度表。需要注意到，可能存在多个事实表与同一个维度都相关的情况，这种情况需保证维度的唯一性，即只创建一张维度表。另外，如果某些维度表的维度属性很少，例如只有一个名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为维度退化*。 - 2）确定主维表和相关维表
此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_info，spu_info，base_trademark，base_category3，base_category2，base_category1等，其中sku_info就称为商品维度的主维表，其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同，主维表通常是粒度最细的表。 - 3）确定维度属性
- 确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择，也可通过进一步加工得到。
- 确定维度属性时，需要遵循以下要求：
- （1）尽可能生成丰富的维度属性
维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。 - （2）尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存。
- （3）尽量沉淀出通用的维度属性
有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理，可将这些维度属性沉淀到维度表中。
- （1）尽可能生成丰富的维度属性
3.维度表设计要点
- 1.规范化与反规范化
- 规范化是指使用一系列范式设计数据库的过程，其目的是减少数据冗余，增强数据的一致性。通常情况下，规范化之后，一张表的字段会拆分到多张表。
- 反规范化是指将多张表的数据冗余到一张表，其目的是减少join操作，提高查询性能。在设计维度表时，如果对其进行规范化，得到的维度模型称为雪花模型，如果对其进行反规范化，得到的模型称为星型模型。
- 数据仓库系统的主要目的是用于数据分析和统计，所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差，而采用星型模型，则方便、易用且性能好。所以出于易用性和性能的考虑，维度表一般是很不规范化的。
2.维度变化
维度属性通常不是静态的，而是会随时间变化的，数据仓库的一个重要特点就是反映历史的变化，所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态，通常有以下两种做法，分别是全量快照表和拉链表。1.全量快照表
- 离线数据仓库的计算周期通常为每天一次，所以可以每天保存一份全量的维度数据。这种方式的优点和缺点都很明显。
- 优点是简单而有效，开发和维护成本低，且方便理解和使用。
- 缺点是浪费存储空间，尤其是当数据的变化比例比较低时。
2.拉链表
1.拉链表的意义：就在于能够更加高效的保存维度信息的历史状态。
2.拉链表是什么：拉链表，记录每条信息的生命周期，一旦一条记录的生命周期结束，就重新开始一条新的记录，并把当前日期放入生效开始日期。
3.为什么要做拉链表：极大地减少了存储空间
- 拉链表适合于：数据会发生变化，但是变化频率并不高的维度（即：缓慢变化维）
- 拉链表适合于：数据会发生变化，但是变化频率并不高的维度（即：缓慢变化维）
4.如何使用拉链表：
- 通过sql处理，生效开始日期 <= 某个日期 且 生效结束日期 >= 某个日期，能够得到某个时间点的数据全量切片。
- 通过sql处理，生效开始日期 <= 某个日期 且 生效结束日期 >= 某个日期，能够得到某个时间点的数据全量切片。
3.多值维度
- 如果事实表中一条记录在某个维度表中有多条记录与之对应，称为多值维度。例如，下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，所会商品维度表中就可能有多条数据与之对应。
- 针对这种情况，通常采用以下两种方案解决。
- 第一种：降低事实表的粒度，例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。
- 第二种：在事实表中采用多字段保存多个维度值，每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。
- 建议尽量采用第一种方案解决多值维度问题。
4.多值属性
- 维表中的某个属性同时有多个值，称之为“多值属性”，例如商品维度的平台属性和销售属性，每个商品均有多个属性值。
- 针对这种情况，通常有可以采用以下两种方案。
- 第一种：将多值属性放到一个字段，该字段内容为key1:value1，key2:value2的形式，例如一个手机商品的平台属性值为“品牌:华为，系统:鸿蒙，CPU:麒麟990”。
- 第二种：将多值属性放到多个字段，每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况。
3.各种表格同步策略
- 绝大多数维度表一般采用：全量同步
- 全量快照表：全量同步
- 拉链表： 增量同步
- 绝大多数事实表一般采用：增量同步
- 所有的事务事实表，通常采用增量同步
- 周期快照事实表，采用全量同步
- 累计快照事实表，采用增量同步
- 有特殊的表格可能全量同步和增量同步都采用，例如：有的表格既要做周期型快照事实表又要做周期型快照事实表，此时，该表格既要做全量同步又要做增量同步。
【离线数仓-3-数仓建模方法理论汇总】相关推荐
- 内部矩阵维度必须一致simulink_浅谈数仓模型（维度建模）
背景 数据仓库的核心是展现层和提供优质的服务.ETL 及其规范.分层等所做的一切都是为了一个更清晰易用的展现层. 数仓架构的原则: 1.底层业务的数据驱动为导向同时结合业务需求驱动 2.便于数据分析 ...
- 离线实时一体化数仓与湖仓一体—云原生大数据平台的持续演进
简介:阿里云智能研究员 林伟 :阿里巴巴从湖到仓的演进给我们带来了湖仓一体的思考,使得湖的灵活性.数据种类丰富与仓的可成长性和企业级管理得到有机融合,这是阿里巴巴最佳实践的宝贵资产,是大数据的新一代架 ...
- 如何创建数仓指标体系？指标建模的基础理论
数仓指标体系建模方法 1.指标体系 2.指标建设过程中遇到的问题 3.指标建设方法论 3.1.北极星指标 3.2.OSM+UJM 模型 4.指标的构成 4.1.指标分类 4.2.指标分级 5.如何设立 ...
- 离线数仓12—— 数仓开发之DWD层
文章目录 第9章 数仓开发之DWD层 9.1 交易域加购事务事实表 9.2 交易域下单事务事实表 9.3 交易域取消订单事务事实表 9.4 交易域支付成功事务事实表 9.5 交易域退单事务事实表 9. ...
- 电商离线数仓-业务数仓指标(GMV主题/转化率主题)
GMV和转化率 GMV主题 GMV的概念 GMV表的创建 GMV表里导入数据 转化率 转化率概念 转化率表的创建 转化率表里导入数据 ADS层用户行为漏斗分析 GMV主题 GMV的概念 什么是GMV? ...
- 数据数仓的三种建模方式
所谓水无定势,兵无常法.不同的行业,有不同行业的特点,因此,从业务角度看,其相应的数据模型是千差万别的.目前业界较为主流的是数据仓库厂商主要是 IBM 和 NCR,这两家公司的除了能够提供较为强大的数 ...
- 数仓、数湖、仓湖一体
数据仓库 通常是业务发展到一定规模后,业务分析师.CIO.决策者们,希望从大量的应用系统.业务数据中,进行关联分析,最终整点"干货"出来. 比如为啥利润会下滑?为啥库存周转变慢了? ...
- 金蝶ERP实现产品入库冲减生产现场虚仓毛坯数
金蝶ERP实现产品入库冲减生产现场虚仓毛坯数,销售成品代码前一位数对应毛坯件的唯一代码,一一对应,具体语句如下: if exists(select 1 from sysobjects where na ...
- 网络流建模方法（四）—— 互不攻击问题 洛谷 P3353 骑士共存问题 （附 洛谷 P2774 方格取数问题）
网络流建模方法(四)互不攻击问题,或者说是共存问题, 这类题目看起来有点像二分图匹配,这类题目我们就是建一个二分图然后跑最大流 还是先说题目洛谷P3353 题目描述 在一个 nn个方格的国际象棋棋盘上 ...
最新文章
- 【转】集合类说明及区别
- Python在mysql中进行操作是十分容易和简洁的
- UI设计素材|卡券界面设计
- 帮助用户进行日常健康管理，常仁科技完成1亿元A轮融资
- 结构建模设计——Solidworks 2021SP5稳定版软件安装详细教程（安装踩坑记录全流程总结）
- java-php-python-ssm社区志愿者服务管理系统计算机毕业设计
- 日常使用的图片文件格式及各自的区别，JPG/PNG/GIF/RAW/WebP/HEIC
- ZigBee Dotdot
- 双十一第二波活动来了，酷客scrm助力商家大卖
- 20189220 余超《Linux内核原理与分析》第六周作业
- 概率论与数理统计(3):二维随机变量及其分布
- 网线如何制作和如何使用？
- php+摩尔斯电码,如何在Symfony 3中使用PHP编码和解码摩尔斯电码(翻译摩尔斯电码)...
- 案例：马斯洛需求层次理论——西游记的5人团队
- 机械设计中要求注重机床的外围钣金设计
- 文字转语音百度 android视频教程,【案例】免费文字转语音：运用百度语音合成智能朗读...
- Java操作Word文档添加水印（文字/图片）
- DNS服务器的安装与配置（VM虚拟机）
- 微信小程序之跳转wx.switchTab的使用
- HBase2.x（五）HBase API DDL的操作