|
北京呼风唤雨文化传媒有限公司  微信公众号太多不好找到我们？ 这个问题其实很容易解决， 置顶，或星标公众号“卫星与网络” 遇见你真好，希望能一直陪着你。  随着我国发射空间科学卫星的越来越多，科学数据量进入爆发增长的时代，随之带来的空间科学卫星大数据处理逐渐成为空间科学创新发展过程中重点关注的环节，建设一套高性能的地面数据处理系统是建设我国自主可控的空间科学大数据生态，助力科学成果产出的重要推手。 面向多星多任务并行处理的任务需求，针对空间科学卫星大数据处理中的多分级分类、多源产品融合组织以及高时效性要求等特点，提出了适用于大数据处理业务场景的高可靠硬件环境设计方案，并针对科学卫星处理任务类型多的特点，提出了基于任务类型感知的统一资源调度系统。完成了面向多星多任务的可扩展地面大数据处理系统的研制，圆满地支撑了中国科学院空间科学先导专项中的科学卫星数据处理任务。   空间科学是一门前沿交叉性学科，聚焦于宇宙和生命起源、太阳系与人类起源等基础前沿主题，致力于解决暗物质与暗能量、引力波、太阳活动与空间天气响应等重大科学问题。空间科学是典型的“数据驱动”型学科。以航天器平台为主要手段获取的科学数据对学科的发展具有举足轻重的作用。一套优良的卫星地面数据处理系统需要保障科学卫星数据的正确性、完整性、可用性、易用性和时效性，最大限度地发挥出卫星探测数据的研究价值。 国内外就卫星地面处理系统开展了大量的研制工作，形成了较稳定的科学卫星地面数据处理系统框架。 国内方面，遥感卫星形成了面向单卫星的基于分布式云存储技术的地面实时处理系统[1]以及具有一定任务调度能力的多卫星地面处理系统模式[2-3]；风云气象卫星数据存档与服务系统基于高性能计算机集群建立了可支持风云系列卫星的存储与服务[4-5]；我国基于面向服务架构（service-oriented architecture，SOA）研制的天宫二号地面数据处理与服务系统实现了多领域、多载荷、海量数据的集中处理和管理[6]。 国外方面，欧洲空间天文中心（European space astronomy centre，ESAC）与日本宇宙航空研究开发机构（Japan aerospace exploration agency，JAXA）采用 Docker 技术研制的卫星地面数据处理系统可支持不同载荷数据处理算法的快速交换和部署[7-8]，很好地执行了水星探测任务 BepiColombo。 空间科学研究具有很强的竞争性，只有大胆创新才能孕育颠覆性的结果，这种学科内禀属性决定了每项空间科学任务在探测空间布局、探测内容设计、有效载荷探测精度/分辨率方面与已有的卫星任务有着巨大的差异或者提升。随之而来的是卫星任务对地面数据处理系统提出的新挑战。 例如，空间天文警报信息的识别和发布要求是秒级响应，处理时效性极高；先进天基太阳天文台（advanced space-based solar observatory，ASO-S）卫星单日产生约 00 GB的原始观测数据，处理数据量巨大；暗物质粒子探测卫星（dark matter particle explorer，DAMPE）要求星上探测数据不丢失一个源包，质量要求严苛。空间科学卫星数据的独特性质给卫星地面数据处理系统提出了更多的个性化需求。 当前，我国空间科学卫星任务呈现体系发展态势，要求配套建设的地面数据处理系统可满足多星多任务地面数据处理与管理需求。传统的卫星地面数据处理系统难以满足大数据场景下的多领域、多种类、大体量、高时效性、高质量等数据处理要求。基于此，本文在细致分析空间科学卫星地面数据处理系统需求与面临的技术挑战的基础上，设计了一套可满足多星多任务的空间科学卫星大数据地面数据处理系统框架，系统地实现了卫星下行数据的快速处理，对特定的天文警报数据实现了秒级快速处理。 空间科学卫星的数据处理过程需根据学科进行差异化流程设计，主要依据卫星的数据产品分级定义划分。从卫星下行的原始数据到用于发布的 2 级或 3 级数据产品，每级数据产品的组织形态根据学科惯例以及卫星任务数据处理和管理需求进行自定义。 本文以引力波暴高能电磁对应体全天监测器（gravitational wave high-energy electromagnetic counterpart all-sky monitor，GECAM）卫星为例介绍卫星数据处理流程和数据产品组织过程的特点。GECAM卫星是我国首颗具有警报数据实时下行能力的空间天文科学卫星，星上下行的数据包括事例数据、并道数据、工程数据以及天文警报数据，其各级数据处理步骤以及数据产品组织过程具有典型的大数据量、密集型计算以及多源数据融合处理等特征。 由于星上计算资源和存储资源非常有限以及载荷部分自身设计的原因，很多科学探测数据需要经过解压、解算以及融合等处理环节后才能成为可供科学家进行科学分析的数据产品，下行处理过程中的输出数据会根据平台、载荷以及辅助数据的类型进行分类处理，通常也会根据处理的程度进行不同的数据产品格式定义。因此，卫星数据处理流程的规划往往与数据产品的分级定义有直接的关联。 图 1 展示了依据产品分级定义的 GECAM 卫星 0 级产品处理流程。GECAM 卫星通过遥测信道、数传信道和北斗信道下行星上原始观测数据。根据数据处理程度的不同，预处理数据产品主要划分为 0A、0B、0C、0D 和 0Q 等级别。GECAM 卫星数据处理首先需要按照不 同的下行信道类型进行区分处理，在每类处理中需根据产品子级定义不同的处理流程。 图 1 GECAM 卫星 0 级产品处理流程 从多源异构数据中抽取相关信息并支持高效数据融合组织，按照产品格式要求输出时间和内容完整的数据产品是科学卫星大数据处理的又一特点。根据科学卫星探测任务的不同类型以及科学数据处理与研究分析的不同需求，数据产品组织的定义往往差异较大。为了实现数据产品的可用性和易用性，通常会根据使用需求在产品中加入其他多源、异构的辅助数据信息，产品组织和生产中存在对多源数据的提取、组织拼接需求。 常规观测类的卫星一般根据数据的生产时间或者轨道圈次进行固定时间段数据内容切分，比如按小时、按天、按轨道号进行数据产品的组织；试验类或者提案类的科学卫星需要针对一次试验或者一次提案覆盖的时间段进行数据产品的组织，将一次试验或者与提案相关的数据进行融合组织。 GECAM 卫星将触发时刻产生的触发信息组织成约 31 条短报文数据，并通过北斗系统实时下行至地面，同时将触发时刻对应的约 300 s 数据通过 X 波段优先下行。由于触发时段内的数据对科学分析工作至关重要，为了方便科学家开展数据产品分析，呈现触发时间段内完整的数据内容，在数据处理过程中为该类产品设计了特有的产品组织模型，如图 2 所示。触发数据产品组织中包括触发数据、姿态数据、轨道数据、载荷工作状态以及太阳月亮星历等数据，这些数据分别来自载荷工程数据信道、爆发科学数据信道以及北斗短报文，在地面经过多源融合处理后，按照触发编号组织成特定的触发数据产品。 图 2 GECAM 卫星触发数据产品组织模型 空间科学卫星数据的最大特点是种类多、来源广、体量大。地面数据处理系统需要同时支持多个空间科学在轨卫星下行数据处理任务。卫星开展 7×24 小时不间断的探测，源源不断地产生新的科学数据并下行至地面，系统需对接收的多源、多信使原始数据（数传信道数据、遥测信道数据、北斗短报文、甚高频（very high frequency，VHF）数据）开展虚拟信道分离、解帧、源包提取、解包、排序、重组、物理量解析转换、载荷粗略标定、产品格式化等处理，按产品内容和处理程度组织成不同级别的编辑级数据产品。 科学卫星在轨单日探测数据量逐渐增长，硬 X 射线调制望远镜（hard x-ray modulation telescope，HXMT）卫星每日通过数传 X 波段下行的原始数据约 27.9 GB，暗物质粒子探测卫星每日下行的原始数据约 26.69 GB，太极一号卫星每日下行的原始数据约 8.05 GB，墨子号量子科学实验卫星每日下行的原始数据约 0.41 GB，ASO-S 卫星每日下行约 500 GB 的原始数据。 此外，还有中法天文卫星 SVOM（space variable objects monitor）、爱因斯坦探针（Einstein probe，EP）卫星以及中欧微笑卫星SMILE（solar wind magnetosphere ionosphere link explorer）等待发射的科学卫星，后续在轨科学卫星单日下行的原始数据峰值量预计将达到800 GB，系统单日需生产数千类编辑级数据产品以及数十类星地时差、轨道根数、精密星历、卫星指向夹角等辅助数据产品，单日输出的数据产品预计约 2 TB。 为了尽快拿到卫星下行的第一手资料并在第一时间发现重大的科学事件，各卫星科学应用系统往往会对数据处理的时效性提出较高的要求。在下行数据量非常大的情况下，往往会对数据设置处理优先级，将有科学事件警报意义的数据以最高优先级进行处理。尤其是针对空间天文类的卫星探测任务，天体爆发事件转瞬即逝，如不能快速处理并发现事件就会错失很多重要的发现。因此，为了满足多源、多信使手段对已发现天体源/爆发源的观测，空间天文数据对处理时效性提出了秒级或者分钟级的要求。 特别地，空间天文警报数据产品的时效性要求达到了秒级。星上原始数据采用将所有数据混合的组织方式，如何设计高效的处理模式和资源调度框架以保证满足秒级的处理时效性要求是地面数据处理系统面临的一大挑战。 空间科学卫星数据处理的另一大特质是需要从数据规范性、一致性和完整性等角度保障数据质量，确保数据可读、可用、易用和好用。数据质量控制要求意味着系统每进行一次（级别）产品生产或数据传输，均需对数据产品质量进行审核和校验，确保数据在地面处理或传输中不引入错误。遇到因星地传输导致的数据缺失或时间不连续时，为了保障数据完整性，系统需对备份数据或历史数据进行重新生产，这为系统中的产品版本识别与控制、产品组织和管理带来了挑战。 各空间科学卫星的数据处理需求和目标不同，因此各个数据处理环节中的计算需求也会根据处理目标的不同而变化。例如 GECAM 卫星 0D 级数据处理中，需对大量事例数据（时间分辨率优于 1 s）中的时间码进行解算，解算算法包括 3 次拟合，计算复杂度高，属于计算密集型处理任务，对 CPU 资源具有较高的需求；0B 级数据处理过程中需要频繁调度地面系统公共信息库提供的 WebService 接口获取处理过程中需要的信息，这种跨服务器的频繁I/O 查询属于 I/O 密集型处理任务，该类型的任务对 CPU 的消耗通常比较低；ASO-S 卫星单次过境下行的原始数据约 110 GB，开展百 GB 量级的数据处理属于典型的数据密集型处理任务，对 CPU 计算资源、存储资源都是巨大的挑战。 作为空间科学卫星的地面共性基础设施，科学卫星大数据处理系统需要统筹考虑卫星数据产品的特性、数据处理过程的特征、以及工程任务的数据时效性和可靠性要求。从可扩展的角度考虑，如果继续采用传统的数据处理系统，在每次扩展新增卫星及其有效载荷的数据处理功能时都需改变原始处理程序的编码，进行重新编译和发布，不仅耗费时间与人力成本，还可能引起软件兼容性问题。因此，亟需研制一套具有可扩展、高性能的数据处理系统，保证系统能够灵活地对处理流程进行动态扩展，实现科学卫星大数据的快速处理与质量控制要求。 本文基于“共性+卫星专用插件”的设计理念，设计统一的任务调度与资源管理平台，为各卫星任务的专用插件提供统一的任务调度接口和资源调度接口，实现卫星专用插件的动态配置，如图 3 所示。系统接收科学卫星通过各个信道下行的原始数据，采用统一的处理计 算调度系统、统一的计算资源任务管理机制以及标准的任务调用接口和信息反馈机制，基于数据驱动的方式对各个科学卫星的数据处理插件进行任务调度，并将生成的数据产品发送至相应的科学应用系统。 图 3 空间科学卫星大数据处理系统框架 3.1.1 大数据处理系统基础软件架构 针对科学卫星载荷数据处理方法多样化、卫星数据产品组织多源性、卫星数据处理流程步骤环环相扣等特点，设计基于高性能计算集群以及超融合计算环境的大数据处理系统，采用统一任务与资源调度+专用业务插件扩展的架构形式，针对计算任务调度的实时性要求，采用 Kafka 分布式消息系统进行消息和日志的传递；针对信息查询类的接口，设计标准的WebService 服务。基础软件架构如图 4 所示。
图 4 空间科学大数据处理系统架构 大数据处理系统最核心的功能是开展各科学卫星的数据处理与质量分析工作，针对各类不同的卫星专用数据处理插件以及专用卫星数据质量分析与控制插件，各插件封装统一标准的任务订单接口以及 UDP 日志上报接口。 设计提供统一的数据接入接口，通过文件实体验证机制保证在数据传输过程中的安全性和正确性。基于数据驱动的方式启动自动数据处理流程，根据输入的原始数据的类型，调度对应的卫星专用数据处理插件以及卫星专用数据质量分析与控制插件，实现科学卫星的各级数据产品处理、标准化产品生成、数据快视、数据质量分析以及质量控制等功能。 统一任务调度引擎负责对输入数据的类型进行识别，并针对数据类型及其对应的数据处理流程发送计算任务请求，实现计算任务的集中式调度以及分布式并行处理。在任务调度过程中，该引擎需要统筹考虑各科学卫星的数据质量信息以及过站计划信息，将这些动态信息作为任务调度的依据。这主要因为以下两点。 （1）由于空间科学研究对数据产品的完整性要求非常高，地面接收站往往会进行多备份数据接收，此外当地面数据质量控制过程中发现数据存在缺失时，往往会通过点播的方式进行星上数据的回放，因此会有大量的冗余数据流入处理系统中。依靠存储在科学卫星数据质量信息库中内容，统一任务调度引擎可以提前识别冗余数据，在生成任务的入口处进行截流，避免冗余数据触发处理任务进而导致占用不必要的计算和存储资源。 （2）通常卫星每日的过站计划都会提前几天制定并通过数传星历表上传至卫星，为了保证计算资源的实时可获取性，当卫星下行数据达到系统时能够有足够的资源开展数据处理任务，系统采用资源预约机制，基于科学卫星过站计划信息进行资源的提前预定。 在数据存储方面，为了提升缓存数据的读写效率以及系统的稳定性，采用分布式文件系统实现多集群统一共享存储。针对科学卫星数据的组织特征建立基于标准元数据信息的高效数据存储模型，从而提高各个插件的数据读写访问速度。 3.1.2 大数据处理系统硬件基础架构 卫星大数据高性能处理系统硬件架构包括高性能计算集群、超融合计算环境以及分布式存储环境 3 个部分，各个部分之间通过高速互联交换机进行数据的传输与交换，硬件基础架构如图 5 所示。 高性能计算集群由调度管理节点和处理计算节点组成，其中调度管理节点采用双路机架式服务器，以主备（active/standby）方式运行；处理计算节点采用四路机架式服务器，根据业务应用需求，通过调度管理算法实现硬件资源的分配管理。 超融合计算环境采用四路高性能服务器，通过部署 FusionSphere 虚拟化软件将物理服务器的 CPU、内存、设备 I/O 进行硬件解耦，从而实现在单一物理服务器上可同时运行多个虚拟机且相互之间互不影响。 分布式存储环境采用冗余网络架构和 N+M 纠删码保护机制充分保证系统无单点故障，确保数据存储的长期安全；在不同存储节点间使用条带化技术，将 I/O 操作均匀分散到多个节点，为应用访问提供多个并行传输通道，从而有效提高了系统的读写带宽和每秒的输入输出量（input/output per second，IOPS）。
图 5 大数据处理系统硬件基础架构 3.1.3 任务类型感知的统一资源调度系统 在传统的空间科学卫星数据地面处理系统中，资源调度系统负责将数据处理子节点的CPU、内存、硬盘、I/O 等资源抽象成资源池，维护管理资源池并将资源分配给相应的数据处理任务，这种架构在空间科学大数据场景下面对多类型的卫星数据处理任务无法做出相应的处理，无法最大化发挥资源节点的性能，而且会影响数据处理的时效性。 本文提出一种任务类型感知的资源调度系统，实现对上层数据处理任务的统一编排与管理，根据科学卫星的数据处理任务需求场景，提供统一可配置的资源管理和分配策略，支持根据卫星、数据类型进行优先级的设定，支持预约类型和实时类型的计算任务请求，提供松耦合和灵活的计算任务与资源的关联关系，支持底层资源池的动态扩展，真正依据计算资源的特点做到物尽其用。任务类型感知的资源调度系统的架构如图 6 所示，主要分为资源预约与请求接口、任务队列、任务与资源的智能关联匹配以及资源节点管理 4 个部分。
图 6 任务类型感知的资源调度系统架构 资源预约与请求接口主要负责向上为统一的任务调度引擎提供资源调度接口，对申请的任务类型进行解析并将任务发送至不同的任务队列中，任务在队列中等待匹配合适的计算资源。 任务队列采用消息队列的方式进行任务请求的解析与保存，除了配置传统的计算任务队列，还专门设计了用于保存资源预约的任务队列，从而提升重要任务响应的及时性。 资源调度算法处理流程如下。 /*初始化*/ AppointmentQueue<>,IOTaskQueue<>,DataTaskQueue<>,CPUTaskQueue<> , Resources <Nodes> 输入：数据处理任务 NewTaskOrder /*接收并解析数据处理任务*/ taskType = NewTaskOrder.type(); if (taskType == appointment) then /*预约任务*/ InsertAppintQueue(NewTaskOrder) else if(taskType == IOtype) then InsertIOQueue(NewTaskOrder) else if (taskType == DataType) then InsertDataQueue(NewTaskOrder) else InsertCPUQueue(NewTaskOrder) end if /**预约资源**/ MakeAppoint(AppointmentQueue<>, Resources<>) /*更新资源状态，并获取可用计算资源*/ AvailableResource<> = Update(Resources<>) /**分配资源**/ for i=0 to i< 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 = FindWaitingTask(IOTaskQueue, CPUTaskQueue,DataTaskQueue) node.execute(unmatchTask) end for 基于高性能服务器集群和超融合计算环境建设的可扩展高性能地面数据处理系统成功地支持了中国科学院空间科学先导专项多颗空间科学卫星的海量原始数据的集中处理，系统的数据处理效率能够满足各科学工程的性能指标要求。作为空间科学卫星地面共性基础设施，该系统支持动态扩展，可基于大数据共性基础平台满足后续空间科学卫星的数据产品处理及产品组织需求。 目前该系统通过 Apache+Tomcat 搭建系统整体业务监管界面，通过 Kafka消息队列实现处理类、数据管理类以及数据服务类的状态消息实时上报，对系统内开展的各类数据处理、数据管理和分发等活动进行实时监视，依据输入数据为运行流程设计唯一标识符，从而可以对从输入开始一直到生产各类数据产品并对外提供服务的整个过程进行跟踪，如图 7 所示。
图 7 系统综合业务展示 该系统通过标准的任务订单接口和任务调度调度接口，集成了多颗科学卫星的数据处理与产品生产、数据质量分析与评估等几十类算法模块，采用标准 WebService 接口实现了对外接口服务，任务调度时延小于 1 s。多星多任务调度平台如图 8 所示。
图 8 多星多任务调度平台 目前系统运行稳定，支撑着 5 颗在轨科学卫星的数据处理。系统每日处理的数据量约103 GB，输出的数据产品数量约 364 GB。系统将每次数传下行处理的数据产品自动准实时地发送至各卫星科学应用系统，有效地支持了 HXMT 卫星、暗物质粒子探测卫星以及墨子号量子科学实验卫星科学成果的发现[9-13]。  面对空间科学后续卫星探测数据量大幅增加，数据处理过程更加复杂，处理耗时增加与天文警报数据超高时效性要求的趋势，在系统自动化的基础上，有待进一步研究智能化技术和流式数据处理技术，以大幅改善系统的多任务并行处理能力。针对多类型任务调度引擎的兼容性和可扩展性，需进一步优化资源统一调度接口，采用轻量化容器技术增强代码迁移的能力。未来还将开展共性数据处理算法的抽象工作，增加共性数据处理工具集，降低扩展新卫星任务带来的成本。 [1]陈世荣, 严立, 申佩佩. 高分遥感卫星影像预处理系统的设计和实现[J]. 测绘与空间地理信息, 2021, 44(3): 1-3. CHEN S R, YAN L, SHEN P P. Design and implements of high-resolution satellite image preprocessing system[J]. Geomatics & Spatial Information Technology, 2021, 44(3): 1-3. [2]刘定生, 陈元伟, 李景山. 遥感卫星地面预处理系统技术发展模式探讨[J]. 遥感信息, 2008, 23(5): 87-91. LIU D S, CHEN Y W, LI J S. The study on the development patterns of remote sensing satellite ground pre-processing systems[J]. Remote Sensing Information, 2008, 23(5): 87-91. [3] MOSES J F. Architectures toward reusable science data systems[C]//AGU Fall Meeting. [S.l:s.n.], 2014. [4]钱建梅, 孙安来, 徐喆, 等. 风云气象卫星数据存档与服务系统[J]. 应用气象学报, 2012, 23(3): 369-376. QIAN J M, SUN A L, XU Z, et al. Fengyun series meteorological satellite data archiving and service system[J]. Journal of Applied Meteorological Science, 2012, 23(3): 369-376. [5]赵现纲, 林曼筠, 谢利子, 等. 风云卫星地面应用系统计算机网络平台架构[J]. 气象科技进展, 2020, 10(3): 43-48. ZHAO X G, LIN M J, XIE L Z, et al. Computer network system of FY satellite ground segment[J].Advances in Meteorological Science and Technology, 2020, 10(3): 43-48. [6]李盛阳, 刘志文, 张万峰, 等. 天宫二号应用任务地面数据处理与服务系统[J]. 中国科学:技术科学, 2020, 50(8): 1066-1080. LI S Y, LIU Z W, ZHANG W F, et al. Tiangong-2 application mission ground data processing and service system[J]. Scientia Sinica Technologica, 2020, 50(8): 1066-1080. [7]BENKHOFF J, CASTEREN J V, HAYAKAWA H, et al. BepiColombo—comprehensive exploration of mercury: mission overview and science goals[J]. Planetary and Space Science, 2010, 58(1-2): 2-20. [8] D’AMORE M, JÖRN H, MATURILLI A, et al. BepiColombo/MERTIS data processing pipeline at DLR[C]//EGU General Assembly 2016. [S.l:s.n.], 2016. [9]DAMPE COLLABORATION. Direct detection of a break in the teraelectronvolt cosmic-ray spectrum of electrons and positrons[J]. Nature, 2017, 552(7683): 63-66. [10]LIAO S K, CAI W Q, LIU W Y, et al. Satellite-to-ground quantum key distribution[J]. Nature, 2017, 549(7670): 43-47. [11]LIAO S K, YONG H L, LIU C, et al. Long-distance free-space quantum key distribution in daylight towards inter-satellite communication[J]. Nature Photonics, 2017, 11(8): 509-513. [12]YIN J, CAO Y, LI Y H, et al. Satellite-based entanglement distribution over 1200 kilometers[J]. Science, 2017, 356(6343): 1140-1144. [13]LI T P, XIONG S L, ZHANG S N, et al. Insight-HXMT observations of the first binary neutron star merger GW170817[J]. Science China Physics, Mechanics & Astronomy, 2017, 61(3): 1-8. 本文转载自“《大数据》”，原标题《面向多星多任务的大数据处理系统设计》，文 | 马福利 1，石涛 2，陈玲 1，郑岩 1，熊森林 1，（ 1.中国科学院国家空间科学中心，2.中国科学院空天信息创新研究院） |
|
|
