虛擬天文臺數據訪問系統(VO-DAS)任務調度設計與實現*

田海俊，劉 超，高 丹，路 勇，楊 陽，崔辰州，趙永恒，鄭小平

(1.華中師范大學物理學院，湖北 武漢 430079;2.中國科學院國家天文臺，北京 100012)

1 概述

天文信息爆炸式增長不僅給天文學家的天文發現帶來了巨大的機遇，同時也帶來了數據存儲、訪問和處理等方面的巨大挑戰。每天GB、甚至TB數量級的觀測數據如何存儲，各國的巡天數據如何共享，歷史遺留的存儲格式、管理模式等方面的差異性如何解決，天文學家如何從如此海量的天文數據中方便地提取自己需要的數據等等一系列問題不斷地困擾著正為數據的“富裕”而喜悅的天文學家。

解決異地、異構、海量天文數據無縫透明地統一訪問，是近年來國際虛擬天文臺聯盟(IVOA［1］)一直致力的問題。計算機科學技術的飛速發展，不斷為這一難題帶來新的希望。世界各國虛擬天文臺項目、天文臺數據中心以及大型巡天觀測項目紛紛提出了自己的解決方案。比如美國國家虛擬天文臺(NVO)先后提出的 Sky Query［2］原型和 Open Sky Query［3］原型;IVOA 制訂的 Sky Node［4］數據訪問模型;英國的 Astro Grid［5］項目; 法國的 Centre de Données astronomiques de Strasbourg(CDS)［6］采用自己設計的一系列協議以及Web服務實現了一個完整的天文資料(包括星表數據和文獻等)訪問系統;美國的大型巡天觀測項目Sloan數字巡天(Sloan Digital Sky Survey，SDSS)［7］，基于Microsoft技術，開發了Sky Server數據訪問系統。雖然已經有了上述若干數據訪問方案的提出，但還沒有一種方案完全滿足天文學家的需求，它們要么因為所選擇的網絡技術限制了其功能，要么因為僅為專門的項目服務限制了應用范圍和互操作性。

在這些研究、試驗的基礎上，IVOA正不斷制訂、完善各種相關標準協議。基于這些協議，China-VO研發小組自主設計了虛擬天文臺數據訪問服務(VO-DAS)。該系統利用OGSA-DAI(Open Grid Services Architecture-Data Access and Integration，開放網格服務體系結構——數據訪問與集成)［8］中間件實現了異地異構的星表數據、圖像數據和光譜數據的統一封裝;利用ADQL(Astronomical Data Query Language，天文數據查詢語言)［9］完成了對任務的統一描述;基于WSRF框架完善了對數據資源、計算資源以及存儲資源任務的統一調度;借助國際通用Registry［10］(比如英國Astro Grid)服務，實現全球數據資源的統一描述和發現。這將使天文數據源的多波段交叉證認、海量數據分析及可視化等成為可能。支持國際虛擬天文臺聯盟(IVOA)的各項標準，使得VO-DAS具有良好的互操作性，它的對外接口簡單實用，可以針對不同需求的天文數據用戶開發出多種網格應用產品。

2 VO-DAS主要接口及框架設計

VO-DAS表現為一個基于Web服務資源框架(Web Services Resource Framework，WSRF)的網格服務，因此它的接口通過一個Web服務定義語言(Web Services Description Language，WSDL)文件就可以完全描述。將VO-DAS的接口分成5個類型:資源元數據接口(Resource Metadata Interface，RMI)、數據查詢接口(Data Query Interface，DQI)、數據分析接口(Data Analysis Interface，DAI)、數據分發接口(Data Delivery Interface，DDI)和操作管理接口(Management Interface，MI)。5個接口的詳細描述參見文［11］。

圖1 VO-DAS的設計Fig.1 Out VO-DAS design

VO-DAS構建在Globus Toolkits 4(GT4)［12］之上，這一方面是因為GT4提供的帶狀態的Web服務(WS)完全滿足需求，另一方面因為這樣可以和OGSA-DAI中間件保持一致的架構平臺。

