CN109725916B - 流处理的拓扑结构更新系统和方法 - Google Patents

Abstract

本发明公开了一种流处理的拓扑结构更新系统和方法。其中，该系统包括：任务管理器，用于检测第一状态机的第一状态，并依据上述状态产生控制消息，其中，上述第一状态用于触发对流处理的拓扑结构进行管理；任务执行器，用于接收上述控制消息；并在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作。本发明解决了现有的大数据流处理架构不适合在线进行流拓扑更新的技术问题。

Description

流处理的拓扑结构更新系统和方法

技术领域

本发明涉及数据处理领域，具体而言，涉及一种流处理的拓扑结构更新系统和方法。

背景技术

随着互联网技术的发展，越来越多的行业领域要求对数据进行快速高效的处理，数据处理的时效性越来越高，如交通监管部门每天都要产生海量的监控数据，这些数据以流的形式源源不断进入系统，需要以最快的速度进行处理；再如新闻时效性也要求第一时间将重大事件推荐给用户，以增大用户粘性带来可观流量。

图1a是根据本发明实施例的一种现有技术中的应用的DAG拓扑示意图,如图1a所示，当前部署运行的DAG有Task1、Task2、Source和Sink。现有的流处理框架在提交了应用并完成DAG部署后，将不能对DAG进行运行时在线的修改，即不能增加和删除DAG任务节点，也不能对现有任务节点处理逻辑进行变更，除非停止应用，重新提交修改后的新DAG，这对于7*24小时和不允许停机的应用是不可接受的。这种需求从技术上抽象，就是在已经部署的DAG上，动态的增加或删除节点(同时增加或删除相应的边)、或者用新的处理逻辑替代节点现有的处理逻辑。也即，当前业界普遍采用的大数据处理架构MapReduce，着重于数据处理的吞吐率，不适合在线进行流拓扑更新。

针对上述现有的大数据流处理架构不适合在线进行流拓扑更新的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种流处理的拓扑结构更新系统和方法，以解决现有的大数据流处理架构不适合在线拓扑更新的技术问题。

根据本发明实施例的一个方面，提供了一种流处理的拓扑结构更新系统，包括：任务管理器，用于检测第一状态机的第一状态，并依据上述状态产生控制消息，其中，上述第一状态用于触发对流处理的拓扑结构进行管理；任务执行器，用于接收上述控制消息；并在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作。

进一步地，上述第一状态包括：第一子状态、第二子状态和第三子状态；其中：上述第一子状态，用于表示当前任务所处的状态或者接收上述拓扑结构的更新信息；上述第二子状态，用于部署更新后的拓扑结构；上述第三子状态，用于在上述拓扑结构的部署出现异常时，将上述拓扑结构恢复为异常之前的版本。

进一步地，上述任务管理器，还用于在上述第一子状态接收到上述拓扑结构的更新信息时，切换至上述第二子状态；在上述第一子状态接收到异常通知时，由上述第一子状态切换至上述第三子状态；以及在上述第二子状态下上述拓扑结构的部署出现异常时，由上述第二子状态切换至上述第三子状态。

进一步地，上述第二状态包括：第四子状态、第五子状态、第六子状态和第七子状态；其中：上述第四子状态，用于表示上述当前任务执行器中任务的执行状态，并在接收到预设消息时，切换至上述第五子状态；上述第五子状态，用于对当前任务执行指定操作，上述指定操作包括：启动上述任务结构中的任务、改变任务执行参数；第六子状态，用于在检测到用于启动任务的消息时，启动与上述第六子状态对应的拓扑结构中的任务；上述第六子状态，用于停止上述拓扑结构中的所有任务，并切换至上述第五子状态，以恢复上述拓扑结构异常前的版本。

进一步地，上述任务包括：Akka系统中的Actor；上述任务执行器包括：虚拟机进程。

进一步地，上述动作包括以下至少之一：上述拓扑结构中节点的增加、节点的删除、修改节点间的逻辑关系。

