海量衛(wèi)星遙感數(shù)據(jù)實時存儲與交換技術設計與實現(xiàn)

周正　鐘志農(nóng)　李軍　伍江江

摘要：隨著人類對地觀測衛(wèi)星系統(tǒng)的發(fā)展，衛(wèi)星遙感數(shù)據(jù)量爆炸性增長。海量的遙感數(shù)據(jù)對當今存儲系統(tǒng)存儲容量、數(shù)據(jù)可用性以及I/O性能等方面提出了越來越高的要求。針對需要持久化存儲與高速交換的數(shù)據(jù)，該文設計并實現(xiàn)了一種基于共享文件系統(tǒng)和文件編目消息推送的海量衛(wèi)星數(shù)據(jù)實時存儲與交換方法。實驗測試表明，該方法針對海量衛(wèi)星遙感數(shù)據(jù)的實時存儲與交換取得了很好的效果。

關鍵詞：海量；遙感數(shù)據(jù)；消息推送；實時存儲；實時存儲與交換

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2017）18-0009-05

1緒論

隨著人類對地衛(wèi)星觀測系統(tǒng)的發(fā)展，遙感數(shù)據(jù)逐步呈現(xiàn)多源、多尺度、多時相、全球覆蓋和高分辨率特征，數(shù)據(jù)量呈爆炸性增長，數(shù)據(jù)存儲規(guī)模達到TB級甚至PB級，IDC預計，到2020年全球數(shù)據(jù)量將達到40ZB。如何更加有序、更加高效地存儲與管理海量遙感數(shù)據(jù)，實現(xiàn)遙感信息的快速共享與分發(fā)，已經(jīng)成為空間信息科學領域研究部門、業(yè)務應用部門和相關機構重點關心的問題。

同時，氣象災害實時監(jiān)測預報、天基遙感信息實時偵察監(jiān)視、軍事情報數(shù)據(jù)實時挖掘等業(yè)務應用對海量衛(wèi)星遙感數(shù)據(jù)的實時分析和處理提出了更高的要求。上述實時分析處理業(yè)務在實現(xiàn)對海量衛(wèi)星數(shù)據(jù)高效存儲的同時，更需要在多個處理節(jié)點間實現(xiàn)海量衛(wèi)星數(shù)據(jù)的實時共享和更新。針對此問題，不但需要利用存儲系統(tǒng)在存儲容量、數(shù)據(jù)可用性以及I/O性能等方面提供支持，更亟需對海量衛(wèi)星遙感數(shù)據(jù)高速實時存儲和數(shù)據(jù)交換機制展開研究。因此，針對需要持久化存儲與高速交換的數(shù)據(jù)，本文擬基于共享文件系統(tǒng)和消息中間件，研究海量衛(wèi)星數(shù)據(jù)實時存儲與交換機制。

1.1問題背景及分析

在實際業(yè)務應用中，衛(wèi)星7×24小時不斷向地面下傳數(shù)據(jù)，地面數(shù)據(jù)處理系統(tǒng)也必須7×24小時處于實時工作狀態(tài)。地面數(shù)據(jù)處理系統(tǒng)接收衛(wèi)星下傳數(shù)據(jù)后，經(jīng)過一系列預處理與分析，將接收到的流式數(shù)據(jù)切分成若干不同大小的小文件，以方便進行數(shù)據(jù)分析和處理。為了實現(xiàn)對海量、高速、持續(xù)衛(wèi)星數(shù)據(jù)流的存儲管理，并保證衛(wèi)星數(shù)據(jù)處理關鍵業(yè)務可重現(xiàn)，以及數(shù)據(jù)可查、可審計，需要對海量衛(wèi)星數(shù)據(jù)進行實時存儲。