總體設計如圖1。全系統分成兩個部分:VO-DAS和Data Node。圖1的上部框圖是VO-DAS部分的設計示意圖。VO-DAS框圖的最上方是面向客戶端的WSRF服務接口。VO-DAS的核心是Task Queue和ADQL Parser。框架中各模塊的描述以及用于任務描述的天文數據查詢語言(ADQL)、數據格式、數據分發、Data Node等詳細闡述請參見文［11］。

3 VO-DAS的任務調度方案設計

任務調度3種可選設計方案:

(1)基于Web服務(Web Service，WS)。Sky Node是基于WS設計的，支持異地異構的多波段天文數據的交叉證認。但是由于WS的限制，Sky Node僅僅能夠用來對小數據集進行操作，無法完成大數據集的訪問和交叉證認。同時WS是無狀態的，只能借助其他方式，比如利用Tomcat容器來維護狀態信息，所以WS無法滿足異步查詢的要求。

(2)基于網格服務基礎結構(Open Grid Service Infrastructure，OGSI)［13］規范。該規范通過擴展Web服務定義語言(Web Services Description Language，WSDL)［14］和XML Schema的使用，封裝資源的狀態，將具有狀態的資源建模為Web服務方式，來解決具有狀態屬性的Web服務的問題。但這方式有以下缺點:過分強調網格服務和Web服務的差別，導致了兩者之間不能更好地融合在一起;Web服務和XML工具不能良好工作，可能會造成移植性差的問題;有些Web服務的實現不能適應網格服務的動態創建和銷毀等等問題。如果VO-DAS基于OGSI會導致VO-DAS先天不足。

(3)基于Web服務資源框架(Web Services Resource Framework，WSRF)［15］。WSRF采用了與OGSI完全不同的定義:資源是有狀態的，服務是無狀態的，很好地解決OGSI和Web服務之間存在的矛盾。WSRF的規范是針對OGSI規范的主要接口和操作而定義的，它保留了OGSI中規定的所有基本功能，只是改變了某些語法，并且使用了不同的術語進行表達;同時，使用WSDL 1.1定義OGSI中的各項能力，充分兼容現有的 Web服務。基于 WSRF的 VO-DAS，同時融合 OGSA-DAI及 WS-Notification(Web Services Notification，Web服務的通知機制)，可以有效地完成對大數據量的操作、異步操作等。

3.1 VO-DAS的執行流程

在詳細探討VO-DAS的調度邏輯之前，明確VO-DAS的執行流程很有必要。VO-DAS的執行流程通常有3類場景:同步查詢、異步查詢、異地異構數據的聯合查詢。其中異地異構數據的聯合查詢最為典型，本文著重以該場景為例闡述VO-DAS的執行流程。

圖2以3個節點為例，展示了VO-DAS執行異地異構數據的聯合查詢。該場景的執行流程概括如下:

A 搭建有效數據節點，并主動向VO-DAS的注冊(Registry)模塊注冊。

B VO-DAS服務器自啟動時刻起，間隔一定時間(默認1小時)從Registry模塊讀取有效數據節點信息，以確保數據節點的及時性和有效性。

C 用戶從客戶端提交ADQL查詢語句。

D VO-DAS調用ADQL解析模塊(ParseADQL)，檢查ADQL中涉及的數據資源的DataNode的有效性，并按照傳輸數據最少的原則為所涉及的DataNode排序并生成每個DataNode的執行計劃對象(ExecPlan)，然后進入排隊列表中，等待有效執行線程，并將任務狀態置為“WAITING”(等待中)。

E 當VO-DAS服務器發現有空閑線程時，首先將任務狀態置為“PROCESSING”(處理中)，然后按照執行計劃從第1個數據節點查詢數據，將查詢結果傳送到第2個數據節點，并在第2個節點創建一個臨時表存儲查詢結果，以便下一步的交叉證認。

圖2 VO-DAS的執行流程示意圖 (僅以三個DataNode的聯合查詢為例)Fig.2 The Workflow of our VO-DAS(in an example of associated query of three data nodes)

F VO-DAS向第2個數據節點查詢數據，同時和上一步生成的臨時表進行交叉證認(CrossMatch)，并將交叉證認結果傳輸到下一節點。

