大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE稳定放心使用
1.数据仓库建模的目的?
为什么要进行数据仓库建模?大数据的数仓建模是通过建模的方法更好的组织、存储数据,以便在 性能、成本、效率和数据质量之间找到最佳平衡点。一般主要从下面四点考虑
- 访问性能:能够快速查询所需的数据,减少数据I/O
- 数据成本:减少不必要的数据冗余,实现计算结果数据复用,降低大数 据系统中的存储成本和计算成本
- 使用效率:改善用户应用体验,提高使用数据的效率
- 数据质量:改善数据统计口径的不一致性,减少数据计算错误 的可能性,提供高质量的、一致的数据访问平台
2.常见的数据建模方法
数据仓库本质是从数据库衍生出来的,所以数据仓库的建模也是不断衍生发展的。从最早的借鉴数据库的范式建模,到逐渐提出维度建模,Data Vault模型,Anchor模型等等,越往后建模的要求越高,越需满足3NF,4NF等。但是对于数据仓库来说,目前主流还是维度建模,会夹杂着范式建模。
数据仓库建模方法论可分为:范式建模、维度建模、Data Vault模型、Anchor模型。
3.常见四种建模方法的建模步骤与演示
3.1.范式建模(E-R模型)
将事物抽象为“实体”、“属性”、“关系”来表示数 据关联和事物描述;实体:Entity,关系:Relationship,这种对数据的抽象 建模通常被称为ER实体关系模型
设计都采用ER模型建模的方式,且该建模方法需要满足3NF。Bill Inom提出的数仓理论,推荐采用ER关系模型进行建模,BI架构提出分层架构,数仓底层ods、dwd也多采用ER关系模型就行设计。
逐渐随着企业数据的高增长,复杂化,数仓全部使用ER模型建模
显得越来越不合时宜。为什么呢,因为其按部就班的步骤,三范式等,不适合现代化复杂,多变的业务组织。
- 抽象出主体 (教师,课程)
- 梳理主体之间的关系 (一个老师可以教多门课,一门课可以被多个老师教)
- 梳理主体的属性 (教师:教师名称,性别,学历等)
- 画出E-R关系图
3.2.维度建模
维度建模,是数据仓库大师Ralph Kimball提出的,是数据仓库工程领域最流行的数仓建模经典。
维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。维度建模是面向分析的,为了提高查询性能可以增加数据冗余,反规范化的设计技术。
Ralph Kimball提出对数据仓库维度建模,并且将数据仓库中的表划分为事实表、维度表两种类型。
3.2.1.事实表
在ER模型中抽象出了有实体、关系、属性三种类别,在现实世界中,每一个操作型事件,基本都是发生在实体之间的,伴随着这种操作事件的发生,会产生可度量的值,而这个过程就产生了一个事实表,存储了每一个可度量的事件。
以电商行业为例:电商场景:一次购买事件,涉及主体包括客户、商品、商家,产生的可度量值 包括商品数量、金额、件数等
事实表根据粒度的角色划分不同,可分为事务事实表、周期快照事实表、累积快照事实表。注意:这里需要值得注意的是,在事实表的设计时,一定要注意一个事实表只能有一个粒度,不能将不同粒度的事实建立在同一张事实表中。
- 事务事实表,用于承载事务数据,通常粒度比较低,它是面向事务的,其粒度是每一行对应一个事务,它是最细粒度的事实表,例如产品交易事务事实、ATM交易事务事实。
- 周期快照事实表,按照一定的时间周期间隔(每天,每月)来捕捉业务活动的执行情况,一旦装入事实表就不会再去更新,它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据,通常粒度比较高,例如账户月平均余额事实表。
- 累积快照事实表,用来记录具有时间跨度的业务处理过程的整个过程的信息,每个生命周期一行,通常这类事实表比较少见。
3.2.2.维度表
涉及到事实表为订单表、订单明细表,维度包括商品维度、用户维度、商家维度、区域维 度、时间维度
商品维度:商品ID、商品名称、商品种类、单价、产地等
用户维度:用户ID、姓名、性别、年龄、常住地、职业、学历等
时间维度:日期ID、日期、周几、上/中/下旬、是否周末、是否假期等
维度分为:
(1)退化维度(DegenerateDimension)
在维度类型中,有一种重要的维度称作为退化维度,亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,退化维度一般在分析中可以用来做分组使用。
(2)缓慢变化维(Slowly Changing Dimensions)
维度的属性并不是始终不变的,它会随着时间的流逝发生缓慢的变化,这种随时间发生变化的维度我们一般称之为缓慢变化维(SCD)。比如员工表中的部门维度,员工的所在部门有可能两年后调整一次。
3.2.3.维度建模模型的分类
维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
星型模型
星型模型主要是维表和事实表,以事实表为中心,所有维度直接关联在事实表上,呈星型分布。
(2)雪花模型
雪花模型,在星型模型的基础上,维度表上又关联了其他维度表。这种模型维护成本高,性能方面也较差,所以一般不建议使用。尤其是基于hadoop体系构建数仓,减少join就是减少shuffle,性能差距会很大。
- 星型模型和雪花模型主要区别就是对维度表的拆分
- 对于雪花模型,维度表的涉及更加规范,一般符合3NF,有效降低数据冗余,维度表之间不会相互关联,但是
- 而星型模型,一般采用降维的操作,反规范化,不符合3NF,利用冗余来避免模型过于复杂,提高易用性和分析效率,效率相对较高。
(3)星座模型
星座模型,是对星型模型的扩展延伸,多张事实表共享维度表。数仓模型建设后期,大部分维度建模都是星座模型。
3.2.4. 维度建模步骤
维度建模步骤:选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。
声明粒度,为业务最小活动单元或不同维度组合。以共同粒度从多个组织业务过程合并度量的事实表称为合并事实表,需要注意的是,来自多个业务过程的事实合并到合并事实表时,它们必须具有同样等级的粒度。
3.3 DataVault模型
Data Vault是Dan Linstedt发起创建的一种模型方法论,Data Vault是在ER模型的基础上衍生而来,模型设计的初衷是有效的组织基础数据层,使之易扩展、灵活的应对业务的变化,同时强调历史性、可追溯性和原子性,不要求对数据进行过度的一致性处理。同时设计的出发点也是为了实现数据的整合,并非为数据决策分析直接使用。
Data Vault模型是一种中心辐射式模型,其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键,用 于定位和唯一标识记录或数据
Data Vault模型包含三种基本结构 :
- 中心表-Hub :唯一业务键的列表,唯一标识企业实际业务,企业的业务主体集合
- 链接表-Link: 表示中心表之间的关系,通过链接表串联整个企业的业务关联关系
- 卫星表- Satellite: 历史的描述性数据,数据仓库中数据的真正载体
3.3.1 中心表-Hub
3.3.2 链接表-Link
3.3.3 卫星表– Satellite
3.3.4 Data Vault模型建模流程
- 梳理所有主要实体
- 将有入边的实体定义为中心表
- 将没有入边切仅有一个出边的表定义为中心表
- 源苦衷没有入边且有两条或以上出边的表定义为连接表
- 将外键关系定义为链接表
3.4Anchor模型
- Anchor是对Data Vault模型做了更近一步的规范会处理,初衷是为了 设计高度可扩展的模型,核心思想是所有的扩张只添加而不修改,于 是设计出的模型基本变成了k-v结构的模型,模型范式达到了6NF
- 由于过度规范化,使用中牵涉到太多的join操作,目前木有实际案例,仅作了解
4.四种模型总结
ER模型、维度模型
- ER模型常用于OLTP数据库建模,应用到构建数仓时更偏重数据整合, 站在企业整体考虑,将各个系统的数据按相似性一致性、合并处理,为 数据分析、决策服务,但并不便于直接用来支持分析。缺陷:需要全面梳理企业所有的业务和数据流,周期长,人员要求高。
- 维度建模是面向分析场景而生,针对分析场景构建数仓模型;重点关注快 速、灵活的解决分析需求,同时能够提供大规模数据的快速响应性能。针对性 强,主要应用于数据仓库构建和OLAP引擎低层数据模型。优点:不需要完整的梳理企业业务流程和数据,实施周期根据主题边界而定,容易快速实现demo
- 数仓模型的选择是灵活的,不局限于某一种模型方法
- 数仓模型的设计也是灵活的,以实际需求场景为导向
- 模型设计要兼顾灵活性、可扩展,而对终端用户透明性
-
模型设计要考虑技术可靠性和实现成本
5.常用建模工具
建模工具,一般企业以Erwin、powerdesigner、visio,甚至Excel等为主。也有些企业自行研发工具,或使用阿里等成熟套装组件产品。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/190158.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...