馬福利，石濤，陳玲，鄭巖，熊森林

1. 中國科學院國家空間科學中心，北京 100190；2. 中國科學院空天信息創(chuàng)新研究院，北京 100094

1 引言

空間科學是一門前沿交叉性學科，聚焦于宇宙和生命起源、太陽系與人類起源等基礎前沿主題，致力于解決暗物質與暗能量、引力波、太陽活動與空間天氣響應等重大科學問題?？臻g科學是典型的“數據驅動”型學科。以航天器平臺為主要手段獲取的科學數據對于學科的發(fā)展具有舉足輕重的作用。一套優(yōu)良的衛(wèi)星地面數據處理系統需要保障科學衛(wèi)星數據的正確性、完整性、可用性、易用性和時效性，最大限度地發(fā)揮出衛(wèi)星探測數據的研究價值。

國內外就衛(wèi)星地面處理系統開展了大量的研制工作，形成了較穩(wěn)定的科學衛(wèi)星地面數據處理系統框架。國內方面，遙感衛(wèi)星形成了面向單衛(wèi)星的基于分布式云存儲技術的地面實時處理系統[1]以及具有一定任務調度能力的多衛(wèi)星地面處理系統模式[2-3]；風云氣象衛(wèi)星數據存檔與服務系統基于高性能計算機集群建立了可支持風云系列衛(wèi)星的存儲與服務[4-5]；基于面向服務架構（service-oriented architecture，SOA）研制的天宮二號地面數據處理與服務系統實現了多領域、多載荷、海量數據的集中處理和管理[6]。國外方面，歐洲空間天文中心（European Space Astronomy Centre，ESAC）與日本宇宙航空研究開發(fā)機構（Japan Aerospace Exploration Agency，JAXA）采用Docker技術研制的衛(wèi)星地面數據處理系統可支持不同載荷數據處理算法的快速交換和部署[7-8]，很好地執(zhí)行了水星探測任務BepiColombo。

空間科學研究具有很強的競爭性，只有大膽創(chuàng)新才能孕育出顛覆性的結果，這種學科內稟屬性決定了每項空間科學任務在探測空間布局、探測內容設計、有效載荷探測精度/分辨率方面與已有的衛(wèi)星任務有著巨大的差異。隨之而來的是衛(wèi)星任務對地面數據處理系統提出的新挑戰(zhàn)。例如，空間天文警報信息的識別和發(fā)布要求是秒級響應，處理時效性極高；先進天基太陽天文臺（advanced space-based solar observatory，ASO-S）衛(wèi)星單日產生約500 GB的原始觀測數據，處理數據量巨大；暗物質粒子探測衛(wèi)星（dark matter particle explorer，DAMPE）要求星上探測數據不丟失一個源包，質量要求嚴苛?？臻g科學衛(wèi)星數據的獨特性質給衛(wèi)星地面數據處理系統提出了更多的個性化需求。

當前，我國空間科學衛(wèi)星任務呈現體系發(fā)展態(tài)勢，要求配套建設的地面數據處理系統可滿足多星多任務地面數據處理與管理需求。傳統的衛(wèi)星地面數據處理系統難以滿足大數據場景下的多領域、多種類、大體量、高時效性、高質量等數據處理要求?；诖?，本文在細致分析空間科學衛(wèi)星地面數據處理系統需求與面臨的技術挑戰(zhàn)的基礎上，設計了一套可滿足多星多任務的空間科學衛(wèi)星大數據地面數據處理系統框架，系統地實現了衛(wèi)星下行數據的快速處理，對特定的天文警報數據實現了秒級快速處理。

2 空間科學衛(wèi)星大數據特性分析

