数据仓库的概念.docx

数据仓库的粗略发展历程及相关概念1.1概述数据仓库的概念可能比一般人想像的都要早一些，中间也经历比较曲折的过程。其最初的目标 是为了实现全企业的集成(Enterprise Integration)，但是在发展过程中却退而求其次：建立战术 性的数据集市(Data Marts)0到目前为止，还有很多分歧、论争，很多概念模棱两可甚至是彻 底的让人迷惑。本文试图从数据仓库的发展历史中看到一些发展的脉络，了解数据仓库应该是 怎么样的，并展望一下未来的数据仓库发展方向。同时，由于新应用的不断出现，出现了很多新的概念和新的应用，这些新的应用如何统一现成 完整的企业BI应用方案还存在很多争论。本文试图对这些概念做一些简要的阐述，让大家对此 有初步的了解。1.2粗略发展过程1.2.1 开始阶段(1978-1988)数据仓库最早的概念可以追溯到20世纪70年代MIT的一项研究，该研究致力于开发一种优化 的技术架构并提出这些架构的指导性意见。第一次，MIT的研究员将业务系统和分析系统分开， 将业务处理和分析处理分成不同的层次，并采用单独的数据存储和完全不同的设计准则。同时，MIT的研究成果与80年代提出的信息中心(Information Center)相吻合：即把那些新出 现的、不可以预测的、但是大量存在的分析型的负载从业务处理系统中剥离出来。但是限于当 时的信息处理和数据存储能力，该研究只是确立了一个论点：这两种信息处理的方式差别如此 之大，以至于它们只能采用完全不同的架构和设计方法。之后，在80年代中后期，作为当时技术最先进的公司，DEC已经开始采用分布式网络架构来支 持其业务应用，并且DEC公司首先将业务系统移植到其自身的RDBMS产品：RdB。并且，DEC 公司从工程部、销售部、财务部以及信息技术部抽调了不同的人员组建了新的小组，不仅研究 新的分析系统架构，并要求将其应用到其全球的财务系统中。该小组结合MIT的研究结论，建 立了 TA2(Technical Architecture 2)规范，该规范定义了分析系统的四个组成部分： 数据获取 数据访问 目录 用户服务其中的数据获取和数据访问目前大家都很清楚，而目录服务是用于帮助用户在网络中找到他们 想要的信息，类似于业务元数据管理；用户服务用以支持对数据的直接交互，包含了其他服务 的所有人机交互界面，这是系统架构的一个非常大的转变，第一次将交互界面作为单独的组件 提出来。1.2.2 全企业集成(Enterprise Intergration 1988)同时，IBM也在处理信息管理不同方面的问题，其最烦人的问题是不断增加的信息孤岛，IBM 的很多客户要面对很多分立系统的数据集成问题，而这些系统有不同的编码方式和数据格式。1988年，为解决全企业集成问题，IBM爱尔兰公司的Barry Devlin和Paul Murphy第一次提出了“信息仓库(Information Warehouse)”的概念，将其定义为：“一个结构化的环境，能支持最 终用户管理其全部的业务，并支持信息技术部门保证数据质量”，并在1991年在DEC TA 2的基 础上把信息仓库的概念包含进去，并称之为 vital规范(virtually integrated technical architecture life cycle)，将PC、图形化界面、面向对象的组件以及局域网都包含在vital里， 并定义了 85种信息仓库的组件，包括数据抽取、转换、有效性验证、加载、Cube开发和图形 化查询工具等。但是IBM只是将这种领先的概念用于市场宣传，而没有付诸实际的架构设计。这是IBM有一个领域上创新后停止不前导致丧失其领先地位。因此，在90年代初期，数据仓库的基本原理、框架架构，以及分析系统的主要原则都已经确定， 主要的技术，包括关系型数据存取、网络、C/S架构和图形化界面均已具备，只欠东风了。同时，在1988年一1991年，一些前沿的公司已经开始建立数据仓库。1.2.3企业级数据仓库(EDW，1991)1991年，Bill Inmon出版了其有关数据仓库的第一本书，这本书不仅仅说明为什么要建数据仓库、 数据仓库能给你带来什么，更重要的是，Inmon第一次提供了如何建设数据仓库的指导性意见， 该书定义了数据仓库非常具体的原则，包括： 数据仓库是面向主题的(Subject-Oriented)、 集成的(Integrated)、包含历史的(Time-variant)、 不可更新的(Nonvolatile)、 面向决策支持的(Decision Support) 面向全企业的(Enterprise Scope) 最明细的数据存储(Atomic Detail) 数据快照式的数据获取(Snap Shot Capture)这些原则到现在仍然是指导数据仓库建设的最基本原则，虽然中间的一些原则引发一些争论， 并导致一些分歧和数据仓库变体的产生。但是，Bill Inmon凭借其这本书奠定了其在数据仓库建 设的位置，被称之为“数据仓库之父”。1.2.4 数据集市(1994-1996)数据仓库发展的第一明显分歧是数据集市概念的产生。由于企业级数据仓库的设计、实施很困 难，使得最早吃数据仓库螃蟹的公司遭到大面积的失败，因此数据仓库的建设者和分析师开始 考虑只建设企业级数据仓库的一部分，然后再逐步添加，但是这有背于Bill Inmon的原则：各个 实施部分的数据抽取、清洗、转换和加载是独立，导致了数据的混乱与不一致性。而且部分实 施的项目也有很多失败，除了常见的业务需求定义不清、项目执行不力之外，很重要的原因是 因为其数据模型设计，在企业级数据仓库中，Inmon推荐采用3范式进行数据建模，但是不排 除其他的方法，但是Inmon的追随者固守OLTP系统的3范式设计，从而无法支持DSS系统的 性能和数据易访问性的要求。这时，Ralph Kimball出现了，他的第一本书“The DataWarehouse Toolkit”掀起了数据集市的狂 潮，这本书提供了如何为分析进行数据模型优化详细指导意见，从Dimensional Modeling大行其 道，也为传统的关系型数据模型和多维OLAP之间建立了很好的桥梁。从此，数据集市在很多 地方冒了出来，并获得很大成功，而企业级数据仓库已逐渐被人所淡忘。1.2.5 争吵与混乱(1996-1997)企业级数据仓库还是部门级数据集市？关系型还是多维？ Bill Inmon和Ralph Kimball 一开始就 争论不休，其各自的追随者也唇舌相向，形成相对立的两派：Inmon派和Kimball派(有点象少 林和武当，呵呵)。在初期，数据集市的快速实施和较高的成功率让Kimball派占了上风，但是很快，他们也发现自 己陷入了某种困境：企业中存在6 7个不同的数据集市，分别有不同的ETL，相互之间的数据 也不完全一致。同时，各个项目实施中也任意侵犯了 Inmon开始定下的准则：把数据集市当成 众多OLTP系统之后的有一个系统，而不是一个基础性的集成性的东西，为保证数据的准确性和 实时性，有的甚至可以由OLTP系统直接修改数据集市里面的数据，为了保证系统的性能，有的 数据集市删除了历史数据。等等，不一而足。当然，这导致了一些新的应用的出现，例如ODS， 但是人们对DataWarehouse、DataMart、ODS的概念非常的模糊，经常混为一谈。有人说OLAP 就是数据仓库，也有人说我要ODS和DataMart，不要Datawarehouse，也有人说，我DataMart 建多了，自然就有DataWarehouse 了。但是Bill Inmon 一直很旗帜鲜明：“你可以打到几万吨的 小鱼小虾，但是这些小鱼小虾加起来不是大鲸鱼”1.2.6 合并(19982001)经过多翻争吵，证明one-size-fits-all是不可能的，你需要不同的BI架构来满足不同的业务 需求oBill Inmon也推出了新的 BI架构 CIF(Corporation information factory),把 Kimball 的数据集市也包容进来了，第一次，Kimball承认了 Inmon,但是仍然还有很多人在争论是自 顶向下，还是自底向上。CIF的核心思想是把整个架构分成不同的层次以满足不同的需求，把DW、DM、ODS进行详细的描述。现在CIF已经成为建设数据仓库的框架指南。Corporate ApplicationscxploraiionCats Miningby Bill Inmon 者nd Glaudia Imhoff Copyright ®2Q01, all rights reserved,InternetFirewallsCookieLocal OdsPrsfarmatted DialoguesDialogueManagerSessionAnal/sisWe b Log Tapes.-Cross MediaStorage ManagerChanged *Data 'CapiureStagingArsa:以*/新GranularityManagei vAcctgFinanceMarketing U吁s宵Depart me nisi QaLa Marts(rplj*CRMIApplications1.2.7未来？但是数据仓库未来会怎么发展呢，有人说是RealTime DW (byMichael Haisten )。但是从其 历史发展过程来看，几个趋势是比较明显的: 从战略决策到战术决策的发展：这对DW的实时性和可获得性(availability)有更高的 要求，甚至要求7X24X365 需求更加多样化，要求有不同的架构和应用层次以适应不同的需求 数据量膨胀，对数据建模、数据组织和层次划分提出更高的要求。从EDW到DM，又有ODS、RTDW、Exploration DataWarehouse等等，同时新的应用层出不穷， 看来DW/BI的未来是热热闹闹的。1.3战术决策支持系统数据仓库从一开始是定位在面向高层管理者、进行战略决策支持的，而随着应用的发展，要求 中层管理者甚至底层的一线操作者也能分享数据仓库的功能。例如客服人员在接听客户电话的 同时能查看到该客户的完整历史信息、该客户的偏好信息、根据其客户情况目前能提供的促销 信息等等。即运营系统与决策支持系统将不再是完全隔离的两个系统，而是要求二者之间能相 互共享有用的信息。1.3.1战术决策支持系统的交互方式运营系统和DW/DSS系统的交互方式可以有两种：直接交互和间接交互。直接交互data data is requested from the data warehouse(5) data is returned直接交互虽然在表面上很直观，但是有很多限制的地方：1. 数据仓库的查询反应速度是比较长的，很难满足运营系统的时间要求，特别是对那些 比较随机的查询，其反应时间超过好几分钟，甚至上小时。2. 得到的数据量可能是比较大的，增加了网络的负担3. 从数据仓库得到的数据格式、数据含义等与运营系统有差距，需要某种数据置换和加 载过程(与数据仓库建设的ETL区分，可以称之为反向ETL)这些问题使得由运营系统直接访问数据仓库系统变动不切实际，在现实世界中也很少有这样的 系统建设。间接交互Figure S: The dynamics of accessing data warehouse data from the operational envirotuiient.间接交互中，通过分析系统计算出该客户能得到的折扣是最重要的组成部分，他需要综合当前 的运营数据（运营系统）和历史消费信息（数据仓库）。通常来说，这部分计算要求的数据量和 计算时间超过了运营系统能承受的范围，一般是在机器空闲的时候在夜间先行计算的。这种间接交互的分析型应用可以存在很多行业的众多应用，例如银行信贷系统的动态评级、电 话销售时的客户细分和促销、航空定票的动态定价、生产系统的动态生产计划制定与调整等等。1.3.2战术决策支持系统的系统架构战术决策支持系统与传统的数据仓库相比有更高的要求：1. 更快的响应速度：在几分钟甚至几十秒之内得到结果，这要求有相应的数据结构设计 和调优工作，以及对各种不同类型的操作进行优先级管理，以保证战术决策支持分析 的SLA2. 更频繁的数据更新：要求实时或者准实时的ETL过程，以保证数据的准确性和时效性3. 更高的数据精度：战略决策对数据精度要求较低，只是要求一个大概的趋势，而战术 决策要求很高的精度，经常是100%，相应对ETL提出更高的要求4. 更强的数据可获得性：运营系统一般要求7*24小时运作，相应地要求战术决策支持系 统有相同的可获得性，因此留给ETL、分析预计算的时间窗口就会很小，甚至要求的 并行的。因此，战术决策支持系统要求与传统的数据仓库有不同的系统架构和设计方法。目前还没有比 较权威的方法得到大家的普遍认可，目前我看到有两种方法相互争论，不过还没有更多的案例 来证明这两种方法的优劣。1.3.2.1 ODS + DWODS是为了弥补业务系统和数据仓库之间的差距而提出的，解决的是这种问题：“对一个特定的 业务流程来说，我怎么才能提供最新的、跨功能部门之间的信息”，例如对客户服务人员，他需 要销售、库存、市场和研发等各部门的最新数据，而这些数据原来是分散在不同部门的不同应 用系统的。如果通过数据仓库来实现数据集成，则实时性难以保证，或者建设成本很高。同数据仓库类似，ODS也是面向主题的、集成的，但是其最大特点是数据是可更新的，甚至由 业务系统通过触发器直接更新。因此，ODS是业务系统和DW之间更偏向业务系统的东东。后心足1-1。.睥，妇门加s心况突白门GDS日nd DWODSDWData of high quality at de tai led level and assured availabilityData may not b白 perfect, but sufficient for .strategic analysts: data does not have to be highly availableContains current and near-current dataContains historical dataReal-time and near real-time data loadsNormally batch data loadsMostly updated at data field level (even if it may be appended)Data is appended, not updatedTypically detailed data onlyContains summarized and detailed dataMod a led to support rapid data updates (3 NF)Variety of modeling techniques used typically 3NF for DW and dimensional for datamarts to optimize query performanceTransactions similar to an Online Transaction Processing (OLTP1 systemQueries process larger volumes of dataUsed for detailed decision making and operational reportingUsed for long-term decision making and management reportingUsed at the operational levelUsed at the managerial level根据ODS的更新策略，可以将ODS分为三类:Type AReal-time, Store & Forward,or BatchType BIReal-tinie. Store & Forward, or BatchTrigger and Apply UpdatesTypeCReal-tinie Update and AccessFiily IntegratedQDSFigure 3-4 Data tiov/ 洱以rv而 tor ODS types A, B. and C这三类ODS可以和DW形成互补的整体，构成完整的战术决策支持系统架构Data Sources Data Acquisition Enterprise Data Data Enhancement Datamarts Data AccessMulti-source UpdatesBatch UpdateInformation CatalogDirect Access- Read OnlyFigure 3-5 Architecture of ODS types Ar B, and C StandardQuery Ad-hoc Query OLAP Data Mining Extractio Cleansing RestructuriBatch UpdateReal-timeBatch or ' /Store & Forwaand/orReal-time Update-.OperationalEnhancementSummarization Custom Interfaces Web Browser Client/Server Campaign Management Customer ServiceCall Centers Risk AnalysisExternal DataSource-_Jrigger_Updates.需要注意的是，数据抽取，要么抽取到ODS中，要么到DW中，不能同时都抽取，而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）另外一种战术决策支持系统是Michael Haisten非常推崇的做法，称之为RTDW（实时数据仓库）。 实时数据仓库的结构分为实时和静态两个分区。它的优点在于将连续采集的实时数据装入到实 时分区的同时将一致的快照在设定的时间间隔里装入到静态分区。实时分区里可以进行增量聚 合，而静态分区实际上就是一个传统的数据仓库，它通过持续的增量加入变化数据来从细节级 上维护历史数据的一致性。但是对实时分区的设计有两种截然不同的方法，也导致了一些纷争:1. 在实时分区，虽然数据也是按照事先拟订的主题域来组织的，但因为它要进行自己的 数据处理一一企业级的OLTP和即时的OLAP，所以应该有它自己的考虑，即：数据表 结构应当和现有的操作和处理系统相似，以便于节省数据传输、存储时的系统开销， 达到更好的实时效果。在这个分区里，还可以对一些记录进行适当的聚合。而在静态 分区中，数据则按照传统的数据仓库的方式来组织。在设定的时间间隔，由DBMS来 控制从实时分区到静态分区的数据导入。在两个分区里，用户都可以进行各种数据浏 览和分析操作。一般来说，应该先建立静态分区，然后综合考虑静态分区和原有的DB 系统的情况来建立实时分区。按照这种做法，实时分区可以是一个独立数据库或者是 数据库中的一个独立的表。这与ODS+DW的情况就非常类似，实时分区相当于ODS， 静态分区相当于传统的DW，虽然这会带来复杂的设计和同步问题。2. 另外一种方法是在实时和静态分区各自独立的情况下使用表级分区，这时，DBMS应 该支持单一的逻辑映像。这种方法虽然能减少系统的维护要求实时分区和静态分区有 相同的库表结构，这会增加实时数据抽取的工作量，从而影响效率。同时还存在更严 重的数据更新问题：因为实时数据很多在业务系统中还未完全稳定下来，经常会发生 变动，因此要求实时分区的数据进行同步更新，而实时分区的数据模型是以星型模型 进行建设的，完全的非范式化，有较多的冗余，更新效率很低。目前为止，Haisten是 比较推崇这中RTDW的建设方法。