基于Flink的空间科学卫星数据实时处理方法

高立京,陈志敏,王春梅,王 静

(1. 中国科学院国家空间科学中心,北京 100190;2. 中国科学院大学计算机科学与技术学院,北京 100049)

1 引言

空间科学是一门研究发生在日地空间、行星际空间乃至整个宇宙空间的物理、天文、化学及生命等自然现象及其规律的学科[1],航天器是研究其具体内容的主要平台。在各种航天器的种类中,空间科学卫星是一类以执行特定科学探测任务为总体目标、以获取科学探测数据为主要需求的航天器。

空间科学卫星下行数据主要分为工程参数数据、卫星平台数据和科学数据。其中,工程参数数据和卫星平台数据用于地面科研人员判断有效载荷和卫星的运行状态正常与否,地面数据处理系统应能够尽可能低延迟地处理工程参数数据和卫星平台数据,从而帮助地面科研人员第一时间发现有效载荷或卫星的异常并给出相应的解决方案,减少甚至避免因载荷或卫星的异常而带来的损失;空间科学卫星下行数据中的科学数据是星上有效载荷探测到的数据,这些科学数据对于地面科研人员开展相应的科学研究工作有着至关重要的作用,由于空间科学卫星上携带的有效载荷数量较多,并且有效载荷的科学数据采样频率极高,导致产生的科学数据数据量巨大。因此研究如何高吞吐率、低延迟地实时处理空间科学卫星下行数据是很有必要的。

目前实时处理空间科学卫星下行数据的方法主要分为两种:流式计算处理方法和非流式计算处理方法。在非流式计算方法中,文献[1]设计两层联合索引,将数据处理问题转化为处理索引表和源包数据单元的问题,提高了空间科学卫星下行数据处理的效率;文献[2]借鉴MapReduce的思想采用单机多线程的方式处理空间科学卫星下行数据,同时将哈希算法与归并算法结合在其中,实现了较高的数据处理吞吐率。在流式计算方法中,文献[3]采用Spark Streaming流式计算框架的方式处理空间科学卫星下行数据,实现了较高的数据吞吐率;文献[4]重新定义数据处理程序的数据结构,将其与Storm流式计算框架结合实现并行处理,相较于原有系统极大地提高了数据处理的吞吐率。

主流的流式计算框架有Strom、Spark Streaming和Flink,在实时处理空间科学卫星下行数据的领域中,基于Storm和Spark Streaming的数据处理方式均取得了不错的性能表现[3,4],但基于Flink流式计算框架的空间科学卫星下行数据的处理方式尚未有人涉足。鉴于以上调研情况,本文提出一种基于Flink流式计算框架的空间科学卫星下行数据的实时处理方法,并讨论了在不同并行度时该方法在吞吐率和延迟方面的性能表现。

2 空间科学卫星下行数据

引力波暴高能电磁对应体全天监测器卫星(Gravitational wave high-energy Electromagnetic Counterpart All-sky Monitor,GECAM)是用来探测引力波事件所发出的高能光的空间科学卫星[5],本文以GECAM为例说明本文中处理数据的数据结构。GECAM的下行数据遵循空间数据系统咨询委员会(Consultative Committee for Space Data Systems, CCSDS)提出的高级在轨系统(Advanced Orbit System, AOS)标准[6],并且按照“AOS传输帧”和“源包”两层的结构分层组织,本文中处理的数据为“内部数据帧”,是由“源包”处理得到的。从“AOS传输帧”到“源包”再到“内部数据帧”的具体处理流程如图1所示。

图1 AOS传输帧的处理流程

“AOS传输帧”的格式如表1所示,其经过以下处理步骤后可得到“源包”:

表1 AOS传输帧格式

1)帧同步:从卫星下行的原始码流中逐位查找同步码,从而确定每个AOS传输帧的起始位置和结束位置。

2)解扰:加扰的数据是除同步码以外的数据,以AOS传输帧为处理单位,对这部分数据进行位运算得到加扰前的数据。

3)RS译码:以“AOS传输帧”为处理单位,使用RS译码对卫星下行数据在传输过程中产生的误码进行纠正。

4)虚拟信道分离:以“AOS传输帧”为处理单位,解析帧头的“虚拟信道标识符”字段信息,按照虚拟信道标识符(Virtual Channel Identifier, VCID)提取不同信道的源包,比如实时工程参数源包、实时科学数据源包等。

“源包”是一种面向应用且长度可变的数据格式,它使用应用过程标识符(Application Identifier, APID)对卫星在采集和传输过程中的不同的数据源设备进行区分[4]。“源包”的格式如表2所示,其经过以下处理步骤后可得到“内部数据帧”:

表2 源包格式

1)源包同步:对于从“AOS传输帧”解析而来的码流逐位查找同步码,从而确定每个“源包”的起始位置和结束位置。

2)源包分包:以“源包”为处理单位,解析“源包”头部的“应用过程标识符”字段信息,按照应用过程标识符(Application Identifier, APID)提取不同有效载荷数据的源包。

3)物理量反演:以“源包”为处理单位,根据源包的“应用过程标识符”字段所对应的特定公式来计算编码所对应的物理量数据。

