CN104052804A

CN104052804A - 一种不同任务拓扑间共享数据流的方法、装置及集群

Info

Publication number: CN104052804A
Application number: CN201410253785.3A
Authority: CN
Inventors: 赵东辉; 范小朋; 沈慧; 须成忠
Original assignee: Shenzhen Institute of Advanced Technology of CAS
Current assignee: Shenzhen Institute of Advanced Technology of CAS
Priority date: 2014-06-09
Filing date: 2014-06-09
Publication date: 2014-09-17

Abstract

本发明适用于流数据处理技术领域，提供了一种不同任务拓扑间共享数据流的方法、装置及集群，所述方法包括：发布第一任务拓扑至集群中；获取所述第一任务拓扑中的数据流的信息；写入所述第一任务拓扑中的数据流的信息至关系型数据库管理节点中；从关系型数据库管理节点中获取第二任务拓扑需要订阅的数据流的发布信息，所述需要订阅的数据流是所述第一任务拓扑中的一条数据流；发布所述第二任务拓扑至集群中，所述第二任务拓扑读取所述发布信息，并根据所述发布信息订阅所述第一任务拓扑中的相应数据流。本发明，相比现有技术不容易出错，且效率高。

Description

一种不同任务拓扑间共享数据流的方法、装置及集群

技术领域

本发明属于流数据处理技术领域，尤其涉及一种不同任务拓扑间共享数据流的方法、装置及集群。

背景技术

传统互联网的高速发展和移动互联网的崛起引领大数据时代的到来，新兴基于MapReduce的计算模型在持久化批量大数据处理上取得巨大成功，然而数据的高速膨胀，一种新的数据密集型应用提出了有力挑战，这类应用的特征是：数据不宜用持久稳定关系建模，而适宜用瞬态数据流建模。这种名为流数据(streaming data)的应用模型广泛出现在众多领域，例如金融应用、网络监视、通信数据管理、Web应用、传感器网络数据处理等等。近年来，业界也出现不少实时流数据计算系统，包括Yahoo！S4、Twitter Storm、IBM StreamBase及学术界开源的Borealis等。其中Twitter Storm因为其规整的编程模型、多语言支持、简单的水平扩展和可靠、高效的流处理能力得到广泛应用。

不同流式计算框架虽然计算模型稍有差异，但是本质都是“单任务、单拓扑”的独立流式计算模式，我们以Twitter Storm为例：在Storm中，一个实时应用的计算任务被打包作为一个任务拓扑Topology发布，Topology是由不同的Spouts和Bolts，通过数据流Stream连接起来的图。图1是Twitter Storm中的一个Topology的结构示意图：在Storm中，每个组件(Spout和Bolt)都会“订阅”一个或多个数据流，在对“订阅”的数据流处理完毕后，也会“发布”一个新的数据流供下面的组件“订阅”。如图1所示，Bolt1从Spout1“订阅”一个数据流Stream1，在对Stream1处理完毕后，“发布”一个新的Stream2供Bolt3订阅和处理；同理，Bolt2从Spout1“订阅”一个数据流Stream1，在对Stream1处理完毕后，“发布”一个新的Stream3供Bolt3订阅和处理。但是Storm中Stream的概念都是私有的，其数据流的“发布、订阅”信息只在当前的Topology里可见，不同Topology之间的数据流信息无法共享。

不同Topology之间Stream无法共享限制了Storm的应用场景，一个典型的流式应用场景如图2所示：现有的Topology1结构可以过滤大于20岁的所有性别为男的用户数据流，现在企业需要过滤大于20岁性别为女的用户数据流，最直观的实现方案是再写一个Topology2，通过Topology2“订阅”大于20岁的数据流，然后再写一个Bolt3过滤性别为女的数据流，如图3所示。

但是Storm中数据流Stream是私有的，其发布订阅信息只在当前的Topology可见，这样图3中Topology2无法从Topology1订阅“大于20岁的数据流”，导致无法实现。

在现有的Storm中，如果要实现上述需求，主要有两种方案：

1)、修改Topology1的源码，在Topology1中增加一个过滤性别为女的Bolt3，然后结束集群中原有的Topology1，再把新更改的Topology1打包上去，此时集群的结构如图4所示。

2)、重写一个Topology，Spout1和Bolt1代码复用，然后编写一个Bolt3负责处理性别为女的过滤逻辑，此时集群的结构如图5所示。

