CN108038201A - 一种数据整合系统及其分布式数据整合系统 - Google Patents

Abstract

本发明提供了一种数据整合系统及分布式数据整合系统，数据整合系统运行于JVM内存中，并包括Web服务器，受控于Web服务器的流程控制器，流程控制器中运行由Web服务器下发的数据转换流程，数据包库、内容库及工序库；所述流程控制器依赖数据转换流程，配置所需的若干功能模块，并通过功能模块对自上游设备获取的数据包执行数据转换操作后，将转换后的数据包所对应的元数据预写入数据包库，同时将剔除元数据的流程数据同时写入内容库及工序库。通过本发明，保证了数据在整合过程中的可靠性与整合效率，并保障了数据交付的安全性。

Description

一种数据整合系统及其分布式数据整合系统

技术领域

本发明涉及大数据技术领域，尤其涉及一种在大数据平台所产生的各种数据进行数据整合的一种数据整合系统及其基于多个数据整合系统所构成的一种分布式数据整合系统。

背景技术

大数据(Big Data)是在信息爆炸时代所衍生出来的具有内在逻辑结构的数据集合。目前，大数据正在云计算进行深度结合，并旨在为商业智能(BI)、用户行为分析、智慧城市等诸多领域中所产生的各种数据进行复合、分析，从而打造更为人性的社会、经济、管理平台。

数据整合是大数据或者包含大数据架构的智能化项目中非常重要的一个环节。为了对海量数据实现更为高效的利用、分析等操作前，通常需要对各种类型的数据进行分析与采集，以建立各种模型并为用户提供可视化界面，从而为各种商业策略、社会管理手段提供比较准确的参考。同时，对收集到的数据进行加工、清洗、提炼是在大数据分析使用之前的一个非常重要的前置工作。目前，在对数据进行整合过程中，为了保证数据在整合过程中的可靠性与整合效率，通常采用并行的分布式架构。

然而，在现有的数据整合系统中，如果某个节点出现网络故障、硬盘故障或者人为操作失误等意外情况时，则会导致整个数据整合系统发生崩溃或者数据整合错误。这会导致基于整合所得到数据所提供的各种决策或者输出结果出现错误。

因此，有必要对现有技术中对数据整合系统及数据整合方法进行改进，以解决上述技术瑕疵。

发明内容

本发明的目的在于提出一种数据整合系统，以及基于该系统的一种分布式数据整合系统，以克服现有技术中的数据整合系统遇到断电、磁盘损坏或者人为操作失误等意外突发情况时保证数据交付的安全性。

为实现上述第一个发明目的，本发明提供了一种数据整合系统，所述数据整合系统运行于JVM内存中，并包括：

Web服务器，受控于Web服务器的流程控制器，所述流程控制器中运行由Web服务器下发的数据转换流程，以及数据包库、内容库及工序库；

其中，所述流程控制器依赖数据转换流程，配置所需的若干功能模块，并通过功能模块对自上游设备获取的数据包执行数据转换操作后，将转换后的数据包所对应的元数据预写入数据包库，同时将剔除元数据的流程数据同时写入内容库及工序库。

作为本发明的进一步改进，当前数据转换流程所指向的数据包保存于JVM内存的哈希映射表中，所述数据包库存储元数据的同步备份日志，当数据包发生更改时，以增量方式写入同步备份日志，并修改JVM内存中的数据包。

作为本发明的进一步改进，所述内容库及工序库运行于配置有JVM内存的计算装置的文件系统中。

作为本发明的进一步改进，所述数据包库用于存储所有数据包的元数据；

所述工序库用于存储数据包的历史记录；

所述内容库用于保存当前数据转换流程和历史数据转换流程所对应数据包的内容。

作为本发明的进一步改进，所述功能模块包括：采集模块、处理模块、路由模块及输出模块；

所述采集模块用于自上游设备的数据库中采集数据包；

所述处理模块由至少一个子处理模块组成，所述子处理模块根据数据转换流程对采集到的数据包进行相应处理；

所述路由模块用于将数据转换任务路由给一个或者多个子处理模块；

所述输出模块用于向下游设备转发转换操作后的数据。

作为本发明的进一步改进，所述采集模块选自FromWebSocket插件、FromAMQP插件、FromIMAP插件、FromJMS插件、FromKafka插件、FromKafka0.10插件、FromMQTT插件、FromPOP3插件、FromWindowsEventLog插件、FromFile插件、FromFTP插件、FromHDFS插件、FromS3插件或者FromSFTP插件；

所述子处理模块选自DataToJSON插件、Base64Encode插件、AvroToJSON插件、CharacterSet插件、RouteByType插件、RouteByContent插件、SpliteAvro插件、SplitJSON插件、SplitText插件、SplitXML插件或者UpdateType插件；

所述输出模块选自ToWebSocket插件、ToAMQP插件、ToIMAP插件、ToJMSToKafka插件、ToKafka0.10插件、ToMQTT插件、ToFile插件、ToFTP插件、ToHDFS插件、ToS3插件或者ToSFTP插件。