G 以同樣的方式處理第3個節點(或者更多節點)，VO-DAS會將最終的處理結果保存在MySpace中，并將任務狀態設置為“COMPLETED”(完成)。自此，VO-DAS服務器完成一次查詢任務，并釋放執行線程。

H 異步查詢時，客戶端從提交任務后，可以隨時查看任務的處理狀態，當發現任務狀態為“COMPLETED”時，便可以到MySpace提取結果了。

在上述執行流程中，一旦出現錯誤，VO-DAS將立即將任務狀態置為“ERROR”，并結束此次任務。相比而言，同步查詢的執行流程和異步查詢要簡單的多，不用維護狀態管理，用戶提交數據后，直接等待結果的返回。所以，同步查詢適合小數據量的簡單任務查詢，而異步查詢適合大數據量的復雜任務查詢。

3.2 VO-DAS的Session機制

Web服務(WS)不帶狀態的，WSRF主要描述了帶狀態的Web服務框架，即WS－R=Web Service+Resource。VO-DAS對外發布的各個接口都是以WS形式發布出來的，而各個操作的中間或最終狀態信息，是通過Session來保存的，這里的Session對應于WSRF框架中Resource。Session與WS的搭配使用，如圖3是一個Factory/Instance(工廠/實例)模式，Session Home專門用來管理所有Session的一個類，Client端通過 Factory Service類調用 Session Home類的 create()方法來創建 Session;DAS Service是VO-DAS通過WS接口對外提供遠程操作的一個類，客戶端(Client)可以遠程調用DAS Service的相關方法，而每一次任務的操作狀態都可以通過與之對應Session來保存。

3.3 VO-DAS的生命周期

VO-DAS的生命周期分為3類:全局對象的生命周期、非全局對象的生命周期和Session的生命周期。全局對象主要包括LoopThread、WorkThreadPool、 WaitingQueue、 Data-ResourceMap等;非全局對象主要包括WorkThread;Session主要包括ExecPlan、status、targetURL等。本文主要討論異步操作的Session的生命周期的控制(因為對于同步操作的Session沒有實際意義，本文不做詳細討論)。

像LoopThread這樣的全局對象的生命周期是從VO-DAS啟動到VODAS的結束，不需要過多考慮。

當LoopThead監控線程發現有排隊的任務，同時檢測到工作線程池(WorkThreadPool)中有可用的工作線程時，非全局對象工作線程WorkThread才能生效，一直到這個線程將任務完成，自動結束，并由系統自動收回。WorkThread的生命周期主要由系統控制，也不需要過多考慮。

當Client端對VO-DAS有新的操作任務時，VO-DAS將首先為這次操作生成一個Session，并分配一個SessionID，這意味著Session“生命”的開始，但是Session的結束情況就比較復雜了，主要分為以下幾種情況:

(1)每一個Session都有一個預設生命期限TimeOut。它是由SessionHome在創建每一個Session的時候，VO-DAS給它預先設置了一個生命期限，比如不能超過6天(這個期限值可以在VO-DAS系統的配置文件中修改)。如果任務可以在預設生命期限內執行完成，那么用戶必須要在預設期限內提取相關數據結果(以后VO-DAS支持用戶注冊時，可以將執行完后的狀態信息永久保存在數據庫中);如果失效的Session“尸體”沒有及時處理，那么這種情況下，失效Session在到達預設生命期限時，自動由系統銷毀。

(2)如果VO-DAS在執行某次任務的過程中，程序出錯拋出異常，這就意味著該Session失效。在這種情況下，VO-DAS在異常處理時，首先將status置為ERROR。LoopThread線程一旦監控到狀態(status)為ERROR的Session，就會調用立即銷毀(Immediate Destruction)方法將該Session立即銷毀。如果不及時處理這些Session“尸體”，VO-DAS可能會因資源耗盡而被“拖死”。

