一种数据汇聚系统和方法与流程

本发明涉及数据处理领域，更具体地，涉及一种数据汇聚系统和方法。

背景技术：

近些年来，我国的城镇化建设取得了卓越的成就。但之前的城镇化进程，在取得巨大成就的同时，也积累下来了很多不符合科学发展观要求、亟待处理和破解的突出问题。为解决城市发展难题，实现城市可持续发展，建设智慧城市已成为当今世界城市发展不可逆转的历史潮流。

智慧城市指的是运用信息和通信技术手段感测、分析、整合城市运行核心系统的各项关键信息，从而对包括民生、环保、公共安全、城市服务、工商业活动在内的各种需求做出智能响应。其实质是利用先进的信息技术，实现城市智慧式管理和运行，进而为城市中的人创造更美好的生活，促进城市的和谐、可持续成长。

信息的来源非常丰富且数据类型多样，存储和分析挖掘的数据量庞大，在对海量数据进行分析、挖掘，为城市的智慧化、精细化管理提供有效的决策依据之前，需要先将海量数据进行汇聚。

目前现有技术中对于数据的汇聚方法一般有两种方式，具体包括：

一是运用开源的ETL工具进行数据的汇总。ETL（Extract-Transform-Load），用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。虽然ETL基本上能够解决数据汇聚的问题，但是同时也存在着以下两个个方面的问题：

1、工具单一：有些ETL工具只能解决部分问题，但是有些数据汇聚的工作需要多个工具的合作，而且这些ETL工具往往规模都比较大，对于一些规模较小的汇聚工作，往往存在着资源浪费的问题。

2、专业性要求高，使用难度大：大多数ETL工具的使用都需要操作人员有一定的编程基础，对于大多数运维人员和运维企业来说，存在一定的使用难度，同时也增加了使用的成本。

二是通过相关人员编写相关的脚本，手动进行数据汇聚。此方式需要大量人工干预，使用方式不够灵活。

技术实现要素：

本发明为克服上述现有技术所述的至少一种缺陷（不足），提供一种使用方式简单且灵活方便的数据汇聚系统。

本发明还提供一种使用方式简单且灵活方便的数据汇聚方法。

为解决上述技术问题，本发明的技术方案如下：

一种数据汇聚系统，包括用于从子系统中获取数据的运行中心和用于生成和配置各个子系统的配置文件的客户端；

运行中心中设有中心数据库和用于根据配置文件和各个子系统进行通信以及接收、处理各个子系统的数据并将数据写入中心数据库的服务端；

运行中心与各个子系统之间建立统一的基于RESTful通信。

本发明的系统在运行中心与子系统之间建立统一的基于RESTful通信，实现了服务端与各个子系统之间的通信以及各个组件之间的通信，而且运用统一协议，使得系统可以自由地选择和更换数据的处理方式，使用者无需具备专业的编程知识即可使用系统，整个系统进行数据汇聚的方式变得简单灵活而且方便 。

上述方案中，服务端中设有用于等待各个子系统推送数据的等待推送进程、用于主动向子系统请求数据的主动请求进程和用于进程调度的调度系统。系统提供了子系统主动推送数据以及主动向子系统请求数据两种策略，给予了调度系统一定的自由度，使得数据的汇聚能够分时分段处理，避免同时处理大量数据，从而可以合理分配网络和技术资源。

上述方案中，服务端中还设有driver层。在建立统一的基于RESTful通信的基础上，系统抽象出driver层，底层可以根据实际需要使用不同的插件，实现底层实现和上层运用的隔离，系统搭建完成后可以根据具体的应用需求扩展或者更改相应的底层处理方式，增加了系统的灵活性。

一种数据汇聚方法，包括：

运行中心与各个子系统之间预先建立基于RESTful的通信；

客户端利用数据库表生成各个子系统的配置文件；

运行中心中的服务端根据配置文件按照调度策略获取各个子系统的数据来更新运行中心中的中心数据库。

