维度设计


维度设计

学习《大数据之路》第10章,《维度设计》摘要。

维度设计基础

维度的基本概念

维度是维度建模的基础和灵魂。
在维度建模中,讲度量称为”事实”,将环境描述称为”维度”,维度是用于分析事实所需要的多样环境。

维度所包含的表示维度的列,称为维度属性。
维度属性是查询约束条件、分组和报表标签生成的基本来源,是数据易用性的关键。

如何获取维度或属性?

1、可以在报表中获取。

2、可以在和业务人员的交谈中发现维度活维度属性。
总结:用来描述其业务的自然方法应该作为维度或维度属性包括在维度模型中。

维度使用主键标识其唯一性,主键也是确保与之相连的任何事实表之间存在引用完整性的基础。
主键有两种:代理键自然键,它们都是用于标识维度的具体值。
但是代理键是不具有业务含义的键,一般用于处理缓慢变化维;
自然键是具有业务含义的键。

维度的基本设计方法

维度的设计过程就是确定维度属性的过程,如何生成维度属性,以及所生成的维度属性的优劣,决定了维度使用的方便性,成为数据仓库易用性的关键。
正如Kimball所说的,数据仓库的能力直接与维度属性的质量和深度成正比。

维度设计方法进行详细说明:

1、选择维度或新建维度。(作为维度建模的核心,在企业级数据仓库中必须保证维度的唯一性。)

2、确定主维度。(此处的主维度表一般是ODS表,直接与业务系统同步。)

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

4、确定维度属性。

确定维度主要包含两个阶段:


1、从主维度表中选择维度属性或生成新的维度属性。

2、从相关维度中选择维度属性或生成新的维度属性。

确定维度属性的几点提示:


1、尽可能生成丰富的维度属性,为下游的数据统计、分析、探查提供良好的基础。

2、尽可能多地给出包含一些富有意义的文字描述,属性不应该是编码,而应该是真正的文字。ID一般用于不同表之间的挂念,而名称一般用于报表标签。

3、区分数值型属性和事实
数值型字段是作为事实还是维度属性,可以参考字段的一般用途。
如果通常用于查询约束条件或分组统计,则是作为维度属性;
如果通常用于参与度量的计算,则是事实。
如果数值型字段是离散值,则作为维度属性存在的可能性比较大;
如果数值型字段是连续值,则作为度量存在的可行性交大,但不绝对,需要同时参考字段的具体用途。
(离散值,类似序号,不能细分的序号1和序号2之间不能拆分,而身高161和162之间依然可以有很多比较值。)

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

维度的层次结构

维度中的一些描述属性以层次方式或一对多的方式相关关联,可以被理解为包含连续主从关系的属性层次。
层次的最底层代表维度中描述最低级别的详细信息,最高层代表最高级别的概要信息。
维度常常有多个这样的嵌入式层次结构。

在属性的层次结构中进行钻取是数据钻取的方法之一。

规范化和反规范化

当属性层次被实例化为一些列维度,而不是单一的维度时,被称为雪花模式。

将维度的属性层次合并到单个维度中的操作称为反规范化
分析系统的主要目的是用于数据分析和统计,如何风方便用户进行统计分析决定了分析系统的优劣。

出于易用性和性能的考虑,维表一般是很不规范化的。
再实际应用中,几乎总是使用维表的空间来换取简明性和查询性能。

一致性维度和交叉探查。

构建企业级数据仓库不可能一蹴而就,一般采用迭代式的构建过程。
而单独构建存在的问题是形成独立型数据集市,导致严重的不一致性。
Kimball的数据仓库总监架构提供了一种分解企业级数据仓库规划任务的合理方法,通过构建企业范围内一致性维度和事实来构建总线架构。

数据仓库总线架构的重要基石之一就是一致性维度。
在针对不同数据域进行迭代构建或并行构建时,存在很多需求是对于不同不同数据域进行迭代构建或并行构建时,
存在很多需求是对于不同数据域的业务过程或者同一数据域的不同业务过程合并在一起观察。
如果不同数据域的计算过程使用的维度不一致,就会导致交叉探查存在问题。
当存在重复的维度,但维度属性或维度属性的值不一致时,会导致交叉探查无法进行或交叉探查结果错误。

维度不一致性进行了详细分析,下面总结维度一致性的几种表现形式。

1、共享维表。

2、一致性上卷,其中一个维度的的维度属性是另一个维度的维度属性的子集,且两个维度的公共维度属性结构和内容相同。

3、交叉属性,两个维度具有部分相同的维度属性。

维度设计高级主题

维度整合

