朱利魯 蘇曉露 閻克棟

(中國科學(xué)院電子學(xué)研究所蘇州研究院 江蘇 蘇州 215123) (蘇州市空天大數(shù)據(jù)智能應(yīng)用技術(shù)重點(diǎn)實(shí)驗(yàn)室 江蘇 蘇州 215123)

0 引 言

近年來，隨著生產(chǎn)生活高度信息化，地理信息服務(wù)在公共交通、社交平臺、購物娛樂以及智慧城市、政府決策等領(lǐng)域逐漸成為各類服務(wù)所依托的基礎(chǔ)模塊。各行業(yè)各部門積累了大量的帶有時間屬性和空間屬性的數(shù)據(jù)資源和服務(wù)應(yīng)用，但由于缺乏有效整合，形成了為數(shù)眾多的“資源孤島”，造成了資源浪費(fèi)和系統(tǒng)重復(fù)建設(shè)等問題[1-3]。因此，為了提高資源利用效率和降低生產(chǎn)、管理成本，通過引入“資源整合”技術(shù)，形成多維度的時空信息資源共享服務(wù)體系成為解決問題的關(guān)鍵，具備高度整合能力的資源共享平臺應(yīng)運(yùn)而生。同時，由于時空數(shù)據(jù)來源和引接方式的不同，形成了基于不同平臺、不同協(xié)議，種類繁多，結(jié)構(gòu)各異的數(shù)據(jù)形態(tài)，在時空信息資源共享平臺的服務(wù)互操作、數(shù)據(jù)同步、實(shí)體文件傳輸?shù)饶K面臨諸多技術(shù)瓶頸。本文基于早先應(yīng)用實(shí)踐，針對現(xiàn)有技術(shù)成果進(jìn)行深入研究分析，結(jié)合時空信息資源共享平臺的技術(shù)要求，提出一種面向多源異構(gòu)時空大數(shù)據(jù)資源的集成框架-STDRIF，解決各類時空數(shù)據(jù)資源、服務(wù)資源整合過程中遇到的問題。

互通互聯(lián)的資源共享服務(wù)體系需要集成遠(yuǎn)程方法調(diào)用、數(shù)據(jù)傳輸、數(shù)據(jù)同步、消息分發(fā)等多種關(guān)鍵技術(shù)，面向不同數(shù)據(jù)、不同環(huán)境形成完整的技術(shù)框架。早先的資源集成框架大多采用面向服務(wù)的體系架構(gòu)(service oriented architecture，SOA)思想[4-5]，具體實(shí)現(xiàn)有Web Service、CORBA、DCOM和RMI等方式。但隨著服務(wù)規(guī)模的不斷擴(kuò)大、性能指標(biāo)要求的不斷提升，Web Service等共享實(shí)現(xiàn)方式的性能缺陷和功能單一性逐漸顯露[6]。無論是在網(wǎng)絡(luò)帶寬還是CPU開銷方面，都會給應(yīng)用造成嚴(yán)重的性能問題，以至于該技術(shù)無法適用于許多高性能以及互操作極為頻繁的場景。CORBA和DCOM因其龐雜的技術(shù)標(biāo)準(zhǔn)以及平臺兼容性方面的缺點(diǎn)而難以廣泛推廣[7]。RMI是Java語言的遠(yuǎn)程調(diào)用，兩端的程序語言必須是Java實(shí)現(xiàn)，無法支持跨語言平臺的通信[8]。另外，在數(shù)據(jù)集成方面，早先的集成框架嘗試將數(shù)據(jù)資源轉(zhuǎn)化為標(biāo)準(zhǔn)的方式(XML)進(jìn)行訪問，但依然面臨著效率低下的問題；在數(shù)據(jù)同步方面，早先主流的數(shù)據(jù)同步解決方案有數(shù)據(jù)庫廠商提供的數(shù)據(jù)同步技術(shù)和基于捕獲變化技術(shù)自行定制開發(fā)的數(shù)據(jù)同步技術(shù)：廠商提供的同步技術(shù)往往都不支持異構(gòu)數(shù)據(jù)庫的同步，難以滿足要求。很多學(xué)者都提出了基于捕獲技術(shù)的數(shù)據(jù)庫同步技術(shù)，文獻(xiàn)[9]利用觸發(fā)器與存儲過程結(jié)合從源數(shù)據(jù)庫子系統(tǒng)中獲取變化數(shù)據(jù)，文獻(xiàn)[10]提出了一個改進(jìn)的主文本更新法與時間戳相結(jié)合的策略。但這些方法沒有統(tǒng)一的技術(shù)標(biāo)準(zhǔn)，存在各種限制條件，不適用于大型應(yīng)用系統(tǒng)。同時，以往的資源集成框架主要關(guān)注于服務(wù)資源和數(shù)據(jù)庫資源的集成，對于消息資源和非結(jié)構(gòu)化數(shù)據(jù)資源的傳輸沒有給出完整、可用的實(shí)現(xiàn)方案。綜上所述，現(xiàn)有方案在性能、兼容性等方面都存在問題，而且在服務(wù)互操作，消息傳輸、數(shù)據(jù)同步以及數(shù)據(jù)傳輸?shù)汝P(guān)鍵技術(shù)上也沒有形成一套基于時空數(shù)據(jù)特點(diǎn)的，有針對性的完整高效異構(gòu)資源集成方案。

