数据仓库解决方案

数据仓库解决方案

本文主要讨论数据仓库的构建方法论，包括数据仓库的价值、选型、构建思

路。随着数据规模膨胀和业务复杂度的提升，大型企业需要构建企业级的数

据仓库（数据湖）来快速支撑业务的数据化需求，与传统的数据库构建不通，

数据仓库即是OLAP场景，偏于历史数据的存储/分析，用冗余存储换取数据

价值。

01数据仓库与数据库的区别

所有的应用系统都会涉及到数据库，针对数据库归纳和存放，也就是数据库

的常见操作：增、删、改、查，那么为什么想要对企业数据进行分析，不能

直接查询数据库，非要大费力气的去创建所谓的数据仓库和数据湖呢？

数据仓库主要是为了能够支持管理决策，而数据库是为了满足系统的及时性、

一致性。

好比你去银行存钱，你希望刚把钱存进去就能够查询到余额增加，你不希望

第二天才能够确认，但是若是银行想对你的流水和余额进行分析，这个时候

希望知道你在不同时期的银行余额，那么从数据库里是查不到你的历史余额

信息的，因为数据库在设计的时候就需要满足一定的范式，为的就是满足及

时性和去冗余，一个客户对应的余额只有一个，你在存款的时候，新的余额

就会覆盖掉老的余额，所以你的历史信息在数据库中是没有记录的。

如果银行希望查询客户的历史信息，比如说你需要查询个人客户信息，他可

能在柜台交易系统中有记录，也可以在网上银行交易系统也有记录，而你希

望查询客户柜台交易信息以及网银交易信息，这个时候需要跨系统查询，有

可能两个系统所使用的数据库都不一样，各自权限负责人员也不一样，跨系

统查询显得非常困难，这个时候需要一个系统能够将所有业务系统的数据汇

总起来并能够跨系统查询，这个时候数据仓库定义中的集成的，反映历史变

化的正好解决了此问题，数据库和数据仓库的对比。

其中OLTP(On-LineTransactionProcessing)指的是传统的关系型数据

库，针对实时业务处理，面对的主要操作是随机读写，采用满足三范式的实

体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题。

而OLAP(On-LineAnalyticalProcessing)系统面向数据批量读写，OLAP

不关注事务处理的一致性，主要在数据的整合，以及复杂大数据查询和处理

性能，OLAP能够支持复杂的分析操作。

区分维度OLTP

用户操作人员、低级管理人员决策人

功能日常查询决策支

DB设计面向应用、事务驱动面向主

历史的

数据特征当前状态的、实时更新的、二维的数据

数据

读写数据量小、频繁的DML操作、面向大读写数

查询特性

规模并发查询、延迟低杂的查

用户数上千个上百个

数据规模GB级别TB级别

综上，数据库的设计是为了完成交易而设计的，不是为了而查询和分析的便

利设计的。而数据仓库是为了大量的查询和分析所设计的。

02数据仓库对于企业的价值

数据仓库能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提

供统一的数据支持，从根本上把运营数据转化成为高价值的可以获取的信息

（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的

人。

数据仓库定义：面向主题的(SubjectOriented)、集成的(Integrate)、

相对稳定的(Non-Volatile),反映历史变化(TimeVariant)的数据集合;

面向主题：是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、

客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组

织的，而不是像业务支撑系统那样是按照业务功能进行组织的。

集成的：是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而

是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个

企业的一致的全局信息。

反映历史变化：数据仓库内的信息并不只是反映企业当前的状态，而是记录

了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发

展历程和未来趋势做出定量分析和预测。

如下图，数据仓库并非是面向生产的数据系统，而是集成并加工了多个数据

库系统数据，并面向各个业务条线构建的数据存储体系，能够提供快速的运

营/决策支撑能力。

源系统数据仓库

基础数据层数据，市

K«y«

舍户关系错理i心”

财力主普产只支・

数幅堂市

数

公

板义工・

据

SP£»共访问

«r«3i«机构靖效考核««

缓

汇数“集市

总

冲次氧主星

履

区收入分析

ttKxe-fWiUR

故我避供叫约

内凝丽

±fl利啪即

数照装＜2

高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具。

主要用于历史性、综合性和深层次数据分析。

数据来源是ERP（例:SAP）系统或其他业务系统。

能够提供灵活、直观、简洁和易于操作的多维查询分析。

不是日常交易操作系统，不能直接产生交易数据。

分析