(3)執行任務尚未完成，Session已經達到了預設生命期限TimeOut時，VO-DAS需要利用調度銷毀(Scheduled Destruction)方式管理生命周期。即通過周期性更新“租用時間”:如果TimeOut到期，發現狀態 (status)尚未被置于“COMPLETED”狀態，比如仍為“PROCESSING”狀態時，那么VODAS將延長TimeOut值，一直到任務執行完成。

(4)客戶端主動銷毀某次執行任務。這種情況需要調用VO-DAS發布的destroy()方法接口。其實，這種情況同樣是利用了Session的立即銷毀(Immediate Destruction)方法。

3.4 VO-DAS的資源銷毀

對于服務資源的銷毀操作，VO-DAS主要提供了兩種方式:一種是立即銷毀(Immediate Destruction)，一種是調度銷毀(Scheduled Destruction)。

圖3 VO-DAS Session機制Fig.3 Mechanism of Session management in our VO-DAS

(1)立即銷毀(Immediate Destruction)

當客戶端主動發出一個立即銷毀資源的請求，或異常出現時，服務器將會對不再使用的服務資源進行立即銷毀處理，以便收回占用的系統資源。在VO-DAS調度中比較典型的場景:客戶要刪除某次任務操作，并向服務器發出請求時，或者是服務器端監控到某次任務在被執行過程中拋出異常，導致任務無法繼續進行，即Status被置為“ERROR”時，系統會立即銷毀這次任務，并收回該任務所占用的系統資源。

如果Web服務資源(WSRF)沒有響應銷毀請求，則必須將返回異常信息:

A ResourceUnknownFault(服務資源標識無法識別):在銷毀請求文檔中的服務資源標識不能被服務器端識別。

B ResourceDotDestroyedFault(服務資源不能被銷毀):服務資源可能由于某種原因不能被銷毀。

(2)調度銷毀(Scheduled Destruction)

一種基于時間“租用”的方式來管理Web服務資源(WSRF)，在這種情況下，Web服務資源(WSRF)具有一個與之相關聯的生命終止時間(TimeOut)，這個時間定義了該Web服務資源(WSRF)預期被銷毀的時刻，這個時刻之前Web服務資源(WSRF)是有效的，超過這個時刻，系統將自動銷毀該Web服務資源(WSRF)。Web服務資源(WSRF)生命終止時刻可以通過查看TerminationTime特征值來獲取，也可以通過SetTerminationTime()方法還改變終止時刻。

在VO-DAS調度中比較典型的場景，每個Session被創建時，都設定了最大生命期，當系統發現在這個生命期內，相應的操作仍沒有完成時，系統將通過SetTerminationTime()方法，延長Session的生命周期。Web服務資源(WSRF)為了支持調度銷毀，Web服務資源(WSRF)必須包含如下的屬性定義:

A CurrentTime(當前時刻)，表示當前時刻。

B TerminationTime(銷毀時刻)，設定預期銷毀時刻。

如果Web服務資源(WSRF)不能在預期時刻成功被銷毀，則將返回異常信息:

A ResourceUnknownFault(服務資源標識無法識別):在銷毀請求文檔中的服務資源標識不能被服務器端識別。

B UnableToSetTermininationTimeFault(不能設置銷毀時刻錯誤):服務資源可能由于某種原因不能設置銷毀時刻。

C TerminationTimeChangeRejectedFault(更改銷毀時刻被拒絕錯誤)。

3.5 VO-DAS的異常處理

VO-DAS是一個相當復雜的系統，系統的層次關系比較復雜，如果系統出現異常，但不拋出，用戶根本不知道系統哪里出現了問題，也就無法“對癥下藥”，所以系統必須在任何可能出現異常的地方，從最低層逐級往上拋出異常，一直拋到最高一層。

程序處理異常通常有以下幾種情況:

(1)捕獲異常但不做相應處理，這種情況通常調用 printStackTrace()、getMessage()或者getStackTrace()等方法。這對程序員調試程序很有幫助，但是當程序調試結束后，這種處理方式往往不再使用。

