CN106681807B - 一种基于Spark的成像卫星任务预处理并行化方法 - Google Patents

Abstract

本发明公开了一种基于Spark的成像卫星任务预处理并行化方法，包括步骤：A、轨道预报的并行化设计，将大规模观测任务分解若干个小任务，每个小任务独立完成；B、轨道预报的并行化实现，对于大规模卫星观测任务预处理问题，每颗卫星或者每颗卫星对单一任务的任务预处理之间是相互独立的，可以通过分布式并行计算来将问题分解。通过本方法，节约任务预处理的整体计算时间，大大提高计算效率。

Description

一种基于Spark的成像卫星任务预处理并行化方法

技术领域

本发明涉及成像卫星任务预处理技术领域，特别是涉及一种基于Spark的成像卫星任务预处理并行化方法。

背景技术

成像卫星任务规划预处理问题来源于成像卫星的工作流程。成像卫星的工作流程可以简述如下：(1)接收用户提出的观测需求；(2)根据卫星资源特性，对用户的需求进行预处理，得到标准的规划输入；(3)结合地面站和卫星使用约束，依据特定的优化算法，对输入任务进行规划和调度，得到任务调度方案；(4)将生成的任务调度方案进行计划编排与指令生成，通过地面站将控制指令上注到卫星，卫星执行指令进行成像和数据回放，地面站接收成像数据，数据处理后被反馈给用户。

其中用户提交的原始观测需求往往不指定观测资源，成像的时间窗口也不明确，而且很多复杂的用户需求如区域目标成像任务等是难以一次性完成观测的，因此有必要对用户原始的观测需求进行一些处理。一方面需要根据用户观测需求和卫星的能力进行匹配和筛选，确定需求的可选卫星及其对应的成像时间窗口；另一方面需要对复杂成像任务进行分解，生成能够一次性观测的单一子任务。对于不同卫星和不同用户观测需求，该问题有其特殊性。但是预处理的最终目的都是将用户提出的规范化需求转变为指卫星一次成像过程可以完成观测的任务，称为元任务。元任务是卫星可以执行的最小成像任务，它包含了具体的位置和时间信息，可以视为考虑了卫星对地观测几何关系的条带。

因此我们考虑成像卫星任务预处理问题的共性问题，可以将其描述为：将用户提出的规范化观测需求根据卫星能力处理成任务规划模型可直接规划调度的元任务(组)。用户的规范化观测需求的输入要素主要包括目标位置、条带参数、成像时间段、成像模式、成像质量(分辨率)、成像角度、成像太阳高度角等；由于预处理要考虑卫星的能力，因此除了用户的需求以外，还需要 卫星的相关参数。

成像卫星任务规划预处理的一般流程可描述为：(1)根据用户观测需求中的成像时间、成像模式、成像质量、太阳高度角和成像角度初步确定完成需求的可选资源，没有合适资源的用户需求，直接从需求集合中删除。(2)将原始的用户观测需求分解为可一次性完成观测的条带。例如使用时姿向量对观测目标进行分解，首先通过时间-姿态转换模块将目标区域顶点坐标转换为时姿向量，然后进入目标分解与合成模块，由全部时姿向量确定目标的特征向量，基于时间-姿态的描述方法进行条带划分和条带裁剪，由用户需求和卫星能力约束进行目标静态合成，再通过时间-姿态转换模块生成元任务的条带坐标信息(3)计算每个元任务条带的时间窗口信息。计算条带起点中心点的时间窗口，在根据成像时间段、地影区等用户需求进行窗口的处理，得到经过各个裁剪过程后生成元任务的时间窗口信息。

经过预处理的一般过程后，那些没有合适观测资源的观测需求直接被删除了，复杂的观测需求被分解成了可调度的元任务，时间窗口不能满足用户要求的元任务也被删除了，从而使得原问题得到了一定程度的简化，求解时消减了不必要的搜索空间。同时，所有观测序曲被抽象成了统一的形式，能够用一个统一的数据格式来表示与观测需求和资源相关的属性和约束，从而为建模过程提供了直接的数据输入。

