数据仓库的粗略发展历程

1、数据仓库的粗略发展历程及相关概念1.1概述数据仓库的概念可能比一般人想像的都要早一些，中间也经历比较曲折的过程。其最初的目标是为了实现全企业的集成(Enterprise Integration),但是在发展过程中却退而求其次：建立战 术性的数据集市(Data Marts)。到目前为止，还有很多分歧、论争，很多概念模棱两可甚至是 彻底的让人迷惑。本文试图从数据仓库的发展历史中看到一些发展的脉络，了解数据仓库应该 是怎么样的，并展望一下未来的数据仓库发展方向。同时，由于新应用的不断出现，出现了很多新的概念和新的应用，这些新的应用如何统一现成完整的企业BI应用方案还存在很多争论。本文试图对这些概念做

2、一些简要的阐述，让大家对此有初步的了解。1.2粗略发展过程1.2.1开始阶段(1978-1988)数据仓库最早的概念可以追溯到20世纪70年代MIT的一项研究，该研究致力于开发一种优化的技术架构并提出这些架构的指导性意见。第一次，MIT的研究员将业务系统和分析系统分开，将业务处理和分析处理分成不同的层次，并采用单独的数据存储和完全不同的设计准则。同时，MIT的研究成果与80年代提出的信息中心(Information Center)相吻合：即把那些新 出现的、不可以预测的、但是大量存在的分析型的负载从业务处理系统中剥离出来。但是限于 当时的信息处理和数据存储能力，该研究只是确立了一个论点：这两种

3、信息处理的方式差别如 此之大，以至于它们只能采用完全不同的架构和设计方法。之后，在80年代中后期，作为当时技术最先进的公司，DEC已经开始采用分布式网络架构来支持其业务应用，并且DEC公司首先将业务系统移植到其自身的RDBMS产品：RdB。并且，DEC公司从工程部、销售部、财务部以及信息技术部抽调了不同的人员组建了新的小组，不仅 研究新的分析系统架构，并要求将其应用到其全球的财务系统中。该小组结合MIT的研究结论，建立了TA2 (Technical Architecture 2)规范，该规范定义了分析系统的四个组成部分：数据获取数据访问目录用户服务其中的数据获取和数据访问目前大家都很清楚，而目

4、录服务是用于帮助用户在网络中找到他们 想要的信息，类似于业务元数据管理；用户服务用以支持对数据的直接交互，包含了其他服务 的所有人机交互界面，这是系统架构的一个非常大的转变，第一次将交互界面作为单独的组件 提出来。1.2.2全企业集成(Enterprise Intergration, 1988)同时，RM也在处理信息管理不同方面的问题，其最烦人的问题是不断增加的信息孤岛，旧M的很多客户要面对很多分立系统的数据集成问题，而这些系统有不同的编码方式和数据格式。1988年，为解决全企业集成问题，旧M爱尔兰公司的Barry Devlin和Paul Murphy第一次提出了 信息仓库(Informati

5、on Warehouse)”的概念，将其定义为：一个结构化的环境，能支 持最终用户管理其全部的业务，并支持信息技术部门保证数据质量”，并在1991年在DEC TA 2的基础上把信息仓库的概念包含进去，并称之为VITAL规范(virtually integrated technicalarchitecture life cycle)，将PC、图形化界面、面向对象的组件以及局域网都包含在VITAL里，并定义了85种信息仓库的组件，包括数据抽取、转换、有效性验证、加载、Cube开发和 图形化查询工具等。但是旧M只是将这种领先的概念用于市场宣传，而没有付诸实际的架构设计。这是旧M有一个领域上创新后停止

6、不前导致丧失其领先地位。因此，在90年代初期，数据仓库的基本原理、 框架架构，以及分析系统的主要原则都已经确定，主要的技术，包括关系型数据存取、网络、C/S架构和图形化界面均已具备，只欠东风了。同时，在1988年1991年，一些前沿的公司已经开始建立数据仓库。1.2.3企业级数据仓库(EDW , 1991)1991年，Bill Inmon出版了其有关数据仓库的第一本书，这本书不仅仅说明为什么要建数据仓库、数据仓库能给你带来什么，更重要的是，Inmon第一次提供了如何建设数据仓库的指导性意见，该书定义了数据仓库非常具体的原则，包括：数据仓库是面向主题的(Subject-Oriented)、集成的