空間科學衛(wèi)星的數據處理過程需根據學科進行差異化流程設計，主要依據衛(wèi)星的數據產品分級定義劃分。從衛(wèi)星下行的原始數據到用于發(fā)布的2級或3級數據產品，每級數據產品的組織形態(tài)根據學科慣例以及衛(wèi)星任務數據處理和管理需求進行自定義。本文以引力波暴高能電磁對應體全天監(jiān)測器（gravitational wave highenergy electromagnetic counterpart all-sky monitor，GECAM）衛(wèi)星為例介紹衛(wèi)星數據處理流程和數據產品組織過程的特點。GECAM衛(wèi)星是我國首顆具有警報數據實時下行能力的空間天文科學衛(wèi)星，星上下行的數據包括事例數據、并道數據、工程數據以及天文警報數據，其各級數據處理步驟以及數據產品組織過程具有典型的大數據量、密集型計算以及多源數據融合處理等特征。

2.1 依據數據產品分級而定義的數據處理流程

由于星上計算資源和存儲資源非常有限以及載荷部分自身設計的原因，很多科學探測數據需要經過解壓、解算以及融合等處理后才能成為可供科學家進行科學分析的數據產品，下行處理過程中的輸出數據會根據平臺、載荷以及輔助數據的類型進行分類處理，通常也會根據處理的程度進行不同的數據產品格式定義。因此，衛(wèi)星數據處理流程的規(guī)劃往往與數據產品的分級定義有直接的關聯。

圖1展示了依據產品分級定義的GECAM衛(wèi)星0級產品處理流程。GECAM衛(wèi)星通過遙測信道、數傳信道和北斗信道下行星上原始觀測數據。根據數據處理程度的不同，預處理數據產品主要劃分為0A、0B、0C、0D和0Q等級別。GECAM衛(wèi)星數據處理首先需要按照不同的下行信道類型進行區(qū)分處理，在每類處理中需根據產品子級定義不同的處理流程。

圖1 GECAM衛(wèi)星0級產品處理流程

2.2 多源融合的數據產品組織結構

從多源異構數據中抽取相關信息并支持高效數據融合組織，按照產品格式要求輸出時間和內容完整的數據產品是科學衛(wèi)星大數據處理的又一特點。由于科學衛(wèi)星探測任務的類型不同以及科學數據處理與研究分析的需求不同，數據產品組織的定義往往差異較大。為了實現數據產品的可用性和易用性，通常會根據使用需求在產品中加入其他多源、異構的輔助數據信息，產品組織和生產中存在對多源數據的提取、組織拼接需求。

常規(guī)觀測類的衛(wèi)星一般根據數據的生產時間或軌道圈次進行固定時間段的數據內容切分，比如按小時、按天、按軌道號進行數據產品的組織；試驗類或者提案類的科學衛(wèi)星需要針對一次試驗或一次提案覆蓋的時間段進行數據產品的組織，將一次試驗或與提案相關的數據進行融合組織。

GECAM衛(wèi)星將觸發(fā)時刻產生的觸發(fā)信息組織成約31條短報文數據，并通過北斗系統實時下行至地面，同時將觸發(fā)時刻對應的約300 s數據通過X波段優(yōu)先下行。由于觸發(fā)時段內的數據對于科學分析工作至關重要，為了方便科學家開展數據產品分析，呈現觸發(fā)時間段內完整的數據內容，在數據處理過程中為該類產品設計了特有的產品組織模型，如圖2所示。觸發(fā)數據產品組織中包括觸發(fā)數據、姿態(tài)數據、軌道數據、載荷工作狀態(tài)以及日月地空間信息等數據，這些數據分別來自載荷工程數據信道、爆發(fā)科學數據信道以及北斗短報文，在地面經過多源融合處理后，按照觸發(fā)編號組織成特定的觸發(fā)數據產品。

圖2 GECAM衛(wèi)星觸發(fā)數據產品組織模型

2.3 處理數據體量大、種類廣

空間科學衛(wèi)星數據的最大特點是種類多、來源廣、體量大。地面數據處理系統需要同時支持多個空間科學在軌衛(wèi)星下行數據處理任務。衛(wèi)星開展7×24小時不間斷的探測，源源不斷地產生新的科學數據并下行至地面，系統需對接收的多源、多信使原始數據（數傳信道數據、遙測信道數據、北斗短報文、甚高頻（very high frequency，VHF）數據）開展虛擬信道分離、解幀、源包提取、解包、排序、重組、物理量解析轉換、載荷粗略標定、產品格式化等處理，按產品內容和處理程度組織成不同級別的編輯級數據產品。

