摘 要： 探討了在以服務為中心的網格環境中分布式查詢的原理及其實現機制，介紹了傳統的數據庫技術在網格環境中部署和使用的方法，提出了分布式查詢引擎需要處理的問題及目前的解決方案。
關鍵詞： 分布式查詢 網格服務 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