•分析企必喇的你1壁所在

•分析企业内部运量的状况和

•分析企业外部市场变化

价值

晌应

•监视”和计■标准•出邮刊后实用n况对比

•密•近事林和历史收据相•遂行弹窝和壮丹分析

关联

•制定及时的应对策咯

数据仓库系统能够为企业的数据化提供:

送轻业务系统的压力

快速为决策者提供企业授曹11思

>等关司1Vmit9m8的企fu猊>的的覆询《进京”8»作.修工"*京

■可R的数据满足快速开发描去的需求

>MSHtifi好后KF9冽发快

>**«i+iJW449m«

统一wrn计口役

>.3K«ie«SSHMKfWBBWHKR>EF号依MglJfi.G企蛔3tift

w.充险计入熨工作.

企业全局信息

>5登第氟蜿中的故it.，长E历ML嗖嬲辱玩

>费供.的》.我方eaaur第分研

03数据仓库的模型构建

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

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

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

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

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

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

是否有问题。

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

设计规范等。

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

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

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

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

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

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

统一企业的数据视图。

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

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

支持数据仓库的发展规划。

初始化业务数据的归属。

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

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

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

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

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

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

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

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

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

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

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

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

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

用片表

网用户ID

订单表用户名

SS订单ID用户性别

购买者ID

商家ID商委表

商品ID3S商家ID

时间ID

商家名称

地址ID

商家地址

订单金额

地址表

地址ID

国

省

市

详细地址

工”据事

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

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

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

order

asid

user_name

user_sex

user_phone

user_email

product_name

product_desc

store_name

store_address

store_country

store_province

date

time_stamp

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

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

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

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

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）和面向

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

04案例：招标采购系统的数据仓库构建

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

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

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

一、概念模型设计

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

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

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

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

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

相关的数据：

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

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

标保证金。

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

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

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

清公告。

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

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

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

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

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

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

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

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

若质疑生效则可能废标和流标（评标成本高，一般不废标）。

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

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

有中标单位的保证金。

工程项目，螃在设想中的工程项

r目，或是准备要建但是还只是停留在计划阶段,

真正的建设活动还没开始。

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

「招标人（业主）一货物，工程或服务的直接需求一方，就是

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

角色

「（没资质的业主可委托他进行招标，分甲乙

是依法从事招标代理业务并提供8艮务的社会

L组织。招标人有权自彳谨择招标代理机

其办理招标事宜

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

构联系人，联系方式）

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

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

--招标文件一盘的规则和程序，告知订立合同的条件。招

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

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

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

投标人通过招标文件编写的标书，应与招标文件

为—对应的关系。Tl涉"w

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

准整理一些监管维度。

❶中标率（以数螃展现,并不做判断）

数据应用指标O预中标公告评析

招标文件发作期不得小于5日

报名截止时间不能少于公告

时间指标投标保证金有效期可;

出中标结娱

退保证金j-------------

---------合同上传一

招标方（采购人）

c雄标人在据株文件中要求投I

“证金有效期应当与投标有效1

❶是否按时到场

O无正当理由改变中标结果

O评审能力评分偏移度高于3%低风险

专家

O不良行为同名专家处m公告提示

二、逻辑模型设计

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

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

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

数据表命名规范：tb一模型层次.主题域一业务域.汇总粒度

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

=,物理模型设计

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

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

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

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

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

某个项目的投标人的注册金额相关统计、某投标人参与投标相关统计等）.

£.□

:.

□TB_DWD_XM_GYSZBJG_DAY

(a:-

.□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_

(±:)-□TB_DWS_ZB_YJXX_DAY

a-:□TB_DWS_ZT_GYSHZ_DAY

(±.:)-□TB_DWS_ZT_GYSJC_DAY

(±.:)-□TB_ODS_XM_ZBJG_DAY

(±)-TB_ODS_ZB_YJXX_DAY

…□

TB_ODS_ZT_GYSBM_DAY

S:.-□

TB_ODS_ZT_GYSIP_DAY

GE.:)-□

S-TB_ODS_ZT_GYbt/衣卷粉沅

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

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

TB_DWD_XM_GYSZBJG_DAY

varchax(32)

招标记录idvaxchax(32)

项自分应int(2)

供应高编号varchax(2000)

vazchar(32)

varchar(32)

vaxchax(32)

〈Undefined〉

〈Undefined)

05数据仓库产品

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

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

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

一、MPP还是Hadoop?

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

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

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