数据仓库的基本架构

数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策支持(Decision-Support)。其实数据仓库本身并不“生产”任何数据,同时自身也不需要“消费”任何的数据,数据来源于外部,并且开放给外部应用,这也是为什么叫“仓库”,而不叫“工厂”的原因。因此数据仓库的基本架构主要包含的是数据流入流出的过程,可以分为三层——源数据、数据仓库、数据应用:

从图中可以看出数据仓库的数据来源于不同的源数据,并提供多样的数据应用,数据自上而下流入数据仓库后向上层开放应用,而数据仓库只是中间集成化数据管理的一个平台。

数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL(抽取Extra, 转化Transfer, 装载Load)的过程,ETL是数据仓库的流水线,也可以认为是数据仓库的血液,它维系着数据仓库中数据的新陈代谢,而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。

下面主要简单介绍下数据仓库架构中的各个模块,当然这里所介绍的数据仓库主要是指网站数据仓库。

数据仓库的数据来源

其实之前的一篇文章已经介绍过数据仓库各种源数据的类型——数据仓库的源数据类型,所以这里不再详细介绍。

对于网站数据仓库而言,点击流日志是一块主要的数据来源,它是网站分析的基础数据;当然网站的数据库数据也并不可少,其记录这网站运营的数据及各种用户操作的结果,对于分析网站Outcome这类数据更加精准;其他是网站内外部可能产生的文档及其它各类对于公司决策有用的数据。

数据仓库的数据存储

源数据通过ETL的日常任务调度导出,并经过转换后以特性的形式存入数据仓库。其实这个过程一直有很大的争议,就是到底数据仓库需不需要储存细节数据,一方的观点是数据仓库面向分析,所以只要存储特定需求的多维分析模型;另一方的观点是数据仓库先要建立和维护细节数据,再根据需求聚合和处理细节数据生成特定的分析模型。我比较偏向后面一个观点:数据仓库并不需要储存所有的原始数据,但数据仓库需要储存细节数据,并且导入的数据必须经过整理和转换使其面向主题。简单地解释下:

(1).为什么不需要所有原始数据?数据仓库面向分析处理,但是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。比如我们知道用户的省份、城市足够,至于用户究竟住哪里可能只是物流商关心的事,或者用户在博客的评论内容可能只是文本挖掘会有需要,但将这些冗长的评论文本存在数据仓库就得不偿失;

(2).为什么要存细节数据?细节数据是必需的,数据仓库的分析需求会时刻变化,而有了细节数据就可以做到以不变应万变,但如果我们只存储根据某些需求搭建起来的数据模型,那么显然对于频繁变动的需求会手足无措;

(3).为什么要面向主题?面向主题是数据仓库的第一特性,主要是指合理地组织数据以方面实现分析。对于源数据而言,其数据组织形式是多样的,像点击流的数据格式是未经优化的,前台数据库的数据是基于OLTP操作组织优化的,这些可能都不适合分析,而整理成面向主题的组织形式才是真正地利于分析的,比如将点击流日志整理成页面(Page)、访问(Visit或Session)、用户(Visitor)三个主题,这样可以明显提升分析的效率。

数据仓库基于维护细节数据的基础上在对数据进行处理,使其真正地能够应用于分析。主要包括三个方面:

数据的聚合

这里的聚合数据指的是基于特定需求的简单聚合(基于多维数据的聚合体现在多维数据模型中),简单聚合可以是网站的总Pageviews、Visits、Unique Visitors等汇总数据,也可以是Avg. time on page、Avg. time on site等平均数据,这些数据可以直接地展示于报表上。

多维数据模型

多维数据模型提供了多角度多层次的分析应用,比如基于时间维、地域维等构建的销售星形模型、雪花模型,可以实现在各时间维度和地域维度的交叉查询,以及基于时间维和地域维的细分。所以多维数据模型的应用一般都是基于联机分析处理(Online Analytical Process, OLAP)的,而面向特定需求群体的数据集市也会基于多维数据模型进行构建。

业务模型

这里的业务模型指的是基于某些数据分析和决策支持而建立起来的数据模型,比如我之前介绍过的用户评价模型、关联推荐模型、RFM分析模型等,或者是决策支持的线性规划模型、库存模型等;同时,数据挖掘中前期数据的处理也可以在这里完成。

