面向航天器飛控任務的大數據處理系統的設計與驗證

師明 王保豐 曹玉娟 高宇輝

(1 北京航天飛行控制中心，北京 100094) (2 北京航天飛行控制中心，航天飛行動力學技術國防科技重點實驗室，北京 100094)

自2008年谷歌公司公開其分布式文件系統(GFS)和分布式計算引擎(MapReduce)的設計思想開始，云計算在學術、商業等領域迅速發展，海量數據存儲管理、實時流數據處理、多源異構數據的融合分析、知識驅動的應用技術等研究成果與行業需求相結合，催生出互聯網+時代大數據技術發展的浪潮。

在航天領域，美國國家航空航天局(NASA)構建了大數據組織管理與數據處理系統[1]實時處理來自火星探測器的原始數據；NASA的氣候模擬中心存儲了有關天氣與氣候的數據超過37 PB；NASA的星云超級計算機[2-3]支持高性能計算處理，進行行星科學計算，為多任務、多用戶提供復雜的計算能力。

隨著我國航天試驗任務的不斷推進，試驗數據正以前所未有的速度不斷增長和累積，具備了大量(Volume)、多類型(Variety)、高速(Velocity)、高價值(Value)的大數據4V特征，對試驗數據的管理與應用提出了更高更迫切的需求。目前，我國一些在軌航天器管理單位運用數據挖掘和可視化技術開展在軌航天器故障診斷方面的預先研究，取得了階段性成果，但是其產品尚未應用在工程任務中。總體而言，國內滿足航天工程任務需求的大數據研究成果較少，尚缺技術落地。

1 數據應用現狀

航天工程數據指航天試驗任務在準備、實施和總結過程中所涉及的各類數據。不同階段的任務生成的數據類型也不同，在任務準備階段生成的數據包括試驗文書、工作計劃、站點的氣象參數表、聯調聯試過程數據，以及試驗信息系統的狀態復查復核信息等。在任務執行階段生成的數據包括外測數據、遙測數據、遙控數據、語音調度、航天器飛行實況以及信息安全和運行管理系統產生的狀態數據。其中，外測數據主要包括光學測量數據、雷達測量數據、衛星導航數據；遙控數據主要包括用于航天器飛行姿態軌道控制和各類載荷工作狀態控制的遙控指令和注入數據；信息安全系統包括病毒查殺、病毒預警、主機管控、網絡攻擊等信息；運行管理系統包括設備監視、系統運行態勢、資源調度等信息；任務完成后生成的數據包括試驗評估報告、測控設備使用報告、事后數據處理結果(包括通過各種處理得到的軌道參數、遙測關鍵參數挑點數據、遙測量綱復原數據、全球導航衛星系統(GNSS)原始測量數據與自定位數據等)、信息安全和運行管理系統評估信息。

從數據類型上可以分為文本、語音、圖像和數據等4類信息；從時效性上可以分為事前、實時、準實時和事后數據；從數據形態上可分為結構化數據、半結構化數據和非結構化數據。

在任務窗口期，我國航天任務系統將面臨多任務高并發的局面，對數據的組織管理提出嚴峻挑戰，當前系統性能與任務需求之間的矛盾日益突出，主要表現為以下幾點。

1)數據存儲架構伸縮性不好

歷次任務對數據裝訂的要求均有差異，導致不同任務均需要單獨數據庫的支持。隨著試驗任務的不斷推進，任務系統數據存儲壓力急速增大。傳統數據存儲架構采用雙集群熱備+關系型數據庫(RDMS)主備的管理方式，不同任務階段的數據庫獨立存儲，以滿足系統的高可靠性要求。在結構上，缺乏對歷史任務分類存儲能力。后續隨著任務活動的并發執行，現行存儲架構將面臨較大的執行壓力。

2)數據集中管理能力不足