当卫星数量较少时，预处理的计算模块相对比较清晰。然而随着卫星数量的增加，卫星的管控方管控的卫星数量不再是一两颗，而是几十颗甚至上百颗，与之相对应的是用户提交的成像需求数量成倍增加。卫星和任务的规模成倍的增加将会使得现有的预处理方法不再适用，主要体现在以下两个方面：

(1)计算速度太慢：以卫星对区域目标的一般小条带划分这一预处理场景为例，1颗卫星对100个任务的条带划分需要300秒，则100颗卫星对100个任务的条带划分大约需要30000秒，即8.333小时。而任务规划的周期一般为1天，因此面对这种大规模卫星观测任务的场景，现有的预处理方法在时间上不能满足工程上的要求。

(2)计算逻辑杂乱：预处理方法中计算模块具有逻辑上的依赖性，比如 计算卫星出入地影的时间预报需要卫星的轨道预报结果。现有的预处理方法对单星或者卫星数量较少的场景还能胜任。但当卫星数量较多时，使用现有的预处理方法必然导致计算逻辑杂乱。

对于大规模卫星观测任务预处理问题，每颗卫星或者每颗卫星对单一任务的任务预处理之间是相互独立的，可以通过分布式并行计算来将问题分解。通过上述方法，可以节约任务预处理的整体计算时间，大大提高计算效率，所以对大规模卫星观测任务预处理的分布式并行实现这一问题进行研究是可行的。

发明内容

本发明的目的是提供一种基于Spark的成像卫星任务预处理并行化方法，可以节约任务预处理的整体计算时间，大大提高计算效率，对大规模卫星观测任务预处理的分布式并行实现这一问题进行研究是可行的。

为实现上述目的，本发明提供了如下方案：

一种基于Spark的成像卫星任务预处理并行化方法，包括步骤：

A、轨道预报的并行化设计，将大规模观测任务分解若干个小任务，每个小任务独立完成；

B、轨道预报的并行化实现。

可选的，步骤A中，将大规模观测任务分解若干个小任务是针对并行计算的思想设计一个全新的并行化算法来达到并行计算。

可选的，步骤A中，轨道预报的并行化设计包括步骤：

A1、获取多颗卫星轨道预报输入；

A2、将所述输入封装在RDD中；

A3、将封装后数据通过轨道预报程序输出；

A4、所述输出为写入本地文件系统、写入RDD、写入Redis。

可选的，步骤A1包括：所述尾气传输管连接所述集气罩的一端处于整跟管路的最低位置，连接所述氧转移效率测定仪的一端处于整跟管路的最高位置，防止冷凝水堵塞管道。

可选的，步骤A1包括：将一颗卫星计算所需要的两个文件数据放在一行，并添加一个参数标识卫星名称，输入数据之间以空格或者其他字符隔开，RDD 的每一行都表示一颗卫星的轨道计算输入。

可选的，步骤A2包括：RDD分区策略，所述RDD分区策略是计算多颗卫星的轨道预报，将几颗卫星的计算任务放在同一个分区，外部程序能接受多个计算输入，并在所述程序中依次执行得到最终的计算结果。

可选的，步骤A3包括：每颗卫星在每个计算时间段的轨道预报计算都会得到一个输出结果，通过轨道标识参数对输出结果进行区分，轨道预报输出结果的存储方式在外部程序的代码中进行指定，存储方式有三种：

a)写入本地文件系统；

b)写入RDD；

c)写入Redis内存。

可选的，步骤B包括：

B1、初始化Spark集群环境，配置集群参数；

B2、从本地文件系统或者Redis中读取输入数据集生成RDD；

B3、通过pipe()方法将RDD中的元素传递给轨道预报这个外部程序；

B4、调用RDD的行动操作触发实际计算。

根据本发明提供的具体实施例，本发明公开了以下技术效果：

可以节约任务预处理的整体计算时间，大大提高计算效率，对大规模卫星观测任务预处理的分布式并行实现这一问题进行研究是可行的。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明的一种基于Spark的成像卫星任务预处理并行化方法的流程图；

图1中101为轨道预报的并行化设计，将大规模观测任务分解若干个小任务，每个小任务独立完成；102为轨道预报的并行化实现；

图2为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的预处理过程图；

图3为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的计算需求之间的逻辑关系图；

图4为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的大规模卫星观测任务并行预处理框架图；

