数仓建模 - 维度 vs 关系

复杂的数据关系.jpg

目录

  • 数据仓库模型建设
    • 模型概念
      • 维度建模
      • 关系建模
    • 建模实现对比
    • 模型选择
    • Data Vault 简介

数据仓库模型建设

数据管理一直在演进,从早期的电子表格、蛛网系统到架构式数据仓库。发展至今以维度建模和关系建模为主,而随着互联网的发展,数据从GB到PB的裱花,企业业务迭代更新亦是瞬息万变,对维度模型的偏爱渐渐有统一互联网数仓建模标准的趋势。

数仓模型不分高下,都是一种观察现实的角度。维度模型以实体与实体之间发生的事务/实为切入,而关系建模则以实体与实体之间的关系来组织数据。在当前的环境下,互联网更倾向于维度建模,而传统行业则较多沿用关系建模。

个人先后经历金融、互联网数仓建设,有多个0到1的项目经历,对于数仓建设仍在持续学习中。如有错误之处,还请多指出交流。

模型理念

维度建模

以事实表为核心,多个维度表作为手臂形成的星型模型,是维度建模的典型实现方式。

事实表,记录业务过程中发生的可度量事件,如订单中的消费金额,折扣金额或是库存数量等,在实际业务中事实表占据主要的存储,如订单表;而维度表,则是对业务过程度量有关的文本环境,描述“谁、什么、哪里、何时、如何、为什么”,常用的维度表有日期、产品、用户、地址等。一般维度表会冗余信息,有超过100个列的维度表,这样的不规范化带来数据组织上的简单。

关系建模

关系建模,被称为“实体-关系”模型,以一种“标准化”的方式存在,强调数据之间非冗余,满足3NF。在建设过程中,将数据标准化到细节级数据,如用户主题下,会有用户与姓名、用户与年龄、用户与住址等。在传统行业中,成熟的关系建模有ls-ldm模型,面向金融行业形成10大主题。

建模实现的对比

对比 维度建模 关系建模
建设周期
优点 高效 灵活
实践方式 需求导向 抽象化企业数据
常用范围 数据集市 企业模型

维度建模: 从实际的需求出发进行数据建设,一般面向部门/业务形成独立的数据集市,这样的方式带来鲜明的特点,高效。但由于基于需求出发,往往导致频繁的需求迭代带来的维护成本较高,一旦业务过程发生调整,模型有可能会重来的风险。

关系建模:面向企业进行模型建设,具有较强的抽象性。建设时以3NF的方式建设无冗余的数据,使模型具有很高的灵活性,但由于不能直接面向需求,效率上不如维度模型。另外面向企业建设,周期相比于维度建模,要长的多,但也有个好处:企业数据集成更容易。

模型选择

在企业内,这两种建模方式往往同时存在,基础数据仓库的建设使用关系建模,技术的优雅换来了数据的精简,保证高度抽象、高度一致性,要求业务稳定;往上维度建模更合适一些,偏向于直接面对业务,靠数据的冗余带来了可用性,保证查询效率。两者优势互补

Data Vault 简介

设计示例

在大数据的环境下,数据存储和发展已发生很大变化,曾经的维度建模和关系建模在当前的场景下都有各自的不足之处。那数据仓库在大数据环境下如何发展、成熟?Inmon等就提出了data vault模型

data valult是一个面向细节的、历史追溯的并且唯一链接的规范化表集,能给支持一个或者多个业务功能区;是一种中心辐射式模型,其设计重点围绕着业务键的集成模式。data vault有三种基本的实体(结构)

  • 中心表(Hub):实际业务键的集合,如订单信息表等

  • 链接表(Link):记录着业务键之间的关系和联系,没有开始或者结束日期,只记录数据到达数据仓库那一时刻的关系的一种表达

  • 卫星表(Satellite):数据仓库概念的表,存储了随时间推移的非易失数据。

从建模风格上看,它采用了一种由第三范式方法与维度建模方法混合而成的方式,以二者的独特组合来满足企业需求。

你可能感兴趣的:(数仓建模 - 维度 vs 关系)