本文提出的基于異構(gòu)時空大數(shù)據(jù)資源集成框架(下文簡稱資源集成框架)，主要是針對當(dāng)前時空數(shù)據(jù)資源集成技術(shù)存在的不足以及資源整合對開發(fā)復(fù)雜度和性能等方面的要求，旨在解決大規(guī)模數(shù)據(jù)資源在網(wǎng)絡(luò)化服務(wù)調(diào)用、消息通信、數(shù)據(jù)同步和數(shù)據(jù)傳輸?shù)冗^程中出現(xiàn)的問題，通過融合各類技術(shù)方案，形成一套完整的、具有實(shí)用價值的時空數(shù)據(jù)資源共享技術(shù)解決方案。

1 時空大數(shù)據(jù)資源集成框架

資源集成框架旨在實(shí)現(xiàn)不同應(yīng)用系統(tǒng)之間一類時空數(shù)據(jù)、消息、服務(wù)的集成，使它們像一個整體一樣進(jìn)行業(yè)務(wù)信息交互，從而使業(yè)務(wù)、管理、資源等各個環(huán)節(jié)達(dá)到協(xié)調(diào)運(yùn)轉(zhuǎn)、效率優(yōu)化的目的。其中這些資源包括已建、在建的基于不同技術(shù)平臺實(shí)現(xiàn)的，并且運(yùn)行于不同網(wǎng)絡(luò)結(jié)構(gòu)中的資源。同時，資源集成框架能夠支持C/S和B/S等不同架構(gòu)模式的第三方應(yīng)用對資源的訪問，實(shí)現(xiàn)多種終端的統(tǒng)一接入。本文提出的資源集成框架總體分為四個模塊，分別是服務(wù)調(diào)用模塊、消息管理模塊、數(shù)據(jù)同步模塊以及數(shù)據(jù)傳輸模塊，如圖1所示。

圖1 時空大數(shù)據(jù)資源集成框架

通過四個模塊的技術(shù)融合和協(xié)調(diào)運(yùn)轉(zhuǎn)，資源集成框架可以有效地集成基于不同平臺、不同開發(fā)語言的時空數(shù)據(jù)服務(wù)資源，多品類時相影像數(shù)據(jù)資源，海量消息資源，關(guān)系型、非關(guān)系型數(shù)據(jù)庫資源以及文件資源等。各類時空數(shù)據(jù)資源通過模塊進(jìn)行整合，實(shí)現(xiàn)統(tǒng)一調(diào)度管理。各行業(yè)部門可基于該資源集成框架定制實(shí)現(xiàn)對現(xiàn)有資源的整合以及新接資源的二次應(yīng)用開發(fā)，同時可以調(diào)用其他中心的數(shù)據(jù)、服務(wù)資源實(shí)現(xiàn)資源統(tǒng)籌，大大減少資源共享成本。