数据仓库的数据应用

之前的一篇文章——数据仓库的价值中介绍过数据仓库的四大特性上的价值体现,但数据仓库的价值远不止这样,而且其价值真正的体现是在数据仓库的数据应用上。图中罗列的几种应用并未包含所有,其实一切基于数据相关的扩展性应用都可以基于数据仓库来实现。

报表展示

报表几乎是每个数据仓库的必不可少的一类数据应用,将聚合数据和多维分析数据展示到报表,提供了最为简单和直观的数据。

即席查询

理论上数据仓库的所有数据(包括细节数据、聚合数据、多维数据和分析数据)都应该开放即席查询,即席查询提供了足够灵活的数据获取方式,用户可以根据自己的需要查询获取数据,并提供导出到Excel等外部文件的功能。

数据分析

数据分析大部分可以基于构建的业务模型展开,当然也可以使用聚合的数据进行趋势分析、比较分析、相关分析等,而多维数据模型提供了多维分析的数据基础;同时从细节数据中获取一些样本数据进行特定的分析也是较为常见的一种途径。

数据挖掘

数据挖掘用一些高级的算法可以让数据展现出各种令人惊讶的结果。数据挖掘可以基于数据仓库中已经构建起来的业务模型展开,但大多数时候数据挖掘会直接从细节数据上入手,而数据仓库为挖掘工具诸如SAS、SPSS等提供数据接口。

元数据管理

元数据(Meta Date),其实应该叫做解释性数据,即数据的数据。主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元数据资料库(Metadata Repository)来统一地存储和管理元数据,其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。

最后做个Ending,数据仓库本身既不生产数据也不消费数据,只是作为一个中间平台集成化地存储数据;数据仓库实现的难度在于整体架构的构建及ETL的设计,这也是日常管理维护中的重头;而数据仓库的真正价值体现在于基于其的数据应用上,如果没有有效的数据应用也就失去了构建数据仓库的意义。

» 本文采用 BY-NC-SA 协议,转载请注明来源:网站数据分析 » 《数据仓库的基本架构》

时间: 2014-12-19

数据仓库的基本架构的相关文章

专家解读微软并行数据仓库

微软并行数据仓库(Parallel Data Warehouse,简称PDW)去年同SQL Server 2008 R2一同发布,该产品设计初衷是为了同Oracle Exadata和Teradata等展开竞 争.PDW真正意义上实现了混合工作负载的能力,用户可以在使用熟悉的SQL Server数据库引擎的情况下,将数据从多个物理服务器上进行扩展. 并行 数据仓库并不是一款软件系统产品,在购买之后你不能简单地将其安装在硬件上 .PDW最基本的配置是双机架,其中一个机架是管理服务器,作为管理节点.控

如何提高SQL Server数据仓库性能

数据仓库通常是企业内部最大的数据库了.构建和管理系统是项大的任务,这些项目会由于众多用户提供的不兼容的输入而很快变得难以控制.提高系统的查询性能是可以实现的,但是必须要经过周密计划,随后还有具有远见的设计和开发阶段.在这篇文章中,我们将会列出获得并且为性能需求计划的一些技术,然后我们会在SQL Server上提高你的数据仓库性能. 需求 对于需要支持数百个GB到几个TB的数据系统而言,性能永远不会是你需要考虑的最后一件事情.当你收集数据仓库需求的时候,你就会被训练掌握用户性能需求的规则了.基于这

胖子哥的大数据之路(一)-数据仓库也需要大数据

一.楔子 大数据传统企业实施,其路漫漫,绝不会如昙花一现,探索大数据在传统行业的实施之路,寻找一条适合传统行业的企业大数据实施方法体系,是我执着坚守的信念,大数据是一种信仰,吾将上下而求索.记下项目中的点滴,算是日志,自勉. 二.项目背景 最近在处理一个商业银行的大数据项目,旨在构建大数据资源池,项目边界确认过程中,针对项目的定位出现了两种不同的观点,对大数据的在传统行业的应用有了新的启发.观点一.大数据作为操作数据历史库,存储操作数据库数据,提供历史数据长周期,快速检索的历史数据存储和快速查询

数据仓库专题(1)-数据仓库生命周期模型