7、(Integrated)、包含历史的(Time-variant)、不可更新的(Nonvolatile)、面向决策支持的(Decision Support )面向全企业的(Enterprise Scope )最明细的数据存储(Atomic Detail )数据快照式的数据获取(Snap Shot Capture )这些原则到现在仍然是指导数据仓库建设的最基本原则，虽然中间的一些原则引发一些争论，并导致一些分歧和数据仓库变体的产生。但是，Bill Inmon凭借其这本书奠定了其在数据仓库建设的位置，被称之为“数据仓库之父”。1.2.4数据集市(19941996)数据仓库发展的第一明显分歧是数据集市

8、概念的产生。由于企业级数据仓库的设计、实施很困难，使得最早吃数据仓库螃蟹的公司遭到大面积的失败，因此数据仓库的建设者和分析师开始考虑只建设企业级数据仓库的一部分，然后再逐步添加，但是这有背于Bill Inmon的原则：各个实施部分的数据抽取、清洗、转换和加载是独立，导致了数据的混乱与不一致性。而且部分 实施的项目也有很多失败，除了常见的业务需求定义不清、项目执行不力之外，很重要的原因是因为其数据模型设计，在企业级数据仓库中，Inmon推荐采用3范式进行数据建模，但是不排除其他的方法，但是Inmon的追随者固守OLTP系统的3范式设计，从而无法支持DSS系 统的性能和数据易访问性的要求。这时，R

9、alph Kimball出现了，他的第一本书The DataWarehouse Toolkit掀起了数据集市的狂潮，这本书提供了如何为分析进行数据模型优化详细指导意见，从Dimensional Modeling大行其道，也为传统的关系型数据模型和多维OLAP之间建立了很好的桥梁。从此，数据集市在很多地方冒了出来，并获得很大成功，而企业级数据仓库已逐渐被人所淡忘。1.2.5争吵与混乱(1996-1997)企业级数据仓库还是部门级数据集市？关系型还是多维？Bill Inmon和Ralph Kimball一开始就争论不休，其各自的追随者也唇舌相向，形成相对立的两派：Inmon派和Kimball派(有

10、点象少林和武当，呵呵)。在初期，数据集市的快速实施和较高的成功率让Kimball派占了上风，但是很快，他们也发现自己陷入了某种困境：企业中存在6 7个不同的数据集市，分别有不同的ETL,相互之间的数据也不完全一致。同时，各个项目实施中也任意侵犯了Inmon开始定下的准则：把数据集市当成众多OLTP系统之后的有一个系统，而不是一个基础性的集成性的东西，为保证数据的准确性和实时性，有的甚至可以由OLTP系统直接修改数据集市里面的数据，为了保证系统的性能，有的数据集市删除了历史数据。等等，不一而足。当然，这导致了一些新的应用的出现，例如ODS ,但是人们对DataWarehouse、DataMart

11、、ODS的概念非常的模糊， 经常混为一谈。有人说OLAP就是数据仓库，也有人说我要ODS和DataMart，不要Datawarehouse,也有人说，我DataMart建多了，自然就有DataWarehouse了。但是Bill Inmon一直很旗帜鲜明:可以打到几万吨的小鱼小虾，但是这些小鱼小虾加起来不是大鲸鱼“你CRMmmLocal1.2.6合并( 1998 2001)经过多翻争吵，证明one-size-fits-all是不可能的，你需要不同的BI架构来满足不同的业务的数据集市也包容进来了，第一次，Kimball承认了Inmon,但是仍然还有很多人在争论是自顶向下，还是自底向上。CIF的核心