1.1 服務(wù)集成模塊

服務(wù)集成模塊如圖2所示，設(shè)計(jì)并實(shí)現(xiàn)服務(wù)通信框架(Service communication framework,SCF)為分布式應(yīng)用程序的開發(fā)、部署提供了一個功能完善的平臺，可以整合不同平臺、多種語言開發(fā)的服務(wù)。在實(shí)際工程中，應(yīng)用程序需要的常常不止是遠(yuǎn)程通信能力，還需要按需啟動、代理分發(fā)、異步事件分發(fā)、應(yīng)用配置、應(yīng)用補(bǔ)丁升級等諸如此類的服務(wù)。服務(wù)集成模塊通過可視化界面可以查看各個節(jié)點(diǎn)的應(yīng)用狀態(tài)，實(shí)現(xiàn)應(yīng)用的全生命周期管理。服務(wù)部署系統(tǒng)可以實(shí)現(xiàn)多節(jié)點(diǎn)應(yīng)用的快速部署以及應(yīng)用的統(tǒng)一升級發(fā)布。不同平臺的服務(wù)集成則通過三層架構(gòu)完成服務(wù)接入與調(diào)用。

圖2 服務(wù)集成模塊框架圖

負(fù)載均衡層作為服務(wù)集成的核心模塊起著承上啟下的作用。主要由服務(wù)注冊和服務(wù)調(diào)度兩部分組成。服務(wù)注冊通過建立注冊中心將服務(wù)集中管理，當(dāng)接收到客戶端請求時，從注冊信息中找到已注冊的服務(wù)信息，通過調(diào)度算法判斷出哪個節(jié)點(diǎn)的服務(wù)有空閑資源可以處理此請求，然后將客戶端請求代理直接與該結(jié)點(diǎn)對應(yīng)的服務(wù)連接。服務(wù)接入需要解決不同服務(wù)資源的發(fā)布、注冊問題。利用接口定義語言定義服務(wù)對象的服務(wù)接口，形成服務(wù)接口描述文件；根據(jù)客戶端和服務(wù)端開發(fā)語言的不同，利用編譯工具分別生成與兩端開發(fā)語言對應(yīng)的接口程序；在服務(wù)端，繼承服務(wù)接口，完成服務(wù)功能的實(shí)現(xiàn)；將完成的服務(wù)與對象適配器進(jìn)行綁定。服務(wù)調(diào)用層使客戶端可以快速獲取所調(diào)用的服務(wù)完成請求?？蛻舳诵枰渲门c注冊中心通信的連接，將請求發(fā)送到注冊中心，通過負(fù)載均衡層高效地獲取空閑的服務(wù)資源并與之建立連接。這里需特別注意的是，服務(wù)調(diào)用層使用間接綁定完成客戶端到服務(wù)端的對象調(diào)用。間接綁定讓客戶端不再需要指定代理的端點(diǎn)信息[11]，代理的端點(diǎn)由注冊中心動態(tài)確定。

1.2 數(shù)據(jù)同步模塊

各類地理信息系統(tǒng)中存在多種類型的數(shù)據(jù)庫以及文件系統(tǒng)，數(shù)據(jù)同步、數(shù)據(jù)傳輸是一個極為棘手的問題。數(shù)據(jù)同步模塊框架如圖3所示，采用增量日志的方式捕捉各類數(shù)據(jù)庫數(shù)據(jù)變化，通過模擬SETL數(shù)據(jù)倉儲過程實(shí)現(xiàn)了MySQL、Oracle以及HBase等異構(gòu)數(shù)據(jù)同步。同時，文件作為數(shù)據(jù)庫中某條數(shù)據(jù)記錄的附件，在數(shù)據(jù)表發(fā)生變化時隨數(shù)據(jù)一起同步。數(shù)據(jù)資源同步模塊支持實(shí)時數(shù)據(jù)同步、多點(diǎn)數(shù)據(jù)插入、附件同步、異地機(jī)房同步、數(shù)據(jù)映射、過濾等多種數(shù)據(jù)資源同步需求。

