数据仓库的粗略发展历程.docx
- 文档编号:26465963
- 上传时间:2023-06-19
- 格式:DOCX
- 页数:12
- 大小:763.76KB
数据仓库的粗略发展历程.docx
《数据仓库的粗略发展历程.docx》由会员分享,可在线阅读,更多相关《数据仓库的粗略发展历程.docx(12页珍藏版)》请在冰豆网上搜索。
数据仓库的粗略发展历程
数据仓库的粗略发展历程及相关概念
1.1概述
数据仓库的概念可能比一般人想像的都要早一些,中间也经历比较曲折的过程。
其最初的目标是为了实现全企业的集成(EnterpriseIntegration),但是在发展过程中却退而求其次:
建立战术性的数据集市(DataMarts)。
到目前为止,还有很多分歧、论争,很多概念模棱两可甚至是彻底的让人迷惑。
本文试图从数据仓库的发展历史中看到一些发展的脉络,了解数据仓库应该是怎么样的,并展望一下未来的数据仓库发展方向。
同时,由于新应用的不断出现,出现了很多新的概念和新的应用,这些新的应用如何统一现成完整的企业BI应用方案还存在很多争论。
本文试图对这些概念做一些简要的阐述,让大家对此有初步的了解。
1.2粗略发展过程
1.2.1开始阶段(1978-1988)
数据仓库最早的概念可以追溯到20世纪70年代MIT的一项研究,该研究致力于开发一种优化的技术架构并提出这些架构的指导性意见。
第一次,MIT的研究员将业务系统和分析系统分开,将业务处理和分析处理分成不同的层次,并采用单独的数据存储和完全不同的设计准则。
同时,MIT的研究成果与80年代提出的信息中心(InformationCenter)相吻合:
即把那些新出现的、不可以预测的、但是大量存在的分析型的负载从业务处理系统中剥离出来。
但是限于当时的信息处理和数据存储能力,该研究只是确立了一个论点:
这两种信息处理的方式差别如此之大,以至于它们只能采用完全不同的架构和设计方法。
之后,在80年代中后期,作为当时技术最先进的公司,DEC已经开始采用分布式网络架构来支持其业务应用,并且DEC公司首先将业务系统移植到其自身的RDBMS产品:
RdB。
并且,DEC公司从工程部、销售部、财务部以及信息技术部抽调了不同的人员组建了新的小组,不仅研究新的分析系统架构,并要求将其应用到其全球的财务系统中。
该小组结合MIT的研究结论,建立了TA2(TechnicalArchitecture2)规范,该规范定义了分析系统的四个组成部分:
♦数据获取
♦数据访问
♦目录
♦用户服务
其中的数据获取和数据访问目前大家都很清楚,而目录服务是用于帮助用户在网络中找到他们想要的信息,类似于业务元数据管理;用户服务用以支持对数据的直接交互,包含了其他服务的所有人机交互界面,这是系统架构的一个非常大的转变,第一次将交互界面作为单独的组件提出来。
1.2.2全企业集成(EnterpriseIntergration,1988)
同时,IBM也在处理信息管理不同方面的问题,其最烦人的问题是不断增加的信息孤岛,IBM的很多客户要面对很多分立系统的数据集成问题,而这些系统有不同的编码方式和数据格式。
1988年,为解决全企业集成问题,IBM爱尔兰公司的BarryDevlin和PaulMurphy第一次提出了“信息仓库(InformationWarehouse)”的概念,将其定义为:
“一个结构化的环境,能支持最终用户管理其全部的业务,并支持信息技术部门保证数据质量”,并在1991年在DECTA2的基础上把信息仓库的概念包含进去,并称之为VITAL规范(virtuallyintegratedtechnicalarchitecturelifecycle),将PC、图形化界面、面向对象的组件以及局域网都包含在VITAL里,并定义了85种信息仓库的组件,包括数据抽取、转换、有效性验证、加载、Cube开发和图形化查询工具等。
但是IBM只是将这种领先的概念用于市场宣传,而没有付诸实际的架构设计。
这是IBM有一个领域上创新后停止不前导致丧失其领先地位。
因此,在90年代初期,数据仓库的基本原理、框架架构,以及分析系统的主要原则都已经确定,主要的技术,包括关系型数据存取、网络、C/S架构和图形化界面均已具备,只欠东风了。
同时,在1988年-1991年,一些前沿的公司已经开始建立数据仓库。
1.2.3企业级数据仓库(EDW,1991)
1991年,BillInmon出版了其有关数据仓库的第一本书,这本书不仅仅说明为什么要建数据仓库、数据仓库能给你带来什么,更重要的是,Inmon第一次提供了如何建设数据仓库的指导性意见,该书定义了数据仓库非常具体的原则,包括:
♦数据仓库是面向主题的(Subject-Oriented)、
♦集成的(Integrated)、
♦包含历史的(Time-variant)、
♦不可更新的(Nonvolatile)、
♦面向决策支持的(DecisionSupport)
♦面向全企业的(EnterpriseScope)
♦最明细的数据存储(AtomicDetail)
♦数据快照式的数据获取(SnapShotCapture)
这些原则到现在仍然是指导数据仓库建设的最基本原则,虽然中间的一些原则引发一些争论,并导致一些分歧和数据仓库变体的产生。
但是,BillInmon凭借其这本书奠定了其在数据仓库建设的位置,被称之为“数据仓库之父”。
1.2.4数据集市(1994-1996)
数据仓库发展的第一明显分歧是数据集市概念的产生。
由于企业级数据仓库的设计、实施很困难,使得最早吃数据仓库螃蟹的公司遭到大面积的失败,因此数据仓库的建设者和分析师开始考虑只建设企业级数据仓库的一部分,然后再逐步添加,但是这有背于BillInmon的原则:
各个实施部分的数据抽取、清洗、转换和加载是独立,导致了数据的混乱与不一致性。
而且部分实施的项目也有很多失败,除了常见的业务需求定义不清、项目执行不力之外,很重要的原因是因为其数据模型设计,在企业级数据仓库中,Inmon推荐采用3范式进行数据建模,但是不排除其他的方法,但是Inmon的追随者固守OLTP系统的3范式设计,从而无法支持DSS系统的性能和数据易访问性的要求。
这时,RalphKimball出现了,他的第一本书“TheDataWarehouseToolkit”掀起了数据集市的狂潮,这本书提供了如何为分析进行数据模型优化详细指导意见,从DimensionalModeling大行其道,也为传统的关系型数据模型和多维OLAP之间建立了很好的桥梁。
从此,数据集市在很多地方冒了出来,并获得很大成功,而企业级数据仓库已逐渐被人所淡忘。
1.2.5争吵与混乱(1996-1997)
企业级数据仓库还是部门级数据集市?
关系型还是多维?
BillInmon和RalphKimball一开始就争论不休,其各自的追随者也唇舌相向,形成相对立的两派:
Inmon派和Kimball派(有点象少林和武当,呵呵)。
在初期,数据集市的快速实施和较高的成功率让Kimball派占了上风,但是很快,他们也发现自己陷入了某种困境:
企业中存在6-7个不同的数据集市,分别有不同的ETL,相互之间的数据也不完全一致。
同时,各个项目实施中也任意侵犯了Inmon开始定下的准则:
把数据集市当成众多OLTP系统之后的有一个系统,而不是一个基础性的集成性的东西,为保证数据的准确性和实时性,有的甚至可以由OLTP系统直接修改数据集市里面的数据,为了保证系统的性能,有的数据集市删除了历史数据。
等等,不一而足。
当然,这导致了一些新的应用的出现,例如ODS,但是人们对DataWarehouse、DataMart、ODS的概念非常的模糊,经常混为一谈。
有人说OLAP就是数据仓库,也有人说我要ODS和DataMart,不要Datawarehouse,也有人说,我DataMart建多了,自然就有DataWarehouse了。
但是BillInmon一直很旗帜鲜明:
“你可以打到几万吨的小鱼小虾,但是这些小鱼小虾加起来不是大鲸鱼”
1.2.6合并(1998-2001)
经过多翻争吵,证明one-size-fits-all是不可能的,你需要不同的BI架构来满足不同的业务需求。
BillInmon也推出了新的BI架构CIF(Corporationinformationfactory),把Kimball的数据集市也包容进来了,第一次,Kimball承认了Inmon,但是仍然还有很多人在争论是自顶向下,还是自底向上。
CIF的核心思想是把整个架构分成不同的层次以满足不同的需求,把DW、DM、ODS进行详细的描述。
现在CIF已经成为建设数据仓库的框架指南。
1.2.7未来?
?
但是数据仓库未来会怎么发展呢,有人说是RealTimeDW(byMichaelHaisten)。
但是从其历史发展过程来看,几个趋势是比较明显的:
♦从战略决策到战术决策的发展:
这对DW的实时性和可获得性(availability)有更高的要求,甚至要求7×24×365
♦需求更加多样化,要求有不同的架构和应用层次以适应不同的需求
♦数据量膨胀,对数据建模、数据组织和层次划分提出更高的要求。
从EDW到DM,又有ODS、RTDW、ExplorationDataWarehouse等等,同时新的应用层出不穷,看来DW/BI的未来是热热闹闹的。
。
1.3战术决策支持系统
数据仓库从一开始是定位在面向高层管理者、进行战略决策支持的,而随着应用的发展,要求中层管理者甚至底层的一线操作者也能分享数据仓库的功能。
例如客服人员在接听客户电话的同时能查看到该客户的完整历史信息、该客户的偏好信息、根据其客户情况目前能提供的促销信息等等。
即运营系统与决策支持系统将不再是完全隔离的两个系统,而是要求二者之间能相互共享有用的信息。
1.3.1战术决策支持系统的交互方式
运营系统和DW/DSS系统的交互方式可以有两种:
直接交互和间接交互。
●直接交互
直接交互虽然在表面上很直观,但是有很多限制的地方:
1.数据仓库的查询反应速度是比较长的,很难满足运营系统的时间要求,特别是对那些比较随机的查询,其反应时间超过好几分钟,甚至上小时。
2.得到的数据量可能是比较大的,增加了网络的负担
3.从数据仓库得到的数据格式、数据含义等与运营系统有差距,需要某种数据置换和加载过程(与数据仓库建设的ETL区分,可以称之为反向ETL)
这些问题使得由运营系统直接访问数据仓库系统变动不切实际,在现实世界中也很少有这样的系统建设。
●间接交互
间接交互中,通过分析系统计算出该客户能得到的折扣是最重要的组成部分,他需要综合当前的运营数据(运营系统)和历史消费信息(数据仓库)。
通常来说,这部分计算要求的数据量和计算时间超过了运营系统能承受的范围,一般是在机器空闲的时候在夜间先行计算的。
这种间接交互的分析型应用可以存在很多行业的众多应用,例如银行信贷系统的动态评级、电话销售时的客户细分和促销、航空定票的动态定价、生产系统的动态生产计划制定与调整等等。
1.3.2战术决策支持系统的系统架构
战术决策支持系统与传统的数据仓库相比有更高的要求:
1.更快的响应速度:
在几分钟甚至几十秒之内得到结果,这要求有相应的数据结构设计和调优工作,以及对各种不同类型的操作进行优先级管理,以保证战术决策支持分析的SLA
2.更频繁的数据更新:
要求实时或者准实时的ETL过程,以保证数据的准确性和时效性
3.更高的数据精度:
战略决策对数据精度要求较低,只是要求一个大概的趋势,而战术决策要求很高的精度,经常是100%,相应对ETL提出更高的要求
4.更强的数据可获得性:
运营系统一般要求7*24小时运作,相应地要求战术决策支持系统有相同的可获得性,因此留给ETL、分析预计算的时间窗口就会很小,甚至要求的并行的。
因此,战术决策支持系统要求与传统的数据仓库有不同的系统架构和设计方法。
目前还没有比较权威的方法得到大家的普遍认可,目前我看到有两种方法相互争论,不过还没有更多的案例来证明这两种方法的优劣。
1.3.2.1ODS+DW
ODS是为了弥补业务系统和数据仓库之间的差距而提出的,解决的是这种问题:
“对一个特定的业务流程来说,我怎么才能提供最新的、跨功能部门之间的信息”,例如对客户服务人员,他需要销售、库存、市场和研发等各部门的最新数据,而这些数据原来是分散在不同部门的不同应用系统的。
如果通过数据仓库来实现数据集成,则实时性难以保证,或者建设成本很高。
同数据仓库类似,ODS也是面向主题的、集成的,但是其最大特点是数据是可更新的,甚至由业务系统通过触发器直接更新。
因此,ODS是业务系统和DW之间更偏向业务系统的东东。
根据ODS的更新策略,可以将ODS分为三类:
这三类ODS可以和DW形成互补的整体,构成完整的战术决策支持系统架构
需要注意的是,数据抽取,要么抽取到ODS中,要么到DW中,不能同时都抽取,而DW会定时到ODS进行数据抽取,这就是一个关键的ETL设计准则:
“singlesourcepopulation”
利用ODS+DW实现战术决策支持有其非常直观的优势:
利用ODS实现实时或者准实时的数据抽取,而且ODS的数据量不大,可以比较高效地进行数据的修改和更新,并且可以提高查询的效率。
而利用数据仓库的海量历史数据存储实现部分战术决策的数据支持,并能实现战略决策支持。
但是,这种也有很明细的劣势:
由于ODS和DW的结构和模型是不同的,这需要进行不同的系统和数据模型设计,也需要不同的系统维护过程,相应增加系统的拥有成本。
(目前对战术决策支持最成功应用的是NCR的数据仓库解决方案,采用的是类似于ODS+DW的方案,不过NCR称之为ActiveDW。
)
1.3.2.2RealtimeDW(RTDW)
另外一种战术决策支持系统是MichaelHaisten非常推崇的做法,称之为RTDW(实时数据仓库)。
实时数据仓库的结构分为实时和静态两个分区。
它的优点在于将连续采集的实时数据装入到实时分区的同时将一致的快照在设定的时间间隔里装入到静态分区。
实时分区里可以进行增量聚合,而静态分区实际上就是一个传统的数据仓库,它通过持续的增量加入变化数据来从细节级上维护历史数据的一致性。
但是对实时分区的设计有两种截然不同的方法,也导致了一些纷争:
1.在实时分区,虽然数据也是按照事先拟订的主题域来组织的,但因为它要进行自己的数据处理——企业级的OLTP和即时的OLAP,所以应该有它自己的考虑,即:
数据表结构应当和现有的操作和处理系统相似,以便于节省数据传输、存储时的系统开销,达到更好的实时效果。
在这个分区里,还可以对一些记录进行适当的聚合。
而在静态分区中,数据则按照传统的数据仓库的方式来组织。
在设定的时间间隔,由DBMS来控制从实时分区到静态分区的数据导入。
在两个分区里,用户都可以进行各种数据浏览和分析操作。
一般来说,应该先建立静态分区,然后综合考虑静态分区和原有的DB系统的情况来建立实时分区。
按照这种做法,实时分区可以是一个独立数据库或者是数据库中的一个独立的表。
这与ODS+DW的情况就非常类似,实时分区相当于ODS,静态分区相当于传统的DW,虽然这会带来复杂的设计和同步问题。
2.另外一种方法是在实时和静态分区各自独立的情况下使用表级分区,这时,DBMS应该支持单一的逻辑映像。
这种方法虽然能减少系统的维护要求实时分区和静态分区有相同的库表结构,这会增加实时数据抽取的工作量,从而影响效率。
同时还存在更严重的数据更新问题:
因为实时数据很多在业务系统中还未完全稳定下来,经常会发生变动,因此要求实时分区的数据进行同步更新,而实时分区的数据模型是以星型模型进行建设的,完全的非范式化,有较多的冗余,更新效率很低。
目前为止,Haisten是比较推崇这中RTDW的建设方法。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据仓库 粗略 发展 历程