数据仓库的定义:
数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合,用来支持管理人员的角色。
其中集成是数据仓库的四个特性中最重要的一个。
数据仓库的重要数据来源是大量的、分散的面向应用的差异具体表现在如下几个方面:
1、应用在编码、命名习惯、度量单位等方面会存在很大的差异。
2、应用在于性能和扩展性的考虑,或者技术框架的演变,以及业务的发展,采用不同的物理实现。
所以数据由面向应用的操作型环境进入数据仓库后,需要进行数据集成。
将面向应用的数据转换为面向主题的数据仓库数据,本身就是一种集成。具体体现在如下几个方面:

1、命名规范统一。

2、字段类型统一。

3、公共代码及代码值的统一。

4、业务含义的相同的表的统一。

5、采用主从表的设计方式,将两个表或多个表都有的字段放在主表中(主要基本信息),从属信息分别放在各自的从表中。

6、直接合并,共有信息和个性信息都存在同一个表中。

7、不合并,因为源表的表结构及主键等差异很大,无法合并,使用数据仓库里的多个表存放各自的数据。

维表的整合涉及的内容,下面看表级别的整合,有两种形式。

1、第一种是垂直整合,即不同的来源表包含相同的数据集,只是存储的信息不同。

2、第二种是水平整合,即不同的来源表包含不同的数据集,不同子集之间无交叉,也可以存在部分交叉。

有整合就有拆分,到底是整合还是拆分,由多种因素决定。下面讨论维度的水平拆分和垂直拆分。

水平拆分

维度通常可以按照类别类型进行细分。
如何设计维度?针对此问题,主要有两种解决方案:
方案1,是维度的不同分类实例化为不同的的维度,同时在主维度中保存公共属性。
方案2,是维护单一维度,包含所有可能的属性。

选择哪种方案?在数据模型设计过程中需要考虑的因素有很多,基本不可能满足各个特性的最优化。
在设计过程中需要重点考虑以下三个原则。

1、扩展性

当源系统、业务逻辑变化时,能通过较少的成本快速扩展模型,保持核心模型的相对稳定。
软件工程中的高内聚、低耦合的思想是重要的指导方针之一。


2、效能

在性能和成本方面取得平衡。通过牺牲一定的存储成本,达到性能和逻辑的优化。


3、易用性

模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表,并能够方便的查询和分析。

水平拆分的依据

根据数据模型设计思想,在对维度进行水平拆分时,主要考虑如下两个依据。

1、第一个依据是维度的不同分类的属性差异情况。
当维度属性随类型化较大时,将所有可能的属性建立在一个表中是不切合实际的,也没有必要这样做,此时建议采用方案1。

2、第二个依据是业务的关联程度。两个相关性比较低的业务,融合在一起弊大于利,对模型的稳定性和易用性影响比较大。

垂直拆分

在维度设计内容中,维度是维度建模的基础和灵魂,维度属性的丰富程度直接决定了数据仓库的能力。
在进行维度设计时,依据维度设计的原则,尽可能丰富维度属性,同时进行反规范化处理。
对于具体实现时可能存在的问题,一是在”水平拆分”中提到的,由于维度分类的不同而存在特殊的维度属性,
可以通过水平拆分的方式解决此问题。
出于扩展性、产出时间、易用性等方面的考虑,设计主从维度。
维表存放稳定、产出时间早、热度搞的属性;
维表存放变化较快,产出时间晚、热度低的属性。

维度变化

缓慢变化维

数据仓库的重要特点之一是反应历史变化,所以如何处理维度的变化是维度设计的重要工作之一。
缓慢变化维的提出是因为在线是世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化。
与数据增长较为快速的事实表相比,维度变化相对缓慢。

在一些情况下,保留历史数据没有什么分析价值;
而在另一些情况下,保留历史数据将会起到至关重要的作用。
在Kimball的理论上,有三种处理缓慢变化维的方式,下面通过简单的实例进行说明。

1、第一种处理方式:重写维度值。采用此种方式,不保留历史数据,始终取最新数据。

2、第二种处理方式:插入新的维度行。采用此种方式,保留历史数据。

3、第三种处理方式:添加维度列。采用第二种处理方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。

快照维表

在**”维度的基本概念”中,介绍了自然键代理键的定义,在Kimball的维度建模中,必须使用代理键**作为每个维表的主键,用于处理缓慢变化维。

极限存储

首先来看历史拉链存储。
历史拉链存储是指利用维度模型中缓慢变化维的第二种处理方式。
这种处理方式是通过新增两个时间戳字段(开始和结束),将所有以天为粒度的变更数据都记录下来。
原书第177页,详细介绍。


文章作者: Callable
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 Callable !
评论
  目录