圖3 數(shù)據(jù)同步模塊框架圖

數(shù)據(jù)庫表發(fā)生變更時，變更監(jiān)聽組件通過解析各類數(shù)據(jù)庫的日志文件獲取變更信息，將變更信息傳輸?shù)礁鱾€Node節(jié)點(diǎn)。Node節(jié)點(diǎn)模擬數(shù)據(jù)倉庫過程通過數(shù)據(jù)接入和數(shù)據(jù)提取對變更信息進(jìn)行提取，提取后的信息可以通過網(wǎng)絡(luò)傳輸?shù)疆惖豊ode節(jié)點(diǎn)。異地Node節(jié)點(diǎn)獲取信息后根據(jù)目標(biāo)數(shù)據(jù)庫進(jìn)行數(shù)據(jù)轉(zhuǎn)換，生成可用查詢語句，最后通過數(shù)據(jù)載入將變更數(shù)據(jù)更新到目標(biāo)數(shù)據(jù)庫。通過管理平臺可以查看數(shù)據(jù)同步、傳輸?shù)膶?shí)時情況，配置各個Node節(jié)點(diǎn)的參數(shù)，統(tǒng)一管理各類數(shù)據(jù)資源。Zookeeper在模塊中協(xié)調(diào)各個Node節(jié)點(diǎn)的工作，統(tǒng)一管理配置信息。

1.3 數(shù)據(jù)傳輸模塊

針對地理空間信息系統(tǒng)中存在大量的時空影像數(shù)據(jù)，這些影像數(shù)據(jù)格式多種多樣，大小由幾十KB到幾十GB不等。如何高效安全地傳輸共享這些資源成為異構(gòu)資源集成框架的重點(diǎn)。利用數(shù)據(jù)傳輸模塊可以整合多品類時空影像資源，實(shí)現(xiàn)批量傳輸和斷點(diǎn)續(xù)傳。數(shù)據(jù)傳輸模塊框架如圖4所示，各個服務(wù)可以調(diào)用消息管理模塊中不同的消息隊(duì)列完成消息傳輸，服務(wù)調(diào)用cTrans傳輸服務(wù)完成影像實(shí)體的傳輸。

圖4 數(shù)據(jù)傳輸模塊框架圖

圖4中，服務(wù)A發(fā)布影像實(shí)體，服務(wù)B需要獲取服務(wù)A所發(fā)布的影像，消息及影像實(shí)體的傳輸流程如下：

(1) 服務(wù)A發(fā)布影像實(shí)體，調(diào)用cTrans傳輸服務(wù)獲取影像實(shí)體并存入第三方存儲模塊；

(2) cTrans傳輸服務(wù)根據(jù)影像實(shí)體的存儲情況制作種子，種子中包含從第三方存儲獲取該影像實(shí)體的相關(guān)信息；

(3) 服務(wù)A通過消息管理模塊選擇相應(yīng)的消息隊(duì)列完成種子的發(fā)布、傳輸；

(4) 服務(wù)B通過消息隊(duì)列獲取服務(wù)A發(fā)布的種子消息并將種子信息傳輸給cTrans服務(wù)；

(5) cTrans服務(wù)解析種子信息，創(chuàng)建鏈接與第三方存儲模塊建立通信。

(6) cTrans服務(wù)從第三方存儲模塊獲取影像實(shí)體并傳輸給服務(wù)B，服務(wù)B獲取該影像實(shí)體，進(jìn)行其他業(yè)務(wù)流程。

1.4 消息管理模塊

消息管理模塊由一系列高性能消息隊(duì)列組成，主要解決應(yīng)用耦合、異步消息通信、流量削峰等問題，如圖5所示。

圖5 消息管理模塊框架圖

