数据仓库模型全景

数据仓库模型全景

数据仓库模型构建

一、数据仓库构建需要考虑的问题

与数据库的单表基于ER模型构建思路不同，其面向特定业务分析的特性，决

定了它的构建需要整合多套数据输入系统，并输出多业务条线的、集成的数

据服务能力，需要考虑更全面的因素，包括：

・业务需求：从了解业务需求着手分析业务特点和业务期望；

・系统架构：从系统架构和数据分布、数据特性等角度，分析系统架构

设计上是否有问题；

•逻辑设计：从数据模型逻辑设计出发是否设计合理，是否符合数据库开发

和设计规范等；

•物理设计：从库表类型、库表分区、索引、主键设计等维度，主要针对性

能，可扩展性进行物理模型设计审查

二、什么是数仓的数据模型

数据仓库模型构建的宗旨能够直观地表达业务逻辑，能够使用实体、属性及

其关系对企业运营和逻辑规则进行统一的定义、编码和命名，是业务人员和

开发人员之间沟通的一套语言，数据仓库数据模型的作用：

・统一企业的数据视图；

・定义业务部门对于数据信息的需求；

•构建数据仓库原子层的基础；

・支持数据仓库的发展规划；

・初始化业务数据的归属；

常用数据模型的是关系模型和维度模型，关系模型从全企业的高度设计一个

3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式

理论上符合3NF,其站在企业角度进行面向主题的抽象，而不是针对某个具

体业务流程的，它更多是面向数据的整合和一致性治理；

维度建模以分析决策的需求为出发点构建模型，直接面向业务，典型的代表

是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型，大多

数据仓库均会采用维度模型建模；

维度建模中的事实表客观反应整个业务的流程，比如一次购买行为我们就可

以理解为是一个事实，订单表就是一个事实表，你可以理解他就是在现实中

发生的一次操作型事件，我们每完成一个订单，就会在订单中增加一条记

录，订单表存放一些维度表中的主键集合，这些ID分别能对应到维度表中的

一条记录，用户表、商家表、时间表这些都属于维度表，这些表都有一个唯

一的主键，然后在表中存放了详细的数据信息：

如果是采用ER模型，需要设计出一个大宽表，将订单-商家-地址-时间等信

息囊括在内，比较直观、细粒度，但也存在设计冗余，如果数据量很大，对

于查询和检索将是一个灾难；

order

£Sid

user_name

user_sex

user_phone

user_email

product_name

product_desc

store_name

store_address

store_country

store_province

date

time_stamp

二渊斓aw

三、如何构建数仓的数据模型

概念模型设计（业务模型）：界定系统边界；确定主要的主题域及其内容；

逻辑模型设计：维度建模方法（事实表、维度表）；以星型和雪花型来组织

数据；物理模型设计：将数据仓库的逻辑模型物理化到数据库的过程；

1、概念模型设计

数据仓库中数据模型设计顺序如上，数据仓库是为了辅助决策的，与业务流

程（BusinessProcess）息息相关，数据模型的首要任务便是选择业务流

程，为数据仓库的建立提供指导方向，这样才能反过来为业务提供更好的决

策数据支撑，让数据仓库价值的最大化，对于每个业务流程，都需要进行独

立的数据建模，将业务系统中的ER模型转化为数据仓库中的维度数据模

型，以便更好的查询与分析。

2、逻辑模型设计

事实表一般由两部分组成，维度(Dimension)和度量

(Measurement),事实表可以通俗的理解为「什么人在什么时间做了什么

事」的事实记录或者场景上下文，拥有最大的数据量，它是业务流程的核心

体现，比如电商场景中的订单表，其主键为一个联合主键，由各个维度的外

键组成，外键不能为空值，事实表一般不包含非数字类型字段，虽然数据量

大，但占用的空间并不大，保证更高的查询效率。

维度表用于对事实表的补充说明，描述和还原事实发生时的场景，如电商订

单中定义用户、商品、地址、时间、促销5个维度，通过这5个维度还原订

单发生时的场景，什么人在什么时间在什么地方购买了什么商品，以及购买

该商品的促销方式。对于每一个维度而言，都有若干个属性来描述，比如用