现有的解决方案都能从一定程度上解决问题，但是都有明显缺点：

1)、第一种方案，修改原有的Topology1源码，再把本来运行正常的Topology1结束掉，最后把新更改的Topology1打包上传上去。在这整个过程中，第一，在原有的代码上增加新的功能，需要大量的测试，耗费人力；第二，结束原来的Topology，会造成原有的业务信息部分丢失，给企业带来损失。

2)、第二种方案，从原始的数据源读取同样一份数据，然后做同样的过滤工作，第一，会增加数据源的压力，第二，形同数据被过滤了多次，浪费集群的计算资源，当Topology多的时候，会给企业带来较大的开销。

综上，通过现有的解决方案实现数据流在不同的Topology之间共享时，比较容易出错，且效率低下。

发明内容

本发明实施例提供了一种不同任务拓扑间共享数据流的方法、装置及集群，旨在解决现有的技术实现数据流在不同的Topology之间共享时，比较容易出错，且效率低下的问题。

一方面，提供一种不同任务拓扑间共享数据流的方法，所述方法包括：

发布第一任务拓扑至集群中；

获取所述第一任务拓扑中的数据流的信息；

写入所述第一任务拓扑中的数据流的信息至关系型数据库管理节点中；

从关系型数据库管理节点中获取第二任务拓扑需要订阅的数据流的发布信息，所述需要订阅的数据流是所述第一任务拓扑中的一条数据流；

发布所述第二任务拓扑至集群中，所述第二任务拓扑读取所述发布信息，并根据所述发布信息订阅所述第一任务拓扑中的相应数据流。

进一步地，在所述发布第二任务拓扑至集群中之后，还包括：

获取所述第二任务拓扑生成的数据流的信息；

写入所述第二任务拓扑生成的数据流的信息至关系型数据库管理节点中。

进一步地，所述数据流的信息包括：数据流的标识、数据流所在的任务拓扑信息、数据流所在节点的ip信息、数据流所在节点的端口信息；

所述发布信息包括：数据流所在节点的ip信息、数据流所在节点的端口信息。

进一步地，所述写入所述第一任务拓扑中的数据流的信息至关系型数据库管理节点中包括：

读取包括关系型数据库管理节点的地址信息的配置文件，得到关系型数据库管理主节点和关系型数据库管理从节点的地址信息；

ping所述关系型数据库管理主节点的地址，如果ping通过，则写入所述第一任务拓扑中的数据流的信息至关系型数据库管理主节点中；

否则，ping所述关系型数据库管理从节点的地址，如果ping通过，则写入所述第一任务拓扑中的数据流的信息至关系型数据库管理从节点中。

另一方面，提供一种不同任务拓扑间共享数据流的装置，所述装置包括：

第一拓扑发布单元，用于发布第一任务拓扑至集群中；

第一数据流信息获取单元，用于获取所述第一任务拓扑中的数据流的信息；

第一数据流信息写入单元，用于写入所述第一任务拓扑中的数据流的信息至关系型数据库管理节点中；

发布信息获取单元，用于从关系型数据库管理节点中获取第二任务拓扑需要订阅的数据流的发布信息，所述需要订阅的数据流是所述第一任务拓扑中的一条数据流；

第二拓扑发布单元，用于发布所述第二任务拓扑至集群中，所述第二任务拓扑读取所述发布信息，并根据所述发布信息订阅所述第一任务拓扑中的相应数据流。

进一步地，所述装置还包括：

第二数据流信息获取单元，用于获取所述第二任务拓扑生成的数据流的信息；

第二数据流信息写入单元，用于写入所述第二任务拓扑生成的数据流的信息至关系型数据库管理节点中。

进一步地，所述第一数据流信息写入单元包括：

主从节点地址读取模块，用于读取包括关系型数据库管理节点的地址信息的配置文件，得到关系型数据库管理主节点和关系型数据库管理从节点的地址信息；

第一ping模块，用于ping所述关系型数据库管理主节点的地址；

第一数据流信息写入模块，用于如果ping通过，则写入所述第一任务拓扑中的数据流的信息至关系型数据库管理主节点中；

第二ping模块，用于如果无法ping通过，则ping所述关系型数据库管理从节点的地址；

第二数据流信息写入模块，用于如果ping通过，则写入所述第一任务拓扑中的数据流的信息至关系型数据库管理从节点中。