图5为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的基于Spark的轨道预报算法并行设计图；

图6为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的卫星对目标点可见时间窗口示意图；

图7为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的基于Spark的可见时间窗口并行计算设计图；

图8为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的基于Spark的可见时间窗口计算并行化实现流程图；

图9为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的区域目标多条带拼接成像示意图；

图10为本发明的一种基于Spark的成像卫星任务预处理并行化方法的实施例的基于Spark的元任务并行计算设计图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的目的是提供基于Spark的成像卫星任务预处理并行化方法，可以节约任务预处理的整体计算时间，大大提高计算效率。

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

图1为本发明的基于Spark的成像卫星任务预处理并行化方法的实施例的流程图。如图1所示，一种基于Spark的成像卫星任务预处理并行化方法，包括步骤：101、轨道预报的并行化设计，将大规模观测任务分解若干个小任 务，每个小任务可以独立完成；

102、轨道预报的并行化实现。步骤101中，将大规模观测任务分解若干个小任务是针对并行计算的思想设计一个全新的并行化算法来达到并行计算。

步骤101中，轨道预报的并行化设计包括步骤：

201、获取多颗卫星轨道预报输入；

202、将所述输入封装在RDD中；

203、将封装后数据通过轨道预报程序输出；

204、所述输出为写入本地文件系统、写入RDD、写入Redis。

步骤201包括：将一颗卫星计算所需要的两个文件数据放在一行，并添加一个参数标识卫星名称，输入数据之间以空格或者其他字符隔开，RDD的每一行都表示一颗卫星的轨道计算输入。

步骤202包括：RDD分区策略，所述RDD分区策略是计算多颗卫星的轨道预报，将几颗卫星的计算任务放在同一个分区，外部程序能接受多个计算输入，并在所述程序中依次执行得到最终的计算结果。

步骤204包括：每颗卫星在每个计算时间段的轨道预报计算都会得到一个输出结果，通过轨道标识参数对输出结果进行区分，轨道预报输出结果的存储方式在外部程序的代码中进行指定，存储方式有三种：

a)写入本地文件系统；

b)写入RDD；

c)写入Redis内存。

步骤102包括：

B1、初始化Spark集群环境，配置集群参数；

B2、从本地文件系统或者Redis中读取输入数据集生成RDD；

B3、通过pipe()方法将RDD中的元素传递给轨道预报这个外部程序；

B4、调用RDD的行动操作触发实际计算。。

本发明的有益效果是：对算法进行并行化设计之后，将算法部署到Spark平台上，算法的执行过程由整个集群同时处理。虽然集群中的节点之间通信开销需要消耗一些时间，但是这些必要的开销相对于算法执行的整个过程而言只占很小的部分。处理大量计算任务时，集群下的并行化算法相比单机下的算法 优势相当明显。

实施例一

预处理过程本质上就是一个计算元任务的过程，而在某些情景下，用户只想要知道某颗卫星对某个目标的可见性情况，并不需要做到计算元任务这一环节，甚至有的用户只想知道某颗卫星的轨道运行情况。基于上述情况，将预处理的概念进行扩展，将狭义的预处理过程，将用户提出的可见性计算、轨道预报等需求也视为预处理概念的范畴，称之为广义的预处理过程。

如图2所示，广义的预处理过程主要包括卫星信息的基本计算、卫星对目标的相关计算以及成像任务的元任务计算等内容。卫星信息的基本计算包括卫星的轨道预报、地影预报、圈号计算。卫星对目标的相关计算主要是指卫星对目标的可见时间窗口计算，按照目标以及卫星机动能力的差异，可分为对点目标的可见时间窗口、对移动目标的时间窗口计算等。成像任务的元任务计算种类有很多，根据预处理过程的差异，算法之间略有差异。以小型敏捷卫星对点目标成像为例，一般小条带划分与立体成像的元任务计算不同，最后输出的元任务信息也不同。

随着卫星技术的不断发展，成像卫星的数量和类型也越来越多，与之相对应的是用户需求也越来越多样化。现有的预处理计算都是针对单星或者单星对单任务的场景，当出现大量的用户计算需求时，现有方法只能通过在单台机器上顺序执行，计算时间不能满足工程需求，需要通过某种机制将这些计算需求同时进行。因此将大规模卫星观测任务并行预处理问题描述为：针对多个用户提出的大批量多类型的预处理计算需求，通过并行计算缩短计算时间，快速得到用户需要的结果。该问题包括：

