劉美佳，張 箐

（1.中國科學(xué)院空天信息創(chuàng)新研究院，北京 100094；2.中國科學(xué)院大學(xué) 電子電氣與通信工程學(xué)院，北京 100049）

0 概述

隨著傳感器技術(shù)、航空航天技術(shù)和數(shù)據(jù)通信技術(shù)的不斷發(fā)展，遙感衛(wèi)星在軌服役數(shù)量逐年遞增［1-3］，遙感數(shù)據(jù)文件數(shù)量及其承載的信息量日益提升，使得遙感衛(wèi)星的數(shù)據(jù)獲取能力高于遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)［4］的負載能力。為解決遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)與傳輸需求的矛盾，通常有兩種提高傳輸系統(tǒng)性能的手段。一種是增加數(shù)據(jù)傳輸基礎(chǔ)設(shè)施數(shù)量，通過擴展物理承載容量提升傳輸系統(tǒng)的性能。另一種是優(yōu)化傳輸系統(tǒng)架構(gòu)，通過合理分配現(xiàn)有硬件資源，使得傳輸系統(tǒng)資源利用率最大化。早期的遙感數(shù)據(jù)傳輸系統(tǒng)采用基礎(chǔ)的單機模式，在該模式下服務(wù)器將遙感數(shù)據(jù)存儲在本地，傳輸系統(tǒng)通過增加服務(wù)器數(shù)量擴展系統(tǒng)的吞吐量和存儲容量。然而在基礎(chǔ)單機模式下服務(wù)器之間的傳輸服務(wù)相互獨立、數(shù)據(jù)存儲彼此隔離，當(dāng)一臺服務(wù)器出現(xiàn)故障時，會導(dǎo)致該服務(wù)器上的全部數(shù)據(jù)無法進行訪問和轉(zhuǎn)發(fā)。因此，在該模式下的傳輸系統(tǒng)抗風(fēng)險能力低，故障恢復(fù)速度慢。

隨著集群技術(shù)的發(fā)展和完善，遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)采用Linux 虛擬服務(wù)器（Linux Virtual Server，LVS）集群模式［5-7］代替基礎(chǔ)單機模式。LVS 集群將多臺服務(wù)器虛擬成一臺服務(wù)器為客戶端提供文件傳輸服務(wù)，該集群中的所有服務(wù)器共享同一個網(wǎng)絡(luò)地址和存儲系統(tǒng)。在LVS 集群架構(gòu)下，只要發(fā)生故障的服務(wù)器數(shù)量小于提供服務(wù)的服務(wù)器數(shù)量，就能保證傳輸遙感衛(wèi)星數(shù)據(jù)傳輸任務(wù)正常進行，從而增強了傳輸系統(tǒng)的魯棒性［8］。但是在該集群架構(gòu)模式下，在客戶端與集群服務(wù)器之間的文件傳輸協(xié)議（File Transfer Protocol，F(xiàn)TP）［9］連接中斷后，負載服務(wù)器將新建連接負載至其他服務(wù)器時，如果新舊服務(wù)器同時讀寫共享存儲的同一路徑文件則會導(dǎo)致該文件中部分數(shù)據(jù)重復(fù)。當(dāng)收發(fā)兩端的數(shù)據(jù)文件大小不一致時，需要重新傳輸數(shù)據(jù)文件，重傳不僅需要額外地消耗傳輸系統(tǒng)的資源，而且降低了遙感數(shù)據(jù)文件的實時性。本文介紹對地觀測遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)，分析當(dāng)前遙感傳輸技術(shù)的研究現(xiàn)狀，提出基于分布式系統(tǒng)架構(gòu)的遙感數(shù)據(jù)處理機制DPM。

1 相關(guān)工作

1.1 對地觀測遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)

