数仓建模

维度建模

概念和背景

维度模型是数据仓库领域大师Ralph Kimball 所倡导,他的《数据仓库工具箱open in new window》,是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。

维度建模源自数据集市,主要面向分析场景 Ralph Kimball 推崇数据集市的集合为数据仓库,同时也提出了对数据集市的维度建模,将数据仓库中的表划分为事实表、维度表两种类型。

一般也称之为星型结构建模,有时也加入一些雪花模型在里面。维度建模是一种面向用户需求的、容易理解的、访问效率高的建模方法。

为什么选择维度建模

适配大数据的处理方式

维度模型的非强范式的,可以更好的利用大数据处理框架的处理能力,避免范式操作的过多关联操作,可以实现高度的并行化。

数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表,通过大量的冗余来提升查询效率,星型模型对OLAP的分析引擎支持比较友好,这一点在Kylin中比较能体现。

雪花模型在关系型数据库中如MySQL,Oracle中很常见,尤其像电商的数据库表。

自下而上的建设现状

表已经存在,业务已经开发完毕,需求直接提过来了,这几乎是一个普遍现状,因为很少有公司会提前成立数据部门,让数据部门跟随着业务从头开始一直成长,都是当业务发展到一定的阶段了,想通过数据来提高公司的运营效果。

简单的模型,使用简单

这个模型相对来说是比较简单的,简单主要体现在两个方面:

  1. 维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。
  2. 星型结构的实现不用考虑很多正规化的因素,设计与实现都比较简单。

分层和建模的关系

明细层的范式模型

明细层采用传统的三范式关系模型。这一层次的数据模型要将业务过程描述清楚,将源数据(即业务系统)中隐含的、有歧义的概念进行清晰化,如活跃用户、VIP用户等。该层次的数据模型追求的目标是灵活地表达业务过程,要保证数据一致性、唯一性、正确性,以尽量少的代价与源数据保持数据同步,同时该层次的数据模型不建议开给不懂技术的业务人员直接使用,因此,采用关系型的三范式模型是最佳的选择。

集市层的维度模型

集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合,该层次的数据模型会开放给业务人员使用,进行数据挖掘及业务分析。由于业务员多数不懂数据库技术,缺少将业务需求转换为关系型数据结构的逻辑思维,更写不出复杂的SQL语句,因此,越简单的数据模型,越能被他们所接受,因此,这个层次所构建出来的数据模型,要按照业务过程进行组织,每个事实表代表一个独立的业务过程,事实表之间不存在直接的依赖关系,这样业务人员可以很容易地将分析需求对应到事实表上,利用工具或手工写出简单的SQL,将统计数据提取出来进行分析。

模型实现

模型的实现主要指的是在维度建模过程中,需要对维度表和事实表进行关联设计,而这里我们对维度表的设计,就决定了我们最终与事实表关联的之后的形态。也就是说我们可以根据事实表和维度表的关系,又可将常见的模型分为星型模型和雪花型模型。

星型模型和雪花模型的主要区别在于对维度表的拆分,对于雪花模型,维度表的设计更加规范,一般符合3NF;而星型模型,一般采用降维的操作,利用冗余来避免模型过于复杂,提高易用性和分析效率。

星型模型

核心是一个事实表及多个非正规化描述的维度表组成,维度表之间是没有关联的,维度表是直接关联到事实表上的,只有当维度表极大,存储空间是个问题时,才考虑雪花型维度,简而言之,最好就用星型维度即可

当所有维表都直接连接到“ 事实表”上时,整个图解就像星星一样,故将该模型称为星型模型

星型架构是一种非正规化的结构,多维数据集的每一个维度都直接与事实表相连接,不存在渐变维度,所以数据有一定的冗余,如在地域维度表中,存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录,那么国家 A 和省 B 的信息分别存储了两次,即存在冗余。

星形

雪花模型

星形模式中的维表相对雪花模式来说要大,而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表,满足了规范化设计。然而这种模式在实际应用中很少见,因为这样做会导致开发难度增大,而数据冗余问题在数据仓库里并不严重

可以认为雪花模型是星型模型的一个扩展,每个维度表可以继续向外扩展,连接多个子维度。

当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型

雪花

星座模型

前面介绍的两种维度建模方法都是多维表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到。在业务发展后期,绝大部分维度建模都采用的是星座模式。

可以认为是多个事实表的关联或者是星型模型的关联,其实到了业务发展后期都是星座模型

星座

应用场景

维度建模是面向分析场景而生,针对分析场景构建数仓模型,重点关注快速、灵活的解决分析需求,同时能够提供大规模数据的快速响应性能。针对性强,主要应用于数据仓库构建和OLAP引擎底层数据模型。

