168大数据

标题: 如何对数仓进行建模 [打印本页]

---

作者: 168主编    时间: 2019-6-25 19:46
标题: 如何对数仓进行建模
1.数仓建模First Blood

2.数仓建模的目的是什么呢？

• 提升访问性能
  

能够快速查询所需的数据，减少数据I/O

• 节省数据成本
  

减少不必要的数据冗余，实现计算结果数据复用，降低大数据系统中的存储成本和计算成本

• 提高使用效率
  

改善用户应用体验，提高使用数据的效率

• 保障数据质量
  

改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台

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

3.回顾关系模式范式

众所周知，RDBMS设计时，需要遵照一定的规范要求，目的在于降低数据的冗余性和数据的一致性，目前业界范式有：

• 1NF
  

域都应该是原子性（即不可分割的）的，即数据库表的每一列都是不可分割的原子数据项。

ID

商品

商家ID

用户ID

xxx4件毛衣xx毛衣生产商10001

上述表格是不符合1NF的，需要拆分为：

ID

商品个数

商品名称

商家ID

用户ID

xxx4毛衣xx毛衣生产商10001

• 2NF
  

在1NF的基础上，实体的属性完全依赖于主关键字，不能存在仅依赖主关键字一部分的属性。

学生ID

所属系

系主任

所修课程

分数

101物理系张三10000000190
101物理系张三100000002100

上述表格中，如果想表达某个学生分数的时候，是通过（学生ID，所修课程）来作为主键，唯一确定分数；而一个学生只能属于一个系，可以理解为所属系是依赖于学生ID的（即给出一个学生ID，就可以给出所属系），这就产生了局部依赖。

该表会带来什么问题呢？

• 1）如果学生所属系改变了，则需要更新该学生的所有记录的所属系和系主任，如果存在上万条记录呢？那么就会带来性能问题。
• 2）如果系主任改变了，同样需要做大量改动，也会带来性能问题。
  

所以作出如下拆分：

• 1) 表1：
  

学生ID

所修课程

分数

10110000000190
101100000002100

• 2) 表2（该表满足2NF，但是不满足3NF，因为系主任依赖于所属系，所属系又依赖于学生ID，即传递依赖）：
  

学生ID

所属系

系主任

101物理系张三

• 3NF
  

在2NF的基础上，任何非主属性不依赖于其他非主属性。

ID

商品ID

商品颜色

商家ID

用户ID

xxx0002x白色xx公司10000001

因为商品颜色依赖于商品ID，商品ID又依赖于ID，存在传递依赖。故拆分为：

• 1) 表1：
  

ID

商品ID

商家ID

用户ID

xxx0002xxx公司10000001

• 2) 表2：
  

商品ID

商品颜色

尺寸

0002x白色30*40

大多数RDBMS业务场景达到3NF即可满足我们业务需求，后续三项范式不再展开介绍。

• BCNF
• 4NF
• 5NF
  

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过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理
      
    
    
• 维度建模源自数据集市，主要面向分析场景
  • 数据仓库建模
  • 主流的OLAP引擎的底层数据模型
    
  
  

6.DataVault模型6.1DataVault是什么样的模型？

DataVault模型介绍：

• DataVault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理；并非针对分析场景所设计
• DataVault模型是一种忠新辐射式模型，其设计重点未到者业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键，用于定位和唯一标识记录或数据。
  
  

DataVault模型结构是什么样的呢？

包含三种基本结构：

• 中心表-Hub
  

唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合。

只包含业务主键信息以及数据状态的描述，不包含非键值以外的业务数据属性本身。

比如中心表商品（Hub_商品），在DataVault下的设计：

PK

Hub_商品ID

商品ID
load_time

而商品属性以及描述信息，都属于卫星表的范畴。

• 链接表-Link
  

表示中心表之间的关系，通过链接表串联整个企业的业务关联关系。

链接表用来描述中心表间的关联关系，亦不包括业务键值以及数据装载描述以外的任何非键值数据。

比如学生选课链接表（Link_授课），在DataVault下的设计为：

PK

Link_授课ID

FK1
FK2hub_教师ID
hub_课程ID
load_time

与选课相关的课时数等描述信息，都属于卫星表的范畴。

• 卫星表-Satellite
  

历史的描述性数据，数据仓库中数据的真正载体。

数仓中数据的主要载体，包括对链接表、中心表的数据描述、数值度量等信息。

中心表商品、订单明细的卫星表分别为：

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.Anchor

• Anchor是对Data Vault模型做了更进一步的规范化处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了K-V结构的模型，模型范式达到了6NF
• 由于过度规范化，使用中牵涉到太多的JOIN操作，目前并木有实际案例，仅做了解学习下。
  
  

Summary

• 4种基本的建模方法中，当前主流建模方法为：ER模型、维度模型
  • ER模型：常用于OLTP数据库建模，应用到构建数仓时更偏重于数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析
    • 有哪些问题？
      • 需要全面梳理企业所有的业务和数据流
      • 实施周期长
      • 对建模人员要求高
        
      
      
  • 维度模型：面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型
    • 不需要完整的梳理企业业务流程和数据
    • 实施周期根据主题边界而定，容易快速实现demo
      
    
    
• CIF层次架构
  

• 【敲黑板，划重点】
  
  • 数仓模型的选择时灵活的，不局限于某一种模型方法
  • 数仓模型的设计也是灵活的，以实际需求场景为导向
  • 模型设计要兼容灵活性、可扩展，而对终端用户透明
  • 模型设计要考虑技术可靠性和实现成本
    

一个正在技术专家成长道路上不断努力前进的程序员

作者和出处 buildupchao

---

欢迎光临 168大数据 (http://www.bi168.cn/)

Powered by Discuz! X3.2