(2)捕獲異常但是不捕獲具體異常，不管下級拋出多少異常、拋出什么樣的異常，僅僅只用一個catch語句來捕獲，最常見的情形是使用catch(Exception ex)。由于大多數異常都直接或者間接從java.lang.Exception派生，catch(Exception ex)就相當于想要捕獲所有的異常，這種捕獲異常的方式沒有任何意義，等于沒有捕獲。所以這種情況一般也只在程序調試階段，為了簡單才采用。

(3)捕獲到異常后不做相應處理，把異常處理重拋給上級處理。處理異常的代碼在分析異常后，認為自己不能處理它，重新向上級拋出異常，這種方式在VO-DAS中是一種常用的處理方式。

表1 VO-DAS的主要異常列表Table 1 The key exceptions list

(4)捕獲到異常并作相應處理。這種情況在VO-DAS的調度程序中非常重要，比如VO-DAS在執行任務的時候，不管哪個環節出現異常，必須要報告上級，上級捕獲到異常后，第一件事就是要將任務狀態(status)置為“ERROR”，然后再做其他的處理，比如銷毀這次任務的Session，釋放資源。資源不釋放是影響系統性能的潛在殺手。

(5)捕獲到異常后將異常轉換成另一種異常。對于比較低級的異常，用戶不容易理解，這時可以將異常轉換成為應用級別的異常。

VO-DAS的部分異常列表見表1。

4 VO-DAS的任務調度方案的實現與測試

整個系統的調度大致如下:DataNode搭建成功時，首先要向Registry服務注冊，注冊的方法主要是將DataNode的描述文檔(XML格式)以URL的方式告訴Registry服務，VO-DAS系統在啟動時，首先要檢測Registry服務，將Registry服務中所有DataNode裝載于VO-DAS服務器中，并周期性地檢查和更新，以確保所有DataNode的有效性。當客戶端向VO-DAS Server提交任務時，Sever首先需要對提交的任務創建一個Session，然后由ADQL解析模塊對任務進行解析，并生成執行計劃(ExecPlan)，保存于Session中。后面的流程，主要由VO-DAS服務器按照該任務的執行計劃(ExecPlan)逐一完成。以圖2為例，它表示的是一次典型的異步查詢的流程，在這次任務中，VO-DAS服務器需要分別從3個DataNode中查詢相應的數據，然后完成兩次交叉證認(CrossMatch)，并最終將結果保存在VOSpace或MySpace中，等待用戶提取。

從上述描述的整個流程來看，異步查詢并不需要用戶始終將自己的電腦開著，用戶只需要借助ADQL語言描述清楚自己的意圖，提交給VO-DAS服務器，DAS會幫你完成剩下所有的操作，這種查詢方式適合大數據量、多任務的耗時查詢。對于另外一種簡單的查詢模式——同步查詢，最終的查詢結果需要直接反饋給用戶，用戶必須始終保持VO-DAS Client端的運行狀態，不然VO-DAS Server最終將把結果丟失。所以，這種模式，適合小數據量、并不耗時的任務查詢。

4.1 VO-DAS服務器的運行環境

DAS是一個獨立的WSRF服務，和OGSA-DAI服務共同安裝在GT4 Java WS Core或Tomcat容器之上。VO-DAS的所有開發都是基于Java，故VO-DAS可同時在Window和Linux平臺下運行。VODAS的安裝部署請參閱說明文檔。

server.xml是VO-DAS的配置文件。該文件必須存放于容器(比如Tomcat或WS Core)根目錄下，用于描述系統的全局變量和設置參數，主要包括:(1)ServerName:服務器名稱;(2)ServerDescription:服務器的描述;(3)RegistryURL:注冊服務器的URL;(4)WorkThreadNum:查詢的最大工作線程;(5)JobValidPeriod:查詢任務的 Session有效期，單位為 d(默認為5 d);(6)SessionIdlePeriod:Session的空閑時間，即從建立連接到提交任務的時間間隔的最大值，單位為ms(默認為120000ms);(7)DiscoverPeriod:服務器重新裝載Registry的時間間隔，單位為ms(默認值3600000ms)。

4.2 VO-DAS服務器的性能