同時，在衛(wèi)星遙感數(shù)據(jù)實時處理業(yè)務流程中，當數(shù)據(jù)生成節(jié)點（包括Linux節(jié)點和Windows節(jié)點）將各種衛(wèi)星數(shù)據(jù)高速存入共享文件系統(tǒng)之后，其他數(shù)據(jù)處理節(jié)點（Linux節(jié)點和Win-dows節(jié)點）和前端業(yè)務綜合顯示節(jié)點（Windows工作站）往往需要求對最新寫入的數(shù)據(jù)文件進行實時查詢和數(shù)據(jù)讀取操作。對于跨平臺進程間的數(shù)據(jù)傳輸，直接通過傳統(tǒng)的TCP/IP方式進行傳輸顯然由于應用的特殊性以及帶寬的限制不能達到很好的效果。所以要求設計一套服務，能夠滿足跨平臺的文件交換，能夠進行多類型數(shù)據(jù)的分發(fā)和交換，滿足數(shù)據(jù)處理低延遲要求。海量衛(wèi)星數(shù)據(jù)實時存儲與交換流程如圖1所示。

1.2服務具備特點

海量衛(wèi)星實時數(shù)據(jù)存儲服務是所有需要進行數(shù)據(jù)高速寫人的實時處理業(yè)務應用的基礎支撐，為此實時數(shù)據(jù)存儲服務需要具備以下特點：

1）海量數(shù)據(jù)存儲管理能力。隨著衛(wèi)星平臺、衛(wèi)星載荷能力的增長，地面數(shù)據(jù)分析處理系統(tǒng)每日需要處理的數(shù)據(jù)量日益龐大，數(shù)據(jù)量呈TR級增長，如何高效合理的組織如此大量的數(shù)據(jù)并能為后期提供可靠的數(shù)據(jù)查詢服務，這對數(shù)據(jù)存儲管理能力提出了很高的要求。

2）7×24小時持續(xù)運行能力。衛(wèi)星遙感數(shù)據(jù)流7×24小時無間斷下傳，這要求數(shù)據(jù)實時存儲服務需要時刻處于高負荷工作狀態(tài)；同時，需要面對存儲過程中可能出現(xiàn)的數(shù)據(jù)量突發(fā)波峰的狀況。這對實時數(shù)據(jù)存儲服務的可用性提出了非常高的要求，需要具備7×24小時不間斷、高可靠運行的能力。

3）數(shù)據(jù)存儲低延遲要求。數(shù)據(jù)實時存儲服務需要為數(shù)據(jù)分析和處理業(yè)務提供商性能的數(shù)據(jù)寫人和讀取服務，以滿足數(shù)據(jù)寫入的低延遲要求。

4）海量小文件快速寫入能力。地面數(shù)據(jù)分析處理系統(tǒng)生成的各級數(shù)據(jù)產(chǎn)品中包含海量小文件（大小從幾百KB至幾兆字節(jié)不等），而典型的共享文件系統(tǒng)在應對海量小文件持續(xù)寫人方面性能低下，所以需要針對海量小文件的持續(xù)寫人進行優(yōu)化設計。

5）快速的消息分發(fā)能力。數(shù)據(jù)實時存儲與交換系統(tǒng)需要實時的在數(shù)據(jù)存儲端與數(shù)據(jù)讀取端進行數(shù)據(jù)交換，并且有一定的時延要求。即數(shù)據(jù)寫入節(jié)點在完成數(shù)據(jù)寫入之后，需要將數(shù)據(jù)的文件編目信息和寫入完成標志及時通知數(shù)據(jù)讀取節(jié)點；同時，數(shù)據(jù)文件編目信息往往需要在多個數(shù)據(jù)讀取節(jié)點之間進行共享，以保證數(shù)據(jù)的一致性，所以需要使用具備發(fā)布/訂閱機制的消息中間件實現(xiàn)數(shù)據(jù)文件編目信息的實時共享和更新。

2海量衛(wèi)星遙感數(shù)據(jù)實時存儲與交換設計

2.1數(shù)據(jù)存儲模式設計

1）數(shù)據(jù)存儲模式選擇

存儲系統(tǒng)的存儲模式影響著整個海量數(shù)據(jù)存儲系統(tǒng)的性能，為了提供高性能的數(shù)據(jù)存儲能力，應該考慮選擇良好的海量數(shù)據(jù)存儲模式。適合海量數(shù)據(jù)的理想存儲模式應該能夠提供高性能、可伸縮、跨平臺、安全的數(shù)據(jù)共享能力。為此選擇了網(wǎng)絡附加存儲（NAS）的網(wǎng)絡附加存儲產(chǎn)品作為目標存儲容器。

2）數(shù)據(jù)庫存儲選擇

