海量卫星遥感数据实时存储与交换技术设计与实现

周正　钟志农　李军　伍江江

摘要：随着人类对地观测卫星系统的发展，卫星遥感数据量爆炸性增长。海量的遥感数据对当今存储系统存储容量、数据可用性以及I/O性能等方面提出了越来越高的要求。针对需要持久化存储与高速交换的数据，该文设计并实现了一种基于共享文件系统和文件编目消息推送的海量卫星数据实时存储与交换方法。实验测试表明，该方法针对海量卫星遥感数据的实时存储与交换取得了很好的效果。

关键词：海量；遥感数据；消息推送；实时存储；实时存储与交换

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2017）18-0009-05

1绪论

随着人类对地卫星观测系统的发展，遥感数据逐步呈现多源、多尺度、多时相、全球覆盖和高分辨率特征，数据量呈爆炸性增长，数据存储规模达到TB级甚至PB级，IDC预计，到2020年全球数据量将达到40ZB。如何更加有序、更加高效地存储与管理海量遥感数据，实现遥感信息的快速共享与分发，已经成为空间信息科学领域研究部门、业务应用部门和相关机构重点关心的问题。

同时，气象灾害实时监测预报、天基遥感信息实时侦察监视、军事情报数据实时挖掘等业务应用对海量卫星遥感数据的实时分析和处理提出了更高的要求。上述实时分析处理业务在实现对海量卫星数据高效存储的同时，更需要在多个处理节点间实现海量卫星数据的实时共享和更新。针对此问题，不但需要利用存储系统在存储容量、数据可用性以及I/O性能等方面提供支持，更亟需对海量卫星遥感数据高速实时存储和数据交换机制展开研究。因此，针对需要持久化存储与高速交换的数据，本文拟基于共享文件系统和消息中间件，研究海量卫星数据实时存储与交换机制。

1.1问题背景及分析

在实际业务应用中，卫星7×24小时不断向地面下传数据，地面数据处理系统也必须7×24小时处于实时工作状态。地面数据处理系统接收卫星下传数据后，经过一系列预处理与分析，将接收到的流式数据切分成若干不同大小的小文件，以方便进行数据分析和处理。为了实现对海量、高速、持续卫星数据流的存储管理，并保证卫星数据处理关键业务可重现，以及数据可查、可审计，需要对海量卫星数据进行实时存储。

同时，在卫星遥感数据实时处理业务流程中，当数据生成节点（包括Linux节点和Windows节点）将各种卫星数据高速存入共享文件系统之后，其他数据处理节点（Linux节点和Win-dows节点）和前端业务综合显示节点（Windows工作站）往往需要求对最新写入的数据文件进行实时查询和数据读取操作。对于跨平台进程间的数据传输，直接通过传统的TCP/IP方式进行传输显然由于应用的特殊性以及带宽的限制不能达到很好的效果。所以要求设计一套服务，能够满足跨平台的文件交换，能够进行多类型数据的分发和交换，满足数据处理低延迟要求。海量卫星数据实时存储与交换流程如图1所示。

1.2服务具备特点

海量卫星实时数据存储服务是所有需要进行数据高速写人的实时处理业务应用的基础支撑，为此实时数据存储服务需要具备以下特点：

1）海量数据存储管理能力。随着卫星平台、卫星载荷能力的增长，地面数据分析处理系统每日需要处理的数据量日益庞大，数据量呈TR级增长，如何高效合理的组织如此大量的数据并能为后期提供可靠的数据查询服务，这对数据存储管理能力提出了很高的要求。

2）7×24小时持续运行能力。卫星遥感数据流7×24小时无间断下传，这要求数据实时存储服务需要时刻处于高负荷工作状态；同时，需要面对存储过程中可能出现的数据量突发波峰的状况。这对实时数据存储服务的可用性提出了非常高的要求，需要具备7×24小时不间断、高可靠运行的能力。

3）数据存储低延迟要求。数据实时存储服务需要为数据分析和处理业务提供商性能的数据写人和读取服务，以满足数据写入的低延迟要求。

4）海量小文件快速写入能力。地面数据分析处理系统生成的各级数据产品中包含海量小文件（大小从几百KB至几兆字节不等），而典型的共享文件系统在应对海量小文件持续写人方面性能低下，所以需要针对海量小文件的持续写人进行优化设计。