(1)计算需求种类多

广义的预处理过程包含的计算模块较多，有些计算模块功能相似但算法细节不同，导致对计算需求的梳理较为麻烦。同时每个用户可以提出多类计算需求，当有多个用户同时提出需求，如何对这些计算需求实时监控，观察其执行情况也是一件比较复杂的事。

(2)计算需求之间有逻辑关系

在广义的预处理过程中，计算需求之间存在逻辑上的关联关系。图3简要表明了这些计算需求之间的逻辑关系。对于多个用户同时提出多类计算需求时，如何梳理这些计算需求之间的逻辑关系得到执行逻辑正确的计算流程也是一件值得研究的问题。

大规模卫星观测任务并行预处理框架

根据对大规模卫星观测任务并行预处理问题的描述与分析，以及Spark实现并行计算的特点，构建如图4所示的大规模卫星观测任务并行预处理的框架。

该框架的功能和执行流程如下：将多个用户提出的多类计算需求进行汇总分类，得到每一类计算需求的输入并通过与之相对应的并行算法实现并行计算。同时不同类型的计算需求也可以在Spark平台上并行执行，最后将输出结果反馈给用户。

上述框架描述了面向大规模观测任务并行预处理的一般流程，该框架存在双层并行机制。首先是针对每一类计算需求的多个输入，设计与需求相对应计算模块的并行算法。同时，对于上述含有多个输入的并行计算模块，可以将其封装成Spark作业在Spark并发执行。

轨道预报的并行化研究

轨道预报是预处理中最基本的计算模块，其他计算模块都需要使用轨道预报的计算结果。

成像卫星一般是近地轨道，运动轨迹是一个椭圆曲线轨道。因此卫星在空间轨道上的位置可以用开普勒轨道根数，即半长轴a、偏心率e、倾角i、升交点赤经、近地点角和指定历元的平近点角M这6个参数来描述。卫星的运动也可以用卫星在某一坐标系下的位置速度描述，通常使用J2000地心惯性坐标系(ECI)。地心惯性坐标系以地心为原点O，OX轴指向春分点方向，OZ轴指向北极，根据右手定则确定OY轴，t时刻卫星在该坐标系下的位置速度表示为

任意时刻的位置速度可以与轨道根数相互转换。

卫星的轨道根数和位置速度都是时间的函数，可以通过动力学模型高精度地预报出未来一段时间内卫星的位置，这个过程称为星历预报或者轨道预报。轨道预报的输入通过文件形式，主要是卫星瞬时轨道数据文件和计算时间段文件。瞬时轨道文件给定了某一时刻点以及该时刻对应的卫星瞬时轨道根数，计算时间段文件给定了轨道预报的开始时间、结束时间以及输出间隔时间。在轨道预报的所有输出文件中，工程常用的是卫星在J2000惯性系下位置速度文件，文件的每一行数据表示一个时刻点以及该时刻点对应的位置速度。

对于轨道预报，可以看出随着卫星数量的增加，单机上依次运行算法的时间会近似线性增长，计算所需要的时间开销大大增加，解决此问题需要将轨道预报算法并行化，通过并行化提高算法计算效率，提高算法的实用性。

轨道预报的并行化设计

并行化设计思想是将一个大的任务划分为若干个小任务，然后每个小任务可以独立完成，这样可以达到并行计算的效果。一般情况下，将一个任务划分成若干个子任务来进行并行计算有两种方法：一种是针对并行计算的思想设计一个全新的并行化算法来达到并行计算，另一种方法是对于传统的串行的算法进行分析，找出算法中能并行化的部分并将其并行化。

对于多星轨道预报计算问题，采用后一种方法将算法并行化在理论上是一个可行的手段。考虑把每颗卫星的轨道预报计算作为一个计算任务，即以每颗卫星的计算作为并行粒度，则多颗卫星的轨道预报计算可以看出多个计算任务，而且这些计算任务之间是相互独立的，可以分配到集群上每个节点进行计算。