數(shù)據(jù)庫管理系統(tǒng)（DBMS）是數(shù)據(jù)實時存儲系統(tǒng)的元數(shù)據(jù)管理的核心組成。Oracle在數(shù)據(jù)高性能存儲檢索領域應用廣泛，海量數(shù)據(jù)實時存儲的元數(shù)據(jù)管理采用Oracle數(shù)據(jù)庫實現(xiàn)。

3）數(shù)據(jù)寫入方式設計

分布式文件系統(tǒng)對于大文件的數(shù)據(jù)訪問操作有較好的支持，能夠提供GB級的數(shù)據(jù)寫人帶寬和數(shù)據(jù)讀取帶寬；但是對于海量小文件的讀寫支持相對受限。因此，針對海量小文件存儲，本文通過多線程、多任務以及分布式文件系統(tǒng)的高帶寬來提升海量小文件的寫入速度。

4）數(shù)據(jù)實時存儲模塊實現(xiàn)形態(tài)設計

API（Application Programming Interface，應用程序編程接口）是一類預先定義的函數(shù)，可以為上層應用程序提供標準的調用方法和接口，上層應用程序以透明方式對API進行訪問。因此，數(shù)據(jù)實時存儲實現(xiàn)形態(tài)擬采用API方式進行實現(xiàn)，從而滿足地面數(shù)據(jù)實時分析與處理業(yè)務對數(shù)據(jù)存儲的時效性要求。endprint

2.2海量衛(wèi)星遙感數(shù)據(jù)實時存儲及消息推送機制方案設計

海量衛(wèi)星數(shù)據(jù)實時存儲與交換主要包含兩個部分。即數(shù)據(jù)實時存儲與數(shù)據(jù)實時交換。

對于實時存儲部分。應用的壓力在于海量衛(wèi)星數(shù)據(jù)的不間斷下傳，導致數(shù)據(jù)量不斷地增長。如何快速、高效、低延遲的將海量衛(wèi)星數(shù)據(jù)存入存儲媒介是要解決的首要問題。分布式文件系統(tǒng)由于其可擴展性、高可用性、多接口協(xié)議、安全等各種優(yōu)點被納入考量的范圍。同時由于其多操作系統(tǒng)訪問的無關性，使得可以利用這個特性來實現(xiàn)不同操作系統(tǒng)之間的數(shù)據(jù)共享。

對于數(shù)據(jù)的交換部分。分布式文件系統(tǒng)為系統(tǒng)提供了一個海量數(shù)據(jù)存儲容器。但如此大量的數(shù)據(jù)的管理勢必成為一個必須解決的問題，如何快速、安全、高效的將用戶需要的數(shù)據(jù)從分布式文件系統(tǒng)這個數(shù)據(jù)池中打撈出來。是我們第二個需要解決的問題。關系型數(shù)據(jù)庫通常以行列的方式進行數(shù)據(jù)的組織，并配備有高效的查詢算法，可以對某個字段進行快速的范圍查詢。海量衛(wèi)星數(shù)據(jù)實時處理過程中需要進行大量的數(shù)據(jù)查詢，關系型數(shù)據(jù)庫已經(jīng)能夠滿足大部分的范圍查詢工作。如何實時的通知讀取應用端進行最新數(shù)據(jù)的讀取，消息分發(fā)服務被用來處理通知的分發(fā)工作。數(shù)據(jù)實時存儲與交換的體系結構如圖1所示：實時數(shù)據(jù)寫服務器調用SJCC.so（數(shù)據(jù)存儲動態(tài)鏈接庫進行文件的快速寫入。當文件和數(shù)據(jù)編目分別寫入分布式文件系統(tǒng)與數(shù)據(jù)庫后，實時數(shù)據(jù)寫服務器將衛(wèi)星數(shù)據(jù)產(chǎn)品文件編目信息以自定義消息格式發(fā)布到消息分發(fā)服務；實時數(shù)據(jù)讀取服務器，即消息訂閱端從消息分發(fā)服務接收已訂閱的衛(wèi)星數(shù)據(jù)產(chǎn)品文件編目信息。實時數(shù)據(jù)讀取服務器解析消息格式并獲取最新的衛(wèi)星數(shù)據(jù)產(chǎn)品文件路徑，從分布式文件系統(tǒng)中讀取最新文件數(shù)據(jù)。