5）快速的消息分发能力。数据实时存储与交换系统需要实时的在数据存储端与数据读取端进行数据交换，并且有一定的时延要求。即数据写入节点在完成数据写入之后，需要将数据的文件编目信息和写入完成标志及时通知数据读取节点；同时，数据文件编目信息往往需要在多个数据读取节点之间进行共享，以保证数据的一致性，所以需要使用具备发布/订阅机制的消息中间件实现数据文件编目信息的实时共享和更新。

2海量卫星遥感数据实时存储与交换设计

2.1数据存储模式设计

1）数据存储模式选择

存储系统的存储模式影响着整个海量数据存储系统的性能，为了提供高性能的数据存储能力，应该考虑选择良好的海量数据存储模式。适合海量数据的理想存储模式应该能够提供高性能、可伸缩、跨平台、安全的数据共享能力。为此选择了网络附加存储（NAS）的网络附加存储产品作为目标存储容器。

2）数据库存储选择

数据库管理系統（DBMS）是数据实时存储系统的元数据管理的核心组成。Oracle在数据高性能存储检索领域应用广泛，海量数据实时存储的元数据管理采用Oracle数据库实现。

3）数据写入方式设计

分布式文件系统对于大文件的数据访问操作有较好的支持，能够提供GB级的数据写人带宽和数据读取带宽；但是对于海量小文件的读写支持相对受限。因此，针对海量小文件存储，本文通过多线程、多任务以及分布式文件系统的高带宽来提升海量小文件的写入速度。

4）数据实时存储模块实现形态设计

API（Application Programming Interface，应用程序编程接口）是一类预先定义的函数，可以为上层应用程序提供标准的调用方法和接口，上层应用程序以透明方式对API进行访问。因此，数据实时存储实现形态拟采用API方式进行实现，从而满足地面数据实时分析与处理业务对数据存储的时效性要求。endprint

2.2海量卫星遥感数据实时存储及消息推送机制方案设计

海量卫星数据实时存储与交换主要包含两个部分。即数据实时存储与数据实时交换。

对于实时存储部分。应用的压力在于海量卫星数据的不间断下传，导致数据量不断地增长。如何快速、高效、低延迟的将海量卫星数据存入存储媒介是要解决的首要问题。分布式文件系统由于其可扩展性、高可用性、多接口协议、安全等各种优点被纳入考量的范围。同时由于其多操作系统访问的无关性，使得可以利用这个特性来实现不同操作系统之间的数据共享。

对于数据的交换部分。分布式文件系统为系统提供了一个海量数据存储容器。但如此大量的数据的管理势必成为一个必须解决的问题，如何快速、安全、高效的将用户需要的数据从分布式文件系统这个数据池中打捞出来。是我们第二个需要解决的问题。关系型数据库通常以行列的方式进行数据的组织，并配备有高效的查询算法，可以对某个字段进行快速的范围查询。海量卫星数据实时处理过程中需要进行大量的数据查询，关系型数据库已经能够满足大部分的范围查询工作。如何实时的通知读取应用端进行最新数据的读取，消息分发服务被用来处理通知的分发工作。数据实时存储与交换的体系结构如图1所示：实时数据写服务器调用SJCC.so（数据存储动态链接库进行文件的快速写入。当文件和数据编目分别写入分布式文件系统与数据库后，实时数据写服务器将卫星数据产品文件编目信息以自定义消息格式发布到消息分发服务；实时数据读取服务器，即消息订阅端从消息分发服务接收已订阅的卫星数据产品文件编目信息。实时数据读取服务器解析消息格式并获取最新的卫星数据产品文件路径，从分布式文件系统中读取最新文件数据。

3海量卫星遥感数据实时存储与交换关键技术

3.1基于消息中间件的卫星数据编目传递方式

数据实时存储服务器也即消息分发客户端作为消息生产者的存在进行消息的发布。在消息分发客户端中定义了消息格式为AAAAdata-typemessage-lengthMESSAGEBBBB。其中，开始的AAAA与结束的BBBB作为统一格式；data-type表示了消息的类型，即当前消息属于哪种消息，以方便订阅端进行数据分类；MESSAGE作为消息的载体用来传输真正有用的数据，实时存储服务将文件的路径作为消息（MESSAGE）发布到消息分发服务。前端显示工作站根据data-type订阅相应数据类型，并从MESSAGE中获取最新写入分布式文件系统中文件的路径，从而读取到最新的文件，完成一轮实时交换。由于省略了文件的直接传输发送，而变成只是进行了类似于元数据的传输，数据的实时交换效率得到了极大提高。基于消息中间件的卫星数据编目推送服务，如图2所示。

