(内容整理自网络学习视频)
一、数仓建模的目标
访问性能:能够快速查询所需的数据,减少数据I/O。
数据成本:减少不必要的数据冗余,实现计算结果数据复用,降低大数据系统中的存储成本和计算成本。
使用效率:改善用户应用体验,提高使用数据的效率。
数据质量:改善数据统计口径的不一致性,减少数据计算错误的可能性,提供高质量的、一致的数据访问平台。
所以,大数据的数仓建模需要通过建模的方法更好的组织、存储数据,以便在性能、成本、效率和数据质量之间找到最佳平衡点。
二、关系模式范式
关系型数据库设计时,遵照一定的规范要求,目的在于降低数据的冗余性和数据的一致性,目前业界范式有:
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
巴斯-科德范式(BCNF)
第四范式(4NF)
第五范式(5NF)
第一范式(1NF):
域都是原子性的,即数据库表的每一列都是不可分割的原子数据项。
例如下面这张表:
ID | 商品 | 商家ID | 用户ID |
---|---|---|---|
1 | 4件毛衣 | B0001 | U00001 |
“商品”字段就不是原子性的,可以分割成“4件”和“毛衣”。
第二范式(2NF):
在1NF的基础上,实体的属性完全依赖于主关键字,不能存在仅依赖主关键字一部分的属性,也就是不存在局部依赖。
例如下面这张表:
学生ID | 所属系 | 系主任 | 所修课程 | 分数 |
---|---|---|---|---|
S001 | 物理系 | 张三 | C001 | 90 |
S001 | 物理系 | 张三 | C002 | 100 |
主键ID为“学生ID,所修课程”,但是字段“所属系”只依赖于“学生ID”,不符合2NF。
第三范式(3NF):
在2NF的基础上,任何非主属性不依赖于其它非主属性,也就是不存在传递依赖。
例如下面这张表:
订单ID | 商品ID | 商品颜色 | 商家ID | 用户ID |
---|---|---|---|---|
O00001 | G0001 | 白色 | B0001 | U00001 |
主键为“订单ID”,但是字段“商品颜色”依赖于“商品ID”,不符合3NF。
三、四种建模方法
1、ER实体模型
在信息系统中,将事务抽象为“实体”(Entity)、“属性”(Property)、“关系”(Relationship)来表示数据关联和事物描述,这种对数据的抽象建模通常被称为ER实体关系模型。
实体:通常为参与到过程中的主体,客观存在的,比如商品、仓库、货位、汽车,此实体非数据库表的实体表。
属性:对主体的描述、修饰即为属性,比如商品的属性有商品名称、颜色、尺寸、重量、产地等。
关系:现实的物理事件是依附于实体的,比如商品入库事件,依附实体商品、货位,就会有“库存”的属性产生;用户购买商品,依附实体用户、商品,就会有“购买数量”、“金额”的属性产品。
实体之间建立关系时,存在对照关系:
1:1:即1对1的关系
1:n:即1对多的关系
n:m:即多对多的关系
在日常建模中,“实体”用矩形表示,“关系”用菱形,“属性”用椭圆形。ER实体关系模型也称为E-R关系图。
应用场景:
1、ER模型是数据库设计的理论基础,当前几乎所有的OLTP系统设计都采用ER模型建模的方式。
2、Bill Inom提出的数仓理论,推荐采用ER关系模型进行建模。
3、BI架构提出分层架构,数仓底层ods、dwd也多采用ER关系模型进行设计。
2、维度建模
维度建模源自数据集市,主要面向分析场景。Ralph Kimball推崇数据集市的集合为数据仓库,同时也提出了对数据集市的维度建模,将数据仓库中的表划分为事实表、维度表两种类型。
事实表:
在ER模型中抽象出了有实体、关系、属性三种类别,在现实世界中,每一个操作型事件,基本都是发生在实体之间的,伴随着这种操作事件的发生,会产生可度量的值,而这个过程就产生了一个事实表,存储了每一个可度量的事件。
维度表:
维度,顾名思义,看待事物的角度。比如从颜色、尺寸的角度来比较手机的外观,从cpu、内存等角度比较手机性能。
维度表一般为单一主键,在ER模型中,实体为客观存在的事务,会带有自己的描述性属性,属性一般为文本性、描述性的,这些描述被称为维度。
比如商品,单一主键:商品ID,属性包括产地、颜色、材质、尺寸、单价等,但并非属性一定是文本,比如单价、尺寸,均为数值型描述性的,日常主要的维度抽象包括:时间维度表、地理区域维度表等。
维度建模通常又分为星型模型和雪花模型。
星型模型:
雪花模型:
星型模型和雪花模型的主要区别在于对维度表的拆分,对于雪花模型,维度表的设计更加规范,一般符合3NF;而星型模型,一般采用降维的操作,利用冗余来避免模型过于复杂,提高易用性和分析效率。
雪花、星型模型对比:
1、冗余:雪花模型符合业务逻辑设计,采用3NF设计,有效降低数据冗余;星型模型的维度表设计不符合3NF,反规范化,维度表之间不会直接相关,牺牲部分存储空间。
2、性能:雪花模型由于存在维度间的关联,采用3NF降低冗余,通常在使用过程中,需要连接更多的维度表,导致性能偏低;星型模型反三范式,采用降维的操作将维度整合,以存储空间为代价有效降低维度表连接数,性能较雪花模型高。
3、ETL:雪花模型符合业务ER模型设计原则,在ETL过程中相对简单,但是由于附属模型的限制,ETL任务并行化较低;星型模型在设计维度表时反范式设计,所以在ETL过程中整合业务数据到维度表有一定难度,但由于避免附属维度,可并行化处理。
大数据和传统关系型数据库的计算框架不一样,例如对比mapreduce和oracle,在mapreduce里面,每多一个表的关联,就多一个job。mapreduce的每个任务进来,要申请资源,分配容器,各节点通信等。有可能YARN调度时长大于任务运行时间,例如调度需要5秒才能申请到资源,而表之间的join只需要2秒。hive优化里面,要尽可能减少job任务数,也就是减少表之间的关联,可以用适当的冗余来避免低效的查询方式,这是和oracle等其他关系型数据库不同的地方。
(点此了解:MapReduce作业运行机制)
3、Data Vault模型
Data Vault是在ER模型的基础上衍生而来,模型设计的初衷是有效的组织基础数据层,使之易扩展,灵活应对业务变化,同时强调历史性、可追溯性和原子性,不要求对数据进行过度的一致性处理,并非针对分析场景所设计。
Data Vault模型是一种中心辐射式模型,其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键,用于定位和唯一标识记录或数据。
Data Vault模型包含三种基本结构:
1)中心表-Hub:唯一业务键的列表,唯一标识企业实际业务,企业的业务主体集合。
2)链接表-Link:表示中心表之间的关系,通过链接表串联整个企业的业务关联关系。
3)卫星表-Satellite:历史的描述性数据,数据仓库中数据的真正载体。
Data Vault是对ER模型更进一步的规范化,由于对数据的拆解更偏向于基础数据组织,在处理分析类场景时相对复杂,适合数仓底层构建,目前实际应用场景较少。
4、Anchor
Anchor是对Data Vault模型做了更进一步的规范化处理,初衷是为了设计高度可扩展的模型,核心思想是所有的扩张只添加而不修改,于是设计出的模型基本变成了K-V结构的模型,模型范式达到了6NF。
由于过度规范化,使用中牵涉到太多的join操作,目前没有实际案例,仅作了解。
四种基本建模方法对比:
当前主流建模方法为:ER模型、维度建模。
1)ER模型
ER模型常用于OLTP数据库建模,应用到构建数仓时更偏重数据整合,站在企业整体考虑,将各个系统的数据按相似性一致性进行合并处理,为数据分析、决策服务,但并不便于直接用来支持分析。
问题:
a)需要全面梳理企业所有的业务和数据流;
b)实施周期长;
c)对建模人员要求高。
2)维度模型
维度建模是面向分析场景而生,针对分析场景构建数仓模型,重点关注快速、灵活的解决分析需求,同时能够提供大规模数据的快速响应性能。针对性强,主要应用于数据仓库构建和OLAP引擎底层数据模型。
模型选择和设计的原则:
a)数仓模型的选择是灵活的,不局限于某一种模型方法;
b)数仓模型的设计也是灵活的,以实际需求场景为导向;
c)模型设计要兼顾灵活性,可扩展,而对终端用户透明性;
d)模型设计要考虑技术可靠性和实现成本。
完毕。