在Spark中，当通过对RDD的操作来表达计算意图时，这些计算就会自动地在集群上并行进行。同时Spark针对Scala、Java、Python都不能实现特定计算功能的情形，提供了一种通用机制，可以将数据通过管道传给其他语言编写的程序。Spark在RDD上提供pipe()方法，Spark的pipe()方法可以让程序开发人员使用任意一种语言实现Spark作业的部分逻辑。通过pipe()可以将RDD中的各元素从标准输入流中以字符串形式读出，并对这些元素执行任何你需要的操作，然后把结果以字符串的形式写入标准输出。

基于Spark实现并行计算的特点，轨道预报并行算法的设计原理如图5所示。在该并行模型中，将多颗卫星轨道预报的输入数据封装在RDD中，同时把原有的轨道预报算法作为一个测试好的外部程序，RDD通过pipe()方法交给这个外部程序进行处理即可实现多颗卫星轨道预报的并行计算。下面分析如何将输入数据表达成RDD，并讨论RDD的分区策略以及轨道预报输出结果的命名和存储方式。

(1)输入数据表达成RDD

每颗卫星的轨道预报需要瞬时轨道数据文件和计算时间段文件。同时pipe()方法通过标准输入流读取RDD中的各元素，这就要求RDD的各元素之间以换行符作为分隔标记。因此可以将一颗卫星计算所需要的两个文件数据放在一行，并添加一个参数标识卫星名称，输入数据之间以空格或者其他字符隔开。这样RDD的每一行都表示一颗卫星的轨道计算输入。

(2)RDD的分区策略

Spark应用在物理执行期间，RDD会被分为一系列的分区，每个分区都是整个数据的子集。当Spark调度并运行任务时，Spark会为每个分区中的数据创建出一个任务。该任务在默认情况下会需要集群中的一个计算核心来执行。因此如果计算多颗卫星的轨道预报，可以将每颗卫星的计算任务即RDD的每一行都当成一个分区，也可以将几颗卫星的计算任务放在同一个分区。后者需要外部程序能接受多个计算输入，并在程序中依次执行得到最终的计算结果。

(3)输出结果的命名和存储方式

每颗卫星在每个计算时间段的轨道预报计算都会得到一个输出结果，可以通过轨道标识参数对输出结果进行区分，便于后续查询。轨道标识参数表明这是哪一颗卫星在哪个时间段的计算结果，因此必须包含卫星名称和计算时间段信息。轨道预报输出结果的存储方式在外部程序的代码中进行指定。可选的存储方式有以下三种：

写入本地文件系统：将结果写入文件存储在本地磁盘是最简单的存储形式。但这种存储方式不够灵活，而且由于其他计算模块的输入需要使用轨道预报的计算结果，频繁的读取磁盘文件会带来大量的I/O开销。同时这种方式有 一个严重的缺陷：在集群上运行时，不同分区可能在不同节点上进行计算，轨道的计算结果会分散在各个节点。因此当在某个节点上执行像可见时间窗口这种需要轨道数据的计算时，会因为轨道数据缺失而出现错误。

写入RDD：由于pipe()方法是一个转换操作，RDD的转换操作会返回一个新的RDD，因此可以将结果存在RDD中。RDD操作方式比较灵活，既可以作为新的计算输入也可以输出到本地文件系统、HDFS文件系统以及内存数据库等位置。

写入Redis内存：Redis是一个开源的、高性能的、基于键值对的缓存与存储系统，它以字典结构存储数据。字典变量是一种键值对形式的变量，例如dict[“key”]＝“value”中dict是一个字典结构变量，字符串“key”是键名，而“value”是键值。可以在外部程序中将轨道预报的输出结果以字符串形式写入“value”，并通过键名来访问这些数据。

对算法进行并行化设计之后，将算法部署到Spark平台上，算法的执行过程由整个集群同时处理。虽然集群中的节点之间通信开销需要消耗一些时间，但是这些必要的开销相对于算法执行的整个过程而言只占很小的部分。处理大量计算任务时，集群下的并行化算法相比单机下的算法优势相当明显。

轨道预报的并行化实现

在Spark平台上轨道预报并行化实现的详细步骤如下：

(1)初始化Spark集群环境，配置集群参数；