現有RDMS服務在強制保證數據一致性的同時，又對數據高可用性形成約束。系統內部也尚未有一套數據管理系統對不同數據庫以及海量異構數據進行統一管理，性能上難以滿足高效檢索的使用需求，以及跨任務、跨型號的數據共享和應用需求，對海量異構數據的管理能力不足，造成了數據孤島現象。

3)數據應用模式單一

傳統RDMS數據管理模式下，對任務全周期內單點數據的查詢分析效率低下，無法完成各類數據間的深層次關聯分析，歷史任務數據分析應用模式比較單一，無法充分發揮歷史數據對當前和今后任務的指導作用，未能實現大規模數據的資源效益。

由此可見，傳統的數據應用技術體系已經不能滿足試驗任務對數據存儲、實時處理、科學分析等需求。

2 系統設計

2.1 功能需求

傳統數據組織管理平臺主要采用的是“主-從”式架構，面對海量數據處理的任務場景在處理速度、存儲空間、容錯性和文件讀寫(IO)等方面都面臨嚴峻的考驗，需要一個能夠管理海量數據整個生命周期的通用的、技術生態閉環的大數據平臺。此外，需要解決現有系統在數據存儲管理、一致性、可用性等問題上存在的固有缺陷，滿足航天工程數據對系統的要求，具體分析見表1。需要考慮與現有系統的接口關系，設計數據采集功能模塊。

表1 航天工程數據特征及對系統的要求

2.2 技術架構

分布式文件系統具有大容量、高可靠性、易擴展等特點，把被求解的問題分解成若干部分，協同多個計算資源完成數據處理，通過擴大問題求解規模來解決復雜計算問題，成為事實上設計大數據應用技術架構的主要方法。

本文所設計的技術架構由3部分組成：①Hadoop平臺開源組件，開源組件的組合方案在數據存儲、處理和應用等方面不能滿足航天工程任務系統多樣化的需求，需要做進一步的分析優化，包括Kafka、Mahout、Storm、Hbase、Hive、Zookeeper、Sqoop等；②第三方組件，前期的研究工作中，主要基于業務使用需求設計實現Hadoop平臺上的第三方組件，可作為單獨軟件，兼容Hadoop平臺；③中間件，形成jar工具包供Hadoop接口調用，完成數據格式整理、格式轉換等數據預處理。所有開源組件均需使用中間件技術調用接口函數進行二次開發。總體技術架構見圖1。

圖1 面向航天工程大數據處理的一種通用型應用技術架構Fig.1 A general application technology architecture of big data processing in aerospace engineering

由圖1可知，本文所設計的大數據應用技術架構由數據采集、數據預處理、數據存儲、分布式計算、數據查詢和數據挖掘等功能組成，具有資源管理調度、組件協調、作業調度等云平臺所必備的屬性，構成一個完整、通用的技術架構。

(1)數據采集，由Kafka、Zookeeper實現基礎架構，Java接口實現導入外部RDMS、離散文本數據。

(2)數據預處理，由中間件實現，完成數據抽取、轉換和加載等功能。針對不同類型數據，區分設計指標，實現對任務數據的整理。

(3)數據存儲，由Hadoop分布式文件系統(HDFS)實現對離線數據、實時流式數據的分布式存儲。

(4)分布式計算，由Hadoop分布式計算引擎MapReduce為Hive、Hbase等上層應用提供分布式計算服務。

(5)數據查詢，由第三方組件Hyperbase實現，采用SQL語言實現對非結構化數據的統計分析和復雜的交互式查詢。

(6)數據挖掘，由Mahout軟件實現基礎架構，針對航天器應用場景進行數據建模和算法優化。