户有性别、年龄、所在地等信息。这些维度的属性就是之后数据统计的依

据，比如我们可以统计不同性别，不同年龄，不同地区在订单中的差异，从

向用户制定更精细的营销策略。

在关系型数据库三范式(3NF)设计极力避免数据的冗余，达到数据的高度

一致性，但在数据仓库中3NF并不是最佳实践，反而让系统复杂不已，不利

于理解和维护，所以在维度建模中，维度表一般采取反范式的设计，在一张

维度表中扁平化存储维度的属性，尽量避免使用外键。

3、物理模型设计

在完成数据仓库的概念模型和逻辑模型设计之后，物理模型设计就是落地实

施环节，根据数据的粒度和对于业务支撑能力将数据进行分层存储，数据分

层存储简化了数据清洗的过程，每一层的逻辑变得更加简单和易于理解，当

发生错误或规则变化时，只需要进行局部调整；

ODS层：全称是OperationalDataStore,又叫数据准备层，数据来源层，

主要用于原始数据在数据仓库的落地，这些数据逻辑关系都与原始数据保持

一致，在源数据装入这一层时，要进行诸如业务字段提取或去掉不用字段，

脏数据处理等等。可以理解为是关系层的基础数据；

DIM层：Dimension层，主要存放公共的信息数据，如国家代码和国家

名，地理位置等信息就存在DIM层表中，对外开放，用于DWD,DWS和

APP层的数据维度关联。

DWD层：全称是DataWarehouseDetail,用于源系统数据在数据仓库中

的永久存储，用以支撑DWS层和DM层无法覆盖的需求，该层的数据模型

主要解决一些数据质量问题和数据的完整度问题，比如商场的会员信息来与

不同表，某些会员的的和数据可能不完整等等问题；

DWS层：全称是DataWarehouseService,主要包含两类汇总表：一是

细粒度宽表，二是粗粒度汇总表，按照商场订单例子，包含基于订单、会

员、商品、店铺等实体的细粒度宽表和基于维度组合(会员日进场汇总、会员

消费汇总、商场销售日汇总、店铺销售日汇总等)的粗粒度汇总表。这层是对

外开放的，用以支撑绝大部分的业务需求，汇总层是为了简化源系统复杂的

逻辑关系以及质量问题等，这层是的业务结构容易理解，dws层的汇总数据

目标是能满足80%的业务计算。

其上根据业务需求可以继续构建ADS层(ApplicationDataStore)和面向

指标和报表的高度汇总层。

案例解读：

招标采购业务的数据仓库模型构建

按照数据仓库的构建思路，顺序是概念模型—>逻辑模型一〉物理模型，最重

要和复杂度较高的是概念模型的设计，需要结合业务，并根据业务特性设计

事实表、维度表、顶层数据汇总表；

一、概念模型设计

概念模型需要结合生产系统的ER关系模型，梳理业务逻辑，当前生产交易系

统使用的是ORACLE数据库，将数据分成多个库：业务库（包含招标采购项

目流程）、主体+组织库（招标人、投标人、评标专家、代理机构）、财务库

（标书费、平台服务费、招标保证金、CA办理费用等），项目表即是一个招

标流程表，该表会记录关于招标过程中的，招标、投标、开标、评标、定标

相关的数据：

・招标：招标流程是招标人发起的，招标人将招标过程委托给代理机构，代

理机构会发布招标公告，投标人在报名、响应阶段产生数据，响应后需要

付投标保证金；

•投标：投标人给代理机构缴纳标书费并下载招标文件，开标之前需要响

应，并缴纳投标保证金；发售招标文件和投标人购买标书后，如果投标人

对招标文件提出质疑，或招标人要修改招标文件，此时要在规定时间内发

布一个澄清公告。

•开标：开标一般是线下进行，代理机构把投标人召集到开标室，公开宣读

投标人关于投标人报价、工期、质量、工程项目经理等投标人有实质要求

的内容，此阶段拆封投标文件，解密电子的投标文件；

•评标：评标一般是线下进行，代理机构把监督人、投标人、专家召集到评