空間科學衛(wèi)星在軌單日探測數據量逐漸增長，硬X射線調制望遠鏡（hard x-ray modulation telescope，HXMT）衛(wèi)星每日通過數傳X波段下行的原始數據約27.9 GB，暗物質粒子探測衛(wèi)星每日下行的原始數據約26.69 GB，太極一號衛(wèi)星每日下行的原始數據約8.05 GB，墨子號量子科學實驗衛(wèi)星每日下行的原始數據約0.41 GB，ASO-S衛(wèi)星每日下行的原始數據約500 GB。此外，還有中法天文衛(wèi)星SVOM（space variable objects monitor）、愛因斯坦探針（Einstein probe，EP）衛(wèi)星以及中歐微笑衛(wèi)星SMILE（solar wind magnetosphere ionosphere link explorer）等待發(fā)射的科學衛(wèi)星，后續(xù)在軌科學衛(wèi)星單日下行的原始數據峰值量預計將達到800 GB，系統單日需生產數千類編輯級數據產品以及數十類星地時差、軌道根數、精密星歷、衛(wèi)星指向夾角等輔助數據產品，單日輸出的數據產品預計約2 TB。

2.4 數據時效性要求高

為了盡快拿到衛(wèi)星下行的第一手資料，并在第一時間發(fā)現重大的科學事件，各衛(wèi)星科學應用系統往往會對數據處理的時效性提出較高的要求。在下行數據量非常大的情況下，往往會對數據設置處理優(yōu)先級，將有科學事件警報意義的數據以最高優(yōu)先級進行處理。尤其是針對空間天文類的衛(wèi)星探測任務，天體爆發(fā)事件轉瞬即逝，如果不能快速發(fā)現并處理事件，就會錯失很多重要的發(fā)現。因此，為了滿足多源、多信使手段對已發(fā)現天體源/爆發(fā)源的觀測，空間天文數據對處理時效性提出了秒級或分鐘級的要求。

特別地，空間天文警報數據產品的時效性要求達到了秒級。星上原始數據采用將所有數據混合的組織方式，設計高效的處理模式和資源調度框架以保證滿足秒級的處理時效性要求是地面數據處理系統面臨的一大挑戰(zhàn)。

2.5 數據產品質量控制要求嚴格

空間科學衛(wèi)星數據處理的另一大特質是需要從數據規(guī)范性、一致性和完整性等角度保障數據質量，確保數據可讀、可用、易用和好用。數據質量控制要求意味著系統每進行一次（級別）產品生產或數據傳輸，均需對數據產品質量進行審核和校驗，確保數據在地面處理或傳輸中不引入錯誤。遇到因星地傳輸導致的數據缺失或時間不連續(xù)時，為了保障數據完整性，系統需對備份數據或歷史數據進行重新生產，這為系統中的產品版本識別與控制、產品組織和管理帶來了挑戰(zhàn)。

2.6 數據計算任務類型多

各空間科學衛(wèi)星的數據處理需求和目標不同，因此各個數據處理環(huán)節(jié)中的計算需求也會根據處理目標的不同而變化。例如在GECAM衛(wèi)星0D級數據處理中，需對大量事例數據（時間分辨率優(yōu)于1 s）中的時間碼進行解算，解算算法包括3次擬合，計算復雜度高，屬于計算密集型處理任務，對CPU資源具有較高的需求；在0B級數據處理過程中需要頻繁調度地面系統公共信息庫提供的WebService接口，以獲取處理過程中需要的信息，這種跨服務器的頻繁I/O查詢屬于I/O密集型處理任務，該類型的任務對CPU的消耗通常比較高；ASO-S衛(wèi)星單次過境下行的原始數據約110 GB，開展百GB量級的數據處理屬于典型的數據密集型處理任務，對于CPU計算資源、存儲資源都是巨大的挑戰(zhàn)。

3 系統設計與實現

3.1 系統框架設計

