CN107479984A - 基于消息的分布式空间数据处理系统 - Google Patents

Abstract

本申请提供了一种基于消息的分布式空间数据处理系统，包括任务管理模块、任务执行模块和消息中间件模块，其中：所述任务管理模块用于定义处理空间数据的任务，并将任务消息发送至消息中间件模块；所述任务执行模块用于从消息中间件模块获取任务消息，根据任务消息对所述空间数据进行相应处理，并将任务状态消息反馈至消息中间件模块；所述消息中间件模块用于将任务管理模块发送的任务消息按预设消息转发规则转发至对应的任务执行模块，以及根据任务执行模块反馈的任务状态消息对所述任务消息进行相应处理。

Description

基于消息的分布式空间数据处理系统

技术领域

本申请涉及空间数据处理技术领域，特别地，涉及一种基于消息的分布式空间数据处理系统。

背景技术

在地理信息系统（GIS，Geographic Information System）应用项目实施过程中，经常涉及大量与地理空间数据的管理、处理和服务有关的工作。传统的解决方案是采用桌面GIS软件，或/和采用组件GIS、服务式GIS开发自动化工具来实现数据的处理和发布。

对于地理空间数据的管理、处理、发布等工作，现有技术一般是采用桌面GIS软件，或/和采用组件GIS、服务式GIS开发自动化工具来实现数据的处理和发布。但这种方法只能解决处理任务的批量运行，任务类型单一，且无法应对空间数据量不断增长带来的处理压力。

随着大数据应用的实施和推广，如何高效、自动化地处理地理空间大数据，保障GIS数据的时效性，充分利用GIS数据的价值，保证各级部门的数据与业务的协同，成为GIS应用领域的技术人员迫切需要解决的技术问题。

发明内容

本申请提供一种基于消息的分布式空间数据处理系统，用于解决现有技术无法应对因空间数据量不断增长带来的处理压力问题。

本申请公开的一种基于消息的分布式空间数据处理系统，包括任务管理模块、任务执行模块和消息中间件模块，其中：所述任务管理模块用于定义处理空间数据的任务，并将任务消息发送至消息中间件模块；所述任务执行模块用于从消息中间件模块获取任务消息，根据任务消息对所述空间数据进行相应处理，并将任务状态消息反馈至消息中间件模块；所述消息中间件模块用于将任务管理模块发送的任务消息按预设消息转发规则转发至对应的任务执行模块，以及根据任务执行模块反馈的任务状态消息对所述任务消息进行相应处理。

优选的，还包括：资源虚拟化模块，用于对物理计算资源进行资源池化，根据需要定义虚拟机实例，确定每个虚拟机的硬件配置，构建包括有多台虚拟机的分布式系统；以及，将任务管理模块、任务执行模块和消息中间件模块配置到相应虚拟主机中。

优选的，配置任务执行模块的虚拟主机包括多个。

优选的，所述任务消息存储在消息队列中，所述预设消息转发规则为预先设置的任务执行模块与消息队列的订阅关系；所述将任务管理模块发送的任务消息按预设消息转发规则转发至对应的任务执行模块，具体为：将所述任务执行模块发送的任务消息分发到消息队列；所述任务执行模块根据所述订阅关系从相应消息队列中读取任务消息。

优选的，所述任务状态消息为任务执行完成，所述根据任务执行模块反馈的任务状态消息对所述任务消息进行相应处理，具体为：将所述任务消息从消息队列中删除。

优选的，所述任务管理模块还用于判断所述空间数据是否发生了变化，若是，则将处理所述空间数据的任务进行更新，并将更新后的任务消息发送至消息中间件模块。

优选的，根据任务消息对所述空间数据进行相应处理，具体为：通过执行基于地理信息开放脚本引擎的处理空间数据的脚本，实现对所述空间数据的处理。

优选的，所述消息队列的任务消息分发和读取过程基于高级消息队列协议实现。

与现有技术相比，本申请具有以下优点：

本申请优选实施例通过利用消息中间件在任务管理模块和任务执行模块之间传递任务消息及其执行结果的手段，可实现各个逻辑组件的解耦，保证各功能模块相互独立，并可以根据需要进行横向扩展形成分布式集群，从而可有效解决现有技术无法应对地理空间数据的爆发式增长带来的海量数据（TB级、PB级）处理，GIS服务提供商只能通过配置更多的服务器资源来支持日益增长的访问压力，导致的系统建设和维护成本直线提高的问题。