再一方面，提供一种集群，所述集群包括用于运行任务拓扑的至少两台计算机，所述集群还包括：关系型数据库管理主节点和包括如权利要求5至8任一项所述的不同任务拓扑间共享数据流的装置的集群服务器；

所述集群服务器连接于各个计算机和所述关系型数据库管理主节点之间。

进一步地，所述集群还包括：关系型数据库管理从节点，所述关系型数据库管理从节点与所述关系型数据库管理主节点和所述集群服务器分别连接，所述关系型数据库管理主节点和所述关系型数据库管理从节点之间通过Push和增量更新机制来保持数据的同步。

在本发明实施例，在集群中增加关系型数据库管理节点，利用关系型数据库实现Topology中Stream的信息的共享存储，当新的Topology需要从已有的Topology中订阅数据流时，从关系型数据库管理节点获取所需Stream的信息，新的Topology根据获取到的Stream的信息订阅所需Stream，从而实现不同Topology之间Stream的流动。这种任务拓扑间共享数据流的方法相比现有技术不容易出错，且效率高。

附图说明

图1是Twitter Storm中的一个Topology的结构示意图；

图2是Twitter Storm中一个典型的流式应用场景的示意图；

图3是在图2所示的流式应用场景中增加Topology2后，最直观的实现方案的示意图；

图4是现有的Storm中，在集群中增加新的Topology后，第一种集群的Topology结构示意图；

图5是现有的Storm中，在集群中增加新的Topology后，第二种集群的Topology结构示意图；

图6是本发明实施例一提供的不同任务拓扑间共享数据流的方法的实现流程图；

图7是本发明实施例一提供的Topology1的结构示意图；

图8是本发明实施例一提供的Topology1中的数据流信息的组成图；

图9是本发明实施例一提供的第二任务拓扑从第一任务拓扑订阅stream113，并对订阅到的stream113进行处理，生成stream115的过程示意图；

图10是本发明实施例二提供的不同任务拓扑间共享数据流的装置的结构框图；

图11是本发明实施例三提供的集群的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在本发明实施例中，在集群中增加关系型数据库管理节点，先写入第一任务拓扑中的数据流的信息至关系型数据库管理节点中；再从关系型数据库管理节点中获取第二任务拓扑需要订阅的数据流的发布信息，所述需要订阅的数据流是所述第一任务拓扑中的一条数据流；最后发布所述第二任务拓扑至集群中，所述第二任务拓扑读取所述发布信息，并根据所述发布信息订阅所述第一任务拓扑中的相应数据流。

以下结合具体实施例对本发明的实现进行详细描述：

实施例一

图6示出了本发明实施例一提供的不同任务拓扑间共享数据流的方法的实现流程，该不同任务拓扑间共享数据流的方法可以运行在包括用于运行不同任务拓扑的至少两台计算机、集群服务器和关系型数据库管理节点的集群中，该集群可以是Yahoo！S4、Twitter Storm等以流数据为数据源的集群中，本实施例中以Twitter Storm集群为例，现以该集群中的集群服务器侧为例进行说明，详述如下：

在步骤S601中，发布第一任务拓扑至集群中。

在本实施例中，集群服务器将第一任务拓扑发布至集群中，所述第一任务拓扑开始在所述集群中运行。第一任务拓扑的结构如图7中的Topology1所示，Topology1中的数据流包括stream112、stream113和stream114，其中stream112是人口数据流，stream113是大于20岁的数据流，stream114是性别为男的数据流。

在步骤S602中，获取所述第一任务拓扑中的数据流的信息。

在Java中将数据写入远程关系型数据库管理节点，可以利用现有的成熟框架Hibernate，Hibernate是一种Java语言下的对象关系映射解决方案，它为面向对象的领域模型到传统的关系型数据库的映射，提供了一个使用方便的框架。用Hibernate将数据流的信息写入关系型数据库管理节点中主要有三部分工作：

S1:集群服务器下载关系型数据库的JDBC驱动，在配置文件中指定远程关系型数据库管理节点的ip地址和端口；

S2:在Java中定义数据流的信息的存储模型(数据字段)；

S3:用Java编写Hibernate驱动代码，定义Hibernate操作数据的核心代码，该核心代码包括更新数据、插入数据、删除数据、根据id查找以及查找多个记录的代码。在本实施例中，数据流的信息以对象的形式存储，其存储模型代码如下：