12、思想是把整个架构分成不同的层次以满足不同的需求，把DW、DM、ODS进行详细的描述。现在CIF已经成为建设数据仓库的框架指南。(by Michael Haisten)。但是从需求。Bill Inmon也推出了新的BI架构CIF (Corporation information factory),把KimballFireballsCorporalsADMtati。淋Cross MediaStorage溢口叫日Explorationrehouse/Data MiningDSSApplicationsChanged Data ICaptureGranularity -i-Manager 二-:责GJ

13、obal /*ODS /号/Oprwsrt JPagingA值aETL*1.2.7未来？ ？但是数据仓库未来会怎么发展呢，有人说是RealTime DWInternby Bi I hmon and Claudra IrrhoffCopyngtitaooi. an灿忡晦湖ygDialogueUanacieTPrErfDmatredDt浏叫寸早sCookieCagritionSessionAnl/sisWsb LogTapesAcctgFinanceMarkeiirg *M SalesDepartrnental Marts其历史发展过程来看，几个趋势是比较明显的：从战略决策到战术决策的发展：这对D

14、W的实时性和可获得性(availability )有更高 的要求，甚至要求7 X 24 X 365需求更加多样化，要求有不同的架构和应用层次以适应不同的需求数据量膨胀，对数据建模、数据组织和层次划分提出更高的要求。从EDW至V DM，又有ODS、RTDW、Exploration DataWarehouse等等，同时新的应用层出 不穷，看来DW/BI的未来是热热闹闹的。1.3战术决策支持系统数据仓库从一开始是定位在面向高层管理者、进行战略决策支持的，而随着应用的发展，要求 中层管理者甚至底层的一线操作者也能分享数据仓库的功能。例如客服人员在接听客户电话的 同时能查看到该客户的完整历史信息、该客户

15、的偏好信息、根据其客户情况目前能提供的促销 信息等等。即运营系统与决策支持系统将不再是完全隔离的两个系统，而是要求二者之间能相 互共享有用的信息。1.3.1战术决策支持系统的交互方式运营系统和DW/DSS系统的交互方式可以有两种：直接交互和间接交互。直接交互data data is requested from the data warehouse(5) data is returned直接交互虽然在表面上很直观，但是有很多限制的地方：1.数据仓库的查询反应速度是比较长的， 很难满足运营系统的时间要求， 特别是对那些 比较随机的查询，其反应时间超过好几分钟，甚至上小时。2.得到的数据量可能是比

16、较大的，增加了网络的负担3.从数据仓库得到的数据格式、数据含义等与运营系统有差距，需要某种数据置换和加载过程(与数据仓库建设的ETL区分，可以称之为反向ETL)这些问题使得由运营系统直接访问数据仓库系统变动不切实际，在现实世界中也很少有这样的 系统建设。间接交互Figure 5; The dyndmks of acceding data warehouse data from the operational environmentflighthistory(data wanehouse)daia warehouseenvironment间接交互中，通过分析系统计算出该客户能得到的折扣是最重要的

17、组成部分，他需要综合当前的运营数据（运营系统）和历史消费信息（数据仓库）。通常来说，这部分计算要求的数据量和计算时间超过了运营系统能承受的范围，一般是在机器空闲的时候在夜间先行计算的。Figure 4: Calculating the optimal commission.这种间接交互的分析型应用可以存在很多行业的众多应用，例如银行信贷系统的动态评级、电话销售时的客户细分和促销、航空定票的动态定价、生产系统的动态生产计划制定与调整等等。1.3.2战术决策支持系统的系统架构战术决策支持系统与传统的数据仓库相比有更高的要求：1.更快的响应速度：在几分钟甚至几十秒之内得到结果，这要求有相应的数据结构

18、设计和调优工作，以及对各种不同类型的操作进行优先级管理，以保证战术决策支持分析的SLA2.更频繁的数据更新：要求实时或者准实时的ETL过程，以保证数据的准确性和时效性3.更高的数据精度：战略决策对数据精度要求较低，只是要求一个大概的趋势，而战术决策要求很高的精度，经常是100%，相应对ETL提出更高的要求4.更强的数据可获得性： 运营系统一般要求7*24小时运作，相应地要求战术决策支持系统有相同的可获得性，因此留给ETL、分析预计算的时间窗口就会很小，甚至要求的currentbookingsflight history(datawarehouse)calculate the optimalco

19、mmissioncommission并行的。 因此，战术决策支持系统要求与传统的数据仓库有不同的系统架构和设计方法。目前还没有比 较权威的方法得到大家的普遍认可，目前我看到有两种方法相互争论，不过还没有更多的案例 来证明这两种方法的优劣。1.3.2.1 ODS + DWODS是为了弥补业务系统和数据仓库之间的差距而提出的，解决的是这种问题：“对一个特定的业务流程来说，我怎么才能提供最新的、跨功能部门之间的信息”，例如对客户服务人员，他需要销售、库存、市场和研发等各部门的最新数据，而这些数据原来是分散在不同部门的不同 应用系统的。如果通过数据仓库来实现数据集成，则实时性难以保证，或者建设成本很高

20、。同数据仓库类似，ODS也是面向主题的、集成的，但是其最大特点是数据是可更新的，甚至由 业务系统通过触发器直接更新。因此，ODS是业务系统和DW之间更偏向业务系统的东东。Table 1 -1 Difrences ODS and DWODSDWData of high quality at detailed levelandassured availabilityData may not be perfect, but sufficient forstrategic analysts; data does not have to behighly availableContains curren

21、t and near-current dataContains historical dataReal-time and near real-time data loadsNormally batch data loadsMostly updated at data fi日Id level (even if itmay be appended)Data is appended, not updatedTypically detailed data onlyContains summarized and detailed dataModeled to support rapid data upd

22、ates (3NF)Variety of modeling techniques used typically3NF far DW and dimensional for datamarts tooptimize query performanceTransactions similar to an Online TransactionProcessing (OLTP) systemQueries process larger volumes of dateUsed tor detailed decision making andoperational re|xrtingU h r lFii-

23、tiileciMicri rn ：ikiridCMaWarehouse SlsiidarclQuery* Ad-hOC QU也V *OLAP DataMiningDirectAccess -由浦OnlyODS Sco&eLkililbacHjrDe UpdtdesExtracitioiXCluruing RBibrUcIljrin站5赢mW.RGaktlnn、，Upd ate押七网捋|心|询J. Data StoreData Source n1；IEictefoal DalaScurcws-._Qi?眺皿枣施，了troMACC&SS- RaidittEnhiancemenitS

24、uiimmrlzaUonBatchUpdhlxBatch of .额or。&Forwa Iah由村 Custom Intwiacw* We4i Browser CH&nt/s&rM&rcampaign Mw阀日HIM CusIcMOBr Servlet call Centers R如K AnriiyBl*e(c.nDircl Ac蚀蟋-Rad Ohly_ nCalalogMrtflidalflACSFigure 3-5 Architecture of ODS types A. B. and C实时分区需要注意的是，数据抽取，要么抽取到ODS中，要么到DW中，不能

25、同时都抽取，而DW会定时到ODS进行数据抽取，这就是一个关键的ETL设计准则：single source population ”利用ODS + DW实现战术决策支持有其非常直观的优势：利用ODS实现实时或者准实时的数据抽取，而且ODS的数据量不大，可以比较高效地进行数据的修改和更新，并且可以提高查询的效率。而利用数据仓库的海量历史数据存储实现部分战术决策的数据支持，并能实现战略 决策支持。但是，这种也有很明细的劣势：由于ODS和DW的结构和模型是不同的，这需要进行不同的系统和数据模型设计，也需要不同的系统维护过程，相应增加系统的拥有成本。（目前对战术决策支持最成功应用的是NCR的数据仓库解决方案，采用的是类似于ODS + DW的方案，不过NCR称之为Active DW。）1.3.2.2 Realtime DW （ RTDW）另外一种战术决策支持系统是Mi