面向不同消費(fèi)場景，消息管理模塊整合多種消息中間件技術(shù)，采用高可用、持久化的部署形態(tài)為業(yè)務(wù)之間的消息驅(qū)動提供基礎(chǔ)支持，消息內(nèi)容來源于各個業(yè)務(wù)模塊，可包括訂單狀態(tài)變更、作業(yè)狀態(tài)變更、計(jì)劃下達(dá)、異常報警等。各個業(yè)務(wù)模塊將消息發(fā)送到消息管理的指定通道上，調(diào)用相應(yīng)中間件完成消息傳輸。

2 應(yīng)用實(shí)例及性能測試

2.1 應(yīng)用實(shí)例

信息資源共享平臺的目的之一就是整合各行業(yè)、部門、企業(yè)的多種多樣的信息服務(wù)、數(shù)據(jù)資源，J2EE作為適用于企業(yè)級應(yīng)用的多層分布式應(yīng)用架構(gòu)在后臺服務(wù)設(shè)計(jì)實(shí)現(xiàn)中有著廣泛的應(yīng)用。因此本節(jié)選取基于J2EE架構(gòu)的應(yīng)用作為實(shí)例，利用所提異構(gòu)資源集成框架完成應(yīng)用資源整合。

基于J2EE框架的時空數(shù)據(jù)服務(wù)實(shí)例，一般包含影像服務(wù)、訂單服務(wù)、地名服務(wù)、地圖服務(wù)、用戶管理服務(wù)、認(rèn)證服務(wù)等諸多類型的服務(wù)。為了實(shí)現(xiàn)多種時空數(shù)據(jù)資源的互操作，需要對相應(yīng)服務(wù)交互接口按照服務(wù)集成模塊的開發(fā)模式進(jìn)行改造，通過服務(wù)集成模塊接入到異構(gòu)資源集成框架，完成服務(wù)的注冊、發(fā)布。圖6給出應(yīng)用整體架構(gòu)圖。

圖6 地理信息應(yīng)用實(shí)例架構(gòu)圖

從圖6中可以看到，資源集成框架整合了應(yīng)用實(shí)例的各類服務(wù)資源、消息和實(shí)體資源以及多種數(shù)據(jù)資源?？蛻舳伺c服務(wù)集成模塊相連，資源集成框架屏蔽系統(tǒng)底層組成，管理整個系統(tǒng)。應(yīng)用實(shí)例的消息傳輸通過消息管理模塊獲取相應(yīng)消息隊(duì)列，完成消息傳輸。多品類非結(jié)構(gòu)化數(shù)據(jù)則由數(shù)據(jù)傳輸模塊通過cTrans傳輸完成，cTrans傳輸服務(wù)與第三方存儲模塊相連，可以實(shí)現(xiàn)批量傳輸與斷點(diǎn)續(xù)傳。消息管理模塊和數(shù)據(jù)傳輸模塊，高效安全地解決了不同平臺間的消息傳送和數(shù)據(jù)傳輸。數(shù)據(jù)同步模塊統(tǒng)一管理地理信息應(yīng)用實(shí)例的各類數(shù)據(jù)庫以及文件系統(tǒng)。

應(yīng)用實(shí)例采用C/S架構(gòu)，客戶端采用C#開發(fā)完成?？蛻舳送ㄟ^注冊中心動態(tài)獲取服務(wù)代理，可以訪問所有集成到資源集成框架中的資源。這里截取登錄和地名查詢服務(wù)客戶端結(jié)果作為呈現(xiàn)。

客戶端登錄服務(wù)界面如圖7所示。

圖7 客戶端登錄服務(wù)

客戶端地名查詢服務(wù)界面如圖8所示。

圖8 客戶端地名查詢服務(wù)

2.2 性能測試與結(jié)果分析

本節(jié)對服務(wù)資源集成模塊以及數(shù)據(jù)同步、文件傳輸進(jìn)行性能測試。服務(wù)資源集成模塊的測試較為復(fù)雜，選取J2EE架構(gòu)中常用的Java遠(yuǎn)程方法調(diào)用RMI作為參照[12]，借助LoadRunner測試工具對RMI以及所提出的服務(wù)通信框架(SCF)進(jìn)行比較測試，使用LoadRunner編輯測試腳本，模擬用戶使用客戶端[13]。測試使用的軟硬件環(huán)境如表1所示。