3.2基于消息中间件的卫星数据编目推送流程

对于消息分发客户端，程序启动过程中会初始化所有相关资源。包括初始化連接环境，设置消息发布种类等。初始化成功后消息分发客户端将开始连接消息分发主服务。若连接成功，消息分发客户端程序进入服务就绪状态并等待新消息的发布。若连接失败，消息分发客户端将开始连接消息分发备服务。若连接成功，将由消息分发备服务提供消息分发功能。若连接仍然失败，在两台消息分发服务均未连接成功的情况下，消息分发客户端启动失败。

对于消息接收客户端，程序流程基本一致，程序启动过程中会初始化所有相关资源，包括初始化连接环境，设置消息发布种类等。初始化成功后消息接收客户端将开始连接消息分发主服务。若连接成功，程序进人服务就绪状态并等待新消息的发布。若连接失败，消息接收客户端将开始连接消息分发备服务。若连接成功，将由消息分发备服务提供消息分发功能。若仍然连接失败，在两台消息分发服务均未连接成功的情况下，消息接收客户端启动失败。基于消息中间件的卫星数据编目推送服务如图3所示。

3.3基于消息中间件的海量卫星遥感数据编目推送类设计

基于消息中间件的卫星编目推送主要包含消息分发客户端，以及消息接收客户端。消息分发客户端的主要任务是发布消息到消息分发服务，消息接收客户端的主要功能为订阅并接收来自消息分发服务的消息。下面将做详细说明。

1）消息分发客户端类详细设计

消息分发类主要功能为稳定、可靠、完整的发布消息到消息分发服务，设计的方法包括构造的方法（PublishCli-ent）主要功能为确定消息分发服务的网络地址，以及当前消息分发客户端将要发布的所有消息种类；单点故障切换方法（changeServer），由于消息分发服务采用主备用方式提供服务，当某一台消息分发服务器宕机时，将调用该方法进行服务器主备连接的切换，时刻保障服务的可用性；重启（re-start）对消息分发客户端进行重启操作；关闭方法（close）将关闭当前与消息分发服务端的连接；清理方法（cleanup）负责关闭清理所有与消息分发连接过程中申请的资源；消息发送方法（sendTextMessage）负责根据传递的参数（Iype）识别不同的数据类型，以此来发送对应的消息类型。初始化方法（initialize）负责资源的初始化工作；状态检查（stillAlive）负责检测当前与消息分发服务的连接是否处于正常连接状态，防止由于消息分发服务端意外宕机或服务关闭造成的连接失效，当检测到连接中断时，stillAlive方法将进行重连操作。详细类图如图4所示。2）消息接收客户端类的详细设计消息接收类（subscription）由于功能相对简单，主要负责订阅接收从消息分发服务传递过来的消息。其主要方法包括开始方法（start）负责初始化消息接收客户端，包括确定消息分发服务的网络地址、确定订阅的消息种类、消息接收模式选择等；关闭方法（close）负责断开与消息服务之间的连接；运行方法（run）为实际数据接收方法；消息接收显示（onMessage）负责显示的将消息呈现到屏幕。资源清理方法（cleanup）负责清理所有连接消息服务过程中使用的资源。详细类图如图5所示：endprint

4测试与分析

1）硬件环境

使用若干台挂载了分布式文件系统的高性能计算服务器作为测试主机，分布式文件存储使用华为Oceanstor5500，服务器配置如下：

CPU：Intel（R）Xeon（R）CPU E5-2670 0@2.60GHz×32

内存：64G

网卡：Intel Corporation 82599ES万兆网卡

2）软件环境

操作系统：Redhat Linux 6.5 64位

文件系统：华为Oceanstor5500分布式文件系統

31测试

数据实时存储与交换结构化数据时间延迟测试

本测试主要用于测试结构数据的实时存储与交换时间延迟。

测试方法：