針對數據應用中的問題分析，在本文的設計中，分布式系統架構可以通過水平擴展，增加更多的計算單元和存儲單元來解決，并具有良好的容錯性和伸縮性，避免了傳統存儲架構在垂直擴展應用中遇到的性能瓶頸和系統穩定性隱患。Hbase的列式結構適用于海量異構數據的存儲，可以規避不同任務的字段定義調整帶來的重復性工作；Hive可以讓開發人員通過SQL來計算和處理HDFS上的結構化數據，二者配合使用，適用于任務背景下海量離線數據的批處理任務，以及任務電文數據的入庫管理。將Mahout應用于航天器健康狀態診斷等工程領域則是目前較為前沿的研究。

2.3 關鍵技術分析

1)數據采集

為規避數據丟失風險，保證系統靈活性，以及保證峰值數據處理能力，技術架構中引入消息隊列框架，采用極簡的數據結構和應用模式。設計特性如下：①以時間復雜度為O(1)(O(1)是數據結構中衡量算法復雜度的標記方法)的方式提供消息持久化能力，對GB級以上數據也能保證常數時間復雜度的訪問性能；②高吞吐率，即使在廉價的商用機器上也能做到單機支持每秒5000條以上消息的傳輸速度；③支持消息分區及分布式消費，同時保證單臺機器內的消息順序傳輸組件的接口。

2)數據預處理

外部數據源主要針對兩類場景：一類結構化數據，存儲在關系型數據庫，如Oracle、Excel、SQL Server、SqlLite、MySQL等；一類是半結構化、非結構化數據，任務數據中以DAT、XML、DOC等離散文本數據為主要類型。該部分主要采用中間件技術，設計特性如下：①支持數據補缺、替換、格式規范化、主鍵約束、去重、緩變參數整合等數據清洗；②能夠實現數據的合并、拆分和驗證等數據轉換操作；③支持時間戳、日志表、全表對比、全表刪除插入等方式的數據加載；④對網絡異常、原數據結構改變、接口改變等引起的數據加載異常有處理手段。

3)數據存儲

對于非結構化數據，采用分布式文件系統直接存儲的方式。任務下數據密集型文件處理應用場景廣泛存在，HDFS提供兩種方法，以改善大量小文件(單個文件小于Block 64 M)造成元數據管理效率低下的問題：一是通過生成SequenceFile[4]文件而合并大量的小文件；二是采用CombineFi1eInputFormat[5]小文件合并方式，將多個文件合并成一個單獨的分塊文件(split)。本文設計中，采用一種對上層應用透明的啟發式文件預取方法，在HDFS建立預取線程池，響應上層應用程序所有的文件訪問請求。該方法主要基于程序局部性原理設計，使用了最近成功訪問(Last Success, LS)模型。程序以組成文件塊的數據存儲文件為預取單位，通過記錄文件訪問信息構建LS模型，申明Posix_fadvise系統調用完成文件訪問與內核函數的交互。該方法部署在Hadoop存儲節點(DataNode)。

對于結構化、半結構化數據，經過數據預處理后直接轉存至分布式數據倉庫和NoSQL數據庫。分布式數據倉庫能夠支持上千臺服務器的規模，支持對大規模靜態數據的批處理操作；NoSQL使用松耦合類型、可擴展的數據模式來對數據進行邏輯建模(Map文件，列，文檔，圖表等)，具有非關系型、分布式、輕量級、支持水平擴展等特點。本文設計中采用Hive作為數據倉庫，Sqoop實現數據傳遞，Hbase作為NoSQL數據庫。對開源軟件的參數進行優化，其中建表過程不再贅述。

設計特性如下：①具備高可靠在線擴容集群存儲架構，能夠處理從GB到PB的數據，動態擴容；②實現對重復數據的壓縮存儲；③支持數據的離線歸檔。

實時流數據主要是指任務執行中的遙測數據，數據量大且格式復雜，帶有明顯的時序特性。以載人交會對接任務為例，遙測數據來自于觀測弧段內最大數目的地基觀測站(3個)、(神舟十號+天宮一號)天基中繼測控，遙測數據規模約149.59 Mbit/s。數據量較大，是一種典型的時間序列。