本发明的方法在运行中心与子系统之间预先建立统一的基于RESTful通信，实现了服务端与各个子系统之间的通信以及各个组件之间的通信，而且运用统一协议，使得服务端可以自由选择调度策略来获取子系统的数据，使得数据的汇聚具备一定的灵活性，而且使用者无需具备专业的编程知识即可使用该方法。本发明的数据汇聚方法方式变得简单灵活而且方便 。

上述方案中，所述数据库表是从运行中心中生成并导出的；每个子系统对应一个或多个数据库表。

上述方案中，客户端生成配置文件时利用字符串匹配的方式从中心数据库中寻找和获取需要的数据，生成配置文件中的配置项。本发明的方法使用字符串匹配技术来根据中心数据库的相关表项和数据结构生成具体的配置文件，使用人员只需要根据自身需要填入一些基本的配置信息即可完成基本的配置工作，减少使用人员工作量的同时还降低了对使用人员的专业要求。

上述方案中，所述调度策略包括子系统主动推送策略；运行中心中的服务端根据配置文件按照子系统主动推送策略获取各个子系统的数据来更新运行中心中的中心数据库的具体步骤包括：

运行中心中的服务端启动等待进程；

服务端接收各个子系统有实时数据需要上送时根据服务端提供的端口向服务端推送的数据；

服务端解析推送的目的url，并搜索是否有与子系统相关的配置文件，配置文件中是否有相关的配置项，若均为是则将接收到的数据更新中心数据库。

子系统的类型各式各样，数据的产生都不尽相同，运行中心有时无法获知子系统一些的实时数据何时产生，因此设计子系统主动推送策略来让子系统将实时产生的数据推送到服务端，服务端负责接收更新数据即可，使得运行中心可以实现实时数据的汇聚。

上述方案中，服务端接收子系统的数据后还判断其自身是否处于主动推送模式，若是则将接收到的数据更新中心数据库。

上述方案中，所述调度策略包括定时策略；

运行中心中的服务端根据配置文件按照调度策略获取各个子系统的数据来更新运行中心中的中心数据库的具体步骤包括：

服务端启动，扫描每个配置文件，读取和保存相关的配置文件；

服务端根据配置文件添加请求数据的定时任务；

定时任务的出发点达到，服务端根据配置文件内容中的url，向子系统请求数据；

服务端接收子系统返回的数据更新数据库。

本发明的方法设置定时策略来对子系统的数据进行汇聚，使得子系统数据的汇聚可以分时分段处理，避免运行中心同时处理大量数据，使得运行中心可以合理分配网络和技术资源。

上述方案中，数据库更新的方式包括增量更新方式和全量更新方式，增量更新方式指的是服务端将接收到的数据添加到中心数据库中，全量更新方式指的是服务端将接收到的子系统数据替换中心数据库中子系统对应的数据。增量更新方式和全量更新方式可以根据数据库实际的需求确定，对于需要长时间保留的数据则可以采用增量更新方式进行数据更新，对于不需要保留的数据可以采用全量更新方式来更新数据库，既可以数据的实际需求来执行更新方式，还可以根据实际需求减少中心数据库的存储压力，提高中心数据库的利用率。

与现有技术相比，本发明技术方案的有益效果是：

本发明由于运用了统一协议，可以自由得更换数据的处理方式，也可以根据具体的项目需求扩展或者更改相关的底层处理方式，使得本发明具备灵活多变的处理方式。

本发明设计了灵活多变的调度策略，使得数据的汇聚能够分时分段处理，避免了同时处理大量数据，合理分配网络和技术资源。

本发明设计了灵活的数据更新方式，能够合理利用数据库，提高数据库的利用率。

本发明还提供了灵活而且方便的使用方式，利用字符串匹配技术，根据中心数据库的相关表项和数据结构生成具体的配置文件，使用人员只需要根据自身需要，填入一些基本的配置信息，就完成基本的配置工作。

附图说明

图1为本发明一种数据汇聚系统的架构图。

图2为本发明中导出的数据库表的示例图。

图3为本发明中生成的配置文件的配置示例图。

图4为本发明一种数据汇聚方法的流程图。

具体实施方式

附图仅用于示例性说明，不能理解为对本专利的限制；

为了更好说明本实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；

对于本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。

