构建企业级数据仓库五步法

在上一期的专栏文章中,我们曾经提到:数据分析系统的总体架构分为四个部分 —— 源系统、数据仓库、多维数据库、客户端(图一:pic1.bmp)

其中,数据仓库(DW)起到了数据大集中的作用。通过数据抽取,把数据从源系统源源不断地抽取出来,可能每天一次,或者每3个小时一次(当然是自动的)。这个过程,我们称之为ETL过程。

那么,今天,我们就来谈一谈:如何搭建数据仓库,在这个过程中都应该遵循哪些方法和原则;然后介绍一些项目实践中的技巧。

一、数据仓库的架构

数据仓库(Data Warehouse DW)是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库,它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题的,以OLAP系统的分析需求为目的。

数据仓库的架构模型包括了星型架构(图二:pic2.bmp)与雪花型架构(图三:pic3.bmp)两种模式。如图所示,星型架构的中间为事实表,四周为维度表,类似星星;而相比较而言,雪花型架构的中间为事实表,两边的维度表可以再有其关联子表,从而表达了清晰的维度层次关系。

从OLAP系统的分析需求和ETL的处理效率两方面来考虑:星型结构聚合快,分析效率高;而雪花型结构明确,便于与OLTP系统交互。因此,在实际项目中,我们将综合运用星型架构与雪花型架构来设计数据仓库。

那么,下面我们就来看一看,构建企业级数据仓库的流程。

二、构建企业级数据仓库五步法

(一)、确定主题

即确定数据分析或前端展现的主题。例如:我们希望分析某年某月某一地区的啤酒销售情况,这就是一个主题。主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑。

我们可以形象的将一个主题想象为一颗星星:统计数值型数据(量度)存在于星星中间的事实表;分析角度(维度)是星星的各个角;我们将通过维度的组合,来考察量度。那么,“某年某月某一地区的啤酒销售情况”这样一个主题,就要求我们通过时间和地区两个维度的组合,来考察销售情况这个量度。从而,不同的主题来源于数据仓库中的不同子集,我们可以称之为数据集市。数据集市体现了数据仓库某一方面的信息,多个数据集市构成了数据仓库。

(二)、确定量度

在确定了主题以后,我们将考虑要分析的技术指标,诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总,或者将该数据取次数、独立次数或取最大最小值等,这样的数据称为量度。

量度是要统计的指标,必须事先选择恰当,基于不同的量度可以进行复杂关键性能指标(KPI)等的设计和计算。

(三)、确定事实数据粒度

在确定了量度之后,我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况。考虑到量度的聚合程度不同,我们将采用“最小粒度原则”,即将量度的粒度设置到最小。

例如:假设目前的数据最小记录到秒,即数据库中记录了每一秒的交易额。那么,如果我们可以确认,在将来的分析需求中,时间只需要精确到天就可以的话,我们就可以在ETL处理过程中,按天来汇总数据,此时,数据仓库中量度的粒度就是“天”;反过来,如果我们不能确认将来的分析需求在时间上是否需要精确到秒,那么,我们就需要遵循“最小粒度原则”,在数据仓库的事实表中保留每一秒的数据,以便日后对“秒”进行分析。

在采用“最小粒度原则”的同时,我们不必担心海量数据所带来的汇总分析效率问题,因为在后续建立多维分析模型(CUBE)的时候,我们会对数据提前进行汇总,从而保障产生分析结果的效率。关于建立多维分析模型(CUBE)的相关问题,我们将在下期栏目中予以阐述。

(四)、确定维度

维度是指分析的各个角度。例如我们希望按照时间,或者按照地区,或者按照产品进行分析,那么这里的时间、地区、产品就是相应的维度。基于不同的维度,我们可以看到各量度的汇总情况,也可以基于所有的维度进行交叉分析。

这里我们首先要确定维度的层次(Hierarchy)和级别(Level)(图四:pic4.bmp)。如图所示,我们在时间维度上,按照“年-季度-月”形成了一个层次,其中“年”、“季度”、“月”成为了这个层次的3个级别;同理,当我们建立产品维度时,我们可以将“产品大类-产品子类-产品”划为一个层次,其中包含“产品大类”、“产品子类”、“产品”三个级别。

那么,我们分析中所用到的这些维度,在数据仓库中的存在形式是怎样的呢?

