摘 要：探讨了在以服务为中心的网格环境中分布式查询的原理及其实现机制，介绍了传统的数据库技术在网格环境中部署和使用的方法，提出了分布式查询引擎需要处理的问题及目前的解决方案。
关键词：分布式查询网格服务OGSA
网格是近年来国际上兴起的一种重要信息技术。它将高速互联网、高性能计算机、大型数据库、传感器、远程设备等融为一体，实现计算资源、存储资源、信息资源、知识资源等的全面共享，消除信息孤岛和资源孤岛。简言之，传统因特网实现了计算机硬件的连通；Web实现了网页的连通；而网格试图实现互联网上所有资源的全面连通。网格在动态变化的多个虚拟机构间共享资源和协同解决问题。
网格中的资源是分布式的，所以基于网格的查询是分布式查询。分布式查询已被广泛地用于数据密集型的应用程序，用户关心的数据存放于多个位置，而且是异构的、分散的和自治的，因此需要提供一种集成数据资源的方法。网格资源的异构特性及其网格环境动态变化的特点给分布式查询处理技术带来了新的挑战，传统的技术已经不能满足网格环境的需要。网格的基本功能(如对远程数据和计算资源的访问、动态资源发现、分配和监控机制)为分布式查询处理提供了技术基础。网格服务的属性（如注册、元数据管理、通知机制、动态服务创建和生命周期管理等）与分布式查询处理引擎的实现密切相关。
1 分布式查询处理原理分析
图1是一个典型的分布式查询处理(Distributed Query Processing，DQP)机制的示意图，在很多与分布式查询处理相关的文献中都可以看到。这个图表示了二个阶段的优化，第一个阶段是单节点优化，第二个阶段是多节点优化。当一个查询被提交以后，首先经过一个分析过程，分析器根据数据源的元数据信息进行类型和一致性检查，将分析结果表示为一棵树。然后将这棵树提交到逻辑优化器产生一个逻辑计划，逻辑计划表示成另外一棵树，它的叶子节点与执行查询所需要的操作符相对应。通过物理优化，逻辑计划转化成一个物理计划（也是一棵树）。因为一个逻辑操作符可能与很多个物理操作符相对应，需要使用代价模型选择一个执行时开销可能最小的计划。逻辑和物理优化器组成了单节点优化器并产生了一个连续计划。在并行和分布式系统中，划分和调度问题在优化阶段产生。为了最大程度地利用并行性，一个查询计划可能被划分成多个子计划，然后通过调度器分配机器资源。
以上介绍了普通的DQP结构，下面结合网格的特点，给出在以服务为中心的网格环境中实现分布式查询引擎（DQPE）必须满足的一些条件。
(1)自适应性。网格环境中数据源的统计信息是不准确的，而且环境不可预测及易变，只根据编译时得到的信息很难产生有效的查询计划。因此DQP引擎必须利用查询运行时的信息并根据运行时环境的变化修改查询计划，也就是设计出具有自适应性的分布式查询引擎。
(2)进度监控。查询进度的监控是实现自适应性的基础条件，并且必须解决基于OGSA（开放网格服务体系结构）统一的实现框架，否则无法在实际中应用。
(3)对数据库中数据和元数据的标准访问。在以服务为中心的体系结构中，数据源都被包装为服务，查询引擎需要访问数据和元数据以获得查询优化时所需要的信息。其中OGSA-DAI的GDS[5]就提供了对数据库中数据及其元数据的一致访问。
2 与DQP设计相关的网格服务属性
OGSA为网格中的资源共享提出了一个以服务为中心的框架。OGSA首先为网格服务提出了一套约定和行为，一个有状态的服务实例支持可靠和安全调用、生命周期管理、通知、策略管理和信任状管理。网格服务规范也定义了动态创建服务实例和发现这些实例的接口。网格服务能维护元数据，而且支持对这些元数据的查询。下面着重讨论一些与分布式查询处理引擎实现有关的网格服务属性。
2.1 注册和服务元数据
OGSA中的注册机构拥有一个服务句柄（GSH）列表，每一个句柄拥有与这个句柄表示的服务有关的静态元数据信息的一部分。一旦选择了一个句柄，就可以进一步查询与这个服务相关的更多的元数据。在分布式查询处理中注册的一个重要用途就是发现相关数据源的元数据。在查询的分析和类型检查阶段，DQP引擎查阅这些数据源，根据实现的数据库的模式、支持的查询语言及其提交结果的格式等弄清功能。
注册的另外一个用途就是DQP引擎需要发现监控服务，它监控网格上的计算资源，并提供有如处理器的数目、内存容量等的统计信息，还有像某一时刻某一节点处理器的负载、当前可用的内存、当前的网络通信量等动态信息。
2.2 动态服务创建和生命周期管理
一个分布式查询处理引擎应该能动态地利用网格上可用的机器分发和执行一个个查询子计划，这就需要动态创建和部署能执行这些子计划的服务，并且必须使服务实例提交完任务之后能撤销，从而释放它所利用的资源。网格服务规范为Factory创建服务实例定义了端口类型和相关的操作，撤销操作通过显式的destroy操作或者通过软状态方法实现。
2.3 通知机制
网格服务的状态信息会随着系统的运行而发生变化。网格服务之间的许多交互要求动态地监控状态的变化。通知把一种传统的发布（NotificationSource）和订阅（NotificationSink)范式应用于这种监控。网格服务支持一个接口，以允许其他网格服务订阅进行变更。OGSA的通知接口为构建一个进度监控系统提供了一个潜在的机制。
3 OGSA环境中的DQP实现机制
这一节主要介绍在基于OGSA的环境中执行分布式查询所涉及到的服务交互。
3.1 查询分析和解释
图2中设计了四个主体元素：客户（Client）、注册机构(Registry)、分析器（Parser）和网格数据服务GDS(Grid Data Service)。Registry是由许多组织共享的一个虚拟组织注册机构。在OGSA环境中，它包含了关于服务的大量信息。
从图2中可以看出，客户提交请求后，分析器为了获得在类型检查阶段所需要的元数据信息，开始搜索与查询相关的GDS。实际上，GDS句柄在DQP实例被创建时就已经可以得到。分析器访问GDS，以获得执行任务所需要的更多的元数据。
3.2 单节点优化
网格资源监控服务（GRMS）通过图3所示的注册机构注册，它部署在网格上并提供关于计算资源状态的实时统计信息。分析器产生一个输出并将其表示为一棵树后，分布式查询优化器将查阅注册机构以获得在查询中涉及到的GDS的元数据、可用计算资源的信息以及当前计算负载。计算资源信息对查询计划的产生也是必不可少的。
3.3 查询计划的调度和执行
执行者(Evaluator)是一个服务，它负责子计划的执行。执行者工厂(Evaluator Factory)是一个永久服务，它实现了网格服务工厂端口类型（Grid Service Factory Port Type）。正如图4所示：当优化器使用从GDSs和GRMSs获得的元数据产生了优化的子计划后，它要把这些子计划分布到各个节点上执行，其关键是子计划与具体的机器资源的映射。优化器根据它获得的元数据信息及其查询特征把Evaluators部署在网格中的多个节点上，这就需要动态地创建和部署Evaluator实例。OGSI提供了动态创建服务实例的机制。
3.4 查询进度监控
优化器服务的内部部件也值得注意。图5中解决的主要问题是基于进度监控的自适应行为的处理。可以使用OGSA通知机制创建一个进度监控框架。为了实现这个目标，优化器应当实现OGSA 信息接收端口类型(Notification Sink Port type），并且应当有一个内部元件监听Evaluators发来的消息。Evaluators充当了一个信息源的角色。很显然，进度消息的内容在这里很重要。对于这个通知消息需要有一个标准的模式，有利于优化器产生有效的应答。
4 结束语
本文主要分析讨论了在OGSA环境中实现和部署分布式查询的工作原理与实现机制。在此研究工作中需要注意：DQP访问数据时遵循一种标准、统一的方式；服务实例的创建、动态部署和生命周期管理对DQP的运行有重要的影响；查询进度监控的设计影响整个系统的性能。下一步的工作是研究查询引擎的自适应性，深入优化查询服务。
参考文献
1 Gounaris A，Paton N W，Fernandes A A A et al.Adaptive query processing：A survey.BNCOD，2002；(19)
2 Hellerstein J，Franklin M，Chandrasekaran S et al.Adaptive query processing：Technology in evolution.IEEE Data Engineering Bulletin，2000；23(2)
3 Alpdemir N，Mukherjee A，Paton N W et al.Service-based distributed querying on the grid.In：Proc.of ICSOC，LNCS，Springer，2003
4 Foster I，Kesselman C，Nick J M et al.Grid Services for Distributed System Integration.IEEE Computer，2002；35(6)
5 Krause A，Sugden T，Borley A.Grid Data Service.Technical report，OGSA-DAI，2003.Document Identi_er：OGSA-DAI-USER-UG-GDS-v4.1，July，2003;6