为了实现上述第二个发明目的，本申请还公开了一种分布式数据整合系统，包括至少两个上述任一项发明所述的数据整合系统，每个数据整合系统独立运行于一个计算装置中，并将其中一个运行数据整合系统的计算装置定义为主控计算装置并将其他运行数据整合系统的计算装置定义为受控计算装置，以配置为分布式计算机集群；其中，所述主控计算装置中配置分布式应用程序协调器。

作为本发明的进一步改进，所述计算装置为物理机或者虚拟机。

作为本发明的进一步改进，所述分布式应用程序协调器选自Zookeeper、etcd或者consul。

作为本发明的进一步改进，所述分布式数据整合系统独立部署于两个或者两个以上并相互通讯的计算机或者计算机集群中，所述分布式数据整合系统还包括至少一个备份装置；

所述备份装置包括备份服务器、磁盘阵列、闪存或者NV-DIMM，所述备份装置部署于其中一个计算机或者计算机集群中。

作为本发明的进一步改进，所述主控计算装置的JVM内存中的流程控制器根据主控计算装置向受控计算装置所下发的数据整合流程，在主控计算装置的JVM内存中形成嵌入式图形用户界面，以在嵌入式图形用户界面中以拉拽方式，对功能模块进行配置与编排操作，所述嵌入式图形用户界面于Web服务器中进行实时展现。

与现有技术相比，本发明的有益效果是：通过本申请所揭示的一种数据整合系统及其基于上述数据整合系统的一种分布式数据整合系统，实现了对上游设备所抓取的源数据进行验证、清洗、过滤等整合操作，以为下游设备对经过整合操作后的数据进行应用提供了现实的可能性，并保证了数据在整合过程中的可靠性与整合效率，从而保证了为下游设备所输出的交付数据的安全性及可靠性，同时也确保了在发生断电、系统崩溃或者宕机等异常情况下进行数据整合的安全性及可靠性。

附图说明

图1为本发明一种数据整合系统的实例图；

图2为在图1所示出的流程控制器中具体执行一个数据转换流程时的数据整合系统的实例图；

图3为本发明一种分布式数据整合系统的实例图；

图4为在图3所示出的一种分布式数据整合系统中将运行数据整合系统的主控计算装置中配置分布式应用程序协调器的实例图，其中，DataIDE代表一个数据整合系统；

图5为物理上相互分离的两个机房中分别部署本发明一种分布式数据整合系统的示例图；

图6为数据整合系统或者分布式数据整合系统中对一个数据包进行数据转换操作的实例图；

图7为在单个计算节点中所部署的数据整合系统中的实例，并对源数据通过该数据整合系统经过转换后所形成的目标数据的示意图；

图8为在分布式计算节点中所部署的分布式数据整合系统中的实例；

图9为图8所示出的实例中通过该分布式数据整合系统中对源数据进行数据转换处理后形成目标数据的示意图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

在详细阐述本发明各实施例之前，对说明书所使用的术语及场景进行必要说明。

在本说明书中，术语“HOST”指代操作系统为Linux的计算机；

术语“Data IDE”指代一个完整的数据整合系统。

术语“源数据”指代未经过数据整合系统或者分布式数据整合系统执行数据清洗处理的数据；

术语“目标数据”指代经过数据整合系统或者分布式数据整合系统执行数据清洗处理后的数据；

术语“数据清洗”指代对源数据所执行的格式调整(例如消费者在购物中心的某台POS机上执行刷卡操作时所形成的刷卡日期所形成的数据，例如2017年3月1日13点24分11秒，调整为20170301132411)、数据验证、数据过滤(例如上述实例中对消费者的身份证号码进行隐藏以保护消费者个人隐私的操作)等适用于下游设备进行为实现商业智能(BI)、用户行为分析、智慧城市提供数据。

参图2所示，在本说明书各实施例中，所述上游设备包括但不限于运行各种关系型数据库(例如，mysql，oracle，postgresql，sqlserver)或者各种非关系型数据库(例如，MongoDB)的任何计算机设备或者其他具有数据存储或者浮点运算功能的装置、终端、设备或者便携式设备。

同时，参图2示，HOST100与架构上属于上游设备的外部系统200a及外部系统200b之间可采用DataAgent协议、TCP协议或者HTTP协议对抓取源数据。上游设备与HOST之间所形成的消息队列支持Kafka、ActiveMQ或者RabbitMQ等等。

此外，数据整合系统或者分布式数据整合系统中的采集模块对上游设备中所保存的源数据进行抓取的工具可采用诸如elasticsearch的搜索引擎来实现。

在本说明书各实施例中，HOST、外部系统、上游设备或者下游设备均可独立的或者共同的配置为实体计算装置(例如：桌面型计算机、计算机集群或者其他具有浮点运算能力的装置/系统/组件/网络接入设备)，也可独立的或者共同的配置为虚拟机或者其他通过虚拟化技术所形成的虚拟化设备。

实施例一：