在本发明的描述中，需要理解的是，此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或隐含所指示的技术特征的数量。由此，限定的“第一”、“第二”的特征可以明示或隐含地包括一个或者更多个该特征。在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以是通过中间媒介间接连接，可以说两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明的具体含义。

下面结合附图和实施例对本发明的技术方案做进一步的说明。

实施例1

如图1所示，为本发明一种数据汇聚系统具体实施例的架构图。参见图1，本具体实施例一种数据汇聚系统具体包括用于从子系统中获取数据的运行中心和用于生成和配置各个子系统的配置文件的客户端101；

运行中心中设有中心数据库和用于根据配置文件和各个子系统进行通信以及接收、处理各个子系统的数据并将数据写入中心数据库的服务端102；

运行中心与各个子系统之间建立统一的基于RESTful通信。

其中，各个子系统是用于采集和处理数据的系统，如各个智慧城市中的用于采集和处理数据的系统。

客户端101生成的配置文件提供给服务端使用，其可以设置在运行中心中，其所利用的数据库表是从运行中心中生成并导出的，每个子系统对应一个或多个数据库表，每个子系统在数据中有一张或多张数据库表，数据库表通过表的前缀来区分不同的子系统。如图2所示，为导出的数据库表的一个实例。

客户端101生成配置文件时根据命令自动利用字符串匹配的方式从中心数据库中寻找和获取需要的数据，生成配置文件中的配置项，配置项可以为表名称、属性名称、是否为主键等。如图3所示，为客户端生成的配置文件的一个实例，客户端101生成配置文件后，使用人员只需根据自身需要填入一些基本的配置信息后就可以完成基本的配置工作。基本的配置信息包括但不限于调度disaptch、时间time、类型type和url，如图3所示。

运行中心用于对数据进行汇聚，服务端102是运行在运行中心的，其主要的功能是根据配置文件和各个子系统进行通信（包括请求数据和接收数据）、处理接收的数据将其写入到运行中心的中心数据库中。服务端102中的配置文件统一存储在子系统配置文件109中。

如图1所示，服务端101中设有用于等待各个子系统推送数据的等待推送进程103、用于主动向子系统请求数据的主动请求进程104和用于进程调度的调度系统104。

等待推送进程103调用时具体的工作模式是：

服务端102启动等待推送进程103；

各个子系统有实时数据需要上送时，根据服务端102提供的端口向服务端102推送的数据；

服务端102接收子系统推送的数据，然后解析推送的目的url，并搜索是否有与子系统相关的配置文件，配置文件中是否有相关的配置项，自身是否处于主动推送模式，若均为是则将接收到的数据更新中心数据库。其中主动推送模式的判断过程主要是服务端查看相应的配置来判断配置是否为主动推送模式，如果是对数据进行处理。

主动请求进程104被调用时的具体工作模式是：

服务端102启动，扫描每个配置文件，读取和保存相关的配置文件；

服务端102根据配置文件将主动请求进程104加入到不同的定时任务队列中；

达到某个定时任务的触发点服务端102开始执行相关任务；

服务端102根据读取的配置文件内容中的url，向子系统请求数据；

服务端102接收子系统返回的数据更新数据库。

其中，服务端102启动并扫描读取配置文件后，还会读取上次成功完成该主动请求进程104对应任务的时间戳，执行完时间戳对应时间之后的失败任务并及时更新数据。

其中，服务端102更新数据库的方式包括增量更新方式和全量更新方式，增量更新方式指的是服务端102将接收到的数据添加到中心数据库中，全量更新方式指的是服务端102将接收到的子系统数据替换中心数据库中子系统对应的数据。增量更新方式和全量更新方式可以根据数据库实际的需求确定，对于需要长时间保留的数据则可以采用增量更新方式进行数据更新，对于不需要保留的数据可以采用全量更新方式来更新数据库，既可以数据的实际需求来执行更新方式，还可以根据实际需求减少中心数据库的存储压力，提高中心数据库的利用率。

在具体实施过程中，运行中心与各个子系统之间建立统一的基于RESTful通信的具体操作过程为：编写相关的协议说明文档；运行中心按照该协议的格式向子系统传送请求，各个子系统按照要求回复相关内容。