优点

  • 方便使用,模型简单;

  • 适合大数据下的处理操作(其实就是shuffle);

  • 适合OLAP操作(上钻下钻);

  • 维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理,即可以完成维度建模;

  • 可扩展,维度模型是可扩展的。由于维度模型允许数据冗余,因此当向一个维度表或事实表中添加字段时,不会像关系模型那样产生巨大的影响,带来的结果就是更容易容纳不可预料的新增数据。

缺点

  • 数据冗余,维度补全后造成的数据浪费;

  • 灵活性差,维度变化造成的数据更新量大(例如刷数据的时候,需要刷大量的表);

  • 与典型的范式理论差异很大,如数据不一致,比如用户发起购买行为的时候的数据,和我们维度表里面存放的数据不一致;

  • 由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。而在这些与处理过程中,往往会导致大量的数据冗余;

  • 如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。

总结:维度建模的领域主要适用与数据集市层,它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法

维度表

维度是维度建模的基础和灵魂。在维度建模中,将度量称为“事实” , 将环境描述为“维度”。

维度表包含了事实表中指定属性的相关详细信息,最常用的维度表有日期维度、区域维度等。

维度表设计原则

维度的作用一般是查询约束、分类汇总以及排序等,我们在进行维度表设计时,应当提前考虑:

(1)维度属性尽量丰富,为数据使用打下基础

比如淘宝商品维度有近百个维度属性,为下游的数据统计、分析、探查提供了良好的基础。

(2)给出详实的、富有意义的文字描述

属性不应该是编码,而应该是真正的文字。在间里巴巴维度建模中, 一般是编码和文字同时存在,比如商品维度中的商品 ID 和商品标题、 类目 ID 和 类目名称等。 ID 一 般用于不同表之间的关联,而名称一般用 于报表标签

(3)区分数值型属性和事实

数值型宇段是作为事实还是维度属性,可以参考字段的一般用途。 如果通常用于查询约束条件或分组统计,则是作为维度属性;如果通常 用于参与度量的计算, 则是作为事实。比如商品价格,可以用于查询约 束条件或统计价格区间 的商品数量,此时是作为维度属性使用的;也可 以用于统计某类目 下商品的平均价格,此时是作为事实使用的。另外, 如果数值型字段是离散值,则作为维度属性存在的可能性较大;如果数 值型宇段是连续值 ,则作为度量存在的可能性较大,但并不绝对,需要 同时参考宇段的具体用途。

(4)沉淀出通用的维度属性,为建立一致性维度做好铺垫

有些维度属性获取需要进行比较复杂的逻辑处理,有些需要通过多表关联得到,或者通过单表 的不同宇段混合处理得到,或者通过对单表 的某个字段进行解析得到。此时,需要将尽可能多的通用的维度属性进 行沉淀。一方 面,可以提高下游使用的方便性,减少复杂度;另一方面,可以避免下游使用解析时由于各自逻辑不同而导致口径不 一致。

(5)退化维度(Degenerate Dimension)

在维度类型中,有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,退化维度一般在分析中可以用来做分组使用。

(6)缓慢变化维(Slowly Changing Dimensions)

维度的属性并不是始终不变的,它会随着时间的流逝发生缓慢的变化,这种随时间发生变化的维度我们一般称之为缓慢变化维(SCD),缓慢变化维一般使用代理健作为维度表的主健。

维度表设计方法

  1. 第一步:选择维度或新建维度。

    作为维度建模的核心,在企业级数 据仓库中必须保证维度的唯一性。以淘宝商品维度为例,有且只允许有 一个维度定义。

  2. 第二步:确定主维表。

    此处的主维表一般是 ODS 表,直接与业务 系统同步。以淘宝商品维度为例, s_auction_auctions 是与前台商品中心 系统同步的商品表,此表即是主维表。

  3. 第三步:确定相关维表。

    数据仓库是业务源系统的数据整合,不同业务系统或者同 一业务系统中的表之间存在 关联性。根据对业务的梳 理,确定哪些表和主维表存在关联关系,并选择其中的某些表用于生成维度属性。

  4. 第四步 :确定维度属性 。

    本步骤主要 包括两个阶段,其中第 一 个阶 段是从主维表 中选择维度属性或生成新的维度属性;第 二个阶段是从相 关维表中选择维度属性或生成新 的维度属性。以淘宝商品维度为例,从 主维表 (s_auction_auctions)和类目、 SPU、卖家、店铺等相关维表中 选择维度属性或生成新 的维度属性。