表1 測試平臺軟硬件環(huán)境

這里選取登錄和地名查詢服務(wù)進(jìn)行性能測試，分別編寫測試腳本進(jìn)行并發(fā)用戶數(shù)、平均響應(yīng)時間以及資源消耗測試[14-15]。部分用例場景設(shè)計(jì)如表2所示。

表2 部分功能模塊用例場景設(shè)計(jì)

首先對登錄和地名查詢服務(wù)進(jìn)行并發(fā)用戶數(shù)測試，結(jié)果如表3所示。從表中可以看出，在并發(fā)用戶數(shù)達(dá)到40時，RMI架構(gòu)的服務(wù)出現(xiàn)錯誤，之后隨著并發(fā)用戶數(shù)的增加，錯誤不斷增加。SCF架構(gòu)的服務(wù)測試結(jié)果如圖9、圖10所示。

表3 并發(fā)用戶測試結(jié)果

圖9 并發(fā)測試-登錄服務(wù)(并發(fā)數(shù)690)

圖10 并發(fā)測試-地名查詢服務(wù)(并發(fā)數(shù)540)

由圖可知，SCF架構(gòu)的登錄服務(wù)并發(fā)用戶數(shù)增加到690時CPU利用率峰值為48%，其他資源占用也在正常范圍內(nèi)，測試通過。當(dāng)并發(fā)數(shù)提高到700時出現(xiàn)錯誤。SCF登錄服務(wù)的并發(fā)數(shù)在690～700之間，同樣可測出地名查詢的并發(fā)數(shù)在540～550。因此，并發(fā)性方面SCF要明顯優(yōu)于RMI框架。

繪制RMI與SCF登錄服務(wù)的平均響應(yīng)時間圖如圖11所示。

圖11 登錄服務(wù)平均響應(yīng)時間圖

繪制RMI與SCF架構(gòu)地名查詢服務(wù)的平均響應(yīng)時間圖如圖12所示。

圖12 地名查詢服務(wù)平均響應(yīng)時間圖

由圖11與圖12可以看出，SCF在平均響應(yīng)時間方面要優(yōu)于RMI框架。響應(yīng)時間取決于通信框架的延遲和吞吐量，在延遲方面由于RMI傳輸包略大于SCF而在回環(huán)環(huán)境下測試延遲稍高，在網(wǎng)絡(luò)環(huán)境中由于網(wǎng)絡(luò)帶寬成為瓶頸而使得兩者延遲性能基本持平。吞吐量方面，SCF要明顯優(yōu)于RMI，這是由于RMI send buffer size沒有優(yōu)化，而要用一段時間等待方法。

據(jù)目前系統(tǒng)用戶數(shù)量測算，實(shí)際并發(fā)用戶數(shù)在100左右，本文對SCF架構(gòu)的服務(wù)采取逐步加壓測試，并發(fā)用戶數(shù)從10逐步遞增到100，觀察其資源消耗及平均響應(yīng)時間，測試結(jié)果如圖13、圖14所示。

圖13 壓力測試-登錄服務(wù)響應(yīng)時間及資源利用

圖14 壓力測試-地名查詢服務(wù)響應(yīng)時間及資源利用

從圖中可以看出，并發(fā)用戶數(shù)從10遞增到100期間，登錄服務(wù)和地名服務(wù)成功通過的事務(wù)數(shù)分別是34 021和14 855。CPU利用率維持在45%以下，內(nèi)存及硬盤的占用率也并不高。因此，SCF在資源占用方面不存在瓶頸。

測試期間，登錄和地名查詢服務(wù)的平均響應(yīng)時間分別是0.488和0.951，最大響應(yīng)時間分別為1.223和2.417。在互聯(lián)網(wǎng)上對于用戶響應(yīng)時間，有一個普遍的標(biāo)準(zhǔn)：2/5/10秒原則。也就是說，在2秒之內(nèi)給客戶響應(yīng)，被用戶認(rèn)為是“非常有吸引力”的用戶體驗(yàn)。