进一步地，上述拓扑结构包括：有向无环图DAG。

根据本发明实施例的一个方面，提供了一种流处理的拓扑结构更新方法，包括：获取控制消息，其中，上述控制消息为依据第一状态机的第一状态产生的消息，上述第一状态用于触发对流处理的拓扑结构进行管理；在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作。

根据本发明实施例的一个方面，提供了一种存储介质，上述存储介质包括存储的程序，其中，在上述程序运行时控制上述存储介质所在设备执行上述的流处理的拓扑结构更新方法。

根据本发明实施例的一个方面，提供了一种存储介质，上述处理器用于运行程序，其中，上述程序运行时执行上述的流处理的拓扑结构更新方法。

在本发明实施例中，采用在线更新的方式，通过任务管理器，用于检测第一状态机的第一状态，并依据上述状态产生控制消息，其中，上述第一状态用于触发对流处理的拓扑结构进行管理；任务执行器，用于接收上述控制消息；并在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作，达到了无需重启应用即可完成流处理的在线变更的目的，从而实现了流处理逻辑的热部署和在线更新的技术效果，进而解决了现有的大数据流处理架构不适合在线拓扑更新的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1a是根据本发明实施例的一种现有技术中的应用的DAG拓扑示意图；

图1b是根据本发明实施例的一种运行时增加新任务节点Task3后的DAG拓扑示意图；

图2是根据本发明实施例的一种拓扑结构更新系统的结构示意图；

图3是根据本发明实施例的一种可选的拓扑结构更新系统的结构示意图；

图4根据本发明实施例的一种可选的第一状态中的子状态的转换关系的结构示意图；

图5是根据本发明实施例的一种可选的第二状态中的子状态的转换关系的结构示意图；

图6是根据本发明实施例的一种任务执行器启动一个任务的执行序列示意图；

图7是根据本发明实施例的一种可选的态转换关系示意图；

图8根据本发明实施例的一种流处理的拓扑结构更新方法的步骤流程图；以及

图9是根据本发明实施例的一种流处理的拓扑结构更新装置的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在解释本申请各个具体实施例之前，对申请中各个实施例所涉及的解决现有技术问题的思路进行解释说明，具体的，可以提供两种思路解决上述现有的技术问题：

首先，图1b是根据本发明实施例的一种运行时增加新任务节点Task3后的DAG拓扑示意图,如图1b所示，第一种是对当前的DAG直接进行在线的修改，增加或删除相应的节点和边。但是上述解决方法，仍然存在如下问题：DAG表示的是一种逻辑的处理关系，实际部署时每个DAG任务节点可能具有多个并行的运行实例，修改一个逻辑上的Task节点，实际需要修改多个它的运行时实例，并且这些实例还可能部署运行在不同的物理机器上，实现上会比较复杂。

其次，另一种解决思路是热部署DAG，即系统实现为状态机，可以有不同的运行状态，这些状态按照设计好的流转规则进行切换。不同的状态完成不同的功能，比如某个状态负责停止当前DAG任务，撤销DAG部署，然后切换到下一个状态部署新的DAG，部署完成后再切换回正常运行状态。系统以一种状态机的方式运行，不需要停止应用即可完成DAG之间的更换，这种DAG更换的时间对用户几乎可忽略不计，在本申请的实现过程中，通常在几十毫秒之内就能完成。其中，有限状态机可被视为一组关系：

