ETL

02 数据仓库设计基础

2019-12-12  本文已影响0人  Youngmon

首先介绍关系数据模型、多维数据模型和 Data Vault 模型这三种常见的数据仓库模型和与之相关的设计方法,然后讨论数据集市的设计问题,最后说明一个数据仓库项目的实施步骤。规划实施过程是整个数据仓库设计的重要组成部分。
关系模型、多维模型已经有很长的历史,而 Data Vault 模型相对比较新。它们都是流行的数据仓库建模方式,但又有各自的特点和适用场景。读者在了解了本章的内容后,可以根据实际需求选择适合的方法构建自己的数据仓库。

2.1 关系数据模型

关系模型是由 E.F.Codd 在 1970 年提出的一种通用数据模型。由于关系数据模型简单明了,并且有坚实的数学理论基础,所以一经推出就受到了业界的高度重视。关系模型被广泛应用于数据处理和数据存储,尤其是在数据库领域,现在主流的数据库管理系统几乎都是以关系数据模型为基础实现的。

关系数据模型可以提供高性能的数据更新操作,能很好地满足事务型系统的需求,这点毋庸置疑。但是对于查询与分析密集型的数据仓库系统还是否合适呢?对这个问题的争论由来已久,基本可以分为 Inmon 和 Kimball 两大阵营, Inmon 阵营是应用关系数据模型构建数据仓库的支持者。

关系数据模型与数据仓库

数据仓库最重要的一个用途是作为坚实的、可靠的、一致的数据基础为后续的报表系统、数据分析、数据挖掘或BI系统服务。数据模型还必须支持为组织建立的业务规则。这就意味着数据模型必须比简单的平面文件功能更强。为此关系数据模型也是最佳选择之一。
关系数据模型已被证明是可靠的、简单的数据建模方法。应用其规范化规则,将产生一个稳定的、一致的数据模型。该模型支持由组织制定的政策和约定的规则,同时为数据集市分析数据提供了更多的灵活性,使得数据库存储以及数据装载方面也是最有效的。
当然,任何一种数据模型都不可能是完美无瑕的。关系数据模型的缺点也很明显,它需要额外建立数据集市的存储区,并增加相应的数据装载过程。另外,对数据仓库的使用强烈依赖于对SQL语言的掌握程度。

2.2 维度数据模型

维度数据模型简称维度模型( Dimensional modeling, DM ),是一套技术和概念的集合,用于数据仓库设计。不同于关系数据模型,维度模型不一定要引入关系数据库。
在逻辑上相同的维度模型,可以被用于多种物理形式,比如维度数据库或是简单的平面文件。根据数据仓库大师Kimball的观点,维度模型是一种趋向于支持最终用户对数据仓库进行查询的设计技术,是围绕性能和易理解性构建的。尽管关系模型对于事务处理系统表现非常出色,但它并不是面向最终用户的。

2.2.1 维度数据模型建模过程

维度模型通常以一种被称为星型模式的方式构建。所谓星型模式,就是以一个事实表为中心,周围环绕着多个维度表。还有一种模式叫做雪花模式,是对维度做进一步规范化后形成的。

2.2.2 维度规范化

与关系模型类似,维度也可以进行规范化。对维度的规范化(又叫雪花化),可以去除冗余属性,是对非规范化维度做的规范化处理,在下面介绍雪花模型时,会看到维度规范化的例子。一个非规范化维度对应一个维度表,规范化后,一个维度会对应多个维度表,维度被严格地以子维度的形式连接在一起。实际上,在很多情况下,维度规范化后的结构等同于一个低范式级别的关系型结构。

2.2.3 维度数据模型的特点

2.2.4 星型模式

星型模式是维度模型最简单的形式,也是数据仓库以及数据集市开发中使用最广泛的形式。星型模式由事实表和维度表组成,一个星型模式中可以有一个或多个事实表,每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状,中心是一个事实表,围绕在事实表周围的维度表表示星星的放射状分支,这就是星型模式这个名字的由来。

  1. 优点
  1. 缺点
    星型模式的主要缺点是不能保证数据完整性。一次性地插入或更新操作可能会造成数据异常,而这种情况在规范化模型中是可以避免的。星型模式的数据装载,一般都是以高度受控的方式,用批处理或实时过程执行的,以此来抵消数据保护方面的不足。
    星型模式的另一个缺点是对于分析需求来说不够灵活。它更偏重于为特定目的建造数据视图,因此实际上很难进行全面的数据分析。星型模式不能自然地支持业务实体的多对多关系,需要在维度表和事实表之间建立额外的桥接表。

2.2.5 雪花模式

