基于多源異構數據的北京GISC數據請求服務

姚 燕，李 湘，郭 萍，鄭 波

(國家氣象信息中心，北京 100081)

0 引 言

二十一世紀初，世界氣象組織(world meteorological organization，WMO)各項計劃已經擁有或正在開發各自獨立的氣象信息系統。系統的多樣性不僅使系統之間缺乏兼容和效率，而且存在重復建設和高成本等弊端。為了避免這些問題的進一步加劇，WMO提出了WMO信息系統(WMO information system，WIS)的概念，旨在建立一個通用的、綜合的信息服務平臺，用以支撐各項計劃以及相關組織的氣象數據交換和共享[1]。全球信息系統中心(global information system center，GISC)是WIS的核心功能中心，其主要功能之一就是要提供與數據存儲位置無關的氣象數據發現、訪問和檢索服務[2]。

國家氣象信息中心從2009年開始逐步開展WIS實施，在2011年完成北京GISC系統主體功能的建設，并通過WMO的能力評估和測試，成為首批全球信息系統中心之一。隨著WIS實施的推進，北京GISC收集和提供服務的數據種類和數量也將進一步拓展和增加[3]。但是由于業務需求和功能歸屬的不同，體系內許多不同氣象數據內容的信息服務和管理系統已經逐步建立起來。這些系統的數據源有著各自不同的處理對象、操作方法和專用客戶端，基本上相互隔離。因此迫切需要在多源異構的數據環境下設計一個統一的數據集成服務來支撐北京GISC用戶對氣象數據的訪問和檢索，實現北京GISC業務系統中各類氣象數據的請求功能[4]。

1 服務設計

1.1 數據分析

在北京GISC系統中，數據請求服務所涉及到的氣象資料主要涉及全球交換的常規氣象資料、全球交換的二進制氣象資料(包括GRIB、BUFR等不同數據格式[5])、中國本地的全球數值預報模式產品、中國風云衛星資料產品以及交互式全球大集合數值預報產品(THORPEX Interactive Grand Global Ensemble[6]，TIGGE)等。通過分析歸納起來整個服務數據源的異構性主要體現在以下三個方面：

(1)系統異構，即數據源所依賴的業務應用系統、數據庫管理系統之間的不同構成了系統異構。北京GISC系統的數據源涉及到業務系統實時氣象數據庫、本地系統應用數據庫以及TIGGE數據專用存儲檢索系統MARS(meteorological archival and retrieval system)。

(2)接口異構，即數據源在檢索接口上存在不同。實時氣象數據庫系統需要采用其統一定制的檢索服務API(application programming interface，應用程序接口)；TIGGE數據檢索則需要安裝和使用其專用的客戶端軟件；本地數據庫則可以通過JDBC等接口直接進行數據表的SQL檢索。

(3)來源異構，即內部數據源和外部數據源之間的異構。

北京GISC系統要實現這些數據的訪問和檢索服務，就必須為數據請求提供一個公共的統一的集成接口，使訪問者不必關心如何才能夠獲取到，也不必考慮數據的來源和異構性、數據抽取、數據合成等問題，只需指定請求的數據條件即可。

1.2 技術分析

目前最主要的異構數據集成體系結構有以下三種[7]：聯邦數據庫模式、數據倉庫模式和中間件模式。

聯邦數據庫模式支持分布、異構與自治，其對應系統包括一組互相協作但分別自治的數據庫系統，這些自治的數據庫系統稱為成員數據庫系統。這些成員數據庫系統可以進行不同程度的集成，而且數據依然保留在原來的存儲位置，不必構建一個集中式的數據倉庫。隨著數據源的增多，數據查詢效率會受到限制，主要適用于異構數據源較少的數據集成[8]。

數據倉庫模式主要是建立一個存儲數據的倉庫，由數據抽取、轉換與裝載工具定期地從數據源過濾數據，然后裝載到數據倉庫中，提供用戶操作。所有的查詢都針對數據倉庫中的數據，數據倉庫必須根據數據的變化而隨時更新。但數據倉庫中數據實時性不強，該模型主要適用于對數據聯機分析和決策支持系統的集成[9]。