本实施例公开了在单个计算节点中所部署的一种数据整合系统的一种具体实施方式。

参图1与图2所示，该数据整合系统(下文中涉及“DataIDE”与该数据整合系统具有等同技术含义)。数据整合系统运行于JVM内存10中，并包括：Web服务器11，受控于Web服务器11的流程控制器20，所述流程控制器20中运行由Web服务器11下发的数据转换流程，以及数据包库30、内容库40及工序库50。流程控制器20依赖数据转换流程，配置所需的若干功能模块，并通过功能模块对自上游设备获取的数据包执行数据转换操作后，将转换后的数据包所对应的元数据预写入数据包库30，同时将剔除元数据的流程数据同时写入内容库40及工序库50。

上述所谓的功能模块是指，流程控制器20根据图1中的数据转换流程1～数据转换流程N(N取大于或者等于1的正整数)所对应的数据处理需求所形成的不同的指令集或者插件或者应用。

具体的，功能模块包括：采集模块(图2中的采集模块201a与采集模块201b)、处理模块202、路由模块203及输出模块(如图2中的输出模块204与输出模块205)。

采集模块用于自上游设备的数据库中采集数据包，处理模块202由至少一个子处理模块组成，所述子处理模块根据数据转换流程(数据转换流程1)对采集到的数据包进行相应处理。所述路由模块用于将数据转换任务路由给一个或者多个子处理模块；所述输出模块用于向下游设备转发转换操作后的数据。其中，子处理模块的数量并不作具体限制，并可根据自外部系统200a或者外部系统200b所抓取的源数据自适应地匹配出具体的子处理模块。

虽然图2中仅示出了采集模块201a与采集模块201b，本领域技术人员可以合理预测到，流程控制器20中还可根据上游设备或抓取的源数据的不同处理需要，配置一个采集模块、三个采集模块或者数量更多的采集模块。当然，处理模块202中所示出的各个子处理模块也不具体限制数量。最后，在本实施例中，输出模块由输出模块204与输出模块205组成，同上所述，本领域技术人员也可合理预测到，该流程控制器20中也可仅包含一个、三个或者数量更多的输出模块。

具体的，在本实施例中，所述采集模块201a或者采集模块201b选自FromWebSocket插件、FromAMQP插件、FromIMAP插件、FromJMS插件、FromKafka插件、FromKafka0.10插件、FromMQTT插件、FromPOP3插件、FromWindowsEventLog插件、FromFile插件、FromFTP插件、FromHDFS插件、FromS3插件或者FromSFTP插件。

其中，

FromWebSocket插件的作用为：从外部的WebSocket服务中采集数据，并以数据包的形式发送到指定的下游设备(即，图2中在逻辑架构上是下游设备的外部系统300和/或外部系统400)。

FromAMQP插件的作用为：从外部的AMQP服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromIMAP插件的作用为：从外部的IMAP服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromJMS插件的作用为：从外部的JMS服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromKafka插件的作用为：从外部的Kafka服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromKafka0.10插件的作用为：从外部的Kafka0.10服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromMQTT插件的作用为：从外部的MQTT服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromPOP3插件的作用为：从外部的POP3服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromWindowsEventLog插件的作用为：从外部的WindowsEventLog中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromFile插件的作用为：从外部的文件中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromFTP插件的作用为：从外部的Kafka0.10服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromHDFS插件的作用为：从外部的HDFS服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromS3插件的作用为：从外部的S3服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

FromSFTP插件的作用为：从外部的SFTP服务中采集数据，并以数据包的形式发送到指定的下游设备(同上解释)。

在本实施例中，子处理模块单独或者共同组成处理模块202。

其中，子处理模块选自DataToJSON插件、Base64Encode插件、AvroToJSON插件、CharacterSet插件、RouteByType插件、RouteByContent插件、SpliteAvro插件、SplitJSON插件、SplitText插件、SplitXML插件或者UpdateType插件。

其中，

DataToJSON插件的作用为：将接受到的上游设备传入的符合JSON规范要求的数据包转化为JSON格式，并将新数据包发送到指定的下游设备。

Base64Encode插件的作用为：将接受到的上游设备传入的符合Base64规范要求的数据包编码为Base64格式，并将新数据包发送到指定的下游设备。

AvroToJSON插件的作用为：将接受到的上游设备传入的符合Base64规范要求的数据包编码为Base64格式，并将新数据包发送到指定的下游设备。

CharacterSet插件的作用为：将接受到的上游设备传入的字符串数据转化为指定的编码格式，如GBK、UTF等，并将新数据包发送到指定的下游设备。

RouteByType插件的作用为：将接受到的上游设备传入的数据包，根据数据包的类型特征路由到指定下游设备，并将新数据包发送到指定的下游设备。

RouteByContent插件的作用为：将接受到的上游设备传入的数据包，根据数据包的内容特征路由到指定下游设备，并将新数据包发送到指定的下游设备。

SpliteAvro插件的作用为：将接受到的上游设备传入的数据包，将Avro类型的数据包，按用户指定要求，分割为多个新的数据包，并将新数据包发送到指定的下游设备。