綜上所述，SCF在并發(fā)用戶數(shù)及平均響應(yīng)時間方面要優(yōu)于RMI框架。系統(tǒng)負(fù)載100左右時，SCF不存在資源占用方面的瓶頸且用戶體驗(yàn)良好。

下面對數(shù)據(jù)庫同步和文件同步性能進(jìn)行測試，測試硬件環(huán)境與通信框架測試硬件環(huán)境一樣。

(1) 數(shù)據(jù)庫同步。情景一：每條數(shù)據(jù)約100 B，傳輸數(shù)量與同步時間關(guān)系(傳輸模式在7 000～8 000時，由rpc變?yōu)閔ttp)如圖15所示。

圖15 數(shù)據(jù)庫傳輸量與時間關(guān)系

情景二：單條數(shù)據(jù)的大小與同步時間的關(guān)系，如圖16所示。

圖16 數(shù)據(jù)大小與時間關(guān)系

數(shù)據(jù)庫性能指標(biāo)取決于目標(biāo)數(shù)據(jù)庫性能，數(shù)據(jù)大小、網(wǎng)絡(luò)環(huán)境等多個因素，單機(jī)房同步初步性能為100 TPS，延遲100 ms，5 000 TPS，延遲1 s，數(shù)據(jù)100 B大小，極限 TPS可達(dá)1萬以上。

(2) 文件同步。文件作為數(shù)據(jù)庫中某條數(shù)據(jù)記錄的附件，在數(shù)據(jù)表發(fā)生變化時隨數(shù)據(jù)一起同步?？梢灾С侄喾N數(shù)據(jù)格式的附件同步，圖片(gif、jpg、png、bmp)、壓縮文件、xls、doc、exe以及文件夾均支持。

情景一：每個文件大小為1 KB，傳輸數(shù)量與同步時間關(guān)系，如圖17所示。

圖17 文件數(shù)量與時間關(guān)系

情景二：單個文件的大小與同步時間的關(guān)系，如圖18所示。

圖18 文件大小與時間關(guān)系

去除壓縮解壓的時間，同步時間與文件大小成線性關(guān)系，傳輸速度在10 MB/s以上，測試環(huán)境為百兆帶寬。

對資源集成框架中服務(wù)調(diào)用以及數(shù)據(jù)、文件同步進(jìn)行了性能測試，結(jié)果表明：SCF在并發(fā)性和響應(yīng)時間方面要優(yōu)于RMI框架，而且SCF可以整合多種語言開發(fā)的服務(wù)，不僅限于Java。在資源占用率方面SCF也有著出色的表現(xiàn)。在數(shù)據(jù)同步和文件傳輸方面，可以支持海量的時空數(shù)據(jù)同步和文件傳輸，數(shù)據(jù)條數(shù)和文件大小不構(gòu)成傳輸瓶頸，而且傳輸帶寬利用率可達(dá)90%以上。

3 結(jié) 語

本文根據(jù)信息資源共享平臺的需求，提出了一種面向時空大數(shù)據(jù)資源集成框架，為實(shí)現(xiàn)大規(guī)模時空數(shù)據(jù)資源和服務(wù)應(yīng)用的整合提供了理論依據(jù)和技術(shù)基礎(chǔ)。實(shí)驗(yàn)表明各系統(tǒng)應(yīng)用可以利用此套資源集成框架高效穩(wěn)定地完成數(shù)據(jù)交換和服務(wù)互操作，實(shí)現(xiàn)系統(tǒng)的互聯(lián)互通。此外，通過性能測試將服務(wù)集成模塊的通信框架SCF與RMI框架進(jìn)行比較分析，結(jié)果表明基于SCF在應(yīng)用于實(shí)際工程時可支持較高的并發(fā)而且響應(yīng)更為快速。通過對數(shù)據(jù)資源集成模塊的性能測試，資源集成框架可以提供高效安全的數(shù)據(jù)庫及文件同步方式。本文研究成果已投入衛(wèi)星地面系統(tǒng)等大型工程實(shí)踐，時空大數(shù)據(jù)資源集成框架能夠滿足系統(tǒng)需求且性能良好。