中國科學(xué)院遙感與數(shù)字地球研究所負責(zé)接收與傳輸對地觀測遙感衛(wèi)星數(shù)據(jù)，其地面?zhèn)鬏斚到y(tǒng)由多個地面接收站［10］和一個數(shù)據(jù)接收中心組成。地面接收站負責(zé)對接遙感衛(wèi)星，并將數(shù)據(jù)上傳到數(shù)據(jù)接收中心進行匯總和備份。目前，該傳輸系統(tǒng)擁有5 個衛(wèi)星地面接收站，每天接收并傳輸約200 個遙感衛(wèi)星數(shù)據(jù)文件，總數(shù)據(jù)量高達1 TB，平均每個文件的數(shù)據(jù)量約60 GB。

當(dāng)前遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)兩端均采用LVS 集群技術(shù)實現(xiàn)高吞吐、可擴展、高冗余的數(shù)據(jù)傳輸，集群內(nèi)部架構(gòu)如圖1 所示。LVS 集群架構(gòu)分為3 層：第1 層是負載調(diào)度服務(wù)器，位于LVS集群前端，采用輪詢（Round-Robin，RR）調(diào)度算法將客戶端的連接請求分發(fā)給真實服務(wù)器；第2 層是服務(wù)器池，位于集群服務(wù)系統(tǒng)的中間層，由多個性能相同的服務(wù)器組成，是用于處理客戶端請求的真實服務(wù)器；第3 層是共享存儲，由多個存儲設(shè)備組成，為真實服務(wù)器提供同一的存儲接口，實現(xiàn)主存儲共享。該集群架構(gòu)具有高容錯能力，可以確保傳輸任務(wù)不受一個甚至多個服務(wù)器宕機的影響，從而為客戶端提供持續(xù)穩(wěn)定的數(shù)據(jù)傳輸服務(wù)。

圖1 LVS 集群內(nèi)部架構(gòu)Fig.1 Internal architecture of LVS cluster

LVS 集群基于TCP/IP 協(xié)議棧第4 層協(xié)議（TCP、UDP）［11-12］實現(xiàn)負載調(diào)度，當(dāng)遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)重新創(chuàng)建FTP 數(shù)據(jù)連接時套接字字段改變，負載均衡服務(wù)器為客戶端重新分配真實服務(wù)器。此時如果舊服務(wù)器未能將本地接收的數(shù)據(jù)及時寫入共享存儲，則會導(dǎo)致部分數(shù)據(jù)片重復(fù)。由于無法定位重復(fù)數(shù)據(jù)片在整軌數(shù)據(jù)中的位置，因此只能丟棄整軌數(shù)據(jù)并進行重傳，這不僅會浪費網(wǎng)絡(luò)資源，而且會降低遙感數(shù)據(jù)的實時性。

1.2 遙感傳輸技術(shù)

文獻［13］針對C/S 模式下存在的遙感數(shù)據(jù)傳輸速度慢、負載任務(wù)重等問題，提出一種快速的遙感數(shù)據(jù)傳輸策略RSDFT。該策略可以根據(jù)數(shù)據(jù)下載速率的變化，動態(tài)地選擇合適的資源服務(wù)器，從而提高客戶端下載速率。然而RSDFT 并未考慮數(shù)據(jù)斷點續(xù)傳的情況，因此該策略不適用于當(dāng)前的對地觀測遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)。

文獻［14］提出遙感數(shù)據(jù)傳輸?shù)亩嘣茨Ｊ剑ㄟ^采用多個數(shù)據(jù)源向同一個用戶提供數(shù)據(jù)傳輸服務(wù)的方式實現(xiàn)遙感數(shù)據(jù)的快速傳輸。實現(xiàn)該模式的條件是需要多個數(shù)據(jù)源，然而由于對地觀測遙感數(shù)據(jù)傳輸系統(tǒng)的數(shù)據(jù)源具有唯一性，因此該傳輸模式也不適用于解決本文的數(shù)據(jù)傳輸問題。

上述文獻從增加資源服務(wù)器數(shù)量或數(shù)據(jù)源數(shù)量的角度出發(fā)提升系統(tǒng)傳輸速率，但是上述方法均不能解決當(dāng)前對地觀測遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)中存在的數(shù)據(jù)片重復(fù)問題，因此本文提出DPM 機制。