SplitJSON插件的作用为：将接受到的上游设备传入的数据包，将JSON类型的数据包，按用户指定要求，分割为多个新的数据包，并将新数据包发送到指定的下游设备。

SplitText插件的作用为：将接受到的上游设备传入的数据包，将TEXT类型的数据包，按用户指定要求，分割为多个新的数据包，并将新数据包发送到指定的下游设备。

SplitXML插件的作用为：将接受到的上游设备传入的数据包，将XML类型的数据包，按用户指定要求，分割为多个新的数据包，并将新数据包发送到指定的下游设备。

UpdateType插件的作用为：将接受到的上游设备传入的数据包，更新数据包的类型，并将新数据包发送到指定的下游设备。

最后，在本实施例中，输出模块(在逻辑上可由图2中的输出模块204和/或输出模块205组成)，输出模块选自ToWebSocket插件、ToAMQP插件、ToIMAP插件、ToJMSToKafka插件、ToKafka0.10插件、ToMQTT插件、ToFile插件、ToFTP插件、ToHDFS插件、ToS3插件或者ToSFTP插件。

输出模块选自ToWebSocket插件、ToAMQP插件、ToIMAP插件、ToJMSToKafka插件、ToKafka0.10插件、ToMQTT插件、ToFile插件、ToFTP插件、ToHDFS插件、ToS3插件或者ToSFTP插件。

其中，

ToWebSocket插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部WebSocket服务。

ToAMQP插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部AMQP服务。

ToIMAP插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部IMAP服务。

ToJMS插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部JMS服务。

ToKafka插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部Kafka服务。

ToKafka0.10插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部Kafka0.10服务。

ToMQTT插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部MQTT服务。

ToFile插件的作用为：将接受到的上游设备传入的数据包，写入指定的外部文件中(可指定a\a+\w\w+)。

ToFTP插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部FTP服务。

ToHDFS插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部HDFS服务

ToS3插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部S3服务。

ToSFTP插件的作用为：将接受到的上游设备传入的数据包，发送给指定的外部SFTP服务。

Web服务器11运行于HOST100中，并托管该数据整合系统。流程控制器20为需要执行的数据转换流程1至数据转换流程N提供线程，并管理具体的数据转换流程所对应资源的时间表(Schedule)。

数据包库30用于存储具体的数据转换流程所对应的数据包的元数据(MetaData)。进一步的，数据包可通过多种方式来进行限定或者划分，例如，以设定时间段内(例如以5分钟或者10分钟为单位)从上游设备的数据库中所接收到的所有数据的集合作为一个数据包，或者以采集模块从属于上游设备的外部系统200a或者外部系统200b中所获取的一定数量(例如，一万条或者两万条)的数据的集合作为一个数据包。

图2中的一个采集模块201a和/或采集模块202b与处理模块202、路由模块203及输出模块204和/或输出模块205共同组成根据图1所示出的数据转换流程1至数据转换流程N经过配置所形成的功能模块，以通过这些功能模块对源数据执行相应的处理后，向逻辑上为下游设备的外部系统300和/或外部系统400下发。具体的，在本实施方式中，上游设备和/或下游设备中的所涉及的外部系统均可被配置为数据库或者文件系统(file system)。

内容库40用于保存上正在被执行的数据转换流程所对应的数据包，以及历史数据转换流程(即相对于上述正在被执行的数据转换流程所对应的数据包)所对应的数据包。工序库50用于保存当前数据转换流程和历史数据转换流程所对应数据包的内容。具体的，在本实施方式中，内容库40与工序库50运行于配置有JVM内存10的计算装置的文件系统(FS)中。优选的，内容库40与工序库50运行于HOST100所处在的单个计算节点的文件系统(FS)中，并进一步具体为linux系统的FS或者Unix系统的FS中。

本实施例所揭示的数据整合系统(即Data IDE，Data Integrated DevelopmentEnvironment)中对自上游设备所获取的源数据进行清洗、过滤、解密、聚合、转换或者其他处理(以下简称“数据整合”)后形成目标数据并下发至下游设备中，从而满足下游设备对目标数据的分析，以适合商业智能(BI，Business Intelligence)、用户行为分析、智慧城市等大数据平台的需求。

以下对数据整合系统运行的过程作详细介绍。

在本实施例中，该数据整合系统正在处理的数据包保存在JVM内存10中的哈希映射表中，数据包库30储存在HOST100的内存60中。当前存在的每个数据的元数据的同步备份日志。当数据包发生更改时，增量将写入同步备份日志，并相应的修改内存中的对象。这使得该数据整合系统可以快速使用数据包，同时也跟踪数据包中哪一条数据或者哪几条数据发生了什么，以及在会话提交时会发生什么整合，这提高了该数据整合系统的效率和耐用性。

在数据整合系统的数据包库30中，数据包中的元数据包括：与数据包相关的所有属性(例如，指向数据包，该数据包存在于内容库40中的实际内容的指针)及数据包的状态(例如数据包属于哪个链接或队列)。备份日志为数据整合系统提供处理重启和意外系统故障所需的弹性。

