传统的数据仓库架构一般包括ETL、ODS、数据仓库、数据集市和BI工具。业务数据一般在每天深夜的批处理作业中从OLTP系统中抽取出来，存储到ODS中。数据在ODS中加工后，也是在夜间启用批处理将数据集中、分段传送给数据仓库，数据仓库把历史数据存储到数据集市的接口中，供相应的业务部门分析和处理。BI工具位于数据仓库或数据集市的顶端提供OLAP分析。

　　实时数据仓库提倡，当数据在OLTP系统内产生后直接进入数据仓库系统，而不必经过夜间的批处理过程，这使得数据仓库内的数据成为即时更新的数据。实时数据仓库包含两方面的含义：(1)实时的动作;(2)数据仓库。实时的动作是指当前正在进行的活动。这种活动可以是任何事情，例如某件商品的销售。一旦这种活动结束，数据仓库中就应该存在相关的数据。

　　目前国内外对数据仓库的研究和应用主要分为两大类。一类是基于ETL实时数据仓库，原则在于采用各种方法缩短ETL周期。这种方案并不能很好的解决实时数据仓库应该具备的无缝共享和交换数据的需要，只是准实时数据仓库实现的方法。另一类是采用EAI实现数据仓库的实时性。利用建立在面向服务架构体系上的企业应用集成将实时数据从数据源系统中抽取出来，拖曳到数据仓库中。

　　本文主要研究了基于(面向服务体系结构)SOA实时数据仓库体系架构、设计和实现方法，采用Web Services技术使得跨平台的、无缝共享的、实时的数据交换更容易实现。

　　1 基于SOA实时数据仓库的设计原则与系统架构

　　1.1 基于SOA实时数据仓库设计原则

　　以下是基于SOA实时数据仓库的一些核心设计原则。

　　1)系统建设可分阶段实施、可持续发展

　　数据仓库的建设是一个系统工程，其中涉及的数据源也可能分散在各个部门，在系统实施过程中会遇到各种包括非技术因素在内的问题。因此，数据仓库的设计必须“大处着眼、小处着手”，数据仓库的建模必须提供系统可以分阶段实施，并在应用层面保持系统可持续发展。为了获得经验和尽快成功，开始的时候只是把现有接口与SOAP及WSDL“捆”在一起，实现单向的点对点集成就行了，这些先期的Web服务应该模仿目前以数据为中心的API。在遗留系统上稳定运行的核心应用程序或定义清晰的已有贸易伙伴的应用程序是合适的集成对象。

　　2)以业务流程为牵引

　　在建立完备的SOA的每个阶段，都要采取“为业务服务”的观点。在确定数据类型或API之前，每个Web服务都要设计成与业务流程的输人和输出粗略对应的任务。SOAP接口及其WSDL描述符同样应该反映这种以流程为中心的方法，而不是很多编程工具自动生成的那些细节。同时数据仓库的建模应该根据业务的流程和数据源来决定。

　　3)以维护成本较高的应用为对象

　　在许多分散的功能中找出手工流程，如现场销售或客户支持。就面向服务设计方案中的战略投资而言，具有较高的集成和管理成本的应用程序是这一阶段合适的候选目标。应该以那些需要专门技能来管理和开发的、需要专用硬件或那些为了实现互操作性需要专门申请许可的附件和适配器的系统为目标。

　　4)确定核心服务平台

　　大多数公司都会从其已经在J2EE或Windows服务器上所做的工作开始。少数公司也可能选择不同的核心平台，例如，SAP正在缓慢地把Web服务标准集成到其业务API(BAPI)中去;一些严重依赖SAP软件的公司可能愿意把BAPI应用放入SOAP和WSDL中，并遵循SAP有关通用业务文档的定义。但无论选择什么作为其核心平台，都要确保厂商拥护独立标准并证实它能提供可靠的互操作性。

　　5)建立共享基础设施服务

　　由异构系统组成的SOA必须利用它自己的一组特殊服务来确保每件事都是可靠的、可管理的和安全的。Web服务管理产品通过提供版本控制、QoS等功能来满足这些需求，但是诸如认证等其它核心需求有可能需要与现有的身份管理系统等基础设施结合在一起来满足。

　　6)注重数据的完整性

　　对每一个数据仓库关心的数据源，数据仓库设计时都将从最明细的数据层次进行收集，即使将来的分析大部分都是基于汇总的数据，但数据仓库中最底层的数据模型将对应业务系统中最明细的部分。这样的设计，数据仓库的建模和数据采集对于业务系统来说是一步到位的，而这样设计出的分析模型是能够支持所有可能的业务分析的，不会因为数据仓库的设计而丢弃业务的细节，导致未来系统重建。