基于原型的反復試驗，VO-DAS的性能概括如下:(1)查詢:一次能夠查詢多于50萬條數據;(2)分析:一次可以分析多于500萬條數據;(3)交叉證認:一次可以做多于50萬條的交叉證認;(4)Session的生命周期:最長可以容許多于168 h;(5)最少支持6個工作線程同時工作，其中至少預留2個線程用于同步查詢，以確保同步查詢的及時性。同時，應允許多于100個任務的等待;(6)Data Node數目允許大于5000;(7)Algorithm數目允許大于100;(8)數據傳輸率:接近網絡最大值。

到目前為止，VO-DAS僅實現了最基本的功能，即同步查詢、異步查詢、異地異構數據的聯合查詢，以及數據傳輸、存儲、格式轉換等在內的輔助功能。但是，它的有效性已經充分體現出來，作為比較，VO-DAS可以同時支持數百萬條數據的異步、同步、以及聯合訪問模式，而美國虛擬天文臺(NVO)的OpenSkyQuery的實驗原型僅支持最多5000條數據的同步查詢，且不支持異步查詢和聯合查詢模式。

5 基于科學范例的系統測試

基于VO-DAS，已經完成了數個科學范例，同時對VO-DAS的任務描述、數據訪問等性能進行了實驗。

范例1，利用星等、顏色等特性，從Sloan數字巡天的星系星表中，為LAMOST［16］巡天選擇目標樣本——亮紅星系(LRGs)以及發射線星系 (ELGs)［17］。該范例的測試目標是檢驗ADQL描述、解析復雜任務的性能。客戶端需要描述一個多達十幾個條件語句，同時涉及多表的交叉證認的復雜任務，對應復雜表達式，VO-DAS僅視為多個條件語句的簡單疊加，但目前VO-DAS僅支持簡單的條件語句和多表的交叉認證，對復雜函數、各種數據挖掘的算法、可視化功能，比如給定紅移直接求得共動距離、體積等尚不支持，需要在今后的開發中進一步完善。

范例2，采用Sloan數字巡天星表中的恒星星表作為數據源，通過研究這些恒星在空間分布密度的特點尋找銀河系的衛星星系或球狀星團［18］。該范例的目的是測試VO-DAS對于密集任務的承受能力。在范例中，客戶端程序會向VO-DAS連續發出數百個空間位置查詢，每得到一個空間位置的數以千計的查詢結果就對這些恒星的空間密度、亮度、顏色特征等進行分析，給出可視化結果供人工判別。該范例驗證了VO-DAS以及OGSA-DAI在較強的訪問密度下進行查詢的穩定性以及大量數據傳輸的可行性。但是當訪問密度非常高(對同一個約7000萬條數據的大表同時有3個客戶端連續發出請求)的時候，可能會出現偶發性的錯誤。發生偶發錯誤的原因尚不能確認，可能是我們使用的MySQL數據庫的問題也可能是OGSA-DAI的自身問題。

范例3，對Sloan數字巡天星表的星系紅移做出估計［19］，并使用估計的結果完成星系大尺度結構的可視化。在此范例中，客戶端需要向VO-DAS以及DataNode請求超過2 400萬條星系位置和紅移數據，并利用這些數據完成星系大尺度結構的繪圖。實驗發現，一次訪問2 400萬條數據會受到實驗計算機的內存限制(使用1.5 GB內存的個人計算機進行實驗)，適當降低一次訪問數據的數量可以讓查詢穩定進行。在我們實驗的環境下，我們一次訪問最多達到500萬條數據。在具體實踐中，一次訪問的允許最大訪問數據量應該同服務器的內存大小以及每條數據的字節長度有關系。

科學范例表明，基于WSRF框架下的VO-DAS系統可以勝任各個模塊的有效調度。在適當的硬件環境保證下，VO-DAS可以為天文學研究帶來極大便利。

6 總結

本文第一節主要歸納了天文領域數據“雪崩”時代所面臨的問題，為此中國虛擬天文臺團隊為解決這些問題，基于國際虛擬天文臺聯盟制定的各種協議標準，自主設計并開發了一套異地異構數據的統一訪問平臺 (VO-DAS)，第二節簡單介紹該系統的框架和主要接口，但VO-DAS的任務調度設計與實現是整個VO-DAS的核心部分，由此本文在第三節、第四節著重從設計模式、Session機制、生命周期、資源銷毀、異常處理等模塊詳細闡述了VO-DAS服務器端(Server)任務調度機制。