在Storm中，Topology由Spout和Bolt组成，Topology所有数据流的发布订阅信息在初始化的时候封装成TopologyContest类，保存在TopologyContest类中，每个Topology都有对应的TopologyContest实例化的对象，其只能在该Topology中可访问。每个Spout和Bolt在开始执行时都会继承一个BaseSpout或者BaseBolt，重写prepare函数，prepare函数定义如下所示：

public void prepare(Map stormConfi, TopologyContest context,OutputCollector collector){

}

Prepare传入TopologyContest context，其保存Topology中数据流的发布订阅信息，因此可以在prepare函数中获取当前Spout或者Bolt中数据流的信息，然后将其写入关系型数据库管理节点中。

具体，通过prepare((Map stormConfi, TopologyContest context,OutputCollector collector)函数获取数据流的信息的代码如下：

在步骤S603中，写入所述第一任务拓扑中的数据流的信息至关系型数据库管理节点中。

在本实施例中，数据流的信息包括数据流的标识id、数据流所在的任务拓扑topology信息、数据流所在节点的ip信息、数据流所在节点的端口信息port。该数据流的信息以表的形式保存在关系型数据库管理节点中，如图8中所示。其中，ip和port组成一条数据流的发布信息。

具体的，集群服务器可以通过调用prepare((Map stormConfi,TopologyContest context,OutputCollector collector)函数写入数据流的信息至关系型数据库管理节点中，prepare函数的代码如下：

关系型数据库管理节点是安装有关系型数据库管理系统的节点，该关系型数据库管理系统可以是MySQL系统，也可以是Oracle、SQL Server、Sybase、DB2、Access等系统，在本实施例中不做限制，以下以MySQL节点为例来进行说明。

优选地，采用关系型数据库MySQL做为共享数据流的信息存储的介质，MySQL虽然有性能、安全方面的优势，但是其是基于单机的，如果该节点出现故障，则不同Topology之间将无法共享数据流。在本实施例中，对MySQL节点进行主从备份，这样当主节点出现故障，则从节点作为新的共享数据流的信息的存储介质，来进行容错。

具体的，容错过程如下：

S1、集群服务器读取保存有MySQL主从节点的地址信息的配置文件，得到MySQL主从节点的地址信息；

S2、集群服务器开始ping MySQL主节点的地址，如果ping通过，说明MySQL主节点运行正常，写入第一任务拓扑中的数据流的信息至关系型数据库管理主节点中，否则转向S3；

S3、MySQL主节点无法ping通过，说明该MySQL主节点已经无法工作，转向ping MySQL从节点，如果可以ping通过，则集群服务器写入第一任务拓扑中的数据流的信息至关系型数据库管理从节点中。

MySQL作为存储共享数据流的信息的媒介，其主、从节点数据的同步是需要解决的重要问题，我们通过push和增量更新机制来保持数据的同步。Push机制作为数据同步的一种常见方式，核心思想为：当MySQL主节点数据发生变动时，把数据推送给MySQL从节点，从而保持数据的一致性。增量更新机制作为一种节约资源的方式，核心思想为：每次只把增加或者减少的部分传输出去，而不传送整个数据集。

基于push和增量的数据同步机制如下：

S11、MySQL主节点接收新的数据流的信息，本地计算相对上次增量数据(增加还是减少)；

S12、MySQL主节点主动连接MySQL从节点，把增量数据的标识push给MySQL从节点；

S13、MySQL从节点接收MySQL主节点push的增量数据的标识，根据所述增量数据的标识增加或者删除MySQL从节点的数据记录，保持与MySQL主节点的同步。

在步骤S604中，从关系型数据库管理节点中获取第二任务拓扑需要订阅的数据流的发布信息，所述需要订阅的数据流是所述第一任务拓扑中的一条数据流。

在本实施例中，如果第二任务拓扑需要订阅第一任务拓扑中的stream113，则集群服务器向关系型数据库管理节点请求stream113的发布信息。

一旦数据写入关系型数据库管理节点，就可以利用Hibernate像对象访问一样轻松获取数据流的信息，核心操作接口如下：

Stream stream＝HibernateDao.getStreamById(String id)；

HibernateDao为Hibernate的驱动代码，getStreamById为实现的接口函数，该函数传入一个数据流的id，返回一条数据流的对象stream，stream中包含该数据流的ip信息和端口信息等。Strom不同组件(Spout和Bolt)之间的通信协议为ZeroMQ，其为一个高效的消息中间件，其订阅函数的核心参数为消息的ip信息和端口号，在新的Topology订阅其他Topology的核心代码如下：

其中，集群服务器发送请求发布信息的指令至关系型数据库管理节点，该指令中包括需要订阅的数据流的标识id，关系型数据库管理节点接收到该指令后，将与该标识id对应的ip和port发送给集群服务器。集群服务器接收到stream113的ip和port后，使第二任务拓扑根据该ip和port订阅第一任务拓扑中的stream113。

集群服务器存储接收到的ip和port，第二任务拓扑运行时，只要读取该ip和port，就能订阅到与该ip和port对应的数据流。

具体的，集群服务器将接收到的ip和port写入第二任务拓扑的配置文件，第二任务拓扑运行时，只要读取该配置文件，就能订阅到与该ip和port对应的数据流。

需要说明的是，本实施例中的第一任务拓扑是指先发布在集群中运行的任务拓扑，第二任务拓扑是指在第一任务拓扑之后发布到集群中，且需要订阅第一任务拓扑中的数据流之后才可以发布并运行的任务拓扑。

在步骤S605中，发布所述第二任务拓扑至集群中，所述第二任务拓扑读取所述发布信息，并根据所述发布信息订阅所述第一任务拓扑中的相应数据流。

在本实施例中，集群服务器发布第二任务拓扑至集群中后，第二任务拓扑即可在集群中开始运行，在运行的过程中，第二任务拓扑从集群服务器读取第二任务拓扑需要订阅的数据流的发布信息，并根据所述发布信息中包括的ip和port订阅相应的数据流，并对订阅到的数据流进行处理，生成新的数据流。比如，若第二任务拓扑需要订阅的数据流为第一任务拓扑的stream113，则第二任务拓扑读取stream113的ip和port，根据stream113的ip和port订阅stream113，并对订阅到的stream113进行处理，生成新的数据流。

具体的，集群服务器可以将从关系型数据库管理节点获取到的发布信息写入第二任务拓扑的配置文件，当第二任务拓扑被发布到集群中后，第二任务拓扑读取该配置文件，并根据该配置文件中包括的ip和port订阅相应的数据流，并对订阅到的数据流进行处理，生成新的数据流。

比如，本实施例中，通过第二任务拓扑的Spout2订阅到第一任务拓扑的stream113后，通过Bolt3处理，生成stream115，stream115是性别为女的数据流。图9示出了第二任务拓扑从第一任务拓扑订阅stream113，并对订阅到的stream113进行处理，生成stream115的过程示意图。

另外，优选地，所述方法还包括：

集群服务器获取第二任务拓扑生成的数据流的信息；

集群服务器写入所述第二任务拓扑生成的数据流的信息至关系型数据库管理节点中。

具体的，集群服务器获取到第二任务拓扑生成的stream115的信息后，可以将stream115的信息写入至关系型数据库管理节点中，以供其它任务拓扑调用。

本实施例，在集群中增加关系型数据库管理节点，利用关系型数据库实现Topology中Stream的信息的共享存储，当新的Topology需要从已有的Topology中订阅数据流时，从关系型数据库管理节点获取所需Stream的信息，新的Topology根据获取到的Stream的信息订阅所需Stream，从而实现不同Topology之间Stream的流动。这种任务拓扑间共享数据流的方法相比现有技术不容易出错，且效率高。

另外，本实施例，关系型数据库管理节点采用关系型数据库系统，关系型数据库以集合论和关系代数为基础，在数据安全，权限控制，性能和功耗上有不俗表现，且其支持ACID特性，可以完全保证数据的正确和可靠。虽然基于单节点的关系型数据库在容错上有劣势，但是本实施例中的集群中包括关系型数据库管理主从节点，解决了基于单节点的关系型数据库在容错上的劣势。

本领域普通技术人员可以理解实现上述各实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，相应的程序可以存储于一计算机可读取存储介质中，所述的存储介质，如ROM/RAM、磁盘或光盘等。

实施例二

图10示出了本发明实施例二提供的不同任务拓扑间共享数据流的装置的具体结构框图，为了便于说明，仅示出了与本发明实施例相关的部分。该不同任务拓扑间共享数据流的装置10可以是内置于集群服务器中的软件单元、硬件单元或者软硬件结合的单元，该不同任务拓扑间共享数据流的装置10包括：第一拓扑发布单元101、第一数据流信息获取单元102、第一数据流信息写入单元103、发布信息获取单元104、发布信息写入单元105和第二拓扑发布单元106。

其中，第一拓扑发布单元101，用于发布第一任务拓扑至集群中；

第一数据流信息获取单元102，用于获取所述第一任务拓扑中的数据流的信息；

第一数据流信息写入单元103，用于写入所述第一任务拓扑中的数据流的信息至关系型数据库管理节点中；

发布信息获取单元104，用于从关系型数据库管理节点中获取第二任务拓扑需要订阅的数据流的发布信息，所述需要订阅的数据流是所述第一任务拓扑中的一条数据流；

第二拓扑发布单元105，用于发布所述第二任务拓扑至集群中，所述第二任务拓扑读取所述发布信息，并根据所述发布信息订阅所述第一任务拓扑中的相应数据流。

进一步地，所述不同任务拓扑间共享数据流的装置10还包括：

具体的，所述数据流的信息包括：数据流的标识、数据流所在的任务拓扑信息、数据流所在节点的ip信息、数据流所在节点的端口信息；

具体的，所述第一数据流信息写入单元103包括：

本发明实施例提供的不同任务拓扑间共享数据流的装置可以应用在前述对应的方法实施例一中，详情参见上述实施例一的描述，在此不再赘述。

值得注意的是，上述装置实施例中，所包括的各个单元只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

实施例三

图11示出了本发明实施例三提供的集群的具体结构框图，为了便于说明，仅示出了与本发明实施例相关的部分。该集群11包括：用于运行不同任务拓扑的至少两台计算机111、集群服务器112和关系型数据库管理主节点113。

其中，一个任务拓扑可以运行于一台或者多台计算机中，每台计算机均与集群服务器112保持连接；

集群服务器112中内置有实施例二中所述的不同任务拓扑间共享数据流的装置；

集群服务器112连接于各个计算机和关系型数据库管理主节点113之间。

优选地，集群11还包括关系型数据库管理从节点114。

关系型数据库管理从节点114与关系型数据库管理主节点和集群服务器112分别连接，关系型数据库管理主节点113和关系型数据库管理从节点114之间通过Push和增量更新机制来保持数据的同步。

本发明实施例提供的集群可以应用在前述对应的方法实施例一中，详情参见上述实施例一的描述，在此不再赘述。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims

1.一种不同任务拓扑间共享数据流的方法，其特征在于，所述方法包括：

发布第一任务拓扑至集群中；

获取所述第一任务拓扑中的数据流的信息；

2.如权利要求1所述的方法，其特征在于，在所述发布第二任务拓扑至集群中之后，还包括：

获取所述第二任务拓扑生成的数据流的信息；

3.如权利要求1所述的方法，其特征在于，所述数据流的信息包括：数据流的标识、数据流所在的任务拓扑信息、数据流所在节点的ip信息、数据流所在节点的端口信息；

4.如权利要求1所述的方法，其特征在于，所述写入所述第一任务拓扑中的数据流的信息至关系型数据库管理节点中包括：

5.一种不同任务拓扑间共享数据流的装置，其特征在于，所述装置包括：

第一拓扑发布单元，用于发布第一任务拓扑至集群中；

6.如权利要求5所述的装置，其特征在于，所述装置还包括：

7.如权利要求5所述的装置，其特征在于，所述数据流的信息包括：数据流的标识、数据流所在的任务拓扑信息、数据流所在节点的ip信息、数据流所在节点的端口信息；

8.如权利要求5所述的装置，其特征在于，所述第一数据流信息写入单元包括：

9.一种集群，所述集群包括用于运行任务拓扑的至少两台计算机，其特征在于，所述集群还包括：关系型数据库管理主节点和包括如权利要求5至8任一项所述的不同任务拓扑间共享数据流的装置的集群服务器；

10.如权利要求9所述的集群，其特征在于，所述集群还包括：关系型数据库管理从节点，所述关系型数据库管理从节点与所述关系型数据库管理主节点和所述集群服务器分别连接，所述关系型数据库管理主节点和所述关系型数据库管理从节点之间通过Push和增量更新机制来保持数据的同步。