数据包库30充当数据整合系统的备份日志。当数据包流经数据整合系统时，对数据包中的每一个数据执行的任何一个更改或者修改操作都会作为事务性工作单元记录在数据包库30中。数据整合系统在处理一段数据时能够确知该计算节点中的数据包中的数据目前处于何种处理阶段及具体的进程。

当计算节点在处理数据的过程中出现故障，那么当数据整合系统重新启动时，可以从停止的位置恢复。日志中的数据包的格式是数据整合系统在对上游设备所获取的源数据进行转换处理过程中发生的一系列增量数据(或更改)。数据整合系统通过恢复数据包的“快照“(在数据包库30被检查指向时创建)，然后从该计算节点所挂载的本地存储70中读取上述增量数据来恢复计算节点在处理数据的过程中出现故障前正在执行数据转换处理所对应的数据包。其中，本地存储70可配置为机械磁盘、RAID0～10、NAND存储或者NOR存储。

数据整合系统会定期自动获取快照，为每个数据包创建一个新的快照。数据整合系统通过序列化的哈希映射表中的每个数据包并使用文件名.partial将其写入磁盘来计算新的基本检测点。随着监测点的推进，新的数据包基线被写入.partial文件。完成检测时，旧的快照文件就会被删除，.partial文件被重命名为快照。具体的，在本实施例中，默认的监测点间所形成的时间间隔为两分钟。

内容库40将所有数据包存储在本地存储70，利用不可变性和写入时复制的方式来实现对源数据的进行转换的最大化速度和线程安全性。内容库40的核心设计是将数据包的内容保存在本地存储70(例如HOST100所挂载的一个或者多个磁盘)上，并在需要的时候将其读入JVM内存10，从而这使得数据整合系统能够同时应对各种规模的数据量。

从逻辑架构而言，内容库40与工序库50表现为在HOST100所在单个计算节点所具有的本地存储70上运行，而数据包库30则表现为在HOST100所在单个计算节点所具有的内存60上运行。当前数据转换流程所指向的数据包保存于JVM内存10的哈希映射表中，所述数据包库30存储元数据的同步备份日志，当数据包发生更改时，以增量方式写入同步备份日志，并修改JVM内存10中的数据包。

需要说明的是，本实施方式所示出的数据整合系统中的采集模块、处理模块(含一种或者几种子处理模块)、路由模块或者输出模块可根据需要源数据所执行的具体的数据转换需要进行自由配置。进一步的，既使在流程控制器20中根据某个数据转换流程所配置得到的上述各个模块是重复的，也可对相同的模块(例如相同的子处理模块、相同的输出模块或者相同的处理模块)赋予不同的操作内容，从而实现不同的技术效果。

以下对单个计算节点中在出现故障(例如：断电、系统崩溃、宕机等异常故障)时，通过该数据整合系统进行故障处理的过程进行介绍。

参图7所示，该数据整合系统通过记录当时计算节点在其数据包库30(图7与图9中缩写为“D”)中的处理记录来防止硬件和系统故障。如数据包库30是系统的备份日志。当该单个计算节点恢复联机时(或者该计算节点恢复正常时)，首先检测快照和.partial文件，恢复其状态。计算节点接受快照并删除.partial文件(如果存在)，如果不存在快照文件，则将.partial文件重命名为快照。

如果计算节点在写入内容的过程中处于中间状态，则由于“备份日志”和“不可变性”，没有任何内容损坏。数据包事务不会修改原始内容并具有由内容指针指向确定，因此原始的数据内容是安全的。当该单个计算节点所运行的系统(例如Linux系统)出现故障时，更改的写入声明将成为孤立，然后由后台垃圾回收清理。这提供了对最后已知的稳定状态的“回滚”。最后计算该单个计算节点从数据包库30中恢复其原始状态，以恢复至该单个计算节点出现故障的前一个正常状态下数据转换流程的进程，以准确地反映出某一个数据转换流程所包含数据包中所包含的元数据被执行某个特定的数据转换处理的进度。

结合参照图7所示，在本实施方式中，单个计算节点(图7中标记为NODE1)的流程控制器20中运行的一个数据转换流程配置模块1与模块2，其中，所述模块1与模块2可为图2所示出的采集模块201a、采集模块201b、处理模块202、路由模块203、输出模块204或者输出模块205中的任意一种模块。

具体的，在本实施方式中，模块1可配置为路由模块203，HOST100上同时运行数据包库30、内容库40及工序库50。模块1对从上游设备获取的源数据并不做任何处理，仅执行路由处理，即将源数据传输到模块2。因此，在上述过程中，数据包库30中的数据并没有发生改变，也没有被修改。同理，内容库40中的数据也没有发生变化。

因此，结合图7所示，在上述过程中，内容库30中的数据D1-1仍然是数据D1-1。内容库40中的数据C1-1仍然是数据C1-1。工序库50在执行数据转换处理之前没有任何数据记录，并在执行数据转换处理后，新增加了一条记录，即记录W1-1。记录W1-1包含了对数据D1-1执行了路由操作。

