基于分布式集群架構的遙感數據傳輸機制

劉美佳，張 箐

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

0 概述

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

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

1 相關工作

1.1 對地觀測遙感衛星數據傳輸系統

中國科學院遙感與數字地球研究所負責接收與傳輸對地觀測遙感衛星數據，其地面傳輸系統由多個地面接收站［10］和一個數據接收中心組成。地面接收站負責對接遙感衛星，并將數據上傳到數據接收中心進行匯總和備份。目前，該傳輸系統擁有5 個衛星地面接收站，每天接收并傳輸約200 個遙感衛星數據文件，總數據量高達1 TB，平均每個文件的數據量約60 GB。

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

圖1 LVS 集群內部架構Fig.1 Internal architecture of LVS cluster

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

1.2 遙感傳輸技術

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

文獻［14］提出遙感數據傳輸的多源模式，通過采用多個數據源向同一個用戶提供數據傳輸服務的方式實現遙感數據的快速傳輸。實現該模式的條件是需要多個數據源，然而由于對地觀測遙感數據傳輸系統的數據源具有唯一性，因此該傳輸模式也不適用于解決本文的數據傳輸問題。

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

2 基于分布式系統架構的遙感數據處理

2.1 功能設計

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

圖2 DPM 整體架構設計Fig.2 Design of DPM overall architecture

2.2 技術實現

2.2.1 基本原理

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

圖3 Kafka 和Spark Streaming 架 構Fig.3 Kafka and Spark Streaming architecture

2.2.2 應用設計

DPM 代碼執行流程如圖4 所示。

圖4 DPM 代碼執行流程Fig.4 Procedure of DPM code execution

DPM 代碼執行步驟具體如下：

1）創建消息隊列，從服務器中快速拉取數據。

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

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

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

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

6）在收到傳輸結束符且任務進度為100%時，代表數據傳輸任務完成。

2.3 代碼實現

3 測試與結果分析

3.1 測試環境搭建

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

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

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

表2 網絡配置信息Table 2 Network configuration information

3.2 結果分析

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

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

圖6 給出了DPM 機制在傳輸數據時的狀態信息。測試結果表明，在傳輸過程中DPM 機制的吞吐量約穩定于3 000 條/s，證明了DMP 機制具有穩定性和高效性。

圖6 DPM 狀態信息的測試結果Fig.6 Test results of DPM status information

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

圖7 DPM 續傳數據的性能測試結果Fig.7 Performance test results of DMP resume data

4 結束語

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