本文設計中采用Storm開源技術，分析處理數據流中的規律和知識。設計特性如下：①支持實時告警流處理業務，提供對異常檢測的處理支持；②支持高吞吐低時延的時間窗口統計挖掘流處理業務；③支持在線自動分類、關鍵事件判斷等實時事件的處理機制。

4)數據查詢

索引的實質是另一種編排形式的數據冗余，高效的檢索源自于面向查詢特別設計的編排形式，如果再輔以分布式的計算框架，就可以支撐起高性能的大數據查詢。基于上述設計思想，本文設計實現可獨立運行的Hyperbase組件，支持在線聯機事務處理(OLTP)應用、高并發聯機分析處理(OLAP)應用、批處理應用、全文搜索或高并發圖形數據庫檢索應用。

設計特性如下：①除主鍵索引外，支持非主鍵的多維索引；②支持全局、局部、高維索引和高級過濾器，可用于高并發低延時的OLAP查詢；③支持SQL命令進行跨表跨行的分布式事務處理以及事務回滾，保證數據更新的一致性；④支持文檔型數據的存儲、索引和搜索，支持對象數據(圖片、音視頻、二進制文檔等)的存儲、檢索和自動回收。

5)數據挖掘

數據挖掘通過測控事件進行狀態判斷、趨勢預測和關聯分析，可為航天器設計的合理性與可靠性驗證、測控資源的管理與調配、科學實驗任務安排的合理性與可行性驗證、測控系統的安全與可靠性驗證、載人環境建設的改進等起到重要的輔助決策作用。

根據挖掘目標和數據形式可以分為分類與預測、聚類分析、關聯規則等模型，生成智能診斷、行為分析、故障診斷、參數優化等具體的數據應用產品。在航天任務中的應用場景分析如下。

(1)分類和預測。分類主要是預測分類標號(離散屬性)，而預測主要是建立連續值函數模型，預測給定自變量對應的因變量的值。分類和預測可用于構建航天器故障診斷自適應門限模型，其核心思想是利用歷史積累的測控數據，通過合適的機器學習算法動態生成實際測控參數合適的上下門限。由于機器學習算法充分利用了歷史數據中的可用信息，因而所確定的門限具有更好的適用性，可以有效地減少門限檢測的誤報率[6-7]。常用的分類和預測算法包括回歸分析、決策樹、隨機森林、貝葉斯網絡和支持向量機等。

(2)聚類分析。與分類模型需要使用有類標記樣本構成的訓練數據不同，聚類模型可以建立在無類標記的數據上，根據數組相似度進行樣本分組。對歷史測控數據進行規則挖掘，從海量的樣本數據中獲取故障診斷的規則，及時發現故障征兆并采取有效措施就可能避免航天器出現重大的故障。NASA 阿姆斯研究中心(ARC)的歸納式推理系統(Inductive Monitoring System，IMS)[8]主要采用聚類的方式對數據進行自動狀態分類。文獻[9]根據遙測數據的時序特性，將聚類分析方法應用于航天器故障診斷決策研究。常用聚類方法包括K-means算法、基于層次分析的BIRCH算法、基于密度的DBSCAN算法、基于網絡的STING算法和基于模型的神經網絡方法等。

(3)關聯分析。關聯分析可以有效發現測控數據中的有用知識，將其應用于專家系統中實現知識的自動獲取[10]。知識庫不是提前編寫好的靜態知識，而是通過數據挖掘技術生成的動態知識。常用的關聯算法包括Apriori、FP-Growth、Eclat、灰色關聯法等。

3 用例測試

本章重點圍繞應用技術需求設計測試用例。其中，數據集中管理能力包括數據接口能否滿足任務場景下的指標要求、數據入庫效率與現有電文軟件的橫向比較，以及對復雜查詢需求的支持等。數據應用模式測試體現在對航天器工程數據進行數據挖掘應用。對系統伸縮性的論證依托于分布式系統的架構設計，不做專項測試。