中間件模式為用戶提供了一個全局模式，用戶提交的查詢都是針對這個全局模式而進行的，因此數據源的位置、模式及訪問對用戶來說都是透明的。系統將基于中間模式的查詢轉換為針對各局部數據源的查詢，將用戶的查詢分解為各個數據源的子查詢，并將各子查詢返回的數據綜合起來得到查詢結果。其優點是數據不需冗余，而且能保證是最新的。中間件模式適合于數據變化較多的異構數據源集成，局部數據源的加入操作實現比較靈活方便，而且可以保持各個數據源充分的自治性。

1.3 總體結構

綜合以上數據分析和數據集成模式分析，考慮中間件模式成本低、易實現以及局部數據源加入方便靈活、自治性強等優點，北京GISC系統采用Web Service和XML技術并應用中間件數據集成模型來進行多源異構氣象數據請求服務的設計和實現。數據請求服務的總體結構如圖1所示，總體從邏輯上分為三層，分別是應用層、應用服務層和數據源層[10]。

圖1 數據請求服務總體結構

應用層是終端用戶與系統交互的接口。該層根據具體的應用和用戶環境，采用合適的信息訪問技術或應用軟件，可以是Web瀏覽器或專用的客戶端，來提供用戶相應的數據請求信息，并從應用服務層接收相應的請求結果狀態信息和結果數據文件。無論應用是C/S模式還是B/S模式，只要遵循應用服務層的數據請求接口規范，就可以有效地、透明地從底層的數據源獲取數據。

應用服務層負責完成所有數據請求邏輯處理，也是總體結構中的核心層，主要包括Web服務和數據請求中間件[11]。數據請求Web服務收集來自應用層的數據請求信息，并為每個數據請求生成全局唯一的任務編號。它首先檢查該數據請求是否在數據緩存中，即同樣的數據是否已被處理過。如果存在則直接反饋用戶結果信息和數據。否則根據用戶請求數據內容不同生成請求條件描述接口文件，轉發給數據請求中間件。數據請求中間件進而解析請求條件描述接口文件，完成服務選擇、數據檢索、數據壓縮或分拆、合并結果、狀態更新等一系列處理后，將請求結果狀態信息和結果數據返回給Web服務。應用層通過任務號可以查詢到請求任務的執行情況，并獲得相應的請求執行結果。相應的處理流程如圖2所示。

圖2 數據請求處理流程

數據源層主要包括需要訪問的各個自治的局部數據源，為數據請求服務提供各種氣象數據支撐。

2 關鍵技術

2.1 Web Service

Web Service是基于一組標準Internet協議的分布式計算組件，具有開放、面向Internet標準化接口等特點，能夠實現松散耦合的、與平臺無關的應用系統交互與協同，是應用集成的理想平臺。它使用SOAP(simple object access protocol)表示信息傳輸協議，使用WSDL(web service description language)進行本身內容描述，使用UDDI(universal description，discovery and integration)來發現、描述與集成Web Service[12]。Web Service為數據集成提供了靈活的訪問方式，能夠較好地為數據集成提供標準的開發接口和良好的擴展性，為快速新增和部署新數據源提供了方便。

2.2 XML技術

可擴展標記語言(extensible markup language，XML)作為一種結構性標記語言，描述能力的擴展性強，結構化程度高，具有標準的編程接口，因其簡單、可擴展、跨平臺的特性而被廣泛應用于數據信息的交換和傳輸[13]。由于XML具有良好的互操作性及數據表示能力，它可以表示任何形式的數據[14]，所以在北京GISC數據請求服務中均采用XML Schema來定義數據請求服務相關的接口參數信息及請求結果信息。請求參數信息主要涉及請求數據集名稱、各個數據集對應請求條件以及請求結果存放目錄和文件名等信息，如表1所示。而請求結果信息則主要包括請求結果狀態信息及請求結果文件，如表2所示。

表1 數據請求條件信息XML內容

續表1

表2 數據請求結果信息XML內容

2.3 數據請求中間件

數據請求中間件由數據集成處理和數據源檢索處理兩部分構成。它是一個組合服務，能夠解析接收到的XML語言描述的數據檢索描述文件，完成一系列服務后，將檢索結果信息和數據文件統一地返回給Web服務器和應用層。因此數據請求中間件技術是實現北京GISC系統數據請求服務的關鍵[15]。