在进一步的优选实施例中，通过资源虚拟化模块可以对物理计算资源进行资源池化，并根据需要定义虚拟机实例，确定每个虚拟机的硬件配置，然后将任务管理模块、消息中间件模块和任务执行模块配置到相应虚拟主机中，其中配置任务执行模块的虚拟机可以根据需要动态增加，从而实现计算资源的横向扩展，降低系统建设和维护成本。另外，本申请通过上述虚拟化技术手段，还可以解决计算资源的利用效率不会随着资源的扩展而线性增加，资源需求也不是长期和持续的过程，供大于求或供过于求的情况经常发生的问题。

附图说明

附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本申请基于消息的分布式空间数据处理系统一实施例的结构示意图；

图2为本申请基于消息的分布式空间数据处理系统具体实施例架构示意图；

图3为本申请基于消息的分布式空间数据处理系统具体实施例中JobMaster的实现原理图；

图4为本申请基于消息的分布式空间数据处理系统具体实施例中JobWorker的实现原理图。

具体实施方式

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

在本申请的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。“多个”的含义是两个或两个以上，除非另有明确具体的限定。术语“包括”、“包含”及类似术语应该被理解为是开放性的术语，即“包括/包含但不限于”。术语“基于”是“至少部分地基于”。术语“一实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”。其他术语的相关定义将在下文描述中给出。

参照图1，示出了本申请基于消息的分布式空间数据处理系统一实施例的结构框图，包括任务管理模块11、任务执行模块13和消息中间件模块12，其中：

任务管理模块11：用于定义处理空间数据的任务，并将任务消息发送至消息中间件模块12。

进一步的，为解决数据文件删除、数据文件追加等空间数据发生变化后的数据处理问题，本申请任务管理模块11还设置有任务更新功能，具体包括：判断所述空间数据是否发生了变化，若是，则将处理所述空间数据的任务进行更新，并将更新后的任务消息发送至消息中间件模块。

任务执行模块13：用于从消息中间件模块12获取任务消息，根据任务消息对所述空间数据进行相应处理，并将任务状态消息反馈至消息中间件模块12。

消息中间件模块12：用于将任务管理模块11发送的任务消息按预设消息转发规则转发至对应的任务执行模块13，以及根据任务执行模块13反馈的任务状态消息对所述任务消息进行相应处理。

对于任务消息被任务执行模块13接收后，如果在任务没有处理完之前，出现错误异常退出等情况，可能会导致该任务消息丢失而不能正常完成数据处理的问题。本申请采用上述根据应答消息（Ack）进行后续处理的方式（即对是否存在未应答消息No-Ack进行确认的方式），可有效避免上述技术问题。

在GIS数据处理的具体实施过程中，计算资源的利用效率不会随着资源的扩展而线性增加，资源需求也不是长期和持续的过程，供大于求或供过于求的情况经常发生。为解决上述问题，所述系统还设置有资源虚拟化模块10，用于对物理计算资源进行资源池化，根据需要定义虚拟机实例，确定每个虚拟机的硬件配置，构建包括有多台虚拟机的分布式系统；以及，将任务管理模块11、任务执行模块13和消息中间件模块12配置到相应虚拟主机中。

具体实施时，配置任务执行模块13的虚拟主机包括多个，通过对配置有任务执行模块13的虚拟主机进行相关设置，可以使该虚拟主机在启动后自动执行任务程序，即：基于消息中间件模块12订阅任务消息，主动领取任务并根据任务消息开展空间数据处理工作。

在进一步的优选实施例中，上述任务消息可存储在消息队列中，其中的预设消息转发规则为预先设置的任务执行模块13与消息队列的订阅关系；上述将任务管理模块发送的任务消息按预设消息转发规则转发至对应的任务执行模块，具体为：任务执行模块11将任务消息通过消息中间件模块12提供的消息通道分发到消息队列；任务执行模块13根据所述订阅关系从相应消息队列中读取任务消息。

相应的，上述消息队列的任务消息分发和读取过程可基于高级消息队列协议（AMQP，Advanced Message Queue Protocol）实现。

另外，上述的任务状态消息包括任务将要执行、任务正在执行、任务执行完成和错误等，当任务执行模块13反馈的任务状态消息为任务执行完成时，上述根据任务执行模块反馈的任务状态消息对所述任务消息进行相应处理，具体为：将该任务消息从消息队列中删除。

具体实施时，上述根据任务消息对所述空间数据进行相应处理，具体可以为：通过执行基于地理信息开放脚本引擎（GIScript，Geospatial Information Open Script）的处理空间数据的脚本，实现对所述空间数据的处理。