(2)从本地文件系统或者Redis中读取输入数据集生成RDD；

(3)通过pipe()方法将RDD中的元素传递给轨道预报这个外部程序；

(4)调用RDD的行动操作触发实际计算。

下面给出Spark并行实现轨道预报的伪代码。Step1实例化了一个SparkContext，SparkContext是Spark应用程序的入口，应用程序通过SparkContext提交到Spark集群中；Step2读取程序输入数据，生成一个List类型的变量lines；Step3通过SparkContext的parallelize()方法将输入数据表示成RDD类型的变量dataRDD，并设置了分区数；Step4将输入数据RDD的元 素通过pipe()方法交给外部程序进行处理；Step5调用行动操作collect()触发实际计算。输出文件的存储形式由外部程序指定。如果要求将输出数据写入RDD，则outputRDD就是输出RDD，这个新RDD的分区数与dataRDD的分区数相同。

输入：数据的存放地址DataPath；轨道预报程序的存放地址CalPath；Spark的集群地址master；分区数PartitionNum。

Step1：sc＝new SparkContext(master，″Cal-eph″)

Step2：lines＝Source.fromFile(DataPath).getLines().toList

Step3：dataRDD＝sc.parallelize(lines，PartitionNum)

Step4：pipeRDD＝dataRDD.pipe(CalPath)

Step5：outputRDD＝pipeRDD.collect()

可见时间窗口计算

卫星绕地球飞行过程中，由于地球遮挡和卫星机动能力限制，卫星对目标不是时时可见的，而是在某个圈次某个弧段对目标可见，将卫星在其机动能力限制范围内星上载荷对目标点可见弧段所对应的开始和结束时间范围定义为可见时间窗口，如图6所示。由于卫星与地面目标的任何直接信息交换活动都必须在卫星对该地面目标的可见时间窗口中，因此计算卫星对目标的可见时间窗口非常重要。

可见时间窗口计算的步骤简述如下：

(1)判断卫星与目标之间是否有遮挡：在t时刻建立卫星和目标两点的连线，通过求连线与地球表面的交点判断是否被地球遮挡；

(2)判断卫星对目标指向姿态机动角是否超出其能力范围：卫星对目标的指向姿态通过侧摆角、俯仰角、偏航角来表示，如果这三个角度都没有超出卫星的姿态机动能力范围，则说明该时刻卫星对目标可见。

一般来说，在上述可见时间窗口计算的基本原理的基础上，可见时间窗口计算有多种变形类型。按照观测目标的差异可分为卫星对点目标的可见时间窗口计算和卫星对区域目标的可见时间窗口计算；按照卫星机动能力形式的差异 可以分为卫星对目标的矩形可见时间窗口和卫星对目标的锥形可见时间窗口。本文描述的可见时间窗口计算是最简单的一种方式即卫星对点目标的可见时间窗口计算。

卫星对点目标的可见时间窗口计算是指给定空间某一点的位置数据(经纬高度)、卫星的位置速度数据文件、时间范围，卫星在该时间范围内，卫星的姿态转动方式和能力，给出能力范围内可以指向该点的时间窗口，按指定粒度给出卫星沿该空间点与该卫星的连线的指向角度和角速度序列。输入文件主要有三个：计算时间段文件；卫星J2000惯性系下位置速度数据文件；目标的位置文件。计算时间段文件给定开始时间、结束时间以及输出间隔时间。卫星的位置速度数据文件就是轨道预报的结果，同时要求该文件的位置速度数据等间隔且时间段包含计算时间段。目标的位置文件不仅给出目标在大地坐标系的经度纬度高度表示，还给出了卫星的姿态转动方式和姿态机动能力即最大滚动角、最大俯仰角和最大偏航角。输出文件有两个：卫星可见目标的时间窗口文件和卫星可见目标的指向姿态角度和角速度序列文件。时间窗口文件的每一行表示卫星在某个圈次对目标的可见信息。指向文件给出了可见时间窗口内每一时刻卫星对目标指向的角度和角速度。

与轨道预报相比，可见时间窗口计算需要读取一个数据量较大的卫星位置速度文件，因此I/O开销较大。当出现需要多颗卫星计算多个点目标可见时间窗口的问题时，现有算法不再适用，下面介绍其并行化设计与实现。