數據集成檢索代理集成了四個核心服務，包括邏輯解析、服務選擇、結果匯總和狀態更新。服務解析服務主要是負責對接收到的檢索描述XML文件進行分析，為檢索服務的選擇提煉出相應的接口信息或關鍵字。服務選擇服務負責根據所提煉的關鍵字對服務元數據進行檢索，找到對應的提供檢索服務的數據源，然后將服務請求向相應的數據源檢索接口服務轉發。結果匯總服務負責將數據源檢索接口服務返回的結果數據和處理信息進行匯總。狀態更新服務實現根據匯總后的處理信息和結果更新檢索請求的元數據信息，這樣Web服務器能夠實時地將最新的處理狀態和結果返回給用戶。

數據源檢索接口代理主要進行針對異構數據源的檢索訪問操作。每一個不同的異構數據源都有一個不同的檢索服務與之相對應，通過對不同的異構數據源的服務化封裝，起到屏蔽異構數據源的目的，并將封裝的服務提供上層數據集成檢索代理的服務調用。

每個異構數據源對應的檢索服務均包括查詢轉換和數據生成兩部分功能。不同數據源支持的查詢語言是不同的，因此需要依次提取出其中的查詢參數，轉換為針對各個局部數據源能夠識別的查詢語句或腳本。例如：實時數據庫的查詢需要將查詢條件和內容整理為其統一檢索接口所規定的輸入參數列表形式。MARS的查詢需要將查詢條件和內容整理為其所能處理的檢索腳本格式。而本地數據則需要將檢索條件組織成相應關系型數據庫的標準的SQL查詢語句即可。數據生成服務則調用相關數據源JDBC或處理API，來執行各個局部數據源的數據檢索，獲取相應的數據，統一以數據文件的形式返回給上層服務。

3 應用效果

采用XML和Web服務結合中間件架構的設計，初步實現了北京GISC系統中異構數據源的透明集成檢索和請求服務，使得多種業務應用系統、多種異構數據源并存，并隨著北京GISC業務系統建成已業務化運行多年，為用戶提供了穩定的數據請求服務。在北京GISC系統中，數據請求服務主要應用于數據發現、數據獲取和數據訂閱這三個主要功能中。

在數據發現功能中，注冊用戶檢索到所需要的氣象數據元數據信息時，用戶可以直接點擊數據訪問按鈕直接瀏覽到對應的氣象數據文件，同時也能通過“是否獲取更多數據”來調用數據請求服務從后臺數據源中獲取用戶指定時間的所查元數據對應數據文件，如圖3所示。

圖3 數據請求服務在數據發現功能中的應用示例

在數據獲取功能中，注冊用戶可以根據需求在數據目錄中選擇不同的氣象數據種類，然后根據不同數據種類中對應的請求要素條件進行設置，最終通過數據請求服務實現氣象數據文件壓縮包的下載，如圖4所示。

圖4 數據請求服務在數據獲取功能中的應用示例

在數據訂閱功能中，注冊用戶通過選擇所需要的數據內容，加入數據訂閱購物車，提交數據訂單。數據訂閱后臺應用根據資料時間特性，通過定時器依據資料類別觸發數據請求服務，獲取訂閱結果氣象數據，并以用戶指定方式返回數據訂閱用戶，如圖5所示。

圖5 數據請求服務在數據訂閱功能中的應用示例

4 結束語

長期以來,由于異構數據源之間的顯著差異,使得異構氣象數據集成請求成為一個難點問題。中間件技術的使用，為解決異構數據集成請求服務提供了機會。同時這種服務設計也保護了原有信息化投資，能夠適應底層數據源應用系統由舊向新的平滑過渡，比如實時業務數據庫在近幾年的更新換代，GISC系統中48小時Cache數據源的加入，能夠滿足系統建設的低成本、階段性和擴展性需求，在北京GISC系統第一版應用軟件建設中取得了一定的成效。同時隨著近幾年WIS2.0概念的提出以及關于氣象云數據的共享服務的逐步實施[16]，也為北京GISC業務系統第二版的建設提供了技術經驗。