2 基于分布式系統(tǒng)架構(gòu)的遙感數(shù)據(jù)處理

2.1 功能設(shè)計

DPM 機制是針對當(dāng)前遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)架構(gòu)提出的工作在FTP 服務(wù)器和共享存儲之間的中間件，其整體架構(gòu)設(shè)計如圖2 中的虛線框所示。DPM 機制主要包含消息隊列、Spark Streaming 集群和數(shù)據(jù)記錄模塊，其中：消息隊列由Kafka 發(fā)布訂閱消息系統(tǒng)［15］實現(xiàn)，用于快速有效地存儲真實服務(wù)器中的數(shù)據(jù)；Spark Streaming 集群［16］負責(zé)按序拉取消息隊列中的數(shù)據(jù)并將其持久化到HDFS［17］，偏移量提交模塊被用于提高Spark Streaming 的準確性；數(shù)據(jù)記錄模塊負責(zé)記錄DPM 機制的實時狀態(tài)，用于系統(tǒng)故障恢復(fù)查詢和實時監(jiān)控查詢。

圖2 DPM 整體架構(gòu)設(shè)計Fig.2 Design of DPM overall architecture

2.2 技術(shù)實現(xiàn)

2.2.1 基本原理

Kafka［18］是由Linkedin［19］開發(fā)的發(fā)布訂閱消息系統(tǒng)，架構(gòu)如圖3 虛線框中上半部分所示。Kafka 分布式集群系統(tǒng)由多個服務(wù)器組成，集群中的服務(wù)器被稱作代理服務(wù)器（Broker）［20-21］。代理服務(wù)器中用主題（Topic）代表邏輯上的消息集合，用分區(qū)（Partition）表示物理設(shè)備上的實際存儲隊列。消息隊列在存儲數(shù)據(jù)時采用備份機制，通過在不同的代理服務(wù)器上創(chuàng)建主備消息隊列確保數(shù)據(jù)準確性。Spark［22-23］是大數(shù)據(jù)處理引擎，可以實現(xiàn)內(nèi)存的統(tǒng)一管理。Spark Streaming［24-25］是Spark的擴展模塊，用于處理實時大規(guī)模流式數(shù)據(jù)，架構(gòu)如圖3虛線框中下半部分所示。Spark Streaming 運行在Spark的核心架構(gòu)上，首先使用Streaming Context 作為數(shù)據(jù)流的入口，從消息隊列中拉取數(shù)據(jù)。然后在內(nèi)存中快速處理消息，并將處理后的數(shù)據(jù)寫入硬盤進行永久存儲。

圖3 Kafka 和Spark Streaming 架 構(gòu)Fig.3 Kafka and Spark Streaming architecture

2.2.2 應(yīng)用設(shè)計

DPM 代碼執(zhí)行流程如圖4 所示。

圖4 DPM 代碼執(zhí)行流程Fig.4 Procedure of DPM code execution

DPM 代碼執(zhí)行步驟具體如下：

1）創(chuàng)建消息隊列，從服務(wù)器中快速拉取數(shù)據(jù)。

2）Spark Streaming 不斷獲取消息隊列中的數(shù)據(jù)，并將處理后的數(shù)據(jù)存儲到HDFS。

3）偏移量提交模塊將處理完成的消息偏移量值寫入數(shù)據(jù)庫。

4）使用處理一個批次數(shù)據(jù)所用的時間值除以數(shù)據(jù)條數(shù)得出處理速率，并將該值寫入數(shù)據(jù)庫。

5）使用消息隊列中的最大偏移量值除以提交偏移量值得出任務(wù)進度，并將該值寫入數(shù)據(jù)庫。

6）在收到傳輸結(jié)束符且任務(wù)進度為100%時，代表數(shù)據(jù)傳輸任務(wù)完成。

2.3 代碼實現(xiàn)

3 測試與結(jié)果分析

3.1 測試環(huán)境搭建