雪花模式是一种多维模型中表的逻辑布局,其实体关系图有类似于雪花的形状,因此得名。与星型模式相同,雪花模式也是由事实表和维度表所组成。所谓
的 “ 雪花化 ” 就是将星型模式中的维度表进行规范化处理。当所有的维度表完成规范化后,就形成了以事实表为中心的雪花型结构,即雪花模式。

  1. 优点
    雪花模式是和星型模式类似的逻辑模型。实际上,星型模式是雪花模式的一个特例(维度没有多个层级)。某些条件下,雪花模式更具优势:
  1. 缺点
    雪花模型的主要缺点是维度属性规范化增加了查询的连接操作和复杂度。相对于平面化的单表维度,多表连接的查询性能会有所下降。但雪花模型的查询性能问题近年来随着数据浏览工具的不断优化而得到缓解。
    和具有更高规范化级别的事务型模式相比,雪花模式并不确保数据完整性。向雪花模式的表中装载数据时,一定要有严格的控制和管理,避免数据的异常插入或更
    新。

2.3 Data Vault 模型

Data Vault 是一种数据仓库建模方法,用来存储来自多个操作型系统的完整的历史数据。 Data Vault 方法需要跟踪所有数据的来源,因此其中每个数据行都要包含数据来源和装载时间属性,用以审计和跟踪数据值所对应的源系统。 Data Vault不区分数据在业务层面的正确与错误,它保留操作型系统的所有时间的所有数据,装载数据时不做数据验证、清洗等工作,这点明显有别于其他数据仓库建模方法。 Data Vault 建模方法显式地将结构信息和属性信息分离,能够还原业务环境的变化。 Data Vault允许并行数据装载,不需要重新设计就可以实现扩展。

2.3.1 Data Vault 模型简介

Data Vault ( DV )模型用于企业级的数据仓库建模,是 Dan Linstedt 在 20 世纪 90 年代提出的。在最近几年, Data Vault 模型获得了很多关注。
Dan Linstedt 将 Data Vault 模型定义如下:
Data Vault 是面向细节的,可追踪历史的,一组有连接关系的规范化的表的集合。这些表可以支持一个或多个业务功能。它是一种综合了第三范式( 3NF )和星型模型优点的建模方法。其设计理念是要满足企业对灵活性、可扩展性、一致性和对需求的适应性要求,是一种专为企业级数据仓库量身定制的建模方式。
从上面的定义可以看出, Data Vault 既是一种数据建模的方法论,又是构建企业数据仓库的一种具体方法。 Data Vault 建模方法论里不仅定义了 Data Vault 的组成部分和组成部分之间的交互方式,还包括了最佳实践来指导构建企业数据仓库。例如,业务规则应该在数据的下游实现,就是说 Data Vault 只按照业务数据的原样保存数据,不做任何解释、过滤、清洗、转换。即使从不同数据源来的数据是自相矛盾的(例如同一个客户有不同的地址), Data Vault 模型不会遵照任何业务的规则,如 “ 以系统 A 的地址为准 ” 。 Data Vault 模型会保存两个不同版本的数据,对数据的解释将推迟到整个架构的后一个阶段(数据集市)。

2.3.2 Data Vault 模型的组成部分

Data Vault 模型有中心表( Hub )、链接表( Link )、附属表( Satellite )三个主要组成部分。中心表记录业务主键,链接表记录业务关系,附属表记录业务描述。
在 DataVault 模型的标准定义里,附属表的主键应该是附属表里参照到中心表或链接表的外键字段和装载时间字段的组合。尽管这个定义是正确的,但从技术角度考
虑,我们最好还是增加一个代理键。使用只有一列的代理键更易维护。另外,对外键列和装载时间列联合建立唯一索引,也是一个好习惯。

2.3.3 Data Vault 模型的特点

一个设计良好的 Data Vault 模型应该具有以下特点:

2.3.4 Data Vault 模型的构建

