深入理解数据仓库建模

深入理解数据仓库建模

一、数据仓库建模的意义

如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类

地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果

把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹

组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。

数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用

角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程

序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们

之间的关系“，最能够说明数据模型的重要性。

只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高

性能、低成本、高效率、高质量的使用。

性能：帮助我们快速查询所需要的数据，减少数据的I/O吞吐，提高

使用数据的效率，如宽表。

成本：极大地减少不必要的数据冗余，也能实现计算结果复用，极大

地降低存储和计算成本。

效率：在业务或系统发生变化时，可以保持稳定或很容易扩展，提高

数据稳定性和连续性。

质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计

算错误的可能性。

数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和

术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业

务。

大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性

能、成本、效率和质量之间取得最佳平衡！

下图是个示例，通过统一数据模型，屏蔽数据源变化对业务的影响，保

证业务的稳定，表述了数据仓库模型的一种价值:

传统业务开发方式-数据源变化，所有业务都需要修改

二、数据仓库分层的设计

一、数据仓座分层

ODSS：原始数据总，存放原始数据，直接加©原始日惠、数娉，数据保持原靛不敬处理.

DWD层：对ODS层数据进行清洗（去原空值，脏数据，超过极跟范围的数据）、维曳退

化、脱敏等.粒度是一行信息代表一次行为，例如一次下单.

以DWD为基础，按天进行轻度汇总.粒度是一行信息代表一天的行为，例如一天下单次数

以DWS为基的，按主题迸行汇总.收受是一行信息代表累积的行为，例如用户从注册那天

开始至今一共下了多少次单

ADSS,为各种统计报表提供数据

二、数据仓库为什么要分层

1）把豆杂问踱简单化将复杂的任务分解成多层来完成，耳一层只处理尚单的任务，方便定位问题.

>2）减少重复开发规垣数据分层，通过的中间层数据，能缪减少极大的重复计算，增恒一次计算结果的复用性.

1发>这答数据

，3）隔惠原始数据不论是数指的异常还是效措的敏宓性，使真实效措与统计数携舞熠开.（

以下是我们的一种分层设计方法，数据缓冲区（ODS）的数据结构与

源系统完全一致。基础数据模型（DWD）和融合数据模型（DWI与DWA）

是大数据平台重点建设的数据模型。应用层模型由各应用按需自行建设,

其中基础数据模型一般采用ER模型，融合数据模型采用维度建模思路。

数据共

数据层次定位与功能1数据粒度建设模式

享

星型亘靖花模^设W

数据应用♦直接面向各应用的多自谈提结构(维

高度汇总数据•分散建设,按零共享

层度模目目)、数据宽表

、融法化

......................1

・各业免单元建设当

视图子星宓生花模型t殳计

应用过程中，枳案的

/汇聚子的多自生数据结构(维多维度汇总数•分散建设

公共数据模型。这层■企业共享

层度模且复)、数据宽表据统一规范

数据模型通常沉淀了•

、融化

融合层模DWA一定的识

型

整合子层・该业务单元使用的关实例级汇总数•集中建设

・企业共享

DWI键数据进行整合业务宽表据•统一规范

.企骏寮资产的汇聚

层，数据经过标准化

・集中建设

草证数据处理后按照数据仓库关系型数据结均

DWD洋卅粒度数据•统一规范•企业共享

层的主题域组织存放，ER模型

保留细亍、历史数据

O

—

.....1.....b.......................................................

•数据着陆区、数据结

构与源系统完全一致

数据罢冲•集中建设・按熹申请

无洋用粒度数据

区ODS

采集、〜加崭除

一周度

三、两种经典的数据仓库建模方法

前面的分层设计中你会发现有两种设计方法，关系建模和维度建模，

下面分别简单介绍其特点和适用场景。

当今的数据处理方式大致可以分成两大类：联机事务处理OLTP(on­

linetransactionprocessing)、联机分析处理OLAP(On-LineAnalytical

Processing)oOLTP是传统的关系型数据库的主要应用，主要是基本的、

日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支

持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二名

的主要区别对比如下表所示

1、维度建模

(1)定义

维度模型是数据仓库领域另一位大师RalphKimball所倡导的。维度

建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，

因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复

杂查询的响应性能，更直接面向业务。

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星库模

型。

1、星型模型2、花模型

3、星座模型

\ShippingFactTabic

timekey

*,*itemkey

shipperkey...

星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个

事实表

基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所

以星座不星座只反映是否有多个事实表，他们之间是否共享一些维度表。

所以星座模型并不和前两个模型冲突

星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主

键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处

理，将多个维度集合到一个事实表，形成一个宽表。

首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不

用选择。