4)添加帧头:以源包为处理单位,添加相关帧头信息。

“内部数据帧”的格式如表3所示,本文中涉及到的数据处理就是要解析“内部数据帧”中的各个字段的十六进制编码,将该编码与配置文件中的相关配置信息做映射,将其解析为具体的物理量信息。

表3 内部数据帧格式

3 基于Flink的数据处理方法

为了提高数据处理的并行度,借助消息中间件Kafka在数据进入Flink集群前将数据进行分流。Kafka是Apache软件基金会开源的一个多分区、多副本、基于发布订阅模式的分布式消息中间件,与传统的消息系统相比,Kafka有着系统解耦、缓冲、异步通信、扩展性强、可恢复性等特点。Kafka作为大数据的组件,能够与HBase、Flink、Spark等开源大数据框架无缝集成,在大数据的应用领域,Kafka多被用作数据流实时传输的管道[7]。Kafka的体系结构如图2所示,Kafka主要由以下几个部分组成[7,9]:

图2 Kafka体系结构图[8]

1)Topic(主题):Topic在逻辑上划分消息的种类,同一个Topic中的消息可以看作是同一种业务类型的消息集合。本文中设置Topic A用于存放解析前的“内部数据帧”,设置Topic B用于存放“内部数据帧”解析后的“结果帧”。

2)Partition(分区):在同一个Topic下可以划分多个Partition,并且这多个Partition中的消息是不重复的,这样的设计可以使得多个Partition中的消息并行地被消费,从而可以提高Kafka的吞吐率。同一个Topic下的Partition会分配到不同的Broker中,所以可以通过增加Partition的数量实现水平扩展。本文中保证Topic A和Topic B中Partition的数量一直相等。

3)Broker(服务代理节点):Broker是Kafka的一个独立服务节点,一个或多个Broker组成Kafka集群。

4)Producer(生产者):Producer负责创建消息并将消息投递到Broker中,Broker便会根据预设规则将该消息存入对应的Topic下的某个Partition中。在本文中,针对于Topic A方面,Producer为UDP服务端,投递的消息为解析前的“内部数据帧”;针对于Topic B方面,Producer为Flink集群的各个节点,投递的消息为处理后的“结果帧”。

5)Consumer (消费者):Consumer订阅指定的Topic,根据预设规则主动从Broker中拉取到相关的消息。在本文中,针对于Topic A方面,Consumer为Flink集群的各个节点,消费的消息为处理前的“内部数据帧”;针对于Topic B方面,Consumer为后处理模块,消费的消息为处理后的“结果帧”。

Flink是Apache软件基金会开源的分布式实时流式计算框架,其核心是一个流数据的处理引擎,Flink将所有任务当做流来处理[10]。Flink的体系结构如图3所示,Flink集群中主要包含以下几种组件[10,11]:

图3 Flink体系结构图[11]

1)Client(客户端):Client负责向JobManager提交作业任务,当用户提交了一个Flink应用的时候,Client就会启动并将作业任务移交给JobManager。

2)JobManager(作业管理器):JobManager作为Flink集群中的主节点,负责接收Client提交的作业任务,并根据一定规则将任务分配给TaskManager执行,同时接收来自于TaskManager反馈的任务状态和统计信息,然后将这些信息反馈给Client。

3)TaskManager(任务管理器):TaskManager作为Flink集群中的从节点,负责接收JobManager所分配的作业任务,对作业任务中的数据流执行具体的业务逻辑处理,同时TaskManager会将任务的状态和统计信息反馈给JobManager。在本文中,TaskManager负责的具体业务逻辑为根据配置文件的相关配置信息解析“内部数据帧”中各个字段的十六进制编码。

4)Slot(插槽):TaskManager中可以根据硬件配置指定Slot的数量,具体地,Slot的最大设定数量等于Flink集群中所有CPU的物理核心总数量,Slot的数量决定了TaskManager中运行的数据处理程序的最大并行度。在TaskManager中运行的每个并行的数据处理程序都分别占用一个Slot资源。

系统整体的架构如图4所示,整体的数据处理流程描述如下。

1)系统整体的数据来源方为上游的参数处理与综合判读系统,上游系统通过UDP组播的形式将满足表3格式的“内部数据帧”实时数据流发送给UDP服务器端,UDP服务器端在接收到该实时数据流后进行合法性校验,将合法的“内部数据帧”存入Kafka中。Kafka同一个Topic下的多个Partition中存放的数据是不重复的[9],借助这个机制,在“内部数据帧”进入Flink集群之前,可以使用Kafka进行数据的分流,从而提升数据处理的并行度。对数据帧进行分流时,将数据帧按照到来的顺序依次存入Partition-1, Partition-2…Partition-(4n-1), Partition-4n中,并重复这个存入过程。

2)为了保证能够做到高吞吐率、低延迟地处理数据,本文采用Flink集群的方式来解析“内部数据帧”,设置Flink集群中数据处理程序的并行度等于Kafka的Topic A和Topic B中Partition的数量,这样可以保证每一个Slot中的数据处理程序并行地分别去Topic A中各自序号对应的Partition中拉取“内部数据帧”,然后并行地解析“内部数据帧”,在解析完毕后并行地将解析得到的“结果帧”存入到Topic B中各自序号对应的Partition中。

