谈笑间学会数仓—建模方法论

谈笑间学会数仓—建模方法论

ER模型

数据仓库之父Bill Inmon提出的建模方法是从全企业的高度设计的一个3NF模型,用实体关系(Entity Relationship,ER)模型描述企业业务,在范式理论上符合3NF。数据仓库中的3NF与OLTP系统中的3NF的区别在于,它是站在企业角度面向主题的抽象,而不是针对某个具体业务流程的实体对象关系的抽象。其具有以下几个特点:

  • 需要全面了解企业业务和数据
  • 实施周期非常长
  • 对建模人员的能力要求非常高

采用ER模型建设数据仓库模型的出发点是整合数据,将各个系统中的数据以整个企业角度按主题进行相似性组合和合并,并进行一致性处理,为数据分析决策服务,但是并不能直接用于分析决策。

其建模步骤分为三个阶段:

  • 高层模型:一个高度抽象的模型,描述主要的主题以及主题间的关系,用于描述企业的业务总体概况。
  • 中层模型:在高层模型的基础上,细化主题的数据项
  • 物理模型(也叫底层模型):在中层模型的基础上,考虑物理存储,同时基于性能和平台特点进行物理属性设计,也可能做一些表的合并、分区和设计等。

ER 模型在实践中最典型的代表是 Teradata 公司基于金融业务发布的FS-LDM (Financial Services Logical Data Model ),它通过对金融业务的高度抽象和总结,将金融业务划分为 10 主题 ,并以设计面向金融仓库模型的核心为基础,企业基于此模型做适当调整和扩展就能快速落地实施。

样例

谈笑间学会数仓—建模方法论_第1张图片

维度模型

维度模型是数据仓库领域的Ralph Kimball 大师所倡导的,他的 The Data Warehouse olkit-The Complete Guide to *Dimensional Modeling是数据仓库工程领域最流行的数据仓库建模的经典。

维度建模从分析决策的需求出发构建模型,为分析需求服务,因此它重点关注用户如何更快速地完成需求分析,同时具有较好的大规模杂查询的响应性能。其典型的代表是星形模型,以及在一些特殊场景下使用的雪花模型。其设计分为以下几个步骤。

  • 选择需要进行分析决策的业务过程。业务过程可以是单个业务事件,比如交易的支付、退款等;也可以是某个事件的状态,比如当前的账户余额等;还可以是一系列相关业务事件组成的业务流程,具体需要看我们分析的某些事件发生情况,还是当前状态伙食事件流转效率。
  • 选择粒度。在事件分析中,我们要预判所以分析需要细分的程度,从而决定选择的粒度。粒度是维度的一个组合。
  • 识别维度。选择好粒度之后,就需要基于此粒度设计维表,包含维度属性,用于分析爱时进行分组和筛选。
  • 选择事实。确定分析需要衡量的指标。

样例 :

谈笑间学会数仓—建模方法论_第2张图片

Data Vault模型

Data Vault 是Dan Linstedt 发起创建的一种模型,它是ER模型的衍生,其设计的出发点也是为了实现数据的整合,但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层,也就是强调数据的历史性、可追溯性和原子性,而不要求对数据进行过度的一致性处理和整合;同时它基于主题概念将企业数据进行结构化组织,并引入了更进一步的范式处理来优化模型,以应对游、系统变更的扩展性。 Data Vault 型由以下几部分组成。

  • Hub:是企业的核心业务实体,由实体Key、数据仓库序列代理键、装载时间、数据来源组成。
  • Link:代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象,可以提升模型的扩展性。它可以直接描述1:1、1:n和n:n的关系,而不需要做任何变更。它由Hub的代理键、装载时间、数据来源组成。
  • Satellite:是Hub的详细描述内容,一个Hub可以有多个Satellite。它由Hub的代理键、装载时间、来源类型、详细的Hub描述信息组成。

DataVault 模型比 ER 模型更容易设计和产出,它的 ETL 加工可实现配置化。通过 Dan Linstedt 的比喻更能理解 Data Vault 的核心思想:Hub 可以想象成人的骨架,那么 Link 就是连接骨架的韧带,而 SateIIite 就是骨架上面的血肉。看如下实例(来自 Data vault Modeling Guide, 作者 Hans Hultgren ),如图 8.1 所示。

样例

谈笑间学会数仓—建模方法论_第3张图片

Anchor模型

Anchor 对 Data Vault 模型做了进一步规范化处理, Lars. Ri:innback 的初衷是设计 个高度可扩展的模型,其核心思想是所有的扩展只是添加而不是修改,因此将模型规范到 6NF ,基本变成了 k-v 结构化模型。

我们看一下 Anchor 模型的组成。

  • Anchors:类似于Data Vault的Hub,代表业务实体,且只有主键。
  • Attributes:功能类似于Data Vault的satellite ,但是它更加规范化,将其全部k-v结构化,一个表只有一个Anchors的属性描述。
  • Ties:就是Anchors之间的关系,单独用表来描述,类似于Data Vault的Link,可以提升整体模型关系的扩展能力。
  • Knotes:代表那些可能会在多个Anchors中公用的属性的提炼,比如性别、状态等这种枚举类型且被公用的属性。

在上述四个基本对象的基础上,又可以细化分为历史和飞力士的,其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。

Anchor 模型的创建者以此方式来获取极大的可扩展性,但是也会增加非常多的查询 join 操作。创建者的观点是,数据仓库中的分析查询只是基于一小部分字段进行的,类似于列存储结构,可以大大减少数据扫描,从而对查询性能影响较小。一些有数据表裁剪( Table Elimination) 特性的数据库如 MariaDB 的出现, 还会大量减少 join 操作。但是实际情况是不是如此,还有待商榷。下面是一个 Anchor 模型图(来自 Anchor Modeling-Agile Information Modeling in Evolving Data Environments ,作者Lars. Ronnback ),如 8.2 所示。

样例

小结:

ER模型适用于系统设计,关系比较复杂,适用于OLTP型

维度建模适用于大数据分析决策,关系简单事实表和维度表构成星型模型或者雪花模型,适用于OLAP

Data Vault 企业级的数据仓库建模、Anchor模型,哈哈,没有搞过,以后有机会再扯吧~

参考:《大数据之路-阿里巴巴大数据实践》

你可能感兴趣的:(谈笑间学会数据仓库,谈笑间学会大数据,大数据,数据仓库)