标室，专家对投标人资质及投标书打分，分为技术、商务、报价分；

•定标：专家对投标人综合打分后，做一个总体排名，排名第1即为中标候

选人，评标结束后需要发布预中标公告，将前3名公布，公告期间接受社

会监督，期间产生的疑问、质疑需要代理机构/招标人澄清，澄清伴随着

澄清公告，若质疑生效则可能废标和流标（评标成本高，一般不废标）；

•合同：若预中标发布后，质疑期间对于预中标候选人无影响，在预中标发

布XXX天后，招标人需要同中标候选人签订合同，同时招标人需要退还其

他没有中标单位的保证金；

指想要建的工程项目，或正在设想中的工程项

r目，或雅备麒留在tno阶段,

真画建摘殳吸

项目一拟建项目-

J前期、立项审批阶段的项目

r招标人（业主）一货物，工程期照的直接需求一方，就是采购方

一投标人（供应商）一出售产品提卿艮务的一方，就是销售方

角色

r（没资质的业主可资崩进行招标，分甲乙级）

J招标代理机构-

是依法从事招标代理业务并提供0照的社会中介

J组织,招标人有权自行选择招标领机受W

其办理招标事宜

标书：（阐明货物，数量，要求，招标代理，机

构联系人，联系方式）

就是通常需要投标方购买的标书。招标文件阐

明，需要采购货物或工程的性质，通报招标程序

将依据的规则和程序，告知订立合同的条件。招

_一招标文件—

文件标文件即是投标商编制投标文件的依据，又是采

购人与中标商签定合同的基础.因此，招标文件

在整个采购过程中起着至关重要的作用。

打圻立吩_投标人通过招标刈怖写的标书，应与招标文件

为——对应的关系.,二个当克效♦据♦-

对于整个流程的梳理和业务了解后，客户更加关注流程的监管预警，以此为

准整理一些监管维度：

o中场率（lumuRix,并不做利»）

O信网期助有行政处罚不以行为■1^

O投惊人被於（*6审查不合格）身风险

QWft✓----------------

------------<❶埠、分nsftg

o4个侬段就建出现住一■目fiXM

位负费人为同一人或者尊询《.

ARM

n保证金赅0USIO子翻与）・T1.幻剧公8SH

U»（BS

0城0*0/不同供应而第应答件9金从同一.位或行个人的

、它幡出

O投诉时不用段标单位百同个发名人颓

供应商0发标过程不同桎标♦&**同个流人tt必死人信息

c投蟠哲广谈生应机《制（fi-RMHWft）（M

题印#标分析"警傀团围好便融）

O上传及贿文向P磔t一«

OJSfiiWBit-W

O行文付

型空ne蚁厦（关做技术环书is似度砌比对技术为m讨论

离要tt®相i3s•大

＞，不向侯戚Mt丽一电位q者个人办函s省事宜

©不归leyfiiws谷文件曲网一年0或者今人n»i

O开标丰利礴开标后投标文件未•际ARM

三丹炳未发（列表）

数据应用指标O附区公钙详频不及公自✓--------

-------------------------------R啊

1所文洋方Wig不停卜于5日恪标学tfff司

的鼓山附同不旭少于公俗•餐竽团承均按去

16标仰U金白效潮可在口懵台考

出中标第・为日.退主中腌沏anm证金

\第保证金/--------------------------------------------

\-------------、毋8上传，退中^俄应Q箕证金

招标方（采购人）

c将标人在昭怀文件中■未投惊人提交豉蟒育证金的,投标停

9试金郎3闻应当与检蜥右一找.

O是否耐到场

0天正当理由改叠中俪结娱

o!?«&/）评分倒移”于3%«ro»

•利婚》ns专家处m公色厚不

❸救：EI80专京不出有于三分之一二三也明无缴据缰沏

二、逻辑模型设计

逻辑模型采用上一篇博文提及的维度建模模型，雪花模型，项目ID,投标人

ID、招标人ID、代理机构ID、专家ID分别是整个招、投、开、评、定标流

程的主要参与主体，数据抽取工具使用kettle:

数据表命名规范：tb_模型层次一主题域一业务域J匚总粒度