作為空間科學衛(wèi)星的地面共性基礎設施，科學衛(wèi)星大數據處理系統需要統籌考慮衛(wèi)星數據產品的特性、數據處理過程的特征，以及工程任務的數據時效性和可靠性要求。從可擴展的角度考慮，如果繼續(xù)采用傳統的數據處理系統，在每次擴展新增衛(wèi)星及其有效載荷的數據處理功能時，都需改變原始處理程序的編碼，進行重新編譯和發(fā)布，不僅耗費時間與人力成本，還可能引起軟件兼容性問題。因此，亟須研制一套具有可擴展、高性能的數據處理系統，保證系統能夠靈活地對處理流程進行動態(tài)擴展，實現科學衛(wèi)星大數據的快速處理與質量控制要求。

本文基于“共性+衛(wèi)星專用插件”的設計理念，設計統一的任務調度與資源管理平臺，為各衛(wèi)星任務的專用插件提供統一的任務調度接口和資源調度接口，實現衛(wèi)星專用插件的動態(tài)配置，如圖3所示。系統接收科學衛(wèi)星通過各個信道下行的原始數據，采用統一的處理計算調度系統、統一的計算資源任務管理機制以及標準的任務調用接口和信息反饋機制，基于數據驅動的方式對各個科學衛(wèi)星的數據處理插件進行任務調度，并將生成的數據產品發(fā)送至相應的科學應用系統。

圖3 空間科學衛(wèi)星大數據處理系統框架

3.1.1 大數據處理系統基礎軟件架構

針對科學衛(wèi)星載荷數據處理方法多樣化、衛(wèi)星數據產品組織多源性、衛(wèi)星數據處理流程步驟環(huán)環(huán)相扣等特點，設計基于高性能計算集群以及超融合計算環(huán)境的大數據處理系統，采用統一任務與資源調度+專用業(yè)務插件擴展的架構形式；針對計算任務調度的實時性要求，采用Kafka分布式消息系統進行消息和日志的傳遞；針對信息查詢類的接口，設計標準的WebService服務?；A軟件架構如圖4所示。

圖4 空間科學大數據處理系統架構

大數據處理系統最核心的功能是開展各科學衛(wèi)星的數據處理與質量分析工作，對于各類不同的衛(wèi)星專用數據處理插件以及專用衛(wèi)星數據質量分析與控制插件，各插件封裝統一標準的任務訂單接口以及UDP日志上報接口。

設計統一的數據接入接口，通過文件實體驗證機制保證數據傳輸過程的安全性和正確性?；跀祿寗拥姆绞絾幼詣訑祿幚砹鞒?，根據輸入的原始數據的類型調度對應的衛(wèi)星專用數據處理插件以及衛(wèi)星專用數據質量分析與控制插件，實現科學衛(wèi)星的各級數據產品處理、標準化產品生成、數據快視、數據質量分析以及質量控制等功能。

統一任務調度引擎負責對輸入數據的類型進行識別，并針對數據類型及其對應的數據處理流程發(fā)送計算任務請求，實現計算任務的集中式調度以及分布式并行處理。在任務調度過程中，該引擎需要統籌考慮各科學衛(wèi)星的數據質量信息以及過站計劃信息，并將這些動態(tài)信息作為任務調度的依據。主要原因包括以下兩點。

● 由于空間科學研究對數據產品的完整性要求非常高，地面接收站往往會進行多備份數據接收。此外，當在地面數據質量控制過程中發(fā)現數據存在缺失時，往往會通過點播的方式進行星上數據的回放，因此會有大量的冗余數據流入處理系統。依靠存儲在科學衛(wèi)星數據質量信息庫中的內容，統一任務調度引擎可以提前識別冗余數據，在生成任務的入口處進行截流，避免冗余數據觸發(fā)處理任務進而占用不必要的計算和存儲資源。

● 通常衛(wèi)星每日的過站計劃會提前幾天制定，并通過數傳星歷表上傳至衛(wèi)星，為了保證計算資源的實時可獲取性，當衛(wèi)星下行數據達到系統時能夠有足夠的資源開展數據處理任務，系統采用資源預約機制，基于科學衛(wèi)星過站計劃信息進行資源的提前預訂。