3.1 測試說明

使用4臺曙光服務器部署4個節點的云平臺測試環境， Hadoop版本為 2.6.5，操作系統環境為Centos 7、JDK1.8。按照圖1所示系統架構在各個節點分別部署軟件。此外，為進行性能橫向比較，在Hadoop1節點部署任務收發信軟件和MySql數據庫。軟件部署見表2。

采用自研的數據模擬發生器構建任務場景，生成DBMS、離線數據等不同應用格式的數據。該程序擔任Kafka數據生產者的角色，通過調用Kafka Producer API建立應用程序到Hodoop平臺的數據流。在Hadoop1節點shell終端完成數據采集效率、入庫效率、查詢能力、數據挖掘等各項測試結果的統計。其中，對數據挖掘的決策樹、回歸分析的測試調用Mahout自帶jar完成，不生成新的算法工具包。

表2 測試環境下的軟件部署信息

3.2 數據采集效率

構建任務場景，測試接口軟件是否滿足任務指標要求，結果見表3。

表3 數據采集效率測試

由表3分析可知，以Kafka架構為核心構建的接口完全滿足任務需求。

3.3 入庫效率

根據任務場景生成不同頻率的數據，測試數據預處理程序性能，并與任務系統收發信軟件進行橫向比較。結果見表4。

在單目標2測站、單目標5測站這兩類常規任務場景下，采用大數據應用系統與傳統任務軟件的性能表現基本持平，隨著多目標、多測站任務壓力的增大，采用大數據應用技術的系統表現明顯優于傳統軟件，尤其在壓力測試下(相當于37個目標5個站同時跟蹤)，大數據應用軟件的入庫效率高效，能夠應對后續任務并行執行的要求。

表4 入庫效率測試

3.4 查詢能力

項目組模擬了雙目標運行289天，單測站不間斷跟蹤的工程遙測數據量，約5000萬行工程遙測數據(3000個參數/行)入庫，然后使用數據模擬發生器，按照雙目標兩測站跟蹤的數據頻率模擬發送數據。數據格式參照不同型號任務執行情況，進行差異化定制。Hbase、Hive接收數據的同時以時間為過濾條件進行查詢，返回結果全集。結果見表5。

從表5測試結果可知：雙目標2測站、雙目標5測站數據入庫的同時提交查詢請求，是一類跨任務的復雜查詢，處理結果均優于任務指標，結果全集證明該系統在數據查詢功能設計的高效性。

表5 查詢能力測試

3.5 數據挖掘

2013年11月11日在天宮一號偏航動力飛行模式期間，當天第一圈跟蹤過程中，遙測監視發現3號控制力矩陀螺(CMG3)出現工作異常現象，具體表現為制導、導航與控制(GNC)分系統遙測參數DKS0088(CMG3轉子脈沖數)由正常值1424或1425逐漸下降至0，遙測參數DKS0090(CMG3自檢狀態)由0CH切換為04H(異常)，VKZ019(CMG3轉子電極電流)由4.0變為0(轉子停轉)。

上述問題屬于一種典型的分類與預測場景。在用例測試中，提取天宮一號CMG3發生故障時的15 min數據、故障切換后為CMG5的30 min數據，以及CMG3故障前6天的數據，進行人工標注。標簽為TYPE1(CMG3正常)、TYPE2(CMG3故障)成為訓練集，模擬中心故障數據與正常數據嚴重失衡的特點。挑選CMG3故障前50天，CMG3發生故障時6 h及故障切換為CMG5的10 h數據作為測試集，并將訓練集去除標簽后放入測試集中。使用訓練集對相對性分析與分類算法進行訓練。采用決策樹進行相關性分析，可以識別與故障相關的字段；采用回歸分析進行分類，可以識別故障發生時間。

1)決策樹

采用基尼系數(Gini Index)判別候選字段對于目標類別的重要性，最小的系數值作為節點劃分決策樹(見表6)。