kettle命名规范：kt一模型层次.主题域一业务域.汇总粒度

三、物理模型设计

构建ODS—>DWD—>DWS—>ADS的分层模型，这里ODS只抽取oracle

库中源数据，不做任何清洗和变动，DWD层开始做数据的清洗和数据工

程，DWS作轻度汇总，ADS面向应用查询提供更上层的汇总；以项目和供

应商的汇总维度为例，项目流程是模型设计主体，供应商是类似维度表的数

据，两者结合能够得到业务需要的一些投/中标相关的汇总维度（比如中标率

排行、某个项目的投标人的注册金额相关统计、某投标人参与投标相关统计

等）：

曲口TB_DWD_XM_GYSZBJG_DAY

由-口TB_DWD_XM_ZBJG_DAY

由…口TB_DWD_ZT_GYSBM_DAY

由-口TB_DWD_ZT_GYSIP_DAY

TB_DWD_ZT_GYSXY_DAY

至口TB_DWS_XM_XMJBXX_DAY_

ffi□TB_DWS_ZB_YJXX_DAY

$•••□TB_DWS_ZT_GYSHZ_DAY

6）口TB_DWS_ZT_GYSJC_DAY

由..留TB_ODS_XM_ZBJG_DAY

由-口TB_ODS_ZB_YJXX_DAY

由-口TB_ODS_ZT_GYSBM_DAY

由一口TB_ODS_ZT_GYSIP_DAY

由-口TB_ODS_ZT_GYbiGdA隹羽沅

在项目流程表中（定标流程），将招标人的编号设计在内，定标流程的统计

项从该类ADS汇总维度出结果：

TB_DVD_XM_GYSZBJG_DAY

IDvaxchar(32)

招标记录idvaxchaz(32)

项自芬应int(2)

包名称varchax(2000)

供应商编号vaxchaz(32)

中标金额varchar(32)

是否中标vaxchar(32)

项目序号〈Undefined〉

定标状态〈Undefined)

操作时间<Un亡当次连初沅

m---

数据仓库的产品

前面讲了数据仓库的价值、构建思路、实例，完成数据仓库的概念、逻辑、

物理模型设计后，数仓的产品选型也是需要考虑的部分，根据数据存储量、

查询效率、并发能力可以选用MPP数仓和基于Hadoop的分布式数仓等。

一、MPP还是Hadoop

这里继续用之前用到的图讲解，数据仓库的特性是处理温数据和冷数据，面

向业务分析提供偏于离线分析能力,因此一般选用Hadoop+MPP数仓结合

的解决方法，Hive能够提供大批量历史数据的存储计算能力，Hbase能够提

供半结构化文档的快速检索能力，MPP能够提供强大高压缩比基础上的快速

查询能力；

I大数据时代分而治之的数据处理解决方案

传统事务型数据库新型MPP数据库

・处理热数据•处理数据

•传统事务型数据库适用于小数据量、・新型MPP数据库适合处理大规模的

业务逻辑复杂、并发度高的事务型复杂分析

业务场景

大数据平台

•处理冷数据

•Hadoop适合非结构化数据处理，流数据处理以及九规模批量作业

Hadoop

•sizefitsallBS■^不鳏了.林大雌平^用，遥瘫微歌舞

户提供整体大数据平台解决方案.

iggang

二、MPP数仓特性

在MPP解决方案中目前我已接触过的是vertica和GP,在teradata实习期

间没有用到td数仓;

JEMCGBASE,1DIADATA,Micmsott

SvKlsr

@GreenplumGBdSC8aIQ1ERADMA眇江光^

数仓的特性是大批量的查询和索引，少量的改查工作，MPP(Massively

ParallelProcessing),即大规模并行处理数据库的一般特性：

①列式存储意味着高压缩比、高10能力、快速查询能力、智能索引(数据

写入时)；

②sharednothing意味着节点的相互独立、数据的冗余备份；

③分布式存储/计算、存储/计算的高扩展性、高安全；

MPP的架构分为3种，GP是master/slave模式，具备统一的查询入口

(master),vertica是无中心架构，所有节点都提供查询服务，gbase是