可见时间窗口计算的并行化设计与实现

基于轨道预报并行化设计的思想，找到上述问题中能并行化的部分并将其并行化。由于同一颗卫星对不同的点目标计算是一个相互独立的过程，不同的卫星对同一个点目标的计算也是一个相互独立的过程，因此可以将每颗卫星对每个点目标的可见时间窗口计算当成一个计算任务，这些计算任务之间是相互独立的，可以分配到集群上每个节点进行计算。

可见时间窗口计算的并行化设计如图7所示。将输入数据封装在RDD中，通过pipe()方法交给可见时间窗口计算这个外部程序进行处理实现并行计算多颗卫星对多个点目标的可见时间窗口。但是由于卫星的位置速度数据文件很 大，很难用RDD的一行表示表示一颗卫星对一个点目标的可见时间窗口计算输入。为此提出了三种方法来解决如何将输入数据表达成RDD。

(1)通过外部程序读取卫星的位置速度数据：卫星的位置速度数据是轨道预报的输出结果。上一节提到轨道预报的输出结果会以本地文件或者Redis内存数据库的方式进行存储，因此可以在外部程序的代码中读取卫星的位置速度数据。此时计算的输入就变成了计算时间段文件和目标的位置文件。将所需要的两个文件数据放在一行，同时为了保证能正确读取所需要的位置速度数据，添加一个轨道标识参数，输入数据之间以空格或者其他字符隔开。

(2)在外部程序中添加轨道预报计算模块：读取卫星的位置速度数据会简化计算，但是同时会产生计算任务之间的依赖关系，使得计算逻辑变得复杂。基于上述考虑，在外部程序的代码中添加轨道预报计算模块。轨道预报的计算需要输入卫星瞬时轨道数据文件和计算时间段文件，而轨道预报和可见时间窗口的计算时间段文件可以一致，只需要添加卫星在计算时间段的开始时刻对应的瞬时轨道根数即可。这种计算方式当然也会产生一定的弊端，比如某一颗卫星在同一时间段对几个目标点进行可见时间窗口计算时，每个目标点都需要计算一次轨道预报，而实际上只需要计算一次轨道预报。

(3)通过卫星的位置速度数据文件与其它输入文件创建pairRDD：pairRDD是键值对类型的RDD，它是Spark中常见的数据类型。将计算时间段文件和目标的位置文件合并，提取这些字段作为pairRDD中的″key″值，卫星的位置速度文件作为pairRDD中的″value″值。这种形式的输入可以由用户指定pairRDD的生成方式，便于轨道预报模块和可见时间窗口计算模块串连在一起。

对于前两种形式的输入RDD，支持将单个计算任务或者多个计算任务放在同一个分区中。而当输入为pairRDD时，一个pairRDD只能表示一颗卫星对一个点目标的计算任务。可见时间窗口计算得到的输出结果通过卫星和目标组成的标识参数进行区分，输出的存储方式主要是写入本地文件系统。

可见时间窗口的并行化实现如图8所示，与轨道预报的并行化实现原理相同。

元任务计算

元任务是卫星可以执行的最小成像任务，可以将其看成卫星能一次完成拍摄的条带和该条带时间窗口信息的组合，生成元任务的过程就是将用户提出的规范化观测需求根据卫星能力处理成任务规划模型可直接规划调度的标准输入。对于不同的任务规划平台、卫星和用户需求，计算元任务的过程不尽相同。下面以小型敏捷卫星对区域目标同轨多条带拼接成像为例详细描述。

图9是小型敏捷卫星对区域目标同轨多条带拼接成像示意图。计算元任务的过程如下：

(1)判断某一圈次卫星对区域目标是否完全可见。只有在卫星对区域目标的所有顶点均可见的圈次才可以进行元任务的计算。

(2)在完全可见的圈次，对区域目标进行条带划分。对区域目标的分解方法通过区域目标的最早时刻、最晚时刻、最小侧摆角和最大侧摆角这四个特征点确定一个与星下线平行的外接矩形。最后根据卫星的幅宽划分条带，并根据区域目标边界将条带裁剪为合适的长度。条带划分的结果得到条带的四个顶点坐标和起止中心点坐标。