使用3 臺性能相同的虛擬機搭建成Hadoop 分布式集群。硬件參數(shù)為8 GB 內(nèi)存、40 GB 磁盤，2.6 GHz CPU，Centos6.10 操作系統(tǒng)。軟件安裝順序與版本號如表1 所示。

表1 軟件安裝順序與版本號Table 1 Software installation sequence and version number

網(wǎng)絡(luò)配置信息如表2 所示。Hadoop 集群由Hadoop101、Hadoop102、Hadoop103 這3 個節(jié)點組成。Kafka 部署在Hadoop 集群上，每臺設(shè)備用Broker-ID 唯一標識，標識號1、2、3 分別對應(yīng)主機Hadoop101、Hadoop102、Hadoop103。Apache Spark 計算平臺兼容Hadoop，可直接部署在Hadoop 集群上。

表2 網(wǎng)絡(luò)配置信息Table 2 Network configuration information

3.2 結(jié)果分析

Spark Streaming 偏移量提交模塊的測試結(jié)果如圖5 所示，其中，offset-DPM 表示DPM 機制記錄的偏移量值，offset-auto 表示Spark Streaming 自動提交的偏移量值。測試結(jié)果表明，Spark Streaming 自動提交的偏移量值相比DPM 機制記錄的偏移量值更精確。

圖5 偏移量提交模塊的測試結(jié)果Fig.5 Test results of offset submission module

圖6 給出了DPM 機制在傳輸數(shù)據(jù)時的狀態(tài)信息。測試結(jié)果表明，在傳輸過程中DPM 機制的吞吐量約穩(wěn)定于3 000 條/s，證明了DMP 機制具有穩(wěn)定性和高效性。

圖6 DPM 狀態(tài)信息的測試結(jié)果Fig.6 Test results of DPM status information

圖7 給出了DPM 機制續(xù)傳數(shù)據(jù)的性能測試結(jié)果，其中，maxoffset 代表分區(qū)中的最大偏移量值，consumeroffset 代表偏移量提交模塊的記錄值。測試結(jié)果表明：當(dāng)服務(wù)器停止向消息隊列中寫入數(shù)據(jù)時，并不影響DPM 機制向HDFS 中寫入數(shù)據(jù)；當(dāng)服務(wù)器繼續(xù)向消息隊列寫入數(shù)據(jù)時，DPM 機制也能及時處理消息隊列中的數(shù)據(jù)，驗證了DPM 機制的續(xù)傳性能良好，且不受服務(wù)器狀態(tài)影響。

圖7 DPM 續(xù)傳數(shù)據(jù)的性能測試結(jié)果Fig.7 Performance test results of DMP resume data

4 結(jié)束語

當(dāng)前對地觀測遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)采用集群加分布式存儲架構(gòu)模式存儲遙感衛(wèi)星數(shù)據(jù)，在實現(xiàn)FTP 斷點續(xù)傳數(shù)據(jù)時因真實服務(wù)器變更造成部分數(shù)據(jù)重復(fù)，導(dǎo)致整軌衛(wèi)星數(shù)據(jù)重傳，從而降低傳輸效率和數(shù)據(jù)實時性。本文提出DPM 機制對遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)架構(gòu)進行優(yōu)化，將消息隊列和實時計算框架相結(jié)合實現(xiàn)數(shù)據(jù)實時接收和處理，利用偏移量提交模塊精準記錄偏移量值，采用數(shù)據(jù)記錄模塊記錄DPM 機制自身的狀態(tài)信息。測試結(jié)果表明，DPM機制可保證傳輸數(shù)據(jù)的準確性和實時性。下一步將設(shè)計DPM 機制的應(yīng)用程序接口，實現(xiàn)segment 文件周期等參數(shù)的靈活配置，并將DPM 機制在實際的遙感衛(wèi)星數(shù)據(jù)傳輸系統(tǒng)中進行驗證，提高遙感數(shù)據(jù)傳輸系統(tǒng)的吞吐量。