　　1.2 基于SOA实时数据仓库系统架构

　　1)数据源：包括需要集成的各个应用系统。

　　2)企业应用集成：此部分为系统的核心。企业应用集成包括集成服务器、事件服务器和消息服务器等。集成服务器连接其它几个服务器模块，共同对外提供一个统一的应用调用处理界面。事件服务器提供了定时器触发、事件探测与监听、事件的调度，主要起到在企业信息系统中定制自动的系统集成服务的作用，通过可视化的事件建模，可以定义一个应用集成的流程，从而实现系统的自动集成。消息服务器提供了基于JMS的消息服务。

　　3)数据仓库：包含实时数据分区和静态数据分区两部分。实时数据仓库采用表分离法，实时数据的查询和存储都是基于实时数据分区;静态数据或历史数据的查询基于静态数据分区实现。实时数据分区的数据建模与静态数据分区相应部分的建模完全相同，系统设置一个固定的时间，将实时数据分区的数据导入静态数据分区。

　　4)应用服务器：用于客户端以Web方式访问数据仓库。

　　5)客户端应用：包括对实时数据仓库的查询、实时数据监控、按需分析业务应用、报表和OLAP分析等。

　　6)XML/SOAP/WSDL/UDDI：Web Services建立在一系列与平台无关的协议之上，包括H1TP，XML，UDDI，WSDL，SOAP。这些协议在源数据库、EM中间件和数据仓库之间，是SOA技术实现方式。SOA要求动态的定位和调用服务，这可以通过UDDI，WSDL，SOAP实现。SOA要求服务接口契约的平台无关性，XML可以实现。私有UDDI注册中心包含了所有关于Web服务的描述文件，对这些服务的调用均要首先在注册中心搜索以决定调用的端口和方式。SOAP封装WSDL描述的服务，实现实时数据传输。

　　7)元数据、管理和安全模块：元数据规则库主要存放企业应用集成中所涉及的所有数据元模型。系统安全模块提供了系统安全保障。

　　2 基于SOA实时数据仓库的设计与实现

　　2.1 实时数据仓库设计

　　2.1.1 实时数据加载方式分析

　　实时数据加载方式有直接插入法、表分离法、外部实时数据缓存法等，每一种加载方式各有其优缺点。根据加载方式的不同，相应的数据建模和数据查询方式也都不同，下面逐一分析这三种方法。

　　1)直接插入法

　　实时数据传输到数据仓库后，数据仓库应该怎样接收或保存这些数据呢?最简单的方法是将这些新数据直接插人数据仓库相应的表中。这种方法存在的问题是，在同一张表上执行连续的Insert/Update操作和OLAP/Reporting查询操作，这极大地影响了数据仓库的查询性能。

　　不论是数据仓库用户并发查询，还是数据流加载，一旦达到某种程度，关系数据库管理系统都会临时阻塞，影响数据流的加载，这样数据又成为旧数据，也可能导致数据流加载应用失败，或者数据仓库反应迟钝，最终导致数据仓库的用户认为数据仓库不可用，而不再使用数据仓库。

　　2)表分离法

　　表分离法不直接将实时数据加载进数据仓库表中，而是建立与数据仓库实际完全相同的表，实时数据先加载进入分段表，这个分段表可以仅包含当天的数据，或者如果数据量小的话，可以包含更多的历史信息。然后定期地将分段表中的数据转移到数据仓库中，可以在每天晚上进行，也可以制定一个更短的周期，只不过在交换数据时可以临时暂停OLAP查询，这样就可以解决查询和更新并发查询时引发的数据仓库性能问题。

　　3)外部实时数据缓存法

　　最好的方法是在数据仓库外部建立一个实时数据缓存(Real-time Data Cache)，将实时数据存放在RTDC中。这种方法完全避免了所有潜在的性能问题，而且最大限度得保持了数据仓库的原貌。

　　实时数据缓存可以使用专有的Database Server，或者使用大型数据库系统一个单独的Instance，专门用于加载、存储和处理实时数据。对于实时数据量大(例如，每秒处理百千次改变)的应用，或者对万方数据查询性能要求很强的应用，系统可以使用In—Memory Database(IMDB)作为实时数据缓存;许多公司，例如Angara、Caeheflow、Kx、TimesTen and InfoCruiser，都提供IMDB。采用这种方法，可以实现秒级的数据更新，而且不影响查询的性能。但是这种方法用户投资较大。

　　2.1.2 实时数据建模分析

　　本节将按照实时数据加载方式的不同，论述数据建模的方法。