在建立统一的基于RESTful通信的基础上，服务端102中抽象出driver层105。系统抽象出driver层105，底层可以根据实际需要使用不同的插件，如图1所示，如使用开源ETL工具106，设置其他扩展插件107，还可以根据中心数据库的需要内置全量增量导入系统108。driver层的设置实现底层实现和上层运用的隔离，系统搭建完成后可以根据具体的应用需求扩展或者更改相应的底层处理方式，增加了系统的灵活性。

实施例2

本发明在实施例1的基础上，还提供一种数据汇聚方法，所述数据汇聚方法可以基于实施例1的数据汇聚系统实现。参见图1，本具体实施例的数据汇聚方法的具体步骤包括：

S201.运行中心与各个子系统之间预先建立基于RESTful的通信；此步骤的目的在于建议统一的协议，实现服务端与各个子系统之间的通信以及各个组件之间的通信，基于该统一的协议，可以对数据处理的接口进行抽象设置driver层，使得底层可以根据实际需要使用不同的插件，以后可以根据具体的项目需求扩展或更改相关的底层处理方式。建立基于RESTful通信的具体实现方式是：

编写相关的协议说明文档；

运行中心按照该协议的格式向子系统传送请求，各个子系统按照要求回复相关内容。

S202.客户端利用数据库表生成各个子系统的配置文件；

S203.运行中心中的服务端根据配置文件按照调度策略获取各个子系统的数据来更新运行中心中的中心数据库。

在上述方法中，各个子系统是用于采集和处理数据的系统，如各个智慧城市中的用于采集和处理数据的系统。运行中心用于对数据进行汇聚，服务端是运行在运行中心的，其主要的功能是根据配置文件和各个子系统进行通信（包括请求数据和接收数据）、处理接收的数据将其写入到运行中心的中心数据库中。服务端中的配置文件统一存储在子系统配置文件中。

在步骤S202中，数据库表是从中心数据库中生成并导出的，每个子系统对应一个数据库表。客户端生成配置文件时利用字符串匹配的方式从中心数据库中寻找和获取需要的数据，生成配置文件中的配置项，配置项可以为表名称、属性名称、是否为主键等。配置文件生成后，使用人员只需要根据自身需要填入一些基本的配置信息即可完成基本的配置工作，减少使用人员工作量的同时还降低了对使用人员的专业要求。

在步骤S203中，调度策略包括但不限于子系统主动推送策略和定时策略；利用子系统主动推送策略进行数据汇聚的具体步骤是：

运行中心中的服务端启动等待进程；

服务端接收各个子系统有实时数据需要上送时根据服务端提供的端口向服务端推送的数据；

服务端解析推送的目的url，并搜索是否有与子系统相关的配置文件，配置文件中是否有相关的配置项，是否处于主动推送模式，若均为是则将接收到的数据更新中心数据库。

利用定时策略进行数据汇聚的具体步骤是：

服务端启动，扫描每个配置文件，读取和保存相关的配置文件；

服务端根据配置文件将数据请求任务加入到不同的定时任务队列中；

达到某个定时任务的触发点服务端开始执行相关任务；

服务端根据读取的配置文件内容中的url，向子系统请求数据；

服务端接收子系统返回的数据更新数据库。

其中，服务端启动并扫描读取配置文件后，还会读取上次成功完成该主动请求任务的时间戳，执行完上次失败的任务并及时更新数据。

具体实施过程中，数据库更新的方式包括增量更新方式和全量更新方式，增量更新方式指的是服务端将接收到的数据添加到中心数据库中，全量更新方式指的是服务端将接收到的子系统数据替换中心数据库中子系统对应的数据。增量更新方式和全量更新方式可以根据数据库实际的需求确定，对于需要长时间保留的数据则可以采用增量更新方式进行数据更新，对于不需要保留的数据可以采用全量更新方式来更新数据库，既可以数据的实际需求来执行更新方式，还可以根据实际需求减少中心数据库的存储压力，提高中心数据库的利用率。

相同或相似的标号对应相同或相似的部件；

附图中描述位置关系的用于仅用于示例性说明，不能理解为对本专利的限制；

显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。