反復試驗表明，ADQL可以有效地對復雜任務進行統一描述，OGSA-DAI可以有效封裝異地異構數據，國際通用Registry(比如英國AstroGrid)服務，可以實現全球數據統一描述、自發現功能，同時OGSA-DAI的Activity插件使得我們可以隨意擴展數據節點的功能(數據格式轉換、傳輸、壓縮、存儲，給定紅移求距離、體積等常用天文算法，可視化……)，而這一切模塊都可以收攏于WSRF框架下有效地調控。隨著VO-DAS數據節點的不斷增多、功能日臻完善，越來越多的科學研究將基于VODAS來完成。比如在測量大尺度星系分布、探測重子聲波震蕩(BAO)，以及研究紅移空間畸變對星系功率譜、相關函數的影響等科學研究中，科學工作者正嘗試利用VO-DAS從SDSS的星系光譜星表中提取數據樣本。隨著科學工作者對VO-DAS的深入使用，VO-DAS也將不斷面臨新的需求和挑戰，最終必將驅使它真正成為一款天文學界統一的數據訪問和處理平臺，這也將為中國已經投入使用的LAMOST［16］、以及正在建造的FAST［20］等大型天文望遠鏡的數據產出提供一種不錯的數據發布平臺。

［1］Quinn Peter J，Barnes David G，Csabai István，et al.The International Virtual Observatory Alliance:Recent Technical Developments and the Road Ahead ［J］.SPIE，2004，5493:137－145.

［2］Budavári T，Malik T，Szalay A S，et al.Sky Query-A Prototype Distributed Query Web Service for the Virtual Observatory ［J］.Astronomical Data Analysis Software and Systems XII ASP Conference Series，2003，295:31.

［3］O’Mullane W，Budavári T，Li N，et al.Open Sky Query and Open Sky Node-the VO Framework to Federate Astronomy Archives［J］.Astronomical Data Analysis Software and Systems XIV ASP Conference Series，2005，347:341.

［4］Wagner Richard P，Norman M L.Theory Sky Node ［J］.Bulletin of the American Astronomical Society，2007，38:1002.

［5］Page C.Astrogrid and Data Mining ［J］.SPIE，2001，4477:53－60.

［6］Cunto W，Mendoza C，Ochsenbein F，et al.Topbase at the CDS ［J］.A＆A，1993，275(1):L5.

［7］York Donald G，Adelman J，John E Anderson Jr，et al.The Sloan Digital Sky Survey:Technical Summary ［J］.AJ，2000，120(3):1579 －1587.

［8］OGSA-DAI.Open Grid Services Architecture-Data Access and Integration ［DB/OL］，http://WWW.ogsadai.org.uk.

［9］ADQL.Astronomical Data Query Language ［DB/OL］，http://www.ivoa.net/Documents/latest/ADQL.html.

［10］Registry［DB/OL］，http://www.ivoa.net/Documents/latest/RegistryInterface.html.

［11］劉超，田海俊，高丹，等.異地異構天文數據資源的統一訪問 ［J］.天文研究與技術——國家天文臺臺刊，2008，5(2):145－155。Liu Chao，Tian Haijun，Gao Dan，et al.Integrated Access of Distributed and heterogeneous Astronomical Data Resources ［J］.Astronomical Research ＆ Technology——Publications of National Astronomical Observatories of China，2008，5(2):145－155.

［12］Globus Alliance［DB/OL］，http://www.globus.org.

［13］OGSI［DB/OL］，http://www.ggf.org/documents/GFD.15.pdf.

［14］WSDL［DB/OL］，http://www.w3.org/TR/wsdl.

［15］WSRF［DB/OL］，http://www.globus.org/wsrf/.

［16］LAMOST ［DB/OL］，http://www.lamost.org.

［20］FAST ［DB/OL］，http://159.226.88.6/bao/LT/.