3)后处理模块从Kafka的Topic B中,依次获取Partition-1, Partition-2…Partition-(4n-1), Partiton-4n中解析好的“结果帧”,然后将“结果帧”进行合并,恢复其原有的顺序,最后将“结果帧”投递到下游系统即数据处理与任务监视系统中。

4 仿真分析验证

本文采用仿真验证基于Flink流式计算框架的空间科学卫星下行数据实时处理方法。实验数据来源于GECAM空间科学卫星在执行科学任务过程中下行的真实数据,该数据遵循AOS格式标准,且按照“AOS传输帧”和“源包”两层的结构分层组织,“AOS传输帧”的格式如表1所示,“源包”的格式如表2所示,该数据经过图1中的处理步骤后,得到525170条满足表3格式的“内部数据帧”,帧的长度为不等长。编程语言采用Java,使用的编辑器为IntelliJ IDEA Community 2021。使用3台服务器节点搭建集群实验环境,3台服务器的配置信息如表4所示。其中主节点运行的为Flink集群中的JobManager进程,负责协调作业任务在各个节点上的分布式执行;2个从节点分别运行的为Flink集群中的TaskManager进程,负责执行具体的作业任务即解析“内部数据帧”。3台服务器节点通过交换机建立局域网连接,3台服务器节点的硬件架构如图5所示。

表4 3台服务器节点配置信息

图5 3台服务器节点硬件架构图

在硬件设备和数据处理程序均一致时,影响Flink集群处理数据的性能的关键点在于其处理数据的并行度。本文中使用的两个服务器从节点均搭载4核心的CPU,故在每一个服务器节点中可以设置Slot的值为4,这说明该Flink集群可以为在其中运行的数据处理程序提供到的最大并行度为8。在数据流进入到Flink集群之前,本文使用到了消息中间件Kafka进行数据分流,考虑到发挥并行处理的最大作用,这里设置Kafka中Topic A的Partition数量和Topic B的Partition数量均等于Flink集群中数据处理程序的并行度的数量。举个例子,在Topic A中,Partition的数量设置为3,则在Flink集群中,数据处理程序的并行度设置为3,并且在Topic B中,Partition的数量也设置为3。

在本文的仿真中,将Kafka中Partition的数量与Flink集群中数据处理程序的并行度两者的组合称为配置,因本文中的Flink集群可以为在其中运行的数据处理程序提供从1到8的并行度,所以本文讨论了从“1-1”到“8-8”多种配置下的空间科学卫星下行数据处理的延迟和吞吐率,其中“1-1”表示Kafka的Topic A和Topic B的Partition数量为1,Flink中数据处理程序的并行度为1。在不同配置下的延迟统计信息如图6所示,图中的横坐标表示配置,纵坐标表示数据处理的延迟,单位是毫秒(ms),并且对于每一种配置均做了5次实验取平均值,从而得到了在每一种配置下数据处理的最大延迟、最小延迟和平均延迟。从图6中可以看出,随着数据处理的并行度的提高,数据处理的最大延迟、最小延迟和平均延迟总体上均呈现下降的趋势,在配置为“8-8”时,平均延迟达到了最低值112ms,相较于配置为“1-1”时,平均延迟降低了78.75%。在不同配置下的吞吐率统计信息如图7所示,图中的横坐标表示配置,纵坐标表示数据处理的吞吐率,单位是兆比特每秒(Mbps),同样的对于每一种配置均做了5次实验取平均值,从而得到了在每一种配置下数据处理的吞吐率。从图7中可以看出,随着数据处理并行度的提高,数据处理的吞吐率逐渐增大,在配置为“8-8”时,吞吐率达到了峰值417.49Mbps,相较于配置为“1-1”时,吞吐率提高了86.60%。同时,结合图6和图7可以看出,在总体趋势上增加并行度可以提高吞吐率降低延迟,由此可以推断,通过增加集群中服务器的数量即增加集群中CPU的总核数来提高数据处理程序的并行度,可以实现在合理的范围内进一步提高数据处理的吞吐率、降低数据处理的延迟。

图6 不同配置下的延迟统计

图7 不同配置下的吞吐率统计

5 结束语

本文设计并实现了一种基于Flink流式计算框架的空间科学卫星下行数据实时处理方法,该方法借助消息中间件Kafka各分区消息不重复的机制,将空间科学卫星下行数据依次存入不同分区中实现数据分流,搭建Flink集群用于高速处理数据,使分流后的数据依次流入到Flink集群的各个并行处理单元中实现并行处理。仿真结果表明,本文提出的方法具有较高的吞吐率和较低的延迟,在并行度为8时,吞吐率可以达到417.49Mbps,平均延迟可以达到112ms,并且可以通过水平扩展服务器的数量从而实现更高的吞吐率和更低的延迟,可以满足地面数据处理系统高速实时处理空间科学卫星下行数据的需求。