数据仓库建模与ETL实践技巧

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

一、数据仓库的架构

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

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

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

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

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

(一)、确定主题

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

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

(二)、确定量度

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

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

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

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

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

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

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

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

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

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

另外,值得一提的是,我们在建立维度表时要充分使用代理键。代理键是数值型的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)。注意在关联时有为空的数据时(数据源脏),需要使用外连接,连接后我们将各维度的代理键取出放于事实表中,事实表除了各维度代理键外,还有各量度数据,这将来自原始表,事实表中将存在维度代理键和

相关文档
最新文档