【IT168技术文档】
引言
信息的不一致和分散让很多组织十分烦恼。在很多情况下，用户花费了大量的时间搜索并手动聚合、关联和更正相关信息，而不能直接根据从信息获得的要点采取行动。
这个被广泛认识的挑战也出现在实现面向服务的体系结构（Service-Oriented Architecture，SOA）时。通常，核心服务需要使用来自多个不同源的已聚合的高质量信息。
现有多个概念和技术专门用于满足这种集成需求。数据联合就是其中的一个。数据联合的目标是有效地联接来自多个异类源的数据，合理利用现有的数据——不会造成数据冗余。数据联合模式支持在集成的临时（虚拟）视图上进行数据操作；在此类视图中，实际数据存储在多个不同的源上。源数据仍然在源系统的控制之下，会根据需要进行提取，以进行联合访问。
本文重点强调了数据联合方法的价值。描述了应用数据联合的上下文后，我们将讨论此模式所针对的问题及其解决方案。我们根据非功能需求对此模式的适用性特点进行了说明。此模式的一些已知用法源自我们应用此模式的经验。最后，我们将总结此模式的重点、风险以及限制。
数据联合方法的价值主张
基础异类系统透明性
通过使用数据联合，使用者将看到的是单个统一接口。位置透明性意味着使用此模式的应用程序不需要注意数据存储的位置。得益于调用透明性，它也不需要知道源数据库所支持的语言或编程接口。例如，如果使用了 SQL，应用程序则不必知道源支持的是哪种 SQL 分支。由于具有物理数据独立性、碎片和复制透明性，因此应用程序不需要知道数据的物理存储方式；而源于其网络透明性，应用程序也不需要知道所使用的是什么网络协议。
上市时间优势
作为数据联合服务器使用者的应用程序可以与单个虚拟数据源通过接口进行通信。如果不使用联合模式，应用程序必须通过不同的接口和不同的协议与多个源分别交互。研究表明，当必须集成多个源时，使用数据联合模式可帮助大幅度减少开发时间。有关更多信息，请参见参考资料部分。
减少开发和维护成本
很多使用者可能会使用相同（或非常相似）的集成信息。可以采用这样的方法处理此问题：每个使用者采用自己的实现来聚合来自不同源的信息。或者，可以一次性开发集成视图，然后在单个位置对其重复利用和维护，从而实现单点更改。此方法可减少开发和维护成本。
性能优势
与内部开发的信息聚合方法相比，特别关注高级数据处理技术的数据联合模式实现在很多情况下都已证明具有卓越的性能特征（有关更多信息，请参见参考资料部分）。通过利用高级查询处理功能，联合服务器可以在联合服务器本身和各个源之间最优地分布工作负载。它将确定工作负载的哪个部分由哪个服务器执行最高效，以实现响应时间最优化。
可重用性优势
将数据联合模式应用到特定集成场景后，此特定联合访问的结果可作为服务向多个服务使用者提供。例如，某个集成场景可能要求从各种源检索结构化和非结构化保险索赔数据。在此示例中，数据联合模式可以提供集成索赔数据的解决方案，以便随后将集成索赔数据通过门户提供给索赔代理人。可以随后将相同的联合访问作为服务提供给其他使用者，如标准索赔应用程序的自动流程或面向 Web 应用程序的客户机等。
改善控制
控制是 SOA 生命周期的关键基本要素。通过执行具有可预测结果的非常好的实践，控制流程可通过使用模式得到增强。在系统的开发和创建过程中重用经过验证的灵活模式可同时确保一致性和高质量，并同时通过使用单个源来更新更改，从而减少维护成本。
公司和组织间的合并和收购通常要求数据和应用程序架构师将异类数据源集成到数据的统一视图中。此类集成信息的使用者是直接与数据库交互的传统应用程序，需要能够访问经过扩展的数据源集。有关如何最好地提供此统一视图的决策通常是根据组织中的工具可用性、经验、专业知识以及企业文化做出的。使用传统遗留体系结构时，与集成关联的时间、工作量以及成本可能会超过所带来的业务好处。在基于服务的环境中实现了基于模式的信息服务方法后，可以增强系统长期的可重用性特征。
信息服务是 SOA 的核心中枢的一部分。这些信息服务提供了对域信息的创建、读取、更新和删除 (CRUD) 访问。它们还可提供各种信息处理功能，如通过分析和评分算法、数据清理规则等进行处理。对于本文，我们将重点讨论可提供统一数据视图的信息集成服务，而这通常会涉及到对各种异类后端源和服务进行集成。
应用数据联合模式时，我们需要对两个上下文进行区分：传统的非 SOA 上下文（由很多以前的应用程序加以处理）和 SOA 上下文（本文的重点）。务必记住，SOA 是一种体系结构方法，可通过其得到可重用服务，能在很多情况下扩展现有非 SOA 实现的功能。
在我们称为传统上下文的环境中，银行的报表应用程序可能需要分析信用卡事务。考虑到此数据的量（每天数百万事务），将所有这些信息存储在分析数据仓库中并不是有效的办法。会频繁访问很多旧数据，将其作为特定的上下文信息，如旅行路线等。将所有信用卡事务数据——当前的和过期的、核心的和相关的——存储在数据仓库中会对性能造成负面影响。一种更好的解决方案是将两种类型的数据加以分离：例如，可将常用、最近使用的信息库事务存储在数据仓库中，而将旧信息存储在磁带上。不过，报表应用程序应该不需要知道这种可通过联合方法提供的数据分布。
在此传统上下文中，应用程序通常使用标准关系接口和协议来与联合服务器（如 SQL 和 JDBS/ODBC）交互。联合服务器将随后通过各种适配器或包装连接到各种数据源，如关系数据库、XML 文档、已打包的应用程序和内容管理及协作系统。联合服务器是一个虚拟数据库，具有关系数据库的所有功能。请求应用程序或用户可以在其访问权限内执行任何查询请求。查询完成后，将返回一个结果集，其中包含满足选择条件的所有记录。此过程如图 1 中所示。此图旨在演示可以基于使用 SQL (JDBC/ODBC) 或 XQuery 的关系应用程序编程接口的传统实现。
在 SOA 上下文中，服务 getCustomerCreditCardData 可能需要检索有关客户及其信用卡事务的全面信息。此信息可能并不是驻留在单个系统中。客户信息可能存储在客户主数据管理系统或多个存储库中，而信用卡事务则可能存储在另一个数据源中。数据联合将对来自多个源的信息进行联接，以便能作为服务向使用者提供。
在此 SOA 上下文中，联合服务器充当使用 SOA 一致接口的服务提供者和/或服务使用者。请注意，这并不排除服务器还会提供对传统关系接口的支持。支持的深度是一项实现决策，这超出了本文所讨论的范围。当数据联合服务器将集成信息作为服务提供者公开时，服务使用者可以通过服务接口（如 WSDL 和 HTTP/SOAP 或其他事前确定的绑定）来访问此集成信息。数据联合服务器可以使用（为了集成）多个信息源提供的服务。
在 SOA 上下文中使用数据集成模式的基本想法是利用和重用集成信息，即，信息集成服务能以可扩展的方式供各种使用者使用。服务的建模和定义是 SOA 的关键方面。一个受到广泛认可的非常好的实践是，将服务设计为能提供信息或功能的重用和/或跨企业互操作性和/或业务流程支持。很多（如果不是大多数）成功的 SOA 项目都将重点放在作为服务公开的最重要、最广泛使用的业务功能上。由于这些服务扮演着关键的角色，因此经常会涉及多个后端系统。因此，从多个异类源收集信息是 SOA 依赖的一项重要需求和功能。服务并不是传统数据访问上下文中的查询，而是对业务实体的请求，可以由联合服务通过一系列查询和其他服务加以满足。
在 SOA 内启用信息集成服务需要使用额外功能，以在面向服务的接口中封装联合访问。这是通过 Information Service Enablement 实现的。此组件用于在面向服务的接口中提供一些联合查询。例如，可以使用 SQL 编写联合查询，并可以指定对产品信息的访问。通过 Information Service Enablement 组件，此联合查询可以作为使用特定机制（如 SCA 或 WSDL）定义的服务提供。实现对产品数据的访问的服务可以随后在整个企业内和企业外进行共享。
在传统上下文中应用数据联合模式的解决方案可以利用 SQL 的声明性和灵活性特征。通过使用恰当的安全凭据，使用者可以访问源中的任何数据，而此过程可能涉及的不同 SQL 查询的数目几乎没有限制。使用者在访问的内容及结果返回的格式方面具有极大的灵活性。尽管在很多情况下，这个灵活性是一个很大的优势，但也增加了使用者所面临的复杂性。使用者必须了解源数据模型以及如何从这个基础源数据模型构造结果。源数据模型越大，此任务就会变得越复杂。
SOA 方法的重点是首先将数量相对有限的最关键业务功能定义为服务，并在整个企业内和企业外进行共享。因此，面向服务的接口更多的是关注数量有限的需向外提供的特定信息请求。这个清楚而集中的重点可为开发人员带来好处，因为这样可以减少他们设计信息请求的时间。他们可以直接从数量相对有限的选项中选择恰当的服务。
在当今业务驱动的环境中，架构师和开发人员要实现数据联合解决方案的情况非常普遍。他们所面临的挑战通常受到一系列体系结构决策的影响，而后者实际上又受到技术、业务或合同方面约束的影响。此场景中包含多个此类常见约束。首先，支持项目的信息访问要求所必需的数据驻留在多个源中，必须对其进行集成，并作为单个结果向用户提供。其次，无法对目标数据源进行复制来满足访问需求。最后，解决方案必须在现有 SOA 内集成，并仍然支持传统的非 SOA 应用程序，如图 3 中所示。
正如问题说明中所述，此方法的目标是避免提供异类源的集成视图时出现数据冗余。数据联合服务器——即实现数据联合模式的组件——必须针对传统非 SOA 上下文提供标准查询接口。这可确保各种各样的传统数据库应用程序能够使用联合数据。联合服务器还必须提供查询优化功能，以最高效地响应请求。此上下文中数据的分发和异类性特征决定了必须重点强调如何最好地转换对集成视图的访问，以及如何分解和分布工作负载。支持对此集成视图的写访问时，联合服务器必须将各个源中的数据操作同步到逻辑工作单元中。这可确保满足事务的原子性、一致性、隔离和持久性 (ACID) 标准，且保证引用完整性。
除了针对传统上下文的这些目标外，此方法还必须适合在 SOA 中使用。这将允许企业内外的各个用户能够有效地重用集成视图。SOA 中的联合访问的潜在使用者是需要访问分布式信息的应用程序、门户和业务流程中的活动。例如，制造商可能定义从异类源检索实时库存信息的服务。内部应用程序和外包业务合作伙伴可以访问相同的服务，从而利用此联合访问的一致且最高效的实现。
在传统上下文和 SOA 上下文中，数据联合服务器提供了有效联接和处理来自异类源的信息的解决方案。此模式实现了处理分布式数据的同步实时集成方法。数据联合服务器负责接收定向到各种源的集成视图的查询。它会使用复杂的优化算法对其进行转换，从而将查询拆分为一系列子操作（称为查询划分与重写），然后对相应的源应用子操作，从每个源收集结果，组装集成结果，并最后将集成结果返回到原始查询。此处理序列将以同步的方式实时完成。
数据联合模式要求对集成视图范围内来自各个数据源的数据元素进行映射。例如，上面示例中提到的保单持有人姓名和地址等客户信息可以存储在一个数据库内的单个表中，也可以存储在另一个数据库内的多个表中。为了构建集成视图，需要将这些不同类型的表示形式映射到公共视图中。映射可以由相关人员手动执行，也可以采用基于各种映射算法（还会捕获任何必要的转换需求）的最新工具辅助完成。这就允许数据联合服务器接收对集成视图的查询和计算要执行的最优子操作数量和类型。
在 SOA 上下文中应用数据联合模式时，需要在 SOA 内将一组联合查询作为服务启用并注册。例如，用于检索保单持有人的关键结构化和非结构化信息（如姓名、地址、状态、索赔文档、维修费用预估和风险评级等）的集成视图可以作为服务启用，并在多个用户间共享。设计时的映射结果通常为联合视图，与关系数据库视图类似，可以随后在联合服务器上进行部署或创建。
数据联合服务器接收对集成视图的请求。根据映射定义，联合服务器将联合查询拆分为多个子操作。多个因素会对此步骤造成影响：
- 响应联合查询所必需的数据驻留在何处？
- 为了将异类源表示形式（如不同的数据类型、规范化模型与非规范化模型）转换为公共集成视图，必须执行哪些操作？
联合服务器使用映射信息来解决这些问题。还有很多其他因素会影响联合查询处理，这将要求使用映射规范之外的其他信息，如：
- 系统管理数据源支持哪些操作，哪些操作必须由联合服务器提供补偿机制？
- 在源中执行一系列操作与在联合服务器上执行这些操作的性能影响如何？联合服务器应将哪些操作委派给源，以便更好地利用源的功能、减少数据传输以及优化总体性能？
回答这些问题需要使用源系统及其查询处理功能方面的知识。为了处理后一个问题，联合服务器还必须使用一系列关于操作环境的信息以及源数据的统计数据。
联合服务器确定了所有子操作的非常好的执行策略后，将连接到数据源——包括结构化和非结构化信息的数据源——以检索相关数据（可能会使用源特定的接口）。根据总体查询执行计划，将随后对数据源执行各个子操作。将接收结果并聚合为集成视图的结果。然后会将此结果返回给使用者。
在 SOA 上下文中，使用者通过预定义的请求格式向联合服务器提交请求。联合服务器将请求转换为对应的 SQL 查询或视图定义，以支持服务。从此时开始，将执行与以上所述相同的查询分解、优化和执行步骤。SOA 中唯一的区别在于最后一步。联合服务器会将传统数据联合方法的结果转换为服务响应，并随后通过预定义的服务接口将其返回给服务使用者。
数据联合模式的功能可以通过使用数据相关的技术（如优化器或补偿）或自己开发的应用程序来实现。由于异类源上的查询优化的复杂性，行业非常好的实践是使用数据联合实现来利用大多数数据库管理系统提供的查询优化技术。
应用数据联合模式时，务必理解其特征以及其受以下所述的非功能要求的影响情况。一定要注意，我们列出的功能要求并不考虑缓存和数据复制模式。我们认为，当采用以基本模式（本例中为数据联合）为基础模式时，可以随后通过其他模式对其进行扩展，以便满足服务的额外非功能要求和功能要求。可以使用缓存和数据复制模式来补充数据联合或形成组合模式。应小心使用这些模式以及可以在总体实现中使用的其他模式，因为它们可能会妨碍最初选择数据联合来解决的一些非功能要求的实现。例如，它们可能会增加数据延迟和导致数据冗余。需要了解非功能要求和体系结构决策之间的得失。
非功能要求的所有特征既适用于传统的非 SOA 上下文，也适用于 SOA 上下文。其包括：
只有具有所集成源中的恰当凭据的用户和应用程序才允许访问集成视图。可以对此进行进一步的限制。应用此模式的一个主要原因是要利用现有源系统的数据和功能。因此，架构师经常还希望利用现有的安全机制，如源系统的身份验证和授权。由于此环境具有异构和分布式的特点，可能会出现数据联合模式外的有关单点登录和全局访问控制的挑战。为了应对这些挑战，架构师将需要把数据联合模式与其他安全相关的模式结合使用。
数据联合模式允许以实时集成的方式访问源，具有最高的数据并发级别。
由于能在接收到集成视图请求时实时地访问源数据，因此数据联合将始终返回最新的源信息。由于数据联合模式并不会创建源数据的副本，因此源更改并不一定要采用这种方法进行传播或处理。
由于需要执行的复杂数据清理、标准化和转换操作的频率增加，因此对总体响应时间造成负面影响的概率也会增加。这是由于数据联合模式中的请求对应的响应的实时同步特征造成的。任何额外的转换都将意味着响应集成查询时会存在额外的工作负载。最好的做法是尽可能减少所需的字段转换的复杂性和数量。
集成数据的可用性依赖于数据联合服务器和集成源服务器在请求时的可用性。如果某个服务器或联合与源服务器间的任何连接失败，集成视图就不可用。
数据联合模式的一个非常重要的好处是，能够屏蔽在源系统中实现的很多模型更改。如果能够将更改限制在联合服务器中，就可以减少将这些更改向服务的发起方或使用者公开的可能性。此外，还能够在无需将更改传播给数据源模型的情况下在集成视图中进行更改。
对联合服务器的请求是采用同步方式执行的。只要接收到响应，请求者就可以调用后续请求了。联合服务器应支持由多个请求者发起的并发请求。频繁的后续请求应该与单个请求具有相同的性能特征。如果源——或联合服务器和源之间的连接器——具有特定特征，在访问频繁时会导致响应性能下降，则可能会出现异常。联合服务器高速执行事务的能力是由联合服务器访问源系统的速度以及这些源系统响应的能力决定的。
在很多情况下，数据联合服务器都具有与数据库或内容服务器很类似的特征。有效管理并发访问的能力由数据联合服务器和所集成的源服务器的性能特征决定。
事务响应时间由很多因素决定，包括：
- 联合查询的复杂性：为了执行查询，联合服务器需要执行多少筛选、联接、排序之类的子操作
- 数据联合服务器的查询优化和处理功能：联合服务器的设计用于处理以下方面的成熟程度——接收联合查询，将其拆分为子操作并进行优化（例如，首先应用筛选器等一些子操作来减少数据集大小，然后执行排序等子操作）
- 数据量：数据量越高，每个子操作执行的时间越长，因此查询的完成时间也就越长
- 网络带宽：联合服务器和源之间的网络连接的吞吐量将影响联合服务器访问源的速度，因此也会影响联合查询的总体响应时间
- CPU 使用率：联合服务器和数据源所在的计算机上的资源使用率的差异需要影响总体联合查询的哪些子操作在联合服务器上执行、哪些在源上执行（如果可能）
- 源服务器的查询处理能力：有些源服务器在其处理和优化影响总体性能的查询方面具有特定的特征和限制
- 联合服务器标识每个数据源的最后查询策略的能力：如果联合服务器能了解源服务器的查询处理能力，则可以确定可委派何种类型的子操作以及何种子操作要在联合服务器层执行
数据联合模式（从分布源获取数据）实现的虚拟数据库的查询响应时间可能比在具有相同功能的单个物理数据库上执行相同的查询长。响应时间的差异将根据上面列出的各个元素的不同而有所变化。因此，在单个物理数据库中提供集成数据集的替代模式的响应时间会有所改善。数据联合模式的有些实现可以将部分或全部子操作（子查询）以并行方式发送到集成源系统。子操作的并行处理能够大幅度改进响应时间。
大部分联合实现都支持不同程度的读写访问。有些实现会对写入操作的逻辑工作单元进行协调，这被称为两阶段提交。在大多数情况下，由于写访问非常复杂，因此数据联合模式主要用于进行读访问。如果没有两阶段提交支持，请求者需在更新数据时负责确保源中的一致性。由于两阶段提交通常要求使用事务管理器，写访问的支持程度可能会根据事务管理器实现的不同以及源服务器在应用和提交更改方面的功能的差异而有所不同。
响应时间受到每个事务需要从远程源传输到联合服务器的数据量的影响：数据量越大，响应时间越长。优化联合查询对联合服务器非常重要，能尽可能减少必须在联合服务器和源之间传输的数据量，特别在联合数据量很大时更要如此。另外，务必还要了解网络基础设施所支持的功能和带宽以及可能对所传输的数据的数量和频率的影响。
正如价值主张中提到的，数据联合可以大幅度改进集成各种源时的交付时间。
数据联合模式的重点是数据源的集成和通过面向数据的接口提供单个系统映像。当将集成信息作为服务提供时，开发人员还将需要理解各个 SOA 概念、标准和技术。
有关定义数据访问和聚合的逻辑可以在不同的项目中加以重用。
数据联合并不会减少维护多个数据源的成本，但由于对现有数据源进行了集成和重用，可以获得更大的好处。
假定已经配备了联合服务器基础设施，则使用最好的联合引擎会相对较为廉价。
本文的重点是结构化数据的联合。目前，最常见的模型是采用 SQL 标准的关系模型。XML 和 XQuery 则是两项新兴标准，正越来越多地在信息管理中采用。数据联合模式的实现通常至少支持其中一种模型，有时候会同时支持这两类模型。数据联合模式的大部分实现都比较强调一个（或数量很有限的）目标模型，以最有效地处理请求。
在 IBM SOA 参考体系结构中，企业服务总线（Enterprise Service Bus，ESB）是基础设施中的一个关键组件。ESB 的责任之一是提供有保证的交付。由于协调逻辑工作单元（如在联合环境中通过两阶段提交协议进行协调）的复杂性，并非数据联合模式的所有实现都支持此功能。当使用支持此功能的联合服务器时，需要对其数据库锁定策略进行仔细分析，以避免对源系统的性能造成负面影响。
联合服务器仅在处理从使用者接收到的请求时才会使用资源。联合服务器的资源使用率水平是由请求的复杂性决定的：请求越复杂，查找将此联合请求分解为子操作的最优计划的任务就越复杂。资源使用率的另一个影响因素是需要在联合服务器上执行的子操作（如补偿源系统所缺少的功能）与可以下推到源系统的子操作的百分率比值。另外，从源系统接收到的数据量和需要通过联合服务器的数据量也影响资源使用率。
联合模式的重点是让数据保持在原来的位置，并提供实时的虚拟集成视图。此模式中的解决方案对可以应用何种转换并没有限制。可以在很多实现中使用基本转换来将异类源格式转换为联合层的公共视图。不过，复杂转换对联合模式的性能有负面影响，从而会降低此模式对此类场景的适用性。因此，大部分数据联合模式的实现对复杂转换功能的关注相对较少，而更强调查询优化技术。
数据联合处理有关集成来自异类源模型的数据的问题，包括将这些不同的源模型映射到联合层的公共模型的概念。数据联合模式的实现在其可以集成的具体源模型的能力方面各有不同。
当在运行时期间将基础源映射到集成视图时，源模型的大小、属性的数量和类型可能对映射任务造成负面影响。范围越大（例如要访问的属性数量越多），标识对应元素的时间可能越长。
联合服务器会将其接收到的每个请求的子操作转发到源系统。这将对源系统的资源使用率造成负面影响，因为需要对来自联合服务器的子操作做出响应。联合服务器接收到的请求越多，发送到所集成的源系统的子操作越多。
我们在本文中对数据联合模式进行了说明，此模式是一种处理对集成临时（虚拟）视图的数据操作的方法，而此类视图中的实际数据都存储在多个不同源系统中。我们在本文中主要讨论的是 SOA 上下文中的情况。我们最后将总结何时应用数据联合模式及何时不应用此模式，并将列出重要的约束。
- 上市时间是具有优异优先级的开发目标之一，数据联合可快速提供对信息源的访问，而不需要进行长时间的信息管理基础设施变更。
- 数据联合通过允许按照数据驻留在源上的方式访问数据，从而支持与数据复制和重复相关的要求。这些要求可能是为了响应法律法规或规则对数据移动或复制的限制，如订阅数据或来自不同国家的个人信息混合存在的情况。
- 像访问单个源的数据一样实时访问分布式信息。信息可以为结构化和非结构化数据。
- 用于动态更改环境（特别是模式更改的情况）的灵活的可扩展信息集成方法：由于没有数据冗余，联合模式中的更改会减少更改对所集成系统的影响。
- 当接收到的请求数量适中，而来自多个异类互补数据源的结果大小有限时，可非常好的地利用数据联合的优势。
- 需要复杂转换来构建集成视图的场景将对响应时间造成负面影响，尤其是采用这种方法时。
- 源服务器可能在必须返回联合查询中请求的数据时受到工作负载增加的负面影响。为了将请求处理到集成视图中，联合服务器将向所集成的源发送子操作。这些子操作越复杂，其发送到源系统的频率越高，源服务器需要管理的额外工作负载也就越多。
- 导致大量过渡结果集从目标数据源移到联合服务器的情况可能带来很大的性能影响。
- 应用程序要求相对较高的集成数据可用性的情况可能不适合应用这种模式。集成数据的可用性完全依赖于过程中涉及的所有联合服务器和源服务器的可用性以及网络的可用性、容量和响应能力。
- 数据联合的很多实现具有受限的数据操作功能。很多将 SQL 作为编程语言使用，且仅支持 SQL 转换。
- 性能很大程度上依赖于供应商特定的实现在缓存功能、理解异类数据源和确定非常好的联合查询和执行路径方面所表现出来的成熟度。
- 不同信息源的读写访问（特别在对逻辑工作单元进行协调时）将受到供应商特定的支持的约束。