在数据库中创建字段个数不小于20的表结构，其中字段类型为任意的数据库基础类型，测试程序TEST01通过随机数据方式向数据实时存储服务（SJCCFW）中进行结构化数据的写入，在调用数据写人前进行时刻记录t0。并通过消息分发服务（XXFFServer）进行消息的多客户端分发。消息接收客户端（XXJSClient）接收完数据进行消息的解析与处理并在处理完毕后发送处理完毕通知给测试程序TEST01，同时记录时刻t1。则结构化数据的实时存储与交换时间延迟t=tl-t0。调用时间间隔为1秒钟。总调用次数10000次。

将测试结果以图表的形式进行结果展示，如图6所示。其中图表的横坐标代表测试的延迟区间，单位为毫秒（ms），延迟总区间为0～1000毫秒，区间间隔50毫秒。纵坐标表示每个区间所占百分比，主纵坐标表示占百分比较大数据的，副坐标表示占百分比较小的数据。

数据实时存储与交换结构化数据时间延迟测试如图Ⅳ.1所示，从图中可以看出，对于结构化数据，数据实时存储与交换的交换延迟区间超过百分之99都处于0～50毫秒，另外的所有区间都落在100～150毫秒，测试结果很理想。

4）数据实时存储与交换非结构化数据时间延迟测试

测试方法：

准备大小为1MB的测试文件FILE进行非结构化数据测试，测试程序TEST02通过以FILE为模板的方式向数据实时存储服务（SJCCFW）中进行非结构化数据的写入，在调用数据写入前进行时刻记录t0。并通过消息分发服务（xXFFServer）进行消息的多客户端分发。消息接收客户端（xXJSClient）接收完数据进行消息的解析与处理并在处理完毕后发送处理完毕通知给测试程序TEST02，同时记录时刻t1。则非结构化数据的实时存储与交换时间延迟t=t1-t0。调用时间间隔为1秒钟。总调用次数10000次。

将测试结果以图表的形式进行结果展示，如图7所示。其中图表的横坐标代表测试的延迟区间，单位为毫秒（ms），延迟总区间为0～1000毫秒，区间间隔50毫秒。纵坐标表示每个区间所占百分比，主纵坐标表示占百分比较大数据的，副坐标表示占百分比较小的数据。

数据实时存储与交换结构化数据时间延迟测试如图7所示，从图中可以看出，对于非结构化数据，数据实时存储与交换的交换延迟区间超过百分之99都处于0～50毫秒，最大区间为200～250毫秒，但百分比占比很小，测试结果很理想。

5）数据实时存储与交换非结构化数据带编目数据时间延迟测试

在数据库中创建字段个数不小于20的表结构，其中字段类型为任意的数据库基础类型，准备大小为1MB的文件FILE作为非结构化数据测试文件，测试程序TEST03通过数据实时存储服务（SJCCFW）以随机方式向数据库中写入结构化数据，并以FILE为模板的方式向数据实时存储服务（SJCCFW）中进行非结构化数据的写入，在调用数据写入前进行时刻记录t0。并通过消息分发服务（XXFFServer）进行消息的多客户端分发。消息接收客户端（XXJSClient）接收完数据进行消息的解析与处理并在处理完毕后发送处理完毕通知给测试程序TEST02，同时记录时刻t1。则非结构化数据的实时存储与交换时间延迟t=t1-t0。调用时间间隔为1秒钟。总调用次数10000次。

将测试结果以图表的形式进行结果展示，如图8所示。其中图表的横坐标代表测试的延迟区间，单位为毫秒（ms），延迟总区间为0～1000毫秒，区间间隔50毫秒。纵坐标表示每个区间所占百分比，主纵坐标表示占百分比较大数据的，副坐标表示占百分比较小的数据。

数据实时存储与交换非结构化数据带编目时间延迟测试如图8所示，从图中可以看出，对于非结构化带编目数据，数据实时存储与交换的交换延迟区间超过百分之68.833都处于0～50毫秒，另外处于50～100毫秒的占比百分之30.944最大延迟区间处于300～350毫秒，即使同时写结构化数据与非结构化数据，结果依然很稳定。

4总结

本章通过对实际业务的具体分析，确定了海量实时存储与交换过程中可能遇到的一些问题，根据对问题的具体分析。设计并实现了一套基于共享文件系统与消息推送机制的数据实时存储与交换服务，通过对结构化数据、非结构化数据、非结构化数据带编目的测试实验，测试结果取得了令人满意的效果。endprint