隨機抽取故障訓練數據中60%用于建模，其余40%用于模型驗證。采用二叉樹構建決策樹，按照置信邊界=0.2進行剪枝，結果如下：

DKS0090(>8.0)→TYPE=1(267275,100.0%,3)

DKS0090(≤8.0)→DKS0100(>6.0)→TYPE=3(44180,100.0%,2)

DKS0090(≤8.0)→ DKS0100(≤6.0)→TYPE=2(2175,100.0%,1)

檢驗結果表明:目標評估指標的準確率、覆蓋率都達到了100%。

表6 決策樹基尼系數分析

2)回歸分析

采用相關系數確定字段重要性，基于最優候選字段作為建模字段，候選子集包括DKS019、DKS0021、DKS0087、DKS0088、DKS0090、VKZ019、VKZ021、VKZ039、DRZ088。誤差控制參數設置為10-4，最大迭代次數200，建立故障回歸模型。決策樹如下：

VKZ019(>0.620000005)→TYPE=1(442409,100.0%,3)

VKZ019(≤0.620000005)→VKZ037(≤1.090000035)→TYPE=2(1200,100.0%,2)

VKZ019(≤0.620000005)→VKZ037(>1.090000035)→TYPE=3(39875,100.0%,3)

檢驗結果表明:目標評估指標的準確率、覆蓋率都達到了100%。

3.6 測試結果分析

所構建的單目標2測站、單目標5測站任務場景，是當前載人航天和深空探測任務中應用最為廣泛的一類場景，雙目標2測站，是后續多任務并發執行的場景，均具有典型代表性。在4個集群節點下的數據采集效率、入庫效率、查詢能力測試，指標完全滿足航天試驗任務需求。取樣天宮一號故障點數據，進行數據挖掘功能測試，結果符合預期指標。測試結果驗證了本文所設計的大數據應用技術架構的有效性。

4 結束語

本文研究任務數據特點，提出面向航天工程大數據處理的一種通用型應用技術架構，以開源組件為主完成系統實現，并基于任務場景對數據采集效率、入庫效率、查詢能力以及數據挖掘能力進行測試驗證，結果滿足工程任務需求。

大數據應用技術與航天試驗任務系統結合，還面臨很多挑戰。

(1)數據復雜性。試驗任務數據典型的特征即類型多樣、關聯關系復雜、信息維度高，使得系統在數據的感知、表達、理解和計算等多個環節面臨著巨大的挑戰。在傳統全量數據計算模式下，時空維度上計算復雜度的激增，導致數據分析與挖掘任務如檢索、主題發現、語義分析等變得異常困難。鑒于航天任務的復雜性，人們對復雜數據內在機理及其背后的物理意義缺乏理解，極大地制約了人們對大數據高效計算模型和方法的設計能力。因此，需要研究航天器、測控系統多模態關聯關系下的數據分布理論和模型，理清數據復雜度和時空計算復雜度之間的內在聯系，通過對大數據復雜性規律的研究理解任務數據的本質特征和生成機理，進而指導大數據計算模型和算法的設計。

(2)高緯度計算。試驗任務大數據多源異構、規模巨大、快速多變等特性使得傳統的數據存儲、信息檢索、數據挖掘等計算方法不能有效支持大數據的處理、分析和計算。特別是大數據計算不能像小樣本數據集那樣依賴于對全局數據的統計分析和迭代計算，需要著眼于航天任務全生命周期，基于航天器的基本特征及其良好指標，突破傳統計算對數據的獨立同分布和采樣充分性的假設。

(3)高性能系統。任務處理系統是以高效能為目標的系統架構設計，突出的問題是計算框架、處理方法和測試基準的效能評價和性能優化，不但要求理清大數據的復雜性、可計算性與系統處理效率、能耗間的關系，還要綜合度量系統中如系統吞吐率、并行處理能力、作業計算精度、作業單位能耗等多種效能因素。