同时，本实施方式所示出的数据整合系统中的各个模块也可以重复配置。例如，重复配置的相同的两个模块可以根据不同的配置，进行不一样的工作。

例如，实例A中，采集模块采集内网地址为127.0.0.1:3306的一个计算节点中的DatabaseA(数据库)中的数据TAB1(源数据)；实例B中，采集模块采集内网地址为127.0.0.1:3306的一个计算节点中的DatabaseA(数据库)中的数据TAB2(源数据)。同理所述，同样是UpdateType插件(一种子处理模块)，UpdateType插件在实例A中，将Createtime>2017年10月11日创建的文件的author属性改为“zhangsan”，其他的author属性改成“lisi”。在实例B中，将author属性为“zhangsan”的，是否共享属性改为共享，反之改为不共享或不修改。

进一步的，参图6所示，子处理模块2020将需要转换的源数据通过路由模块105分发至子处理模块2021、子处理模块2022。。。。(余略)。。。。。子处理模块202i(i取大于或者等于2的正整数)。在上述过程中，子处理模块2020对源数据所执行的具体的数据转换处理与子处理模块2021、子处理模块2022。。。。(余略)。。。。。子处理模块202i所作出的具体的数据转换处理可相同，也可不同。

实施例二：

请参图3、图4、图8及图9所示出的本发明一种分布式数据整合系统的第一种具体实施方式。

在本实施方式中，该分布式数据整合系统包括至少两个如实施例一所述的数据整合系统，每个数据整合系统独立运行于一个计算装置中，并将其中一个运行数据整合系统的计算装置定义为主控计算装置并将其他运行数据整合系统的计算装置定义为受控计算装置，以配置为分布式计算机集群；其中，所述主控计算装置中配置分布式应用程序协调器90。参图3所示，由运行HOST100的计算装置定义为主控计算装置，HOST100与下属的三个受控计算装置形成计算机集群，三个受控计算装置中分别运行数据整合系统100a、数据整合系统100b及数据整合系统100c。三个受控计算装置中的数据整合系统100a～100c均运行于受控计算装置的JVM内存10a～10c中。

参图4所示，HOST100所管辖或者主控的计算装置数量可为一个，也可为两个，也可为N个(N不设上限数量)。进一步的，在图4中，受控计算装置中的HOST200中运行的数据整合系统(Data IDE)可配置为一个(即图4中的Data IDE01)，也可配置为多个。HOST100中的JVM内存10中配置Web服务器11，并配置集群管理服务，以用于实现请求管理。作为受控计算装置中运行的数据整合系统100a的JVM内存10a中也配置上述功能的Web服务器11a，并配置流程控制器20a。

流程控制器20a中运行一个或者多个数据转换流程(即图3中的数据转换流程1～数据转换流程N)。同时，在JVM内存10a中配置数据包库30a、内容库40a及工序库50a。

同理所述，受控计算装置中的HOST300中运行的数据整合系统(Data IDE)可配置为一个(即图4中的Data IDE02)，也可配置为多个。同时，HOST100、HOST200、HOST300至HOSTN依赖的计算装置可配置为物理机，也可被配置为虚拟机。在本实施方式中，该分布式应用程序协调器90选自Zookeeper、etcd或者consul；具体的，本说明书中以Zookeeper作为分布式应用程序协调器90的一种典型范例作示范性说明。

如图3所示，该分布式计算机集群采用Zero-Master集群架构。主控计算装置与受控计算装置(并由此形成多个计算节点)在执行数据转换过程中执行相同的任务。每个计算节点通过均在不同的数据集上运行。通过Zookeeper选择一个计算节点作为集群协调器。例如，在本实施方式中，选定HOST100所在的计算装置定义为主控计算装置，并协调其下属或者控制的三个受控计算装置。当其中一个受控计算装置发生故障，并导致其内置的数据整合系统发生故障时，由Zookeeper执行故障迁移操作。

于此条件下，该分布式计算机集群中的所有计算节点(含主控计算装置所形成的HOST100，以及三个受控计算装置所独立形成的数据整合系统100a～100c)都会向Zookeeper报告心跳及状态信息，由Zookeeper负责断开HOST100与其他计算节点之间的连接或者在其他计算节点恢复正常功能后重新建立连接。

通过Zookeeper所选取的主控计算装置作为数据流管理器，从而使得在该分布式计算机集群中所发生的任何配置修改及数据转换处理均会复制到分布式计算机集群中的所有计算节点中，并形成多个数据转换出入口。

当Zookeeper选定主控计算装置(该主控计算装置形成主控节点)后，由选定的主控计算装置(例如，如图3中由HOST100所形成的主节点)处理用户或者管理员在WEB端发起的各种数据转换请求(例如：对源数据进行清洗、过滤等操作)，并将请求所对应的源数据下发至各个受控计算装置中进行数据转换处理。受控计算装置中所执行的数据转换处理的具体过程参实施例一所示，在此不再赘述。