我们可以将3个级别设置成一张数据表中的3个字段,比如时间维度;我们也可以使用三张表,分别保存产品大类、产品子类、产品三部分数据,比如产品维度。(图五:pic5.bmp)

    另外,值得一提的是,我们在建立维度表时要充分使用代理键。代理键是数值型的ID号码(例如图六中每张表的第一个字段),它唯一标识了每一维度成员。更重要的是,在聚合时,数值型字段的匹配和比较,JOIN效率高,便于聚合。同时,代理键对缓慢变化维度有着重要的意义,在原数据主键相同的情况下,它起到了对新数据与历史数据的标识作用。

在此,我们不妨谈一谈维度表随时间变化的问题,这是我们经常会遇到的情况,我们称其为缓慢变化维度。

比如我们增加了新的产品,或者产品的ID号码修改了,或者产品增加了一个新的属性,此时,维度表就会被修改或者增加新的记录行。这样,我们在ETL的过程中,就要考虑到缓慢变化维度的处理。对于缓慢变化维度,有三种情况:

1、缓慢变化维度第一种类型:历史数据需要修改。这种情况下,我们使用UPDATE方法来修改维度表中的数据。例如:产品的ID号码为123,后来发现ID号码错了,需要改写成456,那么,我们就在ETL处理时,直接修改维度表中原来的ID号码为456。

2、缓慢变化维度第二种类型:历史数据保留,新增数据也要保留。这时,要将原数据更新,将新数据插入,我们使用UPDATE / INSERT。比如:某一员工2005年在A部门,2006年时他调到了B部门。那么在统计2005年的数据时就应该将该员工定位到A部门;而在统计2006年数据时就应该定位到B部门,然后再有新的数据插入时,将按照新部门(B部门)进行处理,这样我们的做法是将该维度成员列表加入标识列,将历史的数据标识为“过期”,将目前的数据标识为“当前的”。另一种方法是将该维度打上时间戳,即将历史数据生效的时间段作为它的一个属性,在与原始表匹配生成事实表时将按照时间段进行关联,这种方法的好处是该维度成员生效时间明确。

3、缓慢变化维度第三种类型:新增数据维度成员改变了属性。例如:某一维度成员新加入了一列,该列在历史数据中不能基于它浏览,而在目前数据和将来数据中可以按照它浏览,那么此时我们需要改变维度表属性,即加入新的字段列。那么,我们将使用存储过程或程序生成新的维度属性,在后续的数据中将基于新的属性进行查看。

(五)、创建事实表

在确定好事实数据和维度后,我们将考虑加载事实表。

在公司的大量数据堆积如山时,我们想看看里面究竟是什么,结果发现里面是一笔笔生产记录,一笔笔交易记录… 那么这些记录是我们将要建立的事实表的原始数据,即关于某一主题的事实记录表。

我们的做法是将原始表与维度表进行关联,生成事实表(图六:pic6.bmp)。注意在关联时有为空的数据时(数据源脏),需要使用外连接,连接后我们将各维度的代理键取出放于事实表中,事实表除了各维度代理键外,还有各量度数据,这将来自原始表,事实表中将存在维度代理键和各量度,而不应该存在描述性信息,即符合“瘦高原则”,即要求事实表数据条数尽量多(粒度最小),而描述性信息尽量少。

如果考虑到扩展,可以将事实表加一唯一标识列,以为了以后扩展将该事实作为雪花型维度,不过不需要时一般建议不用这样做。

事实数据表是数据仓库的核心,需要精心维护,在JOIN后将得到事实数据表,一般记录条数都比较大,我们需要为其设置复合主键和索引,以实现数据的完整性和基于数据仓库的查询性能优化。事实数据表与维度表一起放于数据仓库中,如果前端需要连接数据仓库进行查询,我们还需要建立一些相关的中间汇总表或物化视图,以方便查询。

三、什么是ETL

在数据仓库的构建中,ETL贯穿于项目始终,它是整个数据仓库的生命线,包括了数据清洗、整合、转换、加载等各个过程。如果说数据仓库是一座大厦,那么ETL就是大厦的根基。ETL抽取整合数据的好坏直接影响到最终的结果展现。所以ETL在整个数据仓库项目中起着十分关键的作用,必须摆到十分重要的位置。

ETL是数据抽取(Extract)、转换(Transform)、加载(Load )的简写,它是指:将OLTP系统中的数据抽取出来,并将不同数据源的数据进行转换和整合,得出一致性的数据,然后加载到数据仓库中。例如:下图就向我们展示了ETL的数据转换效果。(图七:pic7.bmp)

那么,在这一转换过程中,我们就完成了对数据格式的更正、对数据字段的合并、以及新增指标的计算三项操作。类似地,我们也可以根据其他需求,完善数据仓库中的数据。

简而言之,通过ETL,我们可以基于源系统中的数据来生成数据仓库。ETL为我们搭建了OLTP系统和OLAP系统之间的桥梁。

 

