面向航天器飞控任务的大数据处理系统的设计与验证

师明 王保丰 曹玉娟 高宇辉

(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)高性能系统。任务处理系统是以高效能为目标的系统架构设计，突出的问题是计算框架、处理方法和测试基准的效能评价和性能优化，不但要求理清大数据的复杂性、可计算性与系统处理效率、能耗间的关系，还要综合度量系统中如系统吞吐率、并行处理能力、作业计算精度、作业单位能耗等多种效能因素。