3海量衛(wèi)星遙感數(shù)據(jù)實時存儲與交換關鍵技術

3.1基于消息中間件的衛(wèi)星數(shù)據(jù)編目傳遞方式

數(shù)據(jù)實時存儲服務器也即消息分發(fā)客戶端作為消息生產(chǎn)者的存在進行消息的發(fā)布。在消息分發(fā)客戶端中定義了消息格式為AAAAdata-typemessage-lengthMESSAGEBBBB。其中，開始的AAAA與結束的BBBB作為統(tǒng)一格式；data-type表示了消息的類型，即當前消息屬于哪種消息，以方便訂閱端進行數(shù)據(jù)分類；MESSAGE作為消息的載體用來傳輸真正有用的數(shù)據(jù)，實時存儲服務將文件的路徑作為消息（MESSAGE）發(fā)布到消息分發(fā)服務。前端顯示工作站根據(jù)data-type訂閱相應數(shù)據(jù)類型，并從MESSAGE中獲取最新寫入分布式文件系統(tǒng)中文件的路徑，從而讀取到最新的文件，完成一輪實時交換。由于省略了文件的直接傳輸發(fā)送，而變成只是進行了類似于元數(shù)據(jù)的傳輸，數(shù)據(jù)的實時交換效率得到了極大提高?；谙⒅虚g件的衛(wèi)星數(shù)據(jù)編目推送服務，如圖2所示。

3.2基于消息中間件的衛(wèi)星數(shù)據(jù)編目推送流程

對于消息分發(fā)客戶端，程序啟動過程中會初始化所有相關資源。包括初始化連接環(huán)境，設置消息發(fā)布種類等。初始化成功后消息分發(fā)客戶端將開始連接消息分發(fā)主服務。若連接成功，消息分發(fā)客戶端程序進入服務就緒狀態(tài)并等待新消息的發(fā)布。若連接失敗，消息分發(fā)客戶端將開始連接消息分發(fā)備服務。若連接成功，將由消息分發(fā)備服務提供消息分發(fā)功能。若連接仍然失敗，在兩臺消息分發(fā)服務均未連接成功的情況下，消息分發(fā)客戶端啟動失敗。

對于消息接收客戶端，程序流程基本一致，程序啟動過程中會初始化所有相關資源，包括初始化連接環(huán)境，設置消息發(fā)布種類等。初始化成功后消息接收客戶端將開始連接消息分發(fā)主服務。若連接成功，程序進人服務就緒狀態(tài)并等待新消息的發(fā)布。若連接失敗，消息接收客戶端將開始連接消息分發(fā)備服務。若連接成功，將由消息分發(fā)備服務提供消息分發(fā)功能。若仍然連接失敗，在兩臺消息分發(fā)服務均未連接成功的情況下，消息接收客戶端啟動失敗?；谙⒅虚g件的衛(wèi)星數(shù)據(jù)編目推送服務如圖3所示。

3.3基于消息中間件的海量衛(wèi)星遙感數(shù)據(jù)編目推送類設計

基于消息中間件的衛(wèi)星編目推送主要包含消息分發(fā)客戶端，以及消息接收客戶端。消息分發(fā)客戶端的主要任務是發(fā)布消息到消息分發(fā)服務，消息接收客戶端的主要功能為訂閱并接收來自消息分發(fā)服務的消息。下面將做詳細說明。

1）消息分發(fā)客戶端類詳細設計