　　1)直接插入法：此方法由于仍然使用原数据仓库表，数据建模没有什么不同之处，但是所有的查询、报表和OLAP工具都有缓存的机制。对于缓存报表和结果数据集，假设这些缓存仅仅在夜间或周末数据加载时才更新，那么实时数据加载进数据库时，就出现实际查询结果和实际数据不符的问题。除非提供一种可以与外部数据改变相一致的缓存机制，但目前还没有这种缓存工具。

　　2)表分离法：这种建模方法是将实时数据表和历史数据表分离开，因此可以使用视图将实时数据表和历史数据表结合起来查询。

　　3)外部实时数据缓存法：数据建模方式与数据仓库完全相同。

　　2.1.3 实时数据查询分析

　　前面提到实时的数据改变和数据查询会影响数据仓库的性能，那么在不降低实时性的条件下，一个最简单的解决办法是尽量降低查询的复杂度，不允许用户执行非常复杂的查询，或者降低实时数据的刷新频率，支持复杂查询。

　　对于实时数据分离的建模方法，解决方案有：通过提高系统硬件的能力;如果应用需求许可，可以将实时数据和历史数据的查询分开处理;也就是说，查询实时数据时不查询历史数据，查询历史数据时，不查询实时数据。

　　但是某些应用既要求大数据量访问、深度分析，又要求实时数据处理，应具备以下的几点要求：

　　(1)实时数据访问(而不是近似实时);(2)快速的数据更新(10～100个事务/s);(3)被10、100或1000个并发用户访问;(4)关联历史数据分析实时数据;(5)涉及复杂的、多通道的分析型OLAP查询。

　　对于这种应用只能采用外部实时数据缓存法，即用Just-in-time Information Merging(JIM)方法实现。在JIM系统中的组件JIM Request Analyzer(JIM-RA)和JIM Data Imager(JIM-DI)可以实现实时数据和历史数据的无缝连接。

　　2.2 基于SOA实时数据仓库的实现

　　以模拟某一监控警示服务为例，涉及的数据主要有：警示项目数据、警示参数、警示级别数据和警示信息详细数据。下面给出相对简单的各XML数据结构定义。

　　每个audit包含两个子元素name和description，分别描述这个警示项目的名称和描述信息，同时audit还包含一个属性auditKey标识警示项目的唯一标识符(UUID)。

　　考虑到系统的适应性和可扩展性，同时设计了dataBag Template的数据描述方式。所谓dataBagTemplate就是一种预先定义好的、在某个特定领域应用中使用的信息数据的模板，这个模板定义了所有合法的字段，包括字段名称及其字段值类型。下面给出一个dataBag Template的例子：

　　这个dataBagTemplate定义了三个字段，auditKey(警示项目)、param1(参数1)、param2(参数2)，这个Template用于定义警示参数的模板结构，得到警示参数的数据结构。

　　3 结 论

　　本文研究了基于SOA实时数据仓库体系架构和设计方法，其功能优势是开发执行常用功能的服务以减少多余的开发工作，以及通过利用标准化接口或外壳使应用功能可以跨系统使用，从而增加应用的灵活性。注意到新兴的面向服务体系结构和Web Service技术为企业应用集成技术注入了新鲜的血液和动力，在此基础上的企业应用集成为实时数据仓库的实现奠定了基础。

　　实时数据仓库的研究与建设仍处于起步的阶段，还有许多的问题需要进一步研究：

　　1)对于并发性大或数据量大的系统会带来一些问题。例如，EAI的信道和服务器必须设计成能够应付骤然增加的大量数据的加载，而且不会丢失紧急信息。但这样就会增大带宽，尽管可能大多数时候带宽是闲置的，但势必增加用户的投资。同样，实时数据仓库数据加载基于事件触发，如果触发过量，必然影响业务系统的性能。

　　2)Web服务通信技术所面临的安全问题日益复杂和多样化，Web服务安全通信机制也要相应地进行改进和扩展。需要跟踪相关规范的发展，特别是微软和IBM提出的一系列Web服务安全性规范;进行Web服务安全通信策略协商机制研究的同时，要考虑到Web服务与QoS机制相结合。

　　3)SOA数据仓库的瓶颈问题。因SOA数据管理的瓶颈是数据集成，不同格式的数据分布在不同的系统中，应用中数据需要被合并和关联，形成一种业务信息，提供决策者使用，这些数据开放出来的障碍，就是存储系统之间的连通性问题。虽然如果架构设计合理可以提高生产率和可操作性，但到目前为止，SOA技术标准尤其是对数据标准的完善还有待作进一步的研究。