五、项目实践技巧

(一)、准备区的运用

 在构建数据仓库时,如果数据源位于一台服务器上,数据仓库在另一台服务器端,考虑到数据源Server端访问频繁,并且数据量大,需要不断更新,所以可以建立准备区数据库(图八:pic8.bmp)。先将数据抽取到准备区中,然后基于准备区中的数据进行处理,这样处理的好处是防止了在原OLTP系统中频繁访问,进行数据运算或排序等操作。

例如我们可以按照天将数据抽取到准备区中,基于数据准备区,我们将进行数据的转换、整合、将不同数据源的数据进行一致性处理。数据准备区中将存在原始抽取表、转换中间表和临时表以及ETL日志表等。

(二)、时间戳的运用

时间维度对于某一事实主题来说十分重要,因为不同的时间有不同的统计数据信息,那么按照时间记录的信息将发挥很重要的作用。在ETL中,时间戳有其特殊的作用,在上面提到的缓慢变化维度中,我们可以使用时间戳标识维度成员;在记录数据库和数据仓库的操作时,我们也将使用时间戳标识信息。例如:在进行数据抽取时,我们将按照时间戳对OLTP系统中的数据进行抽取,比如在午夜0:00取前一天的数据,我们将按照OLTP系统中的时间戳取GETDATE到GETDATE减一天,这样得到前一天数据。

(三)、日志表的运用

在对数据进行处理时,难免会发生数据处理错误,产生出错信息,那么我们如何获得出错信息并及时修正呢? 方法是我们使用一张或多张Log日志表,将出错信息记录下来,在日志表中我们将记录每次抽取的条数、处理成功的条数、处理失败的条数、处理失败的数据、处理时间等等。这样,当数据发生错误时,我们很容易发现问题所在,然后对出错的数据进行修正或重新处理。

(四)、使用调度

在对数据仓库进行增量更新时必须使用调度(图九:pic9.bmp),即对事实数据表进行增量更新处理。在使用调度前要考虑到事实数据量,确定需要多长时间更新一次。比如希望按天进行查看,那么我们最好按天进行抽取,如果数据量不大,可以按照月或半年对数据进行更新。如果有缓慢变化维度情况,调度时需要考虑到维度表更新情况,在更新事实数据表之前要先更新维度表。

调度是数据仓库的关键环节,要考虑缜密。在ETL的流程搭建好后,要定期对其运行,所以调度是执行ETL流程的关键步骤。每一次调度除了写入Log日志表的数据处理信息外,还要使用发送Email或报警服务等,这样也方便的技术人员对ETL流程的把握,增强了安全性和数据处理的准确性。

五、总结

构建企业级数据仓库需要简单的五步,掌握了这五步的方法,我们可以构建一个强大的数据仓库。然而,每一步都有很深的内容需要研究与挖掘,尤其在实际项目中,我们要综合考虑。例如:如果数据源的脏数据很多,在搭建数据仓库之前我们首先要进行数据清洗,以剔除掉不需要的信息和脏数据。

ETL是OLTP系统和OLAP系统之间的桥梁,是数据从源系统流入数据仓库的通道。在数据仓库的项目实施中,它关系到整个项目的数据质量,所以马虎不得,必须将其摆到重要位置,将数据仓库这一大厦的根基筑牢! 

时间: 2024-10-08 23:44:17

构建企业级数据仓库五步法的相关文章

如何构建银行数据仓库

数据 如何构建银行数据仓库河南省邓州市新华东路11号市人行 宋玉长 数据仓库技术作为一项数据管理领域的新技术,其精髓在于针对联机分析处理(OLAP)提出了一种综合的解决方案,与以往很多技术不同的是,它主要是一种概念,在此概念指导下完成系统的构造.既没有可以直接购买到的现成产品,也没有具体的分析规范和实现方法,也就是说没有成熟.可靠且被广泛接受的数据仓库标准.在以往关系数据库的设计和实现中,不仅有详细的理论推导,还有无数的设计实例,无论你使用的是什么公司的数据库产品.开发工具,只要按照规范做,那么

支付宝体验设计精髓. 01 行业设计“五步法”

01 行业设计"五步法" 文/王宇航 随着"互联网+"的火热,越来越多的线下服务"搬"到线上,支付宝也提出了"连接3600行"的口号.设计师要在业务的快速推动与迭代中,快速接手新的行业线设计,必须理解产品背后的逻辑,对其所处的行业背景.商业模式和发展方向的研究保持足够的重视.但是往往一个项目设计的时间又是有限的,对于一个行业的理解也是需要时间沉淀与积累的,这就会产生一定的矛盾.所以动态并快速地使用一些设计策略是行之有效的. 我