在數據存儲方面，為了提升緩存數據的讀寫效率以及系統的穩(wěn)定性，采用分布式文件系統實現多集群統一共享存儲。針對科學衛(wèi)星數據的組織特征建立基于標準元數據信息的高效數據存儲模型，從而提高各個插件的數據讀寫訪問速度。

3.1.2 大數據處理系統硬件基礎架構

衛(wèi)星大數據高性能處理系統硬件架構包括高性能計算集群、超融合計算環(huán)境以及分布式存儲環(huán)境3個部分，各個部分之間通過高速互聯交換機進行數據的傳輸與交換，硬件基礎架構如圖5所示。

圖5 大數據處理系統硬件基礎架構

高性能計算集群由資源調度管理節(jié)點和資源處理計算節(jié)點組成，其中資源調度管理節(jié)點采用雙路機架式服務器，以主/備（active/standby）方式運行；資源處理計算節(jié)點采用四路機架式服務器，根據業(yè)務應用需求通過調度管理算法實現硬件資源的分配管理。

超融合計算環(huán)境采用四路高性能服務器，通過部署FusionSphere虛擬化軟件對物理服務器的CPU、內存、設備I/O進行硬件解耦，從而實現在單一物理服務器上同時運行多個虛擬機且相互之間互不影響。

分布式存儲環(huán)境采用冗余網絡架構和N+M糾刪碼保護機制充分保證系統無單點故障，確保數據存儲的長期安全；在不同存儲節(jié)點間使用條帶化技術，將讀寫操作均勻分散到多個節(jié)點，為應用訪問提供多個并行傳輸通道，從而有效地提高了系統的讀寫帶寬和每秒的輸入輸出量（input/output per second，IOPS）。

3.1.3 任務類型感知的統一資源調度系統

在傳統的空間科學衛(wèi)星數據地面處理系統中，資源調度系統負責將數據處理子節(jié)點的CPU、內存、硬盤、I/O等資源抽象成資源池，維護管理資源池，并將資源分配給相應的數據處理任務，這種架構在空間科學大數據場景下面對多類型的衛(wèi)星數據處理任務時無法做出相應的處理，無法最大化發(fā)揮資源節(jié)點的性能，而且會影響數據處理的時效性。本文提出一種基于任務類型感知的統一資源調度系統，實現對上層數據處理任務的統一編排與管理，根據科學衛(wèi)星的數據處理任務需求場景，提供統一可配置的資源管理和分配策略，支持根據衛(wèi)星、數據類型設定優(yōu)先級，支持預約類型和實時類型的計算任務請求，提供松耦合和靈活的計算任務與資源的關聯關系，支持底層資源池的動態(tài)擴展，真正依據計算資源的特點做到物盡其用。任務類型感知的資源調度系統的架構如圖6所示，主要分為資源預約與請求接口、任務隊列、任務與資源的智能關聯匹配以及資源節(jié)點管理4個部分。

圖6 任務類型感知的資源調度系統架構

資源預約與請求接口主要負責向上為統一任務調度引擎提供資源調度接口，對申請的任務類型進行解析，并將任務發(fā)送至不同的任務隊列中，任務在隊列中等待匹配合適的計算資源。

任務隊列采用消息隊列的方式進行任務請求的解析與保存，除了配置傳統的計算任務隊列，還專門設計了用于保存資源預約的任務隊列，以提升重要任務響應的及時性。

任務與資源的智能關聯匹配主要負責基于請求任務類型標識和資源節(jié)點類型標識分別建立任務索引和資源節(jié)點索引，通過監(jiān)控任務隊列和資源隊列進行全局任務和資源的動態(tài)編排和調度。

資源節(jié)點管理主要負責向下管理集群資源節(jié)點，將資源節(jié)點匯聚成資源池，同時對資源節(jié)點的類型進行標注，針對不同的資源節(jié)點類型，將節(jié)點分為數據密集型節(jié)點、計算密集型節(jié)點、I/O密集型節(jié)點等不同類型的任務節(jié)點。

資源調度算法處理流程如下。

/*初始化*/