参图8及图9所示该分布式数据整合系统中对源数据进行数据转换处理的一个典型过程。

图8中，输入模块可视为图2所示出的处理模块202的一部分或者一个子模块。输入模块通过路由模块203将数据包路由至输出模块1(对应图2中的输出模块204)及输出模块2(对应图2中的输出模块205)。

路由模块203对数据包中的数据路由至输出模块1及输出模块2。在上述路由过程中，从数据包库30中的一条数据D1-1通过克隆，生成了数据D1-2，并将数据D1-1及数据D1-2分别路由至输出模块1及输出模块2。同时，在此数据克隆过程中，内容库40中的数据并未发生变化(仍然是数据C1-1)。由于数据D1-1与数据D1-2仅是通过克隆复制得到的，因此彼此所形成的元数据并未发生变化。同时，工序库50中增加了三条记录：(1)数据D1-1克隆并形成了数据D1-2；(2)将数据D1-1路由至下游的输出模块1；(3)将数据D1-2路由至输出模块2。在各个计算节点呈分布式架构下，各个计算节点中对数据所执行的处理手段是相同的，并仅仅是处理的数据的内容有所差异。

当然，参图9中，计算节点NODE 1至计算节点NODE N所含有具体的数据执行过程及执行原理均相同，为简化标示，在图9中，仅示出计算节点NODE 1与计算节点NODE N。这N个计算节点均作为受控计算装置服从作为主控计算装置的HOST100的控制。

实施例三：

请参图5所示出的发明一种分布式数据整合系统的第二种具体实施方式。本实施例与实施例二所揭示的分布式数据整合系统的主要区别在于，在本实施例中，，所述分布式数据整合系统独立部署于两个或者两个以上并相互通讯的计算机或者计算机集群中，所述分布式数据整合系统还包括至少一个备份装置91。

备份装置91包括：备份服务器、磁盘阵列、闪存或者NV-DIMM，所述备份装置部署于其中一个计算机或者计算机集群中。优选的，备份装置91或者备份装置91a最优选为NV-DIMM(Non-volatile DIMM)。

NV-DIMM是在一种集成了DRAM与非易失性内存芯片的内存条规格，能够在完全断电的时候依然保存完整内存数据，以实现全系统数据保护。对于带有板级RAID控制芯片或者采用软件RAID方案的计算机，缺乏写缓存，NV-DIMM可以直接用做系统主存，配合操作系统，完成写缓存任务。还有一类PCIE接口的RAID控制卡，它们采用普通的带电池(例如，超级电容或者可充电锂电池)后备的内存条作为缓存使用，NV-DIMM可以直接替代这些内存条。

同时，主控计算装置的JVM内存10中的流程控制器根据主控计算装置向受控计算装置所下发的数据整合流程，在主控计算装置的JVM内存10中形成嵌入式图形用户界面，以在嵌入式图形用户界面中用户或者管理员可以以拉拽方式对功能模块进行配置与编排操作。该嵌入式图形用户界面于Web服务器11中进行实时展现。

图5描述了容灾需求下的分布式数据整合系统的架构。

A机房(当然也可理解为一个数据中心)中，HOST1为选举出的数据整合的主控制节点，HOST2至HOSTN为分布式计算机集群中的计算节点(受控于HOST1)，并由HOST2至HOSTN实际执行对数据包或者数据的数据转换操作。HOST 0为ZooKeeper(即，分布式应用程序协调器90)所在的运行节点。HOST P中运行备份装置91。在B机房(当然也可理解为一个数据中心)中，HOST0上运行备装置91a。A机房的备份服务按自定义时间间隔(例如2分钟作为间隔时间进行备份)，采集各计算节点的工序库50的数据及管理节点的管理数据，并提交到B机房的备份装置91a中。同时，在B机房中还配置有HOST Z，并在HOST Z中配置分布式应用程序协调器90a(例如，Zookeeper或者etcd)。

A机房中的备份装置91与B机房中的备份装置91a均运行有相同种类的数据库；所述数据库包括但不限于mysql数据库、oracle数据库或者mssql数据库，并且备份装置91与备份装置91a中所运行的数据库中的数据保持一致。数据保持一致是为了当A机房出现故障时，可以用B机房中备份装置91a中的数据进行快速恢复及重现故障前的状态(反之亦然)。此外，由于备份装置91与备份装置91a中所运行的数据库的种类、数据及版本号保持一致，因此在B机房或者A机房重新启用业务时，可通过彼此的备份装置中的数据库进行高效管理，降低添加数据转化、格式转换的工作量。

用户或者管理员可以在web端设置备份策略(要求低可以1天一备份的备份频率，要求高可以5分钟备份一次)，并且在异地的web端和本地的web端都可以进行备份。为了提高安全性，推荐使用异地备份。