消息分發(fā)類主要功能為穩(wěn)定、可靠、完整的發(fā)布消息到消息分發(fā)服務，設計的方法包括構造的方法（PublishCli-ent）主要功能為確定消息分發(fā)服務的網(wǎng)絡地址，以及當前消息分發(fā)客戶端將要發(fā)布的所有消息種類；單點故障切換方法（changeServer），由于消息分發(fā)服務采用主備用方式提供服務，當某一臺消息分發(fā)服務器宕機時，將調用該方法進行服務器主備連接的切換，時刻保障服務的可用性；重啟（re-start）對消息分發(fā)客戶端進行重啟操作；關閉方法（close）將關閉當前與消息分發(fā)服務端的連接；清理方法（cleanup）負責關閉清理所有與消息分發(fā)連接過程中申請的資源；消息發(fā)送方法（sendTextMessage）負責根據(jù)傳遞的參數(shù)（Iype）識別不同的數(shù)據(jù)類型，以此來發(fā)送對應的消息類型。初始化方法（initialize）負責資源的初始化工作；狀態(tài)檢查（stillAlive）負責檢測當前與消息分發(fā)服務的連接是否處于正常連接狀態(tài)，防止由于消息分發(fā)服務端意外宕機或服務關閉造成的連接失效，當檢測到連接中斷時，stillAlive方法將進行重連操作。詳細類圖如圖4所示。2）消息接收客戶端類的詳細設計消息接收類（subscription）由于功能相對簡單，主要負責訂閱接收從消息分發(fā)服務傳遞過來的消息。其主要方法包括開始方法（start）負責初始化消息接收客戶端，包括確定消息分發(fā)服務的網(wǎng)絡地址、確定訂閱的消息種類、消息接收模式選擇等；關閉方法（close）負責斷開與消息服務之間的連接；運行方法（run）為實際數(shù)據(jù)接收方法；消息接收顯示（onMessage）負責顯示的將消息呈現(xiàn)到屏幕。資源清理方法（cleanup）負責清理所有連接消息服務過程中使用的資源。詳細類圖如圖5所示：endprint

4測試與分析

1）硬件環(huán)境

使用若干臺掛載了分布式文件系統(tǒng)的高性能計算服務器作為測試主機，分布式文件存儲使用華為Oceanstor5500，服務器配置如下：

CPU：Intel（R）Xeon（R）CPU E5-2670 0@2.60GHz×32

內存：64G

網(wǎng)卡：Intel Corporation 82599ES萬兆網(wǎng)卡

2）軟件環(huán)境

操作系統(tǒng)：Redhat Linux 6.5 64位

文件系統(tǒng)：華為Oceanstor5500分布式文件系統(tǒng)

31測試

數(shù)據(jù)實時存儲與交換結構化數(shù)據(jù)時間延遲測試

本測試主要用于測試結構數(shù)據(jù)的實時存儲與交換時間延遲。

測試方法：