AppointmentQueue<>,IOTaskQueue<>,DataTaskQueue<>,CPUTaskQueue<>,

Resources

輸入：數據處理任務 NewTaskOrder

/*接收并解析數據處理任務*/

taskType = NewTaskOrder.type();

if (taskType == appointment) then /*預約任務*/

InsertAppintQueue(NewTaskOrd er)

else if(taskType == IOtype) then

InsertIOQueue(NewTaskOrder)

else if (taskType == DataType) then

InsertDataQueue(NewTaskOrder)

else

InsertCPUQueue(NewTaskOrder)

end if

/**預約資源**/

MakeAppoint(AppointmentQueue<>, Resources<>)

/*更新資源狀態(tài)，并獲取可用計算資源*/

AvailableResource<> = Update (Resources<>)

/**分配資源**/

fori=0 toi< AvailableResource. size()-1 do:

node = AvailableResource (i); /*獲取可用資源*/

/*將各種類型的資源匹配到對應的任務隊列上 */

if (node.type == IOtype && ! IOTaskQueue.empty())

node.execute(IOTaskQueue.getTask())

if(node.type == DataType && ! DataTaskQueue.empty())

node.execute(DataTaskQueue.getTask())

if (node.type == CPUType && !CPUTaskQueue.empty())

node.executre(CPUTaskQueue.getTask())

else

/*如果各類任務和資源沒有完全匹配，則將可用資源分配給其他類型的任務*/

unmatchTask = FindWaiting-Task (IOTaskQueue, CPUTaskQueue, DataTaskQueue)

node.execute(unmatchTask)

end for

3.2 系統實現

基于高性能服務器集群和超融合計算環(huán)境建設的可擴展高性能地面數據處理系統成功地支持了中國科學院空間科學先導專項多顆空間科學衛(wèi)星的海量原始數據的集中處理，系統的數據處理效率能夠滿足各科學工程的性能指標要求。作為空間科學衛(wèi)星地面共性基礎設施，該系統支持動態(tài)擴展，可基于大數據共性基礎平臺滿足后續(xù)空間科學衛(wèi)星的數據產品處理及產品組織需求。目前該系統通過Apache+Tomcat搭建系統整體業(yè)務監(jiān)管界面，通過Kafka消息隊列實現處理類、數據管理類以及數據服務類的狀態(tài)消息實時上報，對系統內開展的各類數據處理、數據管理和分發(fā)等活動進行實時監(jiān)視，依據輸入數據為運行流程設計唯一標識符，從而可以對從輸入開始一直到生產各類數據產品并對外提供服務的整個過程進行跟蹤，如圖7所示。

圖7 系統綜合業(yè)務展示

該系統通過標準的任務訂單接口和任務調度調度接口，集成了多顆科學衛(wèi)星的數據處理與產品生產、數據質量分析與評估等幾十類算法模塊，采用標準WebService接口實現了對外接口服務，任務調度時延小于1 s。多星多任務調度平臺如圖8所示。

圖8 多星多任務調度平臺

目前系統運行穩(wěn)定，支撐著5顆在軌科學衛(wèi)星的數據處理。系統每日處理的數據量約103 GB，輸出的數據產品數量約364 GB。系統將每次數傳下行處理的數據產品自動準實時地發(fā)送至各衛(wèi)星科學應用系統，有效地支持了HXMT衛(wèi)星、暗物質粒子探測衛(wèi)星以及墨子號量子科學實驗衛(wèi)星科學成果的發(fā)現[9-13]。

4 結束語

面對空間科學后續(xù)衛(wèi)星探測數據量大幅增加，數據處理過程更加復雜，處理耗時增加與天文警報數據超高時效性要求的趨勢，有待在系統自動化的基礎上進一步研究智能化技術和流式數據處理技術，以大幅改善系統的多任務并行處理能力。針對多類型任務調度引擎的兼容性和可擴展性，需進一步優(yōu)化資源統一調度接口，采用輕量化容器技術增強代碼遷移的能力。未來還將開展共性數據處理算法的抽象工作，增加共性數據處理工具集，降低擴展新衛(wèi)星任務帶來的成本。