State(S)*Event(E)—>Actions(A)，State(S')其中，可以将上述关系描述为：如果在状态S发生了事件E，应该执行动作A并切换到状态S'。

在一种可选的实施例中，Actor SeasonVariation定义了spring和summer两个Receive类型的实例，初始设置为spring。如果这时Actor收到Season消息，它打印出“It’sspring now！”；如果收到ToSummer消息，Actor通过context.become(summer)调用切换到新状态summer。在新状态如果收到Season消息，打印出的消息将是“It’s summer now！”。基于上述Akka状态机模型，通过替换DAG变更的部分，我们实现了一个可在线更改DAG拓扑的实时流处理平台。

实施例1

本发明实施例提供了一种流处理的拓扑结构更新系统实施例，图2是根据本发明实施例的一种拓扑结构更新系统的结构示意图，如图2所示，该系统包括：任务管理器10和任务执行器12，其中，

任务管理器10，用于检测第一状态机的第一状态，并依据上述状态产生控制消息，其中，上述第一状态用于触发对流处理的拓扑结构进行管理；任务执行器12，用于接收上述控制消息；并在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作。

在本发明实施例中，采用在线更新的方式，通过任务管理器，用于检测第一状态机的第一状态，并依据上述状态产生控制消息，其中，上述第一状态用于触发对流处理的拓扑结构进行管理；任务执行器，用于接收上述控制消息；并在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作，达到了无需重启应用即可完成流处理的在线变更的目的，从而实现了流处理逻辑的热部署和在线更新的技术效果，进而解决了现有的大数据流处理架构不适合在线拓扑更新的技术问题。

在一种可选的实施例中，上述任务执行器包括：虚拟机进程；上述任务包括：Akka系统中的Actor。

需要说明的是，“Akka”作为一种适用于高并发分布式环境下的消息驱动工具和运行时框架，提供了基于Actor的编程模型。Actor是Akka中最小的带状态计算单元，基于输入的消息类型完成不同的动作和响应。Actor可定义多个Receive，分别表示Actor可接收的消息类型和响应动作的集合，通过Akka上下文Context的become调用在不同Receive间切换，从而实现Actor不同的处理行为。

在一种可选的实施例中，上述动作包括以下至少之一：上述拓扑结构中节点的增加、节点的删除、修改节点间的逻辑关系。其中，上述拓扑结构包括：有向无环图DAG。

图3是根据本发明实施例的一种可选的拓扑结构更新系统的结构示意图，如图3所示，本申请提供的拓扑结构更新系统的逻辑结构可以分为两层，上层为任务管理器10，也即Master主控点，负责管理系统资源、对系统进行监控、对任务管理和调度，提供错误恢复、配置管理、元数据管理等多种功能。如图3所示，上述任务管理器10可以多实例部署，各个实例之间动态可以选举一个Leader，别的实例则处于Standby状态，在Leader挂掉时通过重新选举产生新的Leader接管系统，保证系统的高可用性。

仍如图3所示，上述拓扑结构更新系统的逻辑结构下层可以为任务执行器，运行于集群中多个物理服务器上，每个任务执行器是一个Java虚拟机进程，接收来自Master的任务控制命令，对所有部署在虚拟机内的任务进行生命周期管理、资源分配。

需要说明的是，分布式流处理模式作为一种通用的计算模型得到了长足发展，它是对无界数据持续的分析处理，在秒级甚至毫秒级完成响应。由于本申请着重于流处理拓扑在线更新的方法，因此，在各个实施例中，着重关注上述任务管理器和任务执行器的功能与实现。

在一种可选的实施例中，分布式流处理通常以有向无环图(Directed AcyclicGraphs，DAGs)的形式进行表示，DAG节点称之为任务，表示对数据的分析处理逻辑，数据流经过一系列的任务从源点流动到终点，完成流水线式的处理，因此，DAG是一个流工作的拓扑表示。当前有很多的流处理框架，比如Spark、Apache Flink、Storm等，这些系统虽然在使用方法、API上不同，但它们本质都是对提交的应用进行解析，将用户的处理逻辑转换为DAG表示，然后将DAG中的任务部署到分布式集群上，实现流数据在任务节点间的高效分发、处理和汇聚；其中，应用是流处理提交的基本单元，一个应用对应一个DAG表示。

通过本申请上述实施例，基于Akka状态机实现流计算拓扑在线更新，进而可以在线更新在应用不重启的条件下，实现拓扑节点的动态增加、删除和替换等变更，从而实现了流处理逻辑的热部署和在线更新，需要说明的是，上述实施方案具有广泛的应用前景，尤其对7*24小时不允许停机的场合更具潜在意义。

作为一种可选的实施例，上述第一状态包括：第一子状态、第二子状态和第三子状态；其中：上述第一子状态，用于表示当前任务所处的状态或者接收上述拓扑结构的更新信息；上述第二子状态，用于部署更新后的拓扑结构；上述第三子状态，用于在上述拓扑结构的部署出现异常时，将上述拓扑结构恢复为异常之前的版本。

需要说明的是，上述拓扑结构的更新信息，也即新版本的拓扑结构信息。

在一种可选的实施例中，上述任务管理可以是任务管理器Master的一个功能模块，每个任务管理器对应一次应用提交，即对一个DAG拓扑进行管理。功能包括DAG变更后的热部署、任务状态查询、任务执行过程错误处理等。

具体的，上述任务管理器可以实现为状态机，包括三种状态：就绪态(上述第一子状态)、恢复态(上述第二子状态)、动态部署态(上述第三子状态)，图4根据本发明实施例的一种可选的第一状态中的子状态的转换关系的结构示意图，如图4示，这三种状态之间的切换利用了Akka状态机的状态切换功能，不需要重启应用即可完成处理行为的在线变更。

为方便理解本申请实施例，以下结合具体示图4对上述第一状态的三种子状态进行详细说明：

就绪态：表示任务已经部署完成正在执行的状态，或者表示初始时为空正等待接收DAG拓扑。其中，就绪态包括三类消息处理逻辑，分别是onQuery、onError、onNewDag，onQuery处理任务状态查询；onError对收到的错误通知进行处理，比如任务执行器宕机或执行错误等(因为Akka中Master是任务执行器的父节点，能收到任务执行器Stopped和异常消息)，将任务状态切换到“恢复态”；onNewDag接收DAG部署消息，消息中包含新版本的DAG拓扑结构。此处的处理逻辑为：将新版本DAG与上一版本DAG进行对比，分解出DAG哪些节点是新增节点、哪些受影响需要修改节点、哪些是需要删除的节点，未受影响节点则不需要任何操作。对于存在新增节点的情况，可以选择复用现有任务执行器，或者选择如图4所示的“1.新拓扑DAG”处启动新的任务执行器(取决于资源调度情况)，然后执行如图4所示的“2.新拓扑DAG”将状态切换到“动态部署态”。

动态部署态：停止现有DAG任务节点，部署新版本的DAG拓扑，通过startDag完成这种操作。“动态部署态”和“恢复态”共用startDag进行DAG部署，只是在“恢复态”部署的是DAG最近的上一版本。startDag是DAG部署的总控，它向资源管理器申请资源，向任务调度器查询物理部署计划，根据计划在不同的任务执行器上Launch任务、Change任务、Stop任务，通过消息交互实现DAG的部署。除此之外，动态部署态还可以包括onQuery和onMessageLoss，其中，onQuery用于状态查询，onMessageLoss用于处理如图4所示的“消息丢失/任务执行器停止”并切换到“恢复态”。

恢复态：表示任务执行遇到了异常或DAG部署过程产生了问题，需要进行恢复的状态。例如，物理服务器宕机、处理逻辑抛出异常、消息丢失、DAG任务节点某个物理服务器上部署不成功等问题，此时通过“恢复态”恢复最近一次无错的DAG部署。“就绪态”和“动态部署态”均有可能切换到“恢复态”，其中，前者将恢复的DAG拓扑是进入“就绪态”最近一次正确部署的DAG拓扑，后者指的是部署新DAG时被替换的那一个DAG拓扑，通过startDag完成这种拓扑的变更和部署。

需要说明的是，如果startDag执行过程中产生资源不可用的情况，这时状态仍然停留在“恢复态”，但尝试恢复时间上更往前的一次DAG拓扑，直至某次部署成功或追溯到DAG历史链的终点，即DAG为空为止。onExecutorError处理恢复时发生任务执行器宕机或异常的情况，根据预定义策略要么重启执行器要么停止任务。

本申请还提供了一种可选的实施方式，上述任务管理器，还用于在上述第一子状态接收到上述拓扑结构的更新信息时，切换至上述第二子状态；在上述第一子状态接收到异常通知时，由上述第一子状态切换至上述第三子状态；以及在上述第二子状态下上述拓扑结构的部署出现异常时，由上述第二子状态切换至上述第三子状态。

在一种可选的实施例中，上述第二状态包括：第四子状态、第五子状态、第六子状态和第七子状态；其中：上述第四子状态，用于表示上述当前任务执行器中任务的执行状态，并在接收到预设消息时，切换至上述第五子状态；上述第五子状态，用于对当前任务执行指定操作，上述指定操作包括：启动上述任务结构中的任务、改变任务执行参数；第六子状态，用于在检测到用于启动任务的消息时，启动与上述第六子状态对应的拓扑结构中的任务；上述第六子状态，用于停止上述拓扑结构中的所有任务，并切换至上述第五子状态，以恢复上述拓扑结构异常前的版本。

作为一种可选的实施例，上述任务执行器在Akka树结构中是任务管理器的子节点，它接收任务管理器的消息启动、改变和停止任务的执行，上述任务管理器本身实现为包含四个状态的状态机。

图5是根据本发明实施例的一种可选的第二状态中的子状态的转换关系的结构示意图，如图5所示，上述第二状态包括：ACTIVE状态(上述第四子状态)、PHASE1状态(上述第五子状态)、PHASE2状态(上述第六子状态)和RECOVERY状态(上述第七子状态)，为方便理解本申请实施例，以下结合具体示图4对上述第二状态的四种子状态进行详细说明：

ACTIVE状态：是一种任务执行器的稳态，表示对任务的启动、改变或停止操作已经完。该状态能接收StopTask消息，对相应的任务执行停止操作。当收到来自任务管理器的LaunchTasks或ChangeTasks消息时，切换到“PHASE1”态。

PHASE1状态：该状态可执行的操作包括启动任务、改变任务执行参数、接收TaskRegistered消息以追踪注册的任务。任务管理器在所有任务都已经部署后，向任务执行器发送TaskLocationReady消息，从而使处于“PHASE1”状态的任务执行器切换到“PHASE2”状态。“PHASE1”状态也接收来自任务管理器的RestartTasks消息，以恢复版本为dagVersion的DAG拓扑，状态切换到“RECOVERY”状态。

PHASE2状态：类似于一个屏障，在收到任务管理器的StartAllTasks消息后，对自己管理的属于当前DAG的任务发送StartTask消息，开始任务的运行。“PHASE2”状态也接收来自任务管理器的RestartTasks消息，以恢复版本为dagVersion的任务，状态切换到“RECOVERY”状态。

RECOVERY状态：为恢复某个DAG版本的拓扑做准备，这需要停止当前DAG版本的所有任务。当所有当前运行的任务都被停止后(Remain＝0)，状态切换回“PHASE1”进行待恢复版本DAG的部署。由于任务执行器在Akka管理结构中是任务的父节点，因此能收到任务终止的消息TaskStopped，从而能判断尚未关闭的任务数。

图6是根据本发明实施例的一种任务执行器启动一个任务的执行序列示意图，如图6所示，处于状态“PHASE1”的任务执行器收到任务管理器的启动任务命令，执行LaunchTasks创建任务，任务被创建后向任务管理器注册，任务管理器收到注册后发送TaskRegistered向任务执行器反馈注册成功。当任务管理器需要创建的所有任务(可能位于多个任务执行器)都创建成功并注册后，它向所有的任务执行器发送TaskLocationReady消息，从而导致任务执行器由状态“PHASE1”切换到“PHASE2”。任务管理器在处理了必要的资源记账、持久化新版本的DAG表示、进行时钟初始化后，发送消息StartAllTasks到处于“PHASE2”的任务执行器，由任务执行器发送消息StartTask开始任务的执行，同时自身状态切换到“ACTIVE”，从而完成Launch一个任务的操作。

图7是根据本发明实施例的一种可选的态转换关系示意图，如图7所示，任务实现为Akka的Actor，包含三个状态：任务启动时向任务管理器发送RegisterTask消息注册，然后进入“等待任务注册”状态；当收到任务管理器的确认消息TaskRegistered进入“等待任务开始”状态；当任务管理器需要部署的任务都已经启动后，它向任务执行器发送StartAllTasks消息，任务执行器收到消息后会向任务发送StartTask消息，任务进入到“处理消息”状态，在该状态任务可以接收ChangeTask消息，以改变任务执行的操作逻辑。

其中，需要说明的是，上述任务可以但不限于以Java Jar的形式存在，由提交应用API或增删节点API上传到全局存储，具有唯一的路径标识，由执行任务的任务执行器运行时加载、解析后创建任务Actor，完成任务的运行时部署。

在一种可选的实施例中，关于动态增加新的节点，以下进行API描述：由于DAG部署时每个任务节点都会由系统分配唯一Id，当需要为DAG增加新的节点和边时，需要指定新的边引自DAG的哪些节点，其API如下：

addVertext(dag:DAG,upstreamProcessorIds:Array[Id],edges:Array[EdgeDescription],newVertext:VertextDescription,newVersion:Int)

其中，上述参数“dag”表示当前的DAG拓扑；参数“upstreamProcessorIds”表示新加节点起源自dag中的哪些节点，类型为Id的数组；参数“edges”表示为类型EdgeDescription的数组，这里的边是DAG逻辑上的边，逻辑边在实际部署完成后可能对应多条物理上的事件分发通道。参数“EdgeDescription”表示为从逻辑上描述事件在这些物理分发通道中的分发逻辑，比如基于哈希或基于轮转等；参数newVertext类型为VertextDescription，表示节点处理逻辑，从jar包中解析；参数newVersion表示新的版本号，每次增1。

在另一种可选的实施例中，动态增加新的节点的执行过程如下所示：系统基于当前DAG，增加API中指定的节点，生成新版本的DAG。此时任务管理器处于“就绪态”，onNewDag处理逻辑接收到新版本的DAG后，要么启动新的任务执行器要么用现有的某个任务执行器部署新节点(取决于资源调度情况)，然后将任务管理器状态切换到“动态部署态”，由startDag向资源管理器申请资源、向任务调度器请求部署计划，进行DAG节点在任务执行器上的部署(此处只是部署一个新的节点，原有不受影响的DAG节点部署位置不变)，任务执行器上的部署流程如图5所示，待节点部署完成，任务管理器切换回“就绪态”，新的DAG拓扑部署完成。

此外，在一种可选的实施例中，本申请还可以动态减少节点，其中，需要说明的是，减少节点的过程类似于动态增加新节点，只是减少节点是停止操作，节点所占资源需要回收。这里的节点限制为DAG的叶子节点，不允许删除中间节点，删除中间节点可能会出现多个DAG非连通的情况，使部分DAG任务流失去数据源，增加系统管理和实现的复杂度。

实施例2

根据本发明实施例，提供了一种流处理的拓扑结构更新方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图8根据本发明实施例的一种流处理的拓扑结构更新方法的步骤流程图，如图8示，该方法包括如下步骤：

步骤S102，获取控制消息，其中，上述控制消息为依据第一状态机的第一状态产生的消息，上述第一状态用于触发对流处理的拓扑结构进行管理；

步骤S104，在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作。

在本发明实施例中，采用在线更新的方式，通过获取控制消息，其中，上述控制消息为依据第一状态机的第一状态产生的消息，上述第一状态用于触发对流处理的拓扑结构进行管理；在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作，达到了无需重启应用即可完成流处理的在线变更的目的，从而实现了流处理逻辑的热部署和在线更新的技术效果，进而解决了现有的大数据流处理架构不适合在线拓扑更新的技术问题。

在一种可选的实施例中，上述步骤S102至步骤S104的执行主体可以但不限于为任务执行器，上述任务执行器包括：虚拟机进程；上述任务包括：Akka系统中的Actor。

需要说明的是，“Akka”作为一种适用于高并发分布式环境下的消息驱动工具和运行时框架，提供了基于Actor的编程模型。Actor是Akka中最小的带状态计算单元，基于输入的消息类型完成不同的动作和响应。Actor可定义多个Receive，分别表示Actor可接收的消息类型和响应动作的集合，通过Akka上下文Context的become调用在不同Receive间切换，从而实现Actor不同的处理行为。

在一种可选的实施例中，上述动作包括以下至少之一：上述拓扑结构中节点的增加、节点的删除、修改节点间的逻辑关系。其中，上述拓扑结构包括：有向无环图DAG。

如图3所示，本申请提供的拓扑结构更新系统的逻辑结构可以分为两层，上层为任务管理器10，也即Master主控点，负责管理系统资源、对系统进行监控、对任务管理和调度，提供错误恢复、配置管理、元数据管理等多种功能。如图3所示，上述任务管理器10可以多实例部署，各个实例之间动态可以选举一个Leader，别的实例则处于Standby状态，在Leader挂掉时通过重新选举产生新的Leader接管系统，保证系统的高可用性。

仍如图3所示，上述拓扑结构更新系统的逻辑结构下层可以为任务执行器，运行于集群中多个物理服务器上，每个任务执行器是一个Java虚拟机进程，接收来自Master的任务控制命令，对所有部署在虚拟机内的任务进行生命周期管理、资源分配。

需要说明的是，分布式流处理模式作为一种通用的计算模型得到了长足发展，它是对无界数据持续的分析处理，在秒级甚至毫秒级完成响应。由于本申请着重于流处理拓扑在线更新的方法，因此，在各个实施例中，着重关注上述任务管理器和任务执行器的功能与实现。

在一种可选的实施例中，分布式流处理通常以有向无环图(Directed AcyclicGraphs，DAGs)的形式进行表示，DAG节点称之为任务，表示对数据的分析处理逻辑，数据流经过一系列的任务从源点流动到终点，完成流水线式的处理，因此，DAG是一个流工作的拓扑表示。当前有很多的流处理框架，比如Spark、Apache Flink、Storm等，这些系统虽然在使用方法、API上不同，但它们本质都是对提交的应用进行解析，将用户的处理逻辑转换为DAG表示，然后将DAG中的任务部署到分布式集群上，实现流数据在任务节点间的高效分发、处理和汇聚；其中，应用是流处理提交的基本单元，一个应用对应一个DAG表示。

通过本申请上述实施例，基于Akka状态机实现流计算拓扑在线更新，进而可以在线更新在应用不重启的条件下，实现拓扑节点的动态增加、删除和替换等变更，从而实现了流处理逻辑的热部署和在线更新，需要说明的是，上述实施方案具有广泛的应用前景，尤其对7*24小时不允许停机的场合更具潜在意义。

需要说明的是，本实施例的可选或优选实施方式可以参见实施例1中的相关描述，此处不再赘述。

实施例3

本发明实施例还提供了一种用于实施上述流处理的拓扑结构更新方法的装置，图9是根据本发明实施例的一种流处理的拓扑结构更新装置的结构示意图，如图9所示，上述抽油烟机的控制装置，包括：获取模块100和触发模块102，其中，

获取模块100，用于获取控制消息，其中，上述控制消息为依据第一状态机的第一状态产生的消息，上述第一状态用于触发对流处理的拓扑结构进行管理；触发模块102，用于在上述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对上述拓扑结构执行与上述第二状态对应的动作。

此处需要说明的是，上述获取模块100和触发模块102对应于实施例2中的步骤S102至步骤S104，上述模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在计算机终端中。

需要说明的是，本实施例的可选或优选实施方式可以参见实施例1和实施例2中的相关描述，此处不再赘述。

根据本发明实施例的一个方面，提供了一种存储介质，上述存储介质包括存储的程序，其中，在上述程序运行时控制上述存储介质所在设备执行上述的流处理的拓扑结构更新方法。

根据本发明实施例的一个方面，提供了一种存储介质，上述处理器用于运行程序，其中，上述程序运行时执行上述的流处理的拓扑结构更新方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

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

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

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

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (9)

1.一种流处理的拓扑结构更新系统，其特征在于，包括：

任务管理器，用于检测第一状态机的第一状态，并依据所述第一状态产生控制消息，其中，所述第一状态用于触发对流处理的拓扑结构进行管理；

任务执行器，用于接收所述控制消息；并在所述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对所述拓扑结构执行与所述第二状态对应的动作；

其中，所述第一状态包括：第一子状态、第二子状态和第三子状态，所述任务管理器，还用于在所述第一子状态接收到所述拓扑结构的更新信息时，切换至所述第二子状态；在所述第一子状态接收到异常通知时，由所述第一子状态切换至所述第三子状态；以及在所述第二子状态下所述拓扑结构的部署出现异常时，由所述第二子状态切换至所述第三子状态。

2.根据权利要求1所述的系统，其特征在于：

所述第一子状态，用于表示当前任务所处的状态或者接收所述拓扑结构的更新信息；

所述第二子状态，用于部署更新后的拓扑结构；

所述第三子状态，用于在所述拓扑结构的部署出现异常时，将所述拓扑结构恢复为异常之前的版本。

3.根据权利要求1所述的系统，其特征在于，所述第二状态包括：第四子状态、第五子状态、第六子状态和第七子状态；其中：

所述第四子状态，用于表示当前任务执行器中任务的执行状态，并在接收到预设消息时，切换至所述第五子状态；

所述第五子状态，用于对当前任务执行指定操作，所述指定操作包括：启动任务结构中的任务、改变任务执行参数；

第六子状态，用于在检测到用于启动任务的消息时，启动与所述第六子状态对应的拓扑结构中的任务；

所述第六子状态，用于停止所述拓扑结构中的所有任务，并切换至所述第五子状态，以恢复所述拓扑结构异常前的版本。

4.根据权利要求3所述的系统，其特征在于，所述任务包括：Akka系统中的Actor；所述任务执行器包括：虚拟机进程。

5.根据权利要求1至4中任意一项所述的系统，其特征在于，所述动作包括以下至少之一：所述拓扑结构中节点的增加、节点的删除、修改节点间的逻辑关系。

6.根据权利要求1至4中任意一项所述的系统，其特征在于，所述拓扑结构包括：有向无环图DAG。

7.一种流处理的拓扑结构更新方法，其特征在于，包括：

获取控制消息，其中，所述控制消息为依据第一状态机的第一状态产生的消息，所述第一状态用于触发对流处理的拓扑结构进行管理；

在所述控制消息的触发下，触发第二状态机的第二状态，并依据该第二状态对所述拓扑结构执行与所述第二状态对应的动作；

其中，所述第一状态包括：第一子状态、第二子状态和第三子状态，在所述第一子状态接收到所述拓扑结构的更新信息时，切换至所述第二子状态；在所述第一子状态接收到异常通知时，由所述第一子状态切换至所述第三子状态；以及在所述第二子状态下所述拓扑结构的部署出现异常时，由所述第二子状态切换至所述第三子状态。

8.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行权利要求7所述的流处理的拓扑结构更新方法。

9.一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序运行时执行权利要求7所述的流处理的拓扑结构更新方法。

Images