本公开的实施例一般涉及数据处理技术领域，并且更具体地，涉及多源异构数据的接入集成装置及方法。
背景技术：
面向多灾种综合风险防范业务域，数据由两部分组成，一部分是本地数据库已有的支撑数据，一部分是需协调的跨行业多部门共享数据，需协调的共享数据，其数据类型，数据组织形式不仅相同。
由于多灾种综合风险防范业务域需求的特殊性，存在跨行业多部门的多源异构数据，数据整合工作量大，没有通用技术规范；而共享数据没有存储权限，数据共享实时性差。
面对跨行业多部门引接的多灾种海量异构数据及应用插件，平台端的数据接入与集成压力巨大。
技术实现要素：
根据本公开的实施例，提供了一种种多源异构数据的接入集成方案。
在本公开的第一方面，提供了一种多源异构数据的接入集成装置，所述装置包括服务端、消息中心和客户端，其中，所述服务端运行在多灾种综合风险防范平台的服务器上，用于产生及发送消息指令，接收所述客户端返回的执行结果并进行服务发布；所述客户端运行在与多源数据库连接的业务系统服务器上，用于接收及执行所述消息指令，并将执行结果返回到所述服务端；所述消息中心用于在所述服务端即所述客户端之间转发所述消息指令及执行结果。
在本公开的第二方面，提供了一种多源异构数据的接入集成装置的工作方法，所述方法包括服务端接收用户的接入请求；根据所述接入请求生成数据查询请求，发送给消息中心；所述消息中心将所述数据查询请求转发给对应的客户端；所述客户端接收并在数据库中执行所述数据查询请求；将查询结果发送给消息中心转发给服务端；服务端根据所述查询结果进行服务发布。
在本公开的第三方面，提供了一种电子设备。该电子设备包括：存储器和处理器，所述存储器上存储有计算机程序，所述处理器执行所述程序时实现如以上所述的方法。
在本公开的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如根据本公开的第一方面的方法。
应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。
附图说明
结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：
图1示出了能够在其中实现本公开的实施例的示例性运行环境的示意图；
图2示出了根据本公开的实施例的多源数据接入的示意图；
图3示出了根据本公开的实施例的多源数据接入的结构示意图；
图4示出了根据本公开的实施例的多源异构数据的接入集成方法的示意图；
图5示出了根据本公开的实施例的服务端根据查询结果进行服务发布的示意图；
图6示出了能够实施本公开的实施例的示例性电子设备的方框图。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例，都属于本公开保护的范围。
另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
图1示出了能够在其中实现本公开的实施例的示例性运行环境100的示意图。在运行环境100中包括服务端102、消息中心104和客户端106。
在一些实施例中，服务端102运行在多灾种综合风险防范平台的服务器上，负责消息指令的产生及发送；客户端106运行在与多源数据库连接的业务系统服务器上，负责消息指令的接收及执行，并将执行结果返回到服务端102进行服务发布；消息中心104负责消息指令及执行结果的转发。
在一些实施例中，服务端102包括数据源管理模块302、数据接口管理模块304、数据结果展示模块306，通过数据接口管理模块304与消息中心104交互。
在一些实施例中，不同的数据库，例如mysql、hbase、sqlserver、oracle，对应不同的客户端106。
在一些实施例中，如图2所示，跨行业多部门的共享多源数据，一部分具备可存储权限的数据(即网络爬取数据等)，通过数据整合处理、质量控制，进入本地数据库。一部分只读权限的数据，通过消息总线模式调取接入数据，在消息中心进行插件、接口管理，实现平台服务端对数据的统一调配与管理。其中，本地数据库存储的数据，可以直接发布服务，也可以通过消息总线模式，由消息中心104统一调配与管理。
在一些实施例中，如图3所示，按照多灾种综合风险防范大数据平台统一管理的要求，对新增数据和更新数据进行数据整理加工、数据入库，并以服务的形式进行地图服务配置及发布。
在一些实施例中，所述多灾种综合风险防范大数据平台涵盖基础地理数据、承灾体数据、致灾因子数据、孕灾环境数据、历史灾情数据、遥感影像数据以及各个行业共享数据等不同专业的多种数据，是一个“统一空间参考、统一数据标准、横向到边、纵向到底、联动更新”的数据体系。
在一些实施例中，所述数据整理加工如下：
基于预设的数据整理加工规范，包括数据整合、整理以及数据建库的规范，对更新数据和新接收数据进行数据加工，包括数据格式转换、标准化处理、坐标转换、统一数据组织方式、数据项补充、元数据采集及目录整理、数据质量检查等工作。其中，所述更新数据和新接收数据存储在过程数据库中。经过元数据采集及目录整理得到标准元数据文件。对每一步数据加工都要进行过程数据质量检查。
其中，所述预设的数据整理加工规范是通过以下方法得到的：
通过数据梳理，摸清数据基本情况和需求，形成数据管理与应用服务需求；
根据数据基本情况和需求，进行技术涉及，形成数据整理与加工技术要求，明确多灾种综合风险防范核心数据库建设的总体技术要求，包括明确每类数据的整理加工内容、方法、流程、步骤、技术要求、质检细则等，用于以指导数据后续整理加工、入库工作。
在一些实施例中，所述数据入库如下：
将满足入库要求的数据成果、元数据据导入核心数据库中，或以链接及服务集成的方式对已有数据库或服务加载到核心数据库中，经全面质量检查及运行测试无误后，在最终成果数据库上创建索引、建立数据字典。
在一些实施例中，将所述元数据入库到元数据中，将所述数据成果入库到成果数据库中。
在一些实施例中，所述地图服务配置如下：
通常情况下，矢量数据入库后为了便于使用，需要进行符号库制作、数据符号化、地图服务配置与发布；同时为了实现以地图服务的方式为国土资源各项管理工作提供数据支持，还需要进行地图服务的配置及发布。
在一些实施例中，所述数据库满足以下要求：
统一坐标系。数据库各类数据源采用的空间坐标系不统一，在建库前，需要确定统一坐标系，把各类数据进行坐标转换。
数据拼接。为满足的应用需求，对于各类空间数据，数据入库前必须按行政区划进行必要的拼接。
统一基础底图。根据应用需求，建议选择系列比例尺基础底图，基础底图为基础层的数据。在统一底图上进行数据叠加和集成。
统一数据存储环境。例如，空间数据统一采用postgresql geoserver管理模式，非空间数据统一采用postgresql存储管理。
数据库建模。根据应用需求，对各类数据库进行梳理，利用可视化建模工具，分别建立各类数据库的可视化要素模型，最终汇总成核心数据库建设模型。
数据入库。根据数据库建设模型，例如，在postgresql postgis环境中，建立数据库结构，导入各类数据。
数据存储策略。例如，采用postgresql分区技术，将大表及其索引通过分区(partitions)的形式分割为若干较小、可管理的小块，并且每一分区可进一步划分为更小的子分区(sub-partitions)。通过对表进行分区，提高数据访问和获取速度，改善数据库的性能。geoserver性能调整。建立合理空间索引和属性索引，提高数据查询效率。
在一些实施例中，在数据处理方面遵循以下技术要求：
1.数据库与文件命名
1)数据库与文件命名要求
为便于管理及统一数据访问，最终数据库的命名及中间整合数据库或文件的名称，需依据简单易用及统一规则的原则进行命名。
2)处理方法
采用手工修改或自动转换的方式。
2.数据分类组织
1)数据分类组织要求
依据数据中心数据逻辑架构，按照基础层、专业层和管理层进行数据逻辑分类，结合行政区、时间或图幅等维度，进行数据的组织与物理存储。
2)处理方法
采用手工分类或自动转换的方式。
3.数据格式
1)数据格式要求
类数据库中整合后采用如下格式：
矢量空间数据：采用postgisgeodatabase数据模型，数据存储最终采用postgis postgresql方式。
非空间数据：与相关要求和标准一致采用excel、xml格式或access格式(*.mdb)，最终数据通过映射由postgresql数据库管理。
2)数据格式处理方法
数据格式处理的主要方式是通过专用数据格式转换工具或软件系统，将原数据格式转换成符合要求的数据格式。
3)数据格式转换后数据要求
数据格式转换后数据满足：空间实体无丢失；空间实体的几何精度符合要求；空间实体属性内容无缺失；不改变实体之间、实体与属性之间关系。
4.数学基础
数学基础要求
数据库成果采用统一的大地基准、高程基准、坐标单位。通过专用数据坐标转换工具或软件系统，将原数据坐标转换成符合要求的数据坐标。
5.要素分层
1)要素分层要求
数据要素分层应满足相应的数据库标准中必选图层与可选图层的总集合要求，可选图层中要素内容允许为空；要素类命名、要素类型及编码应与相应的数据库标准要求一致。
2)要素分层处理方法
根据数据库标准采用手工修改或自动转换的方式进行要素分层、编码、命名等规范化处理。
6.属性表达
1)属性表达要求
属性结构即字段代码、字段名称、字段类型、长度、小数位，应与相应数据库标准要求一致。属性表中的值域应符合相应数据库标准要求。数据值满足逻辑正确性要求即可，不进行数据准确度的核实，主要为：
必填字段不能为空，唯一值字段不能有重复值；
所填属性值不能超出值域范围：编码类字段值要在标准要求的编码范围内；数值字段值要满足数字的上下限要求；属性值中不应存在非法字符。
2)属性表达处理方法
对不符合属性结构及属性值表达要求的数据，采用手工修改或自动转换的方式进行补充修改。
7.实体对象
1)实体对象要求
实体对象拓扑关系一致，不存在悬结点、未闭合多边形、多边形覆盖、线自相交、面自相交等问题。
2)处理方法
使用专门的数据处理软件对影响数据表达和入库的问题如悬结点、自相交等问题进行处理。对其他不影响数据入库的问题只记录，不进行处理。
在一些实施例中，所述消息指令为json格式，由消息信封、消息体、返回消息体三部分内容组成。其结构如下：
所述消息信封包含四个字段：
fromsessionid：消息的发送方；
tosessionid：消息的接收方；
type：消息类型(接口/sql_select)；
data：消息体，定义客户端要执行的指令。
所述消息体是具体的消息指令，定义了客户端该如何执行消息，当服务器向客户端发送消息时，其结构如下：
appinterfacebean：指令结构定义，其结构如下：
code：指令代码。
interfacetype：数据类型。
interfacedata：接口数据(如一条查询)。
inputdata：输入参数，用于定义数据的输入参数，主要包括key，value键值对，且必须符合json编码规范。
所述返回消息体为当客户端106向服务器102返回的数据，为json格式的数据，其结构如下：
msg：成功/失败。查询成功或失败。
detail：具体的错误说明。
data：返回的数据。
为了实现各类信息数据的动态接入和访问，需要按照消息指令设计的内容，编写消息体，规范数据格式。方便用户统一、直观的掌握信息数据，并支持信息数据的进一步处理。
在一些实施例中，所述多灾种综合风险防范大数据平台可以提供各种插件，所述插件与所述多灾种综合风险防范大数据平台间的通信协议使用互联网标准http(s)协议，插件与数据请求方法使用"post"方法；数据格式采用json数据规范。其中，
所述插件在接入所述多灾种综合风险防范大数据平台时，提供插件的数据输入地址以及插件的返回结果演示数据，其中输入地址为url，在插件接入后所述多灾种综合风险防范大数据平台将向插件提供其对应的插件编码，该参数在返回插件计算结果时使用(对应于plugin_num参数)。
所述插件应向所述多灾种综合风险防范大数据平台提供所述插件的数据输入地址，该地址支持http的"post"方法进行请求，所述多灾种综合风险防范大数据平台将通过该地址提交产品的数据，输入产品相关数据，包括产品基本信息、产品要素信息、产品要素数据等。
所述插件在接收到输入数据后立即返回响应数据，响应数据中不包含计算结果，仅包括成功与否以及失败的具体原因。
所述插件在运行完成后根据所述多灾种综合风险防范大数据平台接收插件计算结果的地址，向所述多灾种综合风险防范大数据平台提交插件计算的结果。
图4示出了图1中所示的服务端102、消息中心104和客户端106之间的多源异构数据的接入集成方法400的示意图。
在框402，服务端102接收用户的接入请求；
在一些实施例中，所述接入请求可以是用户的灾害综合风险监测预警请求，也可以是用户的灾情评估请求，也可以是针对致灾因素的具体风险的防范请求。所述接入请求用于获取对应的多源数据，包括基础地理数据、承灾体数据、致灾因子数据、孕灾环境数据、历史灾情数据、遥感影像数据以及各个行业共享数据。
在框404，服务端102根据所述接入请求生成数据查询请求，发送给消息中心104；
所述数据查询请求为json格式的消息指令，具体格式如前所述，在此不再赘述。
在框406，消息中心104将所述数据查询请求转发给对应的客户端106；
在一些实施例中，数据查询请求对应于不同的数据库，例如mysql、hbase、sqlserver、oracle；不同的数据库，对应不同的客户端106。所述数据库包括本地数据库和多源数据库。其中，跨行业多部门的共享多源数据，一部分具备可存储权限的数据(即网络爬取数据等)，通过数据整合处理、质量控制，进入本地数据库。一部分只读权限的数据进入多源数据库，通过消息总线模式调取接入数据，在消息中心进行插件、接口管理，实现平台服务端对数据的统一调配与管理。其中，本地数据库存储的数据，可以直接发布服务，也可以通过消息总线模式，由消息中心104统一调配与管理。
在本实施例中，本地数据库和多源数据库中的数据由消息中心104统一调配和管理。
在框408，客户端106接收并在数据库中执行所述数据查询请求；
在框410，客户端106将查询结果发送给消息中心104；
在一些实施例中，所述查询结果为json格式的数据，具体格式如前所述，在此不再赘述。
在框412，消息中心104将所述查询结果转发给服务端104；
在框414，服务端104根据所述查询结果进行服务发布。
在一些实施例中，服务端104根据所述查询结果进行服务发布的方法500包括：
在框502，服务端104向所述接入请求对应的插件提交所述查询结果；
在一些实施例中，所述插件向所述多灾种综合风险防范大数据平台提供所述插件的数据输入地址，该地址支持http的"post"方法进行请求。服务端104通过该地址提交所述查询结果，即产品的数据，输入产品相关数据，包括产品基本信息、产品要素信息、产品要素数据等。
在框504，所述插件在接收到所述查询结果后，进行计算，在运行完成后将计算结果提交给服务端104。
在一些实施例中，所述插件根据所述多灾种综合风险防范大数据平台接收插件计算结果的地址，向所述多灾种综合风险防范大数据平台提交插件计算的结果。所述计算结果可以是根据所述数据得到的评估结果。所述插件能够通过自带算法模型很好的解决复杂的灾害问题。
在框506，服务端104接收所述插件的计算结果，并进行展示。
在一些实施例中，在数据量大、数据更新频率快，并且访问客户较多情况下，信息生成服务在分发数据过程中会出现信息堵塞现象，因此，采用服务负载均衡技术，实现持续可靠的实时数据服务能力。
采用多服务器部署的策略，即在多灾种综合风险防范平台的多台服务器上部署同一个信息生成服务，由多台服务器分担数据处理和分发压力，多服务器协同工作机制由信息监控服务实现，一台服务器的用户负载压力较大或出现异常时，信息监控服务自动将部分用户访问负载分配到其他服务器，从而保证了信息客户数据访问与交换的实时性和稳定性。
根据本公开的实施例，通过服务动态配置管理技术，并且使用满足实时性和安全性要求的数据传输总线(消息中心)代替http，最终实现多源信息的统一接入、管理和分发，解决多源异构数据难于存储和管理以及实时性差的问题。实现了以下技术效果：
可满足跨行业多部门不同用户需求，也具有较好的数据访问效率和系统稳定性；
很好的解决了共享数据权限只读的问题，数据共享实时性强；
实现了多源信息的统一接入和动态接入，以便用户及时有效地掌握各种信息，为减灾救灾提供数据支撑。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本公开并不受所描述的动作顺序的限制，因为依据本公开，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本公开所必须的。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，所述描述的方法的具体流程，可以参考前述装置实施例中的对应工作过程，在此不再赘述。
图6示出了可以用来实施本公开的实施例的电子设备600的示意性框图。设备600可以用于实现图1的消息系统104和消息到达率确定系统106中的至少一个。如图所示，设备600包括中央处理单元(cpu)601，其可以根据存储在只读存储器(rom)602中的计算机程序指令或者从存储单元608加载到随机访问存储器(ram)603中的计算机程序指令，来执行各种适当的动作和处理。在ram603中，还可以存储设备600操作所需的各种程序和数据。cpu601、rom602以及ram603通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。
设备600中的多个部件连接至i/o接口605，包括：输入单元606，例如键盘、鼠标等；输出单元607，例如各种类型的显示器、扬声器等；存储单元608，例如磁盘、光盘等；以及通信单元609，例如网卡、调制解调器、无线通信收发机等。通信单元609允许设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
处理单元601执行上文所描述的各个方法和处理，例如方法400、500。例如，在一些实施例中，方法400、500可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元608。在一些实施例中，计算机程序的部分或者全部可以经由rom602和/或通信单元609而被载入和/或安装到设备600上。当计算机程序加载到ram603并由cpu601执行时，可以执行上文描述的方法400、500的一个或多个步骤。备选地，在其他实施例中，cpu601可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法400、500。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)等等。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。
尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。
1.一种多源异构数据的接入集成装置，其特征在于，包括服务端、消息中心和客户端，其中，
所述服务端运行在多灾种综合风险防范平台的服务器上，用于产生及发送消息指令，接收所述客户端返回的执行结果并进行服务发布；
所述客户端运行在与多源数据库连接的业务系统服务器上，用于接收及执行所述消息指令，并将执行结果返回到所述服务端；
所述消息中心用于在所述服务端即所述客户端之间转发所述消息指令及执行结果。
2.根据权利要求1所述的装置，其特征在于，
所述消息指令为json格式，由消息信封、消息体、返回消息体三部分内容组成，所述消息体是具体的消息指令，定义了客户端该如何执行消息。
3.根据权利要求1所述的装置，其特征在于，所述执行结果为在所述多源数据库中执行所述消息指令查询得到的数据，还包括在本地数据库中执行所述消息指令查询得到的数据。
4.根据权利要求3所述的装置，其特征在于，所述数据是对基础地理数据、承灾体数据、致灾因子数据、孕灾环境数据、历史灾情数据、遥感影像数据进行数据整理加工、数据入库，并以服务的形式进行地图服务配置及发布得到的。
5.根据权利要求1所述的装置，其特征在于，所述服务器还用于，将所述执行结果发送给对应插件，接收所述插件返回的计算结果。
6.一种基于权利要求1-5任一所述的多源异构数据的接入集成装置的工作方法，其特征在于，包括：
服务端接收用户的接入请求；根据所述接入请求生成数据查询请求，发送给消息中心；
所述消息中心将所述数据查询请求转发给对应的客户端；
所述客户端接收并在数据库中执行所述数据查询请求；将查询结果发送给消息中心转发给服务端；
服务端根据所述查询结果进行服务发布。
7.根据权利要求6所述的方法，其特征在于，服务端根据所述查询结果进行服务发布包括：
向所述接入请求对应的插件提交所述查询结果；
接收所述插件根据所述查询结果进行计算的计算结果并进行展示。
8.根据权利要求6所述的方法，其特征在于，所述方法还包括：
对基础地理数据、承灾体数据、致灾因子数据、孕灾环境数据、历史灾情数据、遥感影像数据进行数据整理加工、数据入库，并以服务的形式进行地图服务配置及发布。
9.一种电子设备，包括存储器和处理器，所述存储器上存储有计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求6～8中任一项所述的方法。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求6～8中任一项所述的方法。
技术总结