在 Data Vault 模型中,各个实体有着严格、通用的定义与准确、灵活的功能描述,这不但使得 Data Vault 模型能够最直观、最一般地反映数据之间内含的业务规则,同时也为构建 Data Vault 模型提供了一致而普遍的方法。
Data Vault 模型的建立可以遵循如下步骤:

  1. 设计中心表
    首先要确定企业数据仓库要涵盖的业务范围;其次要将业务范围划分为若干原子业务实体,比如客户、产品等;然后,从各个业务实体中抽象出能够唯一标识该实体的业务主键,该业务主键要在整个业务的生命周期内不会发生变化;最后,由该业务主键生成中心表。

  2. 设计链接表
    链接表体现了中心表之间的业务关联。设计链接表,首先要熟悉各个中心表代表的业务实体之间的业务关系,可能是两个或者多个中心表之间的关系。根据业务需求,这种关系可以是 1 对 1 、 1 对多,或者多对多的。
    然后,从相互之间有业务关系的中心表中,提取出代表各自业务实体的中心表主键,这些主键将被加入到链接表中,组合构成该链接表的主键。同样出于技术的原因,需要增加代理键。
    在生成链接表的同时,要注意如果中心表之间有业务交易数据的话,就需要在链接表中保存交易数据,有两种方法,一是采用加权链接表,二是给链接表加上附属表来处理交易数据。

  3. 设计附属表
    附属表包含了各个业务实体与业务关联的详细的上下文描述信息。设计附属表,首先要收集各个业务实体在提取业务主键后的其他信息,比如客户住址、产品价格等;由于同一业务实体的各个描述信息不具有稳定性,会经常发生变化,所以,在必要的时候,需要将变化频率不同的信息分隔开来,为一个中心表建立几个附属表,然后提取出该中心表的主键,作为描述该中心表的附属表的主键。
    当业务实体之间存在交易数据的时候,需要为没有加权的链接表设计附属表,也可以根据交易数据的不同变化情况设计多个附属表。

  4. 设计必要的 PIT 表
    Point—In—Time 表是由附属表派生而来的。如果一个中心表或者链接表设计有多个附属表的话,而为了访问数据方便,就有用到 PIT 表的可能。
    PIT 表的主键也是由其所归属的中心表提取而来,该中心表有几个附属表, PIT 表就至少应该有几个字段来存放各个附属表的变化对比时间。

2.4 数据集市

数据集市是数据仓库的一种简单形式,通常由组织内的业务部门自己建立和控制。一个数据集市面向单一主题域,如销售、财务、市场等。数据集市的数据源可以是操作型系统(独立数据集市),也可以是企业级数据仓库(从属数据集市)。

2.4.2 数据集市与数据仓库的区别

不同于数据集市,数据仓库处理整个组织范围内的多个主题域,通常是由组织内的核心单位,如IT部门承建,所以经常被称为中心数据仓库或企业数据仓库。数据仓库需要集成很多操作型源系统中的数据。由于数据集市的复杂度和需要处理的数据都小于数据仓库,因此更容易建立与维护。表 2-19 总结了数据仓库与数据集市的主要区别。


选区_022.png

2.4.3 数据集市设计

数据集市主要用于部门级别的分析型应用,数据大都是经过了汇总和聚合操作,粒度级别较高。数据集市一般采用维度模型设计方法,数据结构使用星型模式或雪花模式。
正如前面所介绍的,设计维度模型先要确定维度表、事实表和数据粒度级别,下一步是使用主外键定义事实表和维度表之间的关系。数据集市中的主键最好使用系统生成的自增的单列数字型代理键。模型建立好之后,设计 ETL 步骤抽取操作型源系统的数据,经过数据清洗和转换,最终装载进数据集市中的维度表和事实表中。

2.5 数据仓库实施步骤

  1. 定义范围
    在实施数据仓库前,需要制定一个开发计划。这个计划的关键输入是信息需求和数据仓库用户的优先级。当这些信息被定义和核准后,就可以制作一个交付物列表,并给数据仓库开发团队分配相应的任务。

  2. 确定需求
    数据仓库项目的需求可以分为业务需求和技术需求。

  3. 逻辑设计
    定义了项目的范围和需求,就有了一个基本的概念设计。下面就要进入数据仓库的逻辑设计阶段。逻辑设计过程中,需要定义特定数据的具体内容,数据之间的关系,支持数据仓库的系统环境等,本质是发现逻辑对象之间的关系。

  4. 物理设计
    物理设计指的是将逻辑设计的对象集合,转化为一个物理数据库,包括所有的表、索引、约束、视图等。物理数据库结构需要优化以获得最佳的性能。每种数据库产品都有自己特别的优化方法,这些优化对查询性能有极大的影响。比较通用的数据仓库优化方法有位图索引和表分区。

  1. 装载数据
    这个步骤实际上涉及整个 ETL 过程。需要执行的任务包括:源和目标结构之间建立映射关系;从源系统抽取数据;对数据进行清洗和转换;将数据装载进数据仓库;创建并存储元数据。

  2. 访问数据
    访问步骤是要使数据仓库的数据可以被使用,使用的方式包括:数据查询、数据分析、建立报表图表、数据发布等。根据采用的数据仓库架构,可能会引入数据集市的创建。通常,最终用户会使用图形化的前端工具向数据库提交查询,并显示查询结果。

  3. 管理维护
    这个步骤涵盖在数据仓库整个生命周期里的管理和维护工作。这步需要执行的任务包括:确保对数据的安全访问、管理数据增长、优化系统以获得更好的性能、保证
    系统的可用性和可恢复性等。

2.6 小结

上一篇下一篇

猜你喜欢

热点阅读