在數(shù)據(jù)庫中創(chuàng)建字段個數(shù)不小于20的表結構，其中字段類型為任意的數(shù)據(jù)庫基礎類型，測試程序TEST01通過隨機數(shù)據(jù)方式向數(shù)據(jù)實時存儲服務（SJCCFW）中進行結構化數(shù)據(jù)的寫入，在調用數(shù)據(jù)寫人前進行時刻記錄t0。并通過消息分發(fā)服務（XXFFServer）進行消息的多客戶端分發(fā)。消息接收客戶端（XXJSClient）接收完數(shù)據(jù)進行消息的解析與處理并在處理完畢后發(fā)送處理完畢通知給測試程序TEST01，同時記錄時刻t1。則結構化數(shù)據(jù)的實時存儲與交換時間延遲t=tl-t0。調用時間間隔為1秒鐘?？傉{用次數(shù)10000次。

將測試結果以圖表的形式進行結果展示，如圖6所示。其中圖表的橫坐標代表測試的延遲區(qū)間，單位為毫秒（ms），延遲總區(qū)間為0～1000毫秒，區(qū)間間隔50毫秒。縱坐標表示每個區(qū)間所占百分比，主縱坐標表示占百分比較大數(shù)據(jù)的，副坐標表示占百分比較小的數(shù)據(jù)。

數(shù)據(jù)實時存儲與交換結構化數(shù)據(jù)時間延遲測試如圖Ⅳ.1所示，從圖中可以看出，對于結構化數(shù)據(jù)，數(shù)據(jù)實時存儲與交換的交換延遲區(qū)間超過百分之99都處于0～50毫秒，另外的所有區(qū)間都落在100～150毫秒，測試結果很理想。

4）數(shù)據(jù)實時存儲與交換非結構化數(shù)據(jù)時間延遲測試

測試方法：

準備大小為1MB的測試文件FILE進行非結構化數(shù)據(jù)測試，測試程序TEST02通過以FILE為模板的方式向數(shù)據(jù)實時存儲服務（SJCCFW）中進行非結構化數(shù)據(jù)的寫入，在調用數(shù)據(jù)寫入前進行時刻記錄t0。并通過消息分發(fā)服務（xXFFServer）進行消息的多客戶端分發(fā)。消息接收客戶端（xXJSClient）接收完數(shù)據(jù)進行消息的解析與處理并在處理完畢后發(fā)送處理完畢通知給測試程序TEST02，同時記錄時刻t1。則非結構化數(shù)據(jù)的實時存儲與交換時間延遲t=t1-t0。調用時間間隔為1秒鐘?？傉{用次數(shù)10000次。

將測試結果以圖表的形式進行結果展示，如圖7所示。其中圖表的橫坐標代表測試的延遲區(qū)間，單位為毫秒（ms），延遲總區(qū)間為0～1000毫秒，區(qū)間間隔50毫秒?？v坐標表示每個區(qū)間所占百分比，主縱坐標表示占百分比較大數(shù)據(jù)的，副坐標表示占百分比較小的數(shù)據(jù)。

數(shù)據(jù)實時存儲與交換結構化數(shù)據(jù)時間延遲測試如圖7所示，從圖中可以看出，對于非結構化數(shù)據(jù)，數(shù)據(jù)實時存儲與交換的交換延遲區(qū)間超過百分之99都處于0～50毫秒，最大區(qū)間為200～250毫秒，但百分比占比很小，測試結果很理想。

5）數(shù)據(jù)實時存儲與交換非結構化數(shù)據(jù)帶編目數(shù)據(jù)時間延遲測試

在數(shù)據(jù)庫中創(chuàng)建字段個數(shù)不小于20的表結構，其中字段類型為任意的數(shù)據(jù)庫基礎類型，準備大小為1MB的文件FILE作為非結構化數(shù)據(jù)測試文件，測試程序TEST03通過數(shù)據(jù)實時存儲服務（SJCCFW）以隨機方式向數(shù)據(jù)庫中寫入結構化數(shù)據(jù)，并以FILE為模板的方式向數(shù)據(jù)實時存儲服務（SJCCFW）中進行非結構化數(shù)據(jù)的寫入，在調用數(shù)據(jù)寫入前進行時刻記錄t0。并通過消息分發(fā)服務（XXFFServer）進行消息的多客戶端分發(fā)。消息接收客戶端（XXJSClient）接收完數(shù)據(jù)進行消息的解析與處理并在處理完畢后發(fā)送處理完畢通知給測試程序TEST02，同時記錄時刻t1。則非結構化數(shù)據(jù)的實時存儲與交換時間延遲t=t1-t0。調用時間間隔為1秒鐘?？傉{用次數(shù)10000次。

將測試結果以圖表的形式進行結果展示，如圖8所示。其中圖表的橫坐標代表測試的延遲區(qū)間，單位為毫秒（ms），延遲總區(qū)間為0～1000毫秒，區(qū)間間隔50毫秒。縱坐標表示每個區(qū)間所占百分比，主縱坐標表示占百分比較大數(shù)據(jù)的，副坐標表示占百分比較小的數(shù)據(jù)。

數(shù)據(jù)實時存儲與交換非結構化數(shù)據(jù)帶編目時間延遲測試如圖8所示，從圖中可以看出，對于非結構化帶編目數(shù)據(jù)，數(shù)據(jù)實時存儲與交換的交換延遲區(qū)間超過百分之68.833都處于0～50毫秒，另外處于50～100毫秒的占比百分之30.944最大延遲區(qū)間處于300～350毫秒，即使同時寫結構化數(shù)據(jù)與非結構化數(shù)據(jù)，結果依然很穩(wěn)定。

4總結

本章通過對實際業(yè)務的具體分析，確定了海量實時存儲與交換過程中可能遇到的一些問題，根據(jù)對問題的具體分析。設計并實現(xiàn)了一套基于共享文件系統(tǒng)與消息推送機制的數(shù)據(jù)實時存儲與交換服務，通過對結構化數(shù)據(jù)、非結構化數(shù)據(jù)、非結構化數(shù)據(jù)帶編目的測試實驗，測試結果取得了令人滿意的效果。endprint