GIScript是一种研发面向时空大数据的地理信息开放脚本引擎（GeospatialInformation Open Script）技术，能够兼容各个操作系统（如Windows、Linux等）中通用环境下地理信息分析处理方式，满足通用框架下移动计算处理需求，突破开放式脚本引擎研发模式，采用敏捷开发的开放式脚本语言研发机制，从而可解决地理信息开源技术与IT集成问题，促进地理信息技术更好的与IT主流技术的融合应用。GIScript的运行模式主要分为单机运行和分布式运行两套模式，其中：（1）单机运行模式的GIScript主要适用于简单的数据处理工作，面向地理信息大数据处理应用，数据处理已全面转向分布式并行环境，所以GIScript单机运行模式主要用于分布式任务编写、调试与测试验证。（2）分布式运行模式，针对气象、国土等地理信息应用领域中高性能、动态灵活的业务需求，GIScript可以发挥其优秀的跨平台兼容，云端通用、灵活开放优势，通过将GIScript调试器中编写验证的执行代码通过企业服务总线（ESB，Enterprise Service Bus）分发到自动化任务调度执行节点和跨平台（Linux、Windows、Unix等）工作节点上，实现时空大数据分布式处理服务编排、工作流执行与监控。

具体实施时，为保证空间数据处理具有高性能、并具有跨平台能力，GIScript底层可以采用标准C++开发，然后再基于Python封装。此外，为支持多种处理方法，任务执行模块13在内部实现空间数据处理的逻辑可以基于GIScript进行任意扩展。

本申请通过上述手段，使GIS数据处理系统具有可扩展性、高性能跨平台、自动化等优点，其中：

可扩展性体现在系统架构的设计实现了各个逻辑组件的解耦，保证任务管理模块（JobMaster）、消息中间件模块、任务执行模块（JobWorker）相互独立，可以根据需要进行横向扩展形成分布式集群。

高性能跨平台体现在所有技术都可以基于Python开发实现，并继承该技术的跨平台能力；同时JobWorker内部集成的GIScript底层可以采用C++开发，然后再基于Python封装，在保证空间数据处理计算高性能的基础上，也同样具有跨平台能力。此外，JobWorker内部实现空间数据处理的逻辑可以基于GIScript进行任意扩展，进而支持多种处理方法。

自动化体现在通过设置部署有JobWorker的虚拟主机，使该虚拟主机在启动后可立刻自动执行任务程序。具体的，JobWorker基于消息中间件订阅消息队列，并主动领取任务开展工作，使GIS数据能够依次得到处理直到消息队列没有任务消息为止。另外在增加的新的数据文件之后，JobMaster会立刻自动生成新的任务消息进行发布，开启新的处理过程。

参照图2，示出了本申请基于消息的分布式空间数据处理系统具体实施例架构示意图，其实现方法具体包括：

1）计算资源虚拟化

利用OpenStack云计算管理平台，基于内核的虚拟机技术（KVM，Kernel-based VirtualMachine）将物理资源进行资源池化。

基于OpenStack自定义配置云主机类型，安装操作系统及相关软件。

根据需求定义虚拟主机实例，确定虚拟的硬件配置。

在虚拟主机中安装配置数据库、JobMasterControl、JobMaster和JobWorker等。

2）消息中间件模块设计与实现

消息中间件的主要作用是在JobMaster和JobWorker之间传递任务消息，同时保证消息的持久性。消息中间件模块发布消息服务时，通过配置管理控制消息订阅、转发规则，管理消息队列，可对消息以点对点、发布/订阅等方式进行转发，具体说明如下：

消息分发：JobMaster定义的任务通过消息中间件到消息队列。

消息订阅：JobWorker订阅指定的消息队列，从消息队列中获取任务消息。可以设置消息确认，实现长时间的执行任务功能，使JobWorker可以获得所需的任务数据。JobWorker可以接受并且分派不同类型的任务数据。

消息持久：任务消息被JobWorker接收后，如果在任务没有处理完之前，出现错误异常退出，此时为保证这条任务消息不丢失，本专利系统可以采用了No-Ack的方式进行确认。即，当任务消息被JobWorker接收，并完成处理后，JobWorker会发送Ack消息，告知消息中间件消息已被接收并处理完毕可以安全的删除这条消息。

具体实施时，可采用RabbitMQ的消息分发及确认机制，保障消息的持久。

3）JobMaster设计与实现

JobMaster的主要作用是对任务进行管理，包括任务创建、任务分发、任务更新和任务确认；同时，将任务消息发送给消息中间件模块。具体说明如下：