星型还是雪花，取决于性能优先，还是灵活更优先目前实际企业开发中，

不会绝对选择一种，根据情况灵活组合，甚至并存(一层维度和多层维度

都保存)。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop

休系，减少Join就是减少Shuffle,性能差距很大(关系型数据可以依靠强

大的主键索引)

(2)建模方法

选择业务过程一声明粒度一确认维度一确认事实

(a)选择业务过程

在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业

务，退款业务，物流业务，一条业务线对应一张事实表。

如果是中小公司，尽量把所有业务过程都选择。如果是大公司(1000

多张表)，选择和需求相关的业务线。

(b)声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级

别。

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能

选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下：

•订单当中的每个商品项作为下单事实表中的一行，粒度为每次。

•每周的订单次数作为一行，粒度为每周。

•每月的订单次数作为一行，粒度为每月。

•如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度

的指标了。所以建议采用最小粒度。

(c)确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”

等信息。

确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，

需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订

单多。需要确定的维度就包括：时间维度、地区维度、用户维度。

维度表：需要根据维度建模中的星型模型原则进行维度退化。

(d)确定事实

此处的“事实”一词，指的是业务中的度量值(次数、个数、件数、金

额，可以进行累加)，例如订单金额、下单次数等。

在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构

建最细粒度的明细层事实表.事实表可做适当的宽表化处理.

法及业务过程

可以是单个北岳存事件分析中，

U于港律的越虚

事件，也可以基依月所有分析的

设计缰布，分析

票个事件的状态一分艘虚，然后

维去的具体修住

，迁可以是多个次定选比的像虚

事件组成的凌望

以下是阿里的OneData的建模工作流

（3）优缺点

优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析

需求，较好的大规模复杂查询的响应性能

缺点：维度表的冗余会较多，视野狭窄

2、关系建模

（1）定义

美系模型如图所示，严格遵循第三范式（3NF）,从图中可以看出，

较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众

多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主要

应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分

业务系统的表都是遵循第三范式的。

它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的

“singleversionofthetruth”。

关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程

中，会造成多表关联，这会大大降低执行效率，所以在数据仓库系统里面

我们通常采用维度模型建模，把相关各种表整理成两种：事实表和维度表

两种。

（2）建模方法

关系建模要从整体进行考虑，也就是说要对业务有全面的了解和把

控，要对上游业务系统的进行信息调研，以做到对其业务和数据的基本了

解，要做到主题划分，让模型有清晰合理的实体关系体系，以下是方法的

小思:

基本是总结不出来的:

报务依效于资源

非务使运工录

俣存在萼诠士

jL

」帐务卜臧量静L事件1管铐是更'

张务为营髭

资源淮注约成大U

注录在b务三鬃域

伎乘务务

的费5用及

矗蛔

溪道的数支已记录在财务主题域参与人

人是苦鸨苫动的

发起者、我行者和对;

rw>管亚活牛的或云三家左i才务主差域<W]

(3)优缺点

优点：规范性较好，冗余小，数据集成和数据一致性方面得到重视，比如

运营商可以参考国际电信运营业务流程规范(ETOM),有所谓的最佳实

践。

缺点：需要全面了解企业业务、数据和关系；实施周期非常长，成木昂

贵；对建模人员的能力要求也非常高，容易烂尾。现在一般企业中大部分

都是使用维度建模来进行数仓模型的设计。

3、建模方法比较

一般来讲，维度模型简单直观，适合业务膜式快速变化的行业，关系

模型实现复杂，适合业务模式比较成熟的行业，在现在业务快速的发展变

化，关系建模来不及快速的响应和改变。

运营商以前都是关系建模，现在其实边界越来越模糊，很多大数据业

务变化很快，采用维度建模也比较方便，不需要顶层设计。

屋性维度模型关系模型

数据总量多少

可读性容易差

表个数少多

快慢

冗余度高低

对实时表的情况增加宽度字段t阐少，冗余1氐

扩展性差好

实施难度低，周期短高，周期长

快速变化行业、战术性投入、M成熟行业、战住投入、不M接

适用场量IS

接面向客户，比如淘宝面向客户，比如运营商

四、企业建模的三点经验

维度建模就不说了，只要能理解业务过程和其中涉及的相关数据、维

度就可以，但自顶向下的关系建模难度很大，以下是关系建模的三个建设

要点。

1、业务的理解：找到企'IK内最理解'1K务和源系统的人，梳理出现状，比

如运营商就要深刻理解三域（O/B/M）,概念建模的挑战就很大，现在做

到B域的概念建模已经很不容易。

M

域

现

状

M域现状

政企都市等部**

组

。

织

域

现

现

状

状

2、数据及关系的理