该分布式数据整合系统并不备份元数据，而是备份请求管理数据，以及各个计算节点中工序库50中的数据。主控节点的管理数据记录所有已执行和未执行的数据整合需求，工序库50记录了已执行的数据整合需求。因此，结合这两部分数据即可在当前机房(例如A机房)瘫痪后，迅速在异地(即在B机房)重新启动服务。

异地重启的该分布式数据整合系统的计算机集群并不需要有相同数量的资源，比如原数据中心(即A机房)中有10台节点，备用数据中心(即B机房)中只有1到N台节点，也可以在启用节点后，按照数据整合需求及现有执行记录，继续执行数据整合作业(数据整合需求包含主要实际上主要指的是模块配置，模块配置指明了模块的上下游和处理逻辑)。

本实施例与实施例一和或实施例二中相同部分的技术方案请参上文所述，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (11)

1.一种数据整合系统，其特征在于，所述数据整合系统运行于JVM内存中，并包括：

Web服务器(11)，受控于Web服务器(11)的流程控制器(20)，所述流程控制器(20)中运行由Web服务器(11)下发的数据转换流程，以及数据包库(30)、内容库(40)及工序库(50)；

其中，所述流程控制器(20)依赖数据转换流程，配置所需的若干功能模块，并通过功能模块对自上游设备获取的数据包执行数据转换操作后，将转换后的数据包所对应的元数据预写入数据包库(30)，同时将剔除元数据的流程数据同时写入内容库(40)及工序库(50)。

2.根据权利要求1所述的数据整合系统，其特征在于，当前数据转换流程所指向的数据包保存于JVM内存的哈希映射表中，所述数据包库(30)存储元数据的同步备份日志，当数据包发生更改时，以增量方式写入同步备份日志，并修改JVM内存中的数据包。

3.根据权利要求1所述的数据整合系统，其特征在于，所述内容库(40)及工序库(50)运行于配置有JVM内存的计算装置的文件系统中。

4.根据权利要求1所述的数据整合系统，其特征在于，所述数据包库(30)用于存储所有数据包的元数据；

所述工序库(50)用于存储数据包的历史记录；

所述内容库(40)用于保存当前数据转换流程和历史数据转换流程所对应数据包的内容。

5.根据权利要求1所述的数据整合系统，其特征在于，所述功能模块包括：采集模块、处理模块、路由模块及输出模块；

所述采集模块用于自上游设备的数据库中采集数据包；

所述处理模块由至少一个子处理模块组成，所述子处理模块根据数据转换流程对采集到的数据包进行相应处理；

所述路由模块用于将数据转换任务路由给一个或者多个子处理模块；

所述输出模块用于向下游设备转发转换操作后的数据。

6.根据权利要求5所述的数据整合系统，其特征在于，所述采集模块选自FromWebSocket插件、FromAMQP插件、FromIMAP插件、FromJMS插件、FromKafka插件、FromKafka0.10插件、FromMQTT插件、FromPOP3插件、FromWindowsEventLog插件、FromFile插件、FromFTP插件、FromHDFS插件、FromS3插件或者FromSFTP插件；

所述子处理模块选自DataToJSON插件、Base64Encode插件、AvroToJSON插件、CharacterSet插件、RouteByType插件、RouteByContent插件、SpliteAvro插件、SplitJSON插件、SplitText插件、SplitXML插件或者UpdateType插件；

所述输出模块选自ToWebSocket插件、ToAMQP插件、ToIMAP插件、ToJMSToKafka插件、ToKafka0.10插件、ToMQTT插件、ToFile插件、ToFTP插件、ToHDFS插件、ToS3插件或者ToSFTP插件。

7.一种分布式数据整合系统，其特征在于，包括至少两个如权利要求1至6中任一项所述的数据整合系统，每个数据整合系统独立运行于一个计算装置中，并将其中一个运行数据整合系统的计算装置定义为主控计算装置并将其他运行数据整合系统的计算装置定义为受控计算装置，以配置为分布式计算机集群；其中，所述主控计算装置中配置分布式应用程序协调器(90)。

8.根据权利要求7所述的分布式数据整合系统，其特征在于，所述计算装置为物理机或者虚拟机。

9.根据权利要求7所述的分布式数据整合系统，其特征在于，所述分布式应用程序协调器(90)选自Zookeeper、etcd或者consul。

10.根据权利要求7至9中任一项所述的分布式数据整合系统，其特征在于，所述分布式数据整合系统独立部署于两个或者两个以上并相互通讯的计算机或者计算机集群中，所述分布式数据整合系统还包括至少一个备份装置(91)；

所述备份装置(91)包括：备份服务器、磁盘阵列、闪存或者NV-DIMM，所述备份装置部署于其中一个计算机或者计算机集群中。

11.根据权利要求10所述的分布式数据整合系统，其特征在于，所述主控计算装置的JVM内存中的流程控制器根据主控计算装置向受控计算装置所下发的数据整合流程，在主控计算装置的JVM内存中形成嵌入式图形用户界面，以在嵌入式图形用户界面中以拉拽方式，对功能模块进行配置与编排操作，所述嵌入式图形用户界面于Web服务器(11)中进行实时展现。