任务创建：动态加载运行与任务输入有关的程序，实现对接不同空间数据，并生成任务数据。

任务分发：定义独立的消息通道，将任务消息发布到消息中间件模块。

任务更新：当空间数据发生变化，如进行了数据文件的删除、追加等，自动实现对任务数据的更新，并对新任务消息进行分发。

任务确认：任务处理完成后接收确认消息，再接收新的任务消息继续工作。

具体实施时，JobMaster占用一个虚拟主机资源，可采用如图3所示的方式设计实现，其中：JobMaster负责调创建维护消息队列和链接，调用xxx_JobInput获取任务信息并发布任务消息。JobInput基类，实现处理数据到任务消息转换的逻辑，最终的成功是生成ToDo中的job数据。xxx_JobInput继承JobInput的getfLstTodo方法，重写initialToDo、updateJob方法。

4）JobWorker设计与实现

JobWorker的主要作用是执行任务，包括任务接收、任务执行、任务状态确认；同时，将任务状态消息发送给消息中间件模块。具体说明如下：

任务接收：接收来自消息中间件模块的任务消息，出发任务执行程序。

任务执行：根据接收的任务消息内容，自动调用GIScript，对空间数据进行高效、并行化处理。

任务状态确认：返回任务执行的状态，包括将要执行、正在执行、已经执行、错误等。

具体实施时，JobWorker通过配置能够在系统启动后自动运行，可根据需求动态启动创建多台虚拟主机，实现系统模块的横向扩展。可采用如图4所示的方式设计实现，其中：JobWorker实现Worker主机（或虚拟主机）自动启动运行初始化的工作，包括链接消息中间件模块获取消息，动态加载JobApp脚本等功能操作。JobApp基类，实现任务处理的基本方法，主要负责基于GIScript开发用于数据处理的脚本，基类不用实现doJob方法；xxx_JobApp继承JobApp的方法，重写doJob方法；文件名可以任意定义。

需要说明的是，上述装置实施例属于优选实施例，所涉及的单元和模块并不一定是本申请所必须的。本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

以上对本申请所提供的一种基于消息的分布式空间数据处理系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (8)

1.一种基于消息的分布式空间数据处理系统，其特征在于，包括任务管理模块、任务执行模块和消息中间件模块，其中：

所述任务管理模块用于定义处理空间数据的任务，并将任务消息发送至消息中间件模块；

所述任务执行模块用于从消息中间件模块获取任务消息，根据任务消息对所述空间数据进行相应处理，并将任务状态消息反馈至消息中间件模块；

所述消息中间件模块用于将任务管理模块发送的任务消息按预设消息转发规则转发至对应的任务执行模块，以及根据任务执行模块反馈的任务状态消息对所述任务消息进行相应处理。

2.根据权利要求1所述的系统，其特征在于，还包括：资源虚拟化模块，用于对物理计算资源进行资源池化，根据需要定义虚拟机实例，确定每个虚拟机的硬件配置，构建包括有多台虚拟机的分布式系统；以及，将任务管理模块、任务执行模块和消息中间件模块配置到相应虚拟主机中。

3.根据权利要求2所述的系统，其特征在于，配置任务执行模块的虚拟主机包括多个。

4.根据权利要求3所述的系统，其特征在于，所述任务消息存储在消息队列中，所述预设消息转发规则为预先设置的任务执行模块与消息队列的订阅关系；所述将任务管理模块发送的任务消息按预设消息转发规则转发至对应的任务执行模块，具体为：

将所述任务执行模块发送的任务消息分发到消息队列；

所述任务执行模块根据所述订阅关系从相应消息队列中读取任务消息。

5.根据权利要求4所述的系统，其特征在于，所述任务状态消息为任务执行完成，所述根据任务执行模块反馈的任务状态消息对所述任务消息进行相应处理，具体为：将所述任务消息从消息队列中删除。

6.根据权利要求1所述的系统，其特征在于，所述任务管理模块还用于判断所述空间数据是否发生了变化，若是，则将处理所述空间数据的任务进行更新，并将更新后的任务消息发送至消息中间件模块。

7.根据权利要求1所述的系统，其特征在于，根据任务消息对所述空间数据进行相应处理，具体为：通过执行基于地理信息开放脚本引擎的处理空间数据的脚本，实现对所述空间数据的处理。

8.根据权利要求4所述的系统，其特征在于，所述消息队列的任务消息分发和读取过程基于高级消息队列协议实现。