《SOA与REST:用REST构建企业级SOA解决方案》目录—导读

献词 SOA与REST:用REST构建企业级SOA解决方案 谨以此书献给ChristophSchittko,他毫无顾忌的审阅评注使我们在本书书稿已经提交印刷之后仍然决定改变内容结构,而后续的变化极大地提升了书稿的质量. --Thomas Erl 献给亲爱的妻子Michelle,献给我的父母Rob和Sue,献给我的孩子Genevieve和Matthew.感谢你们多年来的支持与鼓励! --Benjamin Carlyle 献给我的家人及我的Esperanza. --Cesare Pautasso 向

如何构建企业级Hadoop/Spark分析平台

文章讲的是如何构建企业级Hadoop/Spark分析平台,一说大数据,人们往往想到Hadoop.这固然不错,但随着大数据技术的深入应用,多种类数据应用要求的不断提出,一些Hadoop不甚专注的领域开始被人们注意,相关技术也迅速获得专业技术领域的应用.最近半年来的Spark之热即是这样的一个典型. Spark是一个基于内存计算的开源集群计算系统,目的是更快速地进行数据分析. Spark由加州伯克利大学AMP实验室Matei为主的小团队使用Scala开发,早期核心部分的代码只有3万行,非常轻量级.S

用SQL-on-Hadoop构建互联网数据仓库与商务智能系统

大数据是现在非常热门的一个话题,SQL on Hadoop是目前大数据技术发展的一个重要方向,如何可以迅速的了解掌握这门技术,CSDN特地邀请梁堰波来为我们做这次讲座"用SQL-on-Hadoop构建互联网数据仓库与商务智能系统",通过对业务需求与SQL-on-Hadoop现状的分析,详细阐述SQL on Hadoop中各个技术点,分享一线的经验实践,帮助从业技术人员更快的掌握相关技术要点,少走弯路. 对于一个工程师或者分析师来说,如何查询和分析TB/PB级别的数据是在大数据时代不可回

DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践

本文讲的是DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践[编者的话]企业级容器化PaaS平台旨在为企业应用提供底层支撑能力,覆盖应用开发.应用交付.上线运维等环节,包括代码的管理.持续集成.自动化测试.交付物管理.应用托管.中间件服务.自动化运维.监控报警.日志处理等,本次分享主要介绍基于容器技术构建PaaS平台所采用的相关技术.涉及的核心功能模块以及相关方案. 为满足以上需求,MoPaaS企业版基于Cloud Foundry及Kubernetes等开源技术框架和智能

软件需求调研“五步法” 收藏

  软件需求调研"五步法" 收藏 摘要 客户需求,是软件生产加工的"原材料",是团队展开工作的"依据",是项目管理的"基石",需求调研是获取这此基础信息的启始阶段,良好开始是成功的一半.在需求调研分析阶段,项目经理和需求分析人员无法推动需求调研,客户参与积极性不高,获取客户需求信息不完整,且没有得到客户的认可.将决定能否奠定项目成功的保障,决定软件项目实施的成败.本文介绍"B项目"需求调研不深入所造成项目经

《SOA与REST:用REST构建企业级SOA解决方案》—第2章2.1节如何使用案例研究

第 2 章 案例研究背景 SOA与REST:用REST构建企业级SOA解决方案 2.1 如何使用案例研究 2.2 案例研究背景之一:中西部大学联盟(MUA) 2.3 案例研究背景之二:KioskEtc有限公司 2.1 如何使用案例研究 案例研究示例是在现实场景中探索抽象话题的有效手段.这一简短的章节根据背景资料建立起一个持续的故事情节.后续一些章节将以与本章中所描述场景相关的案例研究示例作为结束,为了更容易地识别这些部分,使用了浅灰色背景. 案例研究调查了两个组织的IT和业务环境.中西部大学联盟

Hadoop专业解决方案-第12章 为Hadoop应用构建企业级的安全解决方案

一.前言: 非常感谢Hadoop专业解决方案群:313702010,兄弟们的大力支持,在此说一声辛苦了,春节期间,项目进度有所延迟,不过元宵节以后大家已经步入正轨, 目前第12章 为Hadoop应用构建企业级的安全解决方案已经翻译完成,在此对:译者:杨有鹏 不莱梅狗  78280847 表示感谢. 二.意见征集: 本章节由<Hadoop专业解决方案群:313702010>翻译小组完成,为小组校验稿,已经通过小组内部校验通过,特此面向网络征集意见,如果对本章节内容有任何异议,请在评论中加以说明,