(3)计算元任务条带对应的时间信息。元任务条带的时间信息包括卫星对条带起点中心点的可见时间窗口、卫星推扫条带所需时间等信息。

元任务计算的输入文件有四个：场景文件、卫星文件、轨道计算输入文件和任务输入文件。场景文件中给出场景名称、场景开始时间、场景结束时间以及场景是否应急等信息。卫星文件给出卫星的详细信息，包括卫星名字、质量、光压系数等内容。轨道计算输入文件除了包括瞬时轨道根数和计算时间段之外，还有圈号、大气阻尼面积等内容。任务输入文件给出任务ID、观测目标的边数及其各个顶点的经纬高信息。同时还给出了条带的一些属性包括条带是否裁剪、条带扩充长度、条带划分粒度等内容。

元任务计算是预处理中计算量最多的任务，计算时间相对较长。当多颗卫星对多个成像任务进行元任务计算时，现有串行算法很难适应工程需要，下面介绍其并行化设计与实现。

元任务计算的并行化设计与实现

我们考虑在元任务计算中能并行执行的模块将其并行化。由于同一颗卫星对不同的观测目标进行元任务计算是一个相互独立的过程，不同的卫星对同一个观测目标进行元任务计算也是一个相互独立的过程，因此可以将每颗卫星对每个观测目标的元任务计算当成一个计算任务，这些计算任务之间是相互独立的，可以分配到集群上每个节点进行计算。

元任务计算的并行化设计原理同轨道预报、可见时间窗口计算并行设计原理相同，如图10所示。将输入数据封装在RDD中，通过pipe()方法交给元任务计算这个外部程序进行处理实现并行计算多颗卫星对多个观测目标的元任务。其中输入RDD支持将多个计算任务放在同一个分区，元任务计算得到的输出结果可以通过卫星、目标以及成像模式组成的标识参数进行区分，输出的存储方式主要是写入本地文件系统。元任务计算的并行化实现原理也与前两种算法相同。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。

Claims (4)

1.一种基于Spark的成像卫星任务预处理并行化方法，其特征在于，包括步骤：

A、轨道预报的并行化设计，将大规模观测任务分解若干个小任务，每个小任务独立完成；

B、轨道预报的并行化实现；

所述步骤A中，将大规模观测任务分解若干个小任务是针对并行计算的思想设计一个全新的并行化算法来达到并行计算；

对算法进行并行化设计之后，将算法部署到Spark平台上，算法的执行过程由整个集群同时处理；

所述步骤A中，轨道预报的并行化设计包括步骤：

A1、获取多颗卫星轨道预报输入；

A2、将所述输入封装在RDD中；

A3、将封装后数据通过轨道预报程序输出；

A4、所述输出为写入本地文件系统、写入RDD、写入Redis；

所述步骤A1包括：将一颗卫星计算所需要的两个文件数据放在一行，并添加一个参数标识卫星名称，输入数据之间以空格或者其他字符隔开，RDD的每一行都表示一颗卫星的轨道计算输入。

2.根据权利要求1所述的基于Spark的成像卫星任务预处理并行化方法，其特征在于，所述步骤A2包括：RDD分区策略，所述RDD分区策略是计算多颗卫星的轨道预报，将几颗卫星的计算任务放在同一个分区，外部程序能接受多个计算输入，并在所述程序中依次执行得到最终的计算结果。

3.根据权利要求1所述的基于Spark的成像卫星任务预处理并行化方法，其特征在于，所述步骤A3包括：每颗卫星在每个计算时间段的轨道预报计算都会得到一个输出结果，通过轨道标识参数对输出结果进行区分，轨道预报输出结果的存储方式在外部程序的代码中进行指定，存储方式有三种：

a)写入本地文件系统；

b)写入RDD；

c)写入Redis内存。

4.根据权利要求1所述的基于Spark的成像卫星任务预处理并行化方法，其特征在于，所述步骤B包括：

B1、初始化Spark集群环境，配置集群参数；

B2、从本地文件系统或者Redis中读取输入数据集生成RDD；

B3、通过pipe()方法将RDD中的元素传递给轨道预报这个外部程序；

B4、调用RDD的行动操作触发实际计算。

Images