一.前言 工作内容的变更,导致重新回到数据仓库模型的架构和设计,于是花点时间比较系统的回顾数据仓库建模和系统建设的知识体系,记录下来,作为笔记吧. 二.模型 无论数据仓库技术如何变化,从RDBMS到NoSQL,从传统技术到大数据,其实只是实现技术手段的变化,数据仓库建设生命周期的模式从来都不曾真正颠覆性改变过.向前辈致敬.下图是The Kimball Lifecycle diagram中文版本: 三.未完待续 后续考虑根据项目的实施,分环节,从实践角度,记录分享点滴,算是我的工作笔记吧. 另外项

数据仓库的一些理解(原创)

概述 数据仓库概念创始人W.H.Inmon在<建立数据仓库>一书中对数据仓库的定义是:数据仓库就是面向主题的.集成的.相对稳定的.随时间不断变化(不同时间)的数据集合,用以支持经营管理中的决策制定过程.数据仓库中的数据面向主题,与传统数据库面向应用相对应. 主题导向(Subject-Oriented) 主题是一个在较高层次上将数据归类的标准,每一个主题对应一个宏观的分析领域.有别于一般OLTP系统,数据仓库的资料模型设计,着重将资料按其意义归类至相同的主题区(subject area),因此称

[转载]聊聊Greenplum的那些事

原文   http://dbaplus.cn/news-21-341-1.html 聊聊Greenplum的那些事 李巍 2016-04-01 14:15:00 1024   开卷有益--作者的话    有时候真的感叹人生岁月匆匆,特别是当一个IT人沉浸于某个技术领域十来年后,蓦然回首,总有说不出的万千感慨.   笔者有幸从04年就开始从事大规模数据计算的相关工作,08年作为Greenplum 早期员工加入Greenplum团队(当时的工牌是"005",哈哈),记得当时看了一眼Gree

四大银行的CIO们如何看待大数据

1.银行压力越来越大 从十二五走到十三五期间,银行业面临的各方面的压力越来越大,从我们的年报数字可以看出去年四大行的利润增长基本上趋近于零增长.在这样的情况下,我们怎样通过IT的引领提升传统银行的竞争力,这是摆在我们面前的一个很重要的课题. 2.过去十多年期间,银行业务出现两个拐点 大数据怎么样能够在智慧银行的方向上起到更大的作用呢? 通过银行的历程佐证这样一个观点.过去十多年期间银行基本上有两个拐点: 第一个拐点就是发生在互联网银行慢慢取代柜员,IT支持从支持几万十几万的柜员到支持面向所有的互

Microsoft 数据仓库架构 !

架构|数据 Microsoft 数据仓库架构 摘要:本文简单介绍了使用 Microsoft 数据仓库架构的数据仓库,讨论了数据仓库能够实现的功能,使用数据仓库的恰当时机,以及如何将数据仓库与系统体系结构合成一体. 目录简介数据仓库作为数据仓库模型的立方体使用数据仓库进行决策查看立方体片段和编程接口Microsoft 数据仓库架构数据仓库的其他应用实现数据仓库易犯的错误总结简介1998 年发布的 7.0 版 Microsoft SQL Server 中已经包含数据仓库软件.如果您对数据仓库比较陌生

考虑两种数据仓库架构共存的可行性

在Google上搜索"Inmon和Kimball",你会和轻松地找到这两个名字的概念,它们是两种著名的数据仓库架构方式.然而在这信息的海洋中,你会发现几乎所有的内容几乎都能得出一个结论,那就是要在Bill Inmon和Ralph Kimball两者之间选择其一. 但是,"数据仓库之父"Bill Inmon却告诉我们,在一定的环境这下,其实这两种架构完全可以共存,且协作良好.对此,来自电力公司的BI系统架构师Bill Harrison表示:"两种架构都有各自

对比两种数据仓库设计架构

Bill Inmon和Ralph Kimball,在上学的时候接触到的两个名字,对于大多数人来说,这两个美国人显得有些陌生,但是在数据库领域,他们可是响当当的人物.Bill Inmon,被称为"数据仓库之父",现在可以在网上看到他大把大把的学术性论文和文章,Wikipedia上对他的介绍应该是非常全面的:在上世纪80年代,Inmon的<建立数据仓库>一书中定义了数据仓库的概念,随后又给出了更为精确的定义:数据仓库是在企业管理和决策中面向主题的.集成的.与时间相关的.不可修改