马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
1.数仓建模First Blood2.数仓建模的目的是什么呢?能够快速查询所需的数据,减少数据I/O 减少不必要的数据冗余,实现计算结果数据复用,降低大数据系统中的存储成本和计算成本 改善用户应用体验,提高使用数据的效率 改善数据统计口径的不一致性,减少数据计算错误的可能性,提供高质量的、一致的数据访问平台 所以,大数据的数仓建模需要通过建模的方法更好的组织、存储数据,以便在性能、成本、效率和数据质量之间找到最佳平衡点。 3.回顾关系模式范式众所周知,RDBMS设计时,需要遵照一定的规范要求,目的在于降低数据的冗余性和数据的一致性,目前业界范式有: 域都应该是原子性(即不可分割的)的,即数据库表的每一列都是不可分割的原子数据项。 ID 商品 商家ID 用户ID
xxx4件毛衣xx毛衣生产商10001上述表格是不符合1NF的,需要拆分为: ID 商品个数 商品名称 商家ID 用户ID
xxx4毛衣xx毛衣生产商10001在1NF的基础上,实体的属性完全依赖于主关键字,不能存在仅依赖主关键字一部分的属性。 学生ID 所属系 系主任 所修课程 分数
101物理系张三10000000190
101物理系张三100000002100上述表格中,如果想表达某个学生分数的时候,是通过(学生ID,所修课程)来作为主键,唯一确定分数;而一个学生只能属于一个系,可以理解为所属系是依赖于学生ID的(即给出一个学生ID,就可以给出所属系),这就产生了局部依赖。 该表会带来什么问题呢? - 1)如果学生所属系改变了,则需要更新该学生的所有记录的所属系和系主任,如果存在上万条记录呢?那么就会带来性能问题。
- 2)如果系主任改变了,同样需要做大量改动,也会带来性能问题。
所以作出如下拆分: 学生ID 所修课程 分数
10110000000190
101100000002100- 2) 表2(该表满足2NF,但是不满足3NF,因为系主任依赖于所属系,所属系又依赖于学生ID,即传递依赖):
学生ID 所属系 系主任
101物理系张三在2NF的基础上,任何非主属性不依赖于其他非主属性。 ID 商品ID 商品颜色 商家ID 用户ID
xxx0002x白色xx公司10000001因为商品颜色依赖于商品ID,商品ID又依赖于ID,存在传递依赖。故拆分为: ID 商品ID 商家ID 用户ID
xxx0002xxx公司10000001商品ID 商品颜色 尺寸
0002x白色30*40大多数RDBMS业务场景达到3NF即可满足我们业务需求,后续三项范式不再展开介绍。 4.ER实体关系模型4.1什么是ER模型?在信息系统中,将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述。 三者用来做什么呢? - 实体:通常为参与到过程中的主体,客观存在的,比如商品、仓库、货位、汽车等;此实体非数据库中的实体表。
- 属性:对主体的描述、修饰即为属性,比如商品的属性有商品名称、颜色、尺寸、重量、产地等。
- 关系:现实的物理事件是依附于实体的,比如商品入库事件,依附实体商品、货位,就会有“库存”的属性产生;用户购买商品,依附实体用户、商品,就会有“购买数量”、“金额”的属性产品。
实体之间建立关系时,存在哪些对照关系呢? - 1:1,一对一关系,比如一个人有且仅有一个身份证号
- 1:n,一对多关系,比如一个班级有多个学生,但是一个学生只能属于一个班级
- m:n,多对多关系,比如学生选课,每个学生可以选修多门课程,每门课程也可以被多个学生选修
如何建立ER模型呢? - 1)抽象出实体
- 2)梳理实体间的关系
- 3)梳理实体属性、关系属性
- 4)构建ER图
举个例子,教师、学生与课程之间的ER图: 4.2小结- ER模型是数据库设计的理论基础,当前几乎所有的OLTP系统设计都采用ER模型建模的方式
- Bill Inom提出的数仓理论,推荐采用ER关系模型进行建模
- BI架构提出分层架构,数仓底层ODS、DWD也多采用ER关系模型进行设计
5.维度建模5.1什么是维度建模?Ralph Kimball推崇数据集市的集合为数据仓库,同时也提出了对数据集市的维度建模,将数据仓库中的表划分为事实表、维度表两种类型。 在ER模型中抽象出了实体、关系、属性三种类别。在现实世界中,每一个操作型事件,基本都是发生在实体之间的,伴随着这种操作事件的发生,会产生可度量的值,而这个过程就产生了一个事实表,存储了每一个可度量的事件。 比如电商场景:一次购买事件,涉及主体包括客户、商品、商家,产生的可度量值包括商品数量、金额、件数等。 fact_订单明细事实表如下: PK 订单ID
FK1
FK2
FK3
FK4商品ID
用户ID
时间ID
劵ID
单价
件数
减免金额
状态
入购物车时间
下单时间
结算时间维度,很显然就是看待事物的角度。比如从颜色、尺寸的角度来比较手机的外观,从CPU、内存等比较手机性能。 维度表一般为单一主键,在ER模型中,实体为客观存在的事务,会带有自己的描述性属性,属性一般为文本性、描述性的,这些描述被称为维度。 比如商品,商品ID是单一主键,属性包括产地、颜色、材质、尺寸、单价等,但并非属性一定是文本,比如单价、尺寸均为数值型描述性的。日常主要的维度抽象包括:时间维度表、地理区域维度表等。 商品维度表之’dim_商品’: PK 商品ID
商品名称
商品种类
单价
产地时间维度表之’dim_时间维度’: PK 时间ID
日期
周几
旬
是否周末
是否假期
特殊日期区域维度表之’dim_区域’(不唯一,还可以拆分成省、市、县、乡镇四张维度表;也可以聚合为一张表展示): PK 区域ID
区域名称
所属大区
位置经度
位置纬度
时区
上级区域ID维度建模通常有哪几种模型呢? 由上述两种模型可以看出,星型模型和雪花模型的主要区别就是对维度表的拆分。
对于雪花模型,维度表的设计更加规范,一般符合3NF。
对于星型模型,一般采用降维的操作,利用冗余来避免模型过于复杂,提高易用性和分析效率。 5.2小结- 雪花模型和星型模型的对比
- 冗余
- 雪花模型:符合业务逻辑设计,采用3NF设计,有效降低了数据冗余
- 星型模型:的维度表设计不符合3NF,反规范化,维度表之间不会直接相关,牺牲部分存储空间
- 性能
- 雪花模型:由于存在维度间的关联,采用3NF降低冗余,通常在使用过程中,需要连接更多的维度表,导致性能偏低
- 星型模型:反第三范式,采用降维的操作将维度整合,以存储空间为代价有效降低维度表连接数,性能较雪花模型高
- ETL
- 雪花模型:符合业务ER模型设计原则,在ETL过程中相对简单,但是由于附属模型的限制,ETL任务并行化较低
- 星型模型:在设计维度表时反范式设计,所以在ETL过程中整合业务数据到维度表有一定难度,但由于避免附属维度,可并行化处理
- 维度建模源自数据集市,主要面向分析场景
6.DataVault模型6.1DataVault是什么样的模型?DataVault模型介绍: DataVault模型结构是什么样的呢? 包含三种基本结构: 唯一业务键的列表,唯一标识企业实际业务,企业的业务主体集合。 只包含业务主键信息以及数据状态的描述,不包含非键值以外的业务数据属性本身。 比如中心表商品(Hub_商品),在DataVault下的设计: PK Hub_商品ID
商品ID
load_time而商品属性以及描述信息,都属于卫星表的范畴。 表示中心表之间的关系,通过链接表串联整个企业的业务关联关系。 链接表用来描述中心表间的关联关系,亦不包括业务键值以及数据装载描述以外的任何非键值数据。 比如学生选课链接表(Link_授课),在DataVault下的设计为: PK Link_授课ID
FK1
FK2hub_教师ID
hub_课程ID
load_time与选课相关的课时数等描述信息,都属于卫星表的范畴。 历史的描述性数据,数据仓库中数据的真正载体。 数仓中数据的主要载体,包括对链接表、中心表的数据描述、数值度量等信息。 中心表商品、订单明细的卫星表分别为: sat_商品表: PK sat_商品ID
上平ID
商品名称
颜色
尺寸
品类sat_订单明细表: PK sat_订单明细表
link_订单明细ID
商品数量
商品单价
商品减免如何建立DataVault模型呢? - 1) 梳理所有主要实体
- 2)将有入边的实体定义为中心表
- 3)将没有入边仅有一个出边的表定义为卫星表
- 4)将没有入边且有两条或以上出边的表定义为连接表
- 5)将外键关系定义为链接表
6.2小结- DataVault模型更容易设计,ETL过程中更已配置化实现,Hub就像是人体的骨架,Link呢就是连接骨架的韧带组织,而Satellite就是骨架上的血肉。
- DataVault是对ER模型的更进一步规范化,由于对数据的拆解和更偏向于基础数据组织,在处理分析类场景时相对复杂,适合数仓底层构建,目前实际应用场景较少。
7.AnchorSummary- 4种基本的建模方法中,当前主流建模方法为:ER模型、维度模型
- ER模型:常用于OLTP数据库建模,应用到构建数仓时更偏重于数据整合,站在企业整体考虑,将各个系统的数据按相似性一致性、合并处理,为数据分析、决策服务,但并不便于直接用来支持分析
- 有哪些问题?
- 需要全面梳理企业所有的业务和数据流
- 实施周期长
- 对建模人员要求高
- 维度模型:面向分析场景而生,针对分析场景构建数仓模型;重点关注快速、灵活的解决分析需求,同时能够提供大规模数据的快速响应性能。针对性强,主要应用于数据仓库构建和OLAP引擎低层数据模型
- 不需要完整的梳理企业业务流程和数据
- 实施周期根据主题边界而定,容易快速实现demo
- CIF层次架构
- 【敲黑板,划重点】
- 数仓模型的选择时灵活的,不局限于某一种模型方法
- 数仓模型的设计也是灵活的,以实际需求场景为导向
- 模型设计要兼容灵活性、可扩展,而对终端用户透明
- 模型设计要考虑技术可靠性和实现成本
一个正在技术专家成长道路上不断努力前进的程序员
|