CN116302546A - 流处理系统、状态恢复方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种流处理系统、状态恢复方法、设备及存储介质。其中，系统包括：多个工作节点；流处理任务的多个子任务分布在多个工作节点上；多个子任务中包括上游子任务和下游子任务；上游子任务所在的工作节点，用于：持久化存储上游子任务的状态；上游子任务的状态中包括上游子任务分配给下游子任务的数据，上游子任务对应有状态快照；下游子任务所在的工作节点，用于：从上游子任务的状态中获取上游子任务分配给下游子任务的数据；持久化存储下游子任务的状态；其中，下游子任务的状态中包括：下游子任务针对上游子任务的状态的消费位置；下游子任务对应有状态快照。本申请实施例提供的技术方案能够减少数据恢复后数据重算成本。

Description

流处理系统、状态恢复方法、设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种流处理系统、状态恢复方法、设备及存储介质。

背景技术

流处理是一种重要的大数据处理手段，其主要特点是其处理的数据是源源不断且实时到来的。流处理技术广泛应用在各种领域的实时处理系统中，例如：金融交易中心、web应用、通信数据管理。

目前，流数据处理主要采用分布式的计算方式，分布式流处理系统中包括多个工作节点，可以由该多个工作节点共同完成流数据的处理过程。用户提交流处理任务之后，该分布式流处理系统将该流处理任务分发给多个工作节点来处理。

容错是流处理的重要特性也是最基本的挑战，现有的流处理容错方案存在失败恢复后重算成本高的问题。

发明内容

鉴于上述问题，提出了本申请以提供一种解决上述问题或至少部分地解决上述问题的流处理系统、状态恢复方法、设备及存储介质。

于是，在本申请的一个实施例中，提供了一种流处理系统，包括：多个工作节点；流处理任务的多个子任务分布在所述多个工作节点上；所述多个子任务中包括上游子任务和下游子任务；所述上游子任务所在的工作节点，用于：持久化存储所述上游子任务的状态；其中，所述上游子任务的状态中包括所述上游子任务分配给所述下游子任务的数据，所述上游子任务对应有状态快照；

所述下游子任务所在的工作节点，用于：从所述上游子任务的状态中，获取所述上游子任务分配给所述下游子任务的数据；持久化存储所述下游子任务的状态；其中，所述下游子任务的状态中包括：所述下游子任务针对所述上游子任务的状态的消费位置；所述下游子任务对应有状态快照。

在本申请的又一实施例中，提供了一种流处理系统的状态恢复方法，包括：

确定流处理任务对应的多个子任务中各子任务是否出现异常；

当流处理任务对应的多个子任务中第一子任务出现异常时，对所述第一子任务进行状态恢复；

其中，所述状态恢复是基于所述第一子任务对应的状态快照实现的；多个工作节点；流处理任务的多个子任务分布在所述多个工作节点上；所述多个子任务中包括上游子任务和下游子任务；

所述上游子任务所在的工作节点，用于：持久化存储所述上游子任务的状态；其中，所述上游子任务的状态中包括所述上游子任务分配给所述下游子任务的数据，所述上游子任务对应有状态快照；

所述下游子任务所在的工作节点，用于：从所述上游子任务的状态中，获取所述上游子任务分配给所述下游子任务的数据；持久化存储所述下游子任务的状态；其中，所述下游子任务的状态中包括：所述下游子任务针对所述上游子任务的状态的消费位置；所述下游子任务对应有状态快照。

在本申请的又一实施例中，提供了一种电子设备。该电子设备，包括：存储器和处理器，其中，

所述存储器，用于存储程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以实现上述任一项所述的方法。

在本申请的又一实施例中，提供了一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述任一项所述的方法。

本申请实施例提供的技术方案中，上游子任务将其分配给下游子任务的数据当作其状态进行持久化保存；下游子任务从上游子任务的状态中获取上游子任务分配给下游子任务的数据，并将其针对所述上游子任务的状态的消费位置当作其状态进行持久化保存；上下游子任务各自对应有状态快照。那么，当上游子任务出现异常时，根据上游子任务的状态快照恢复上游子任务的状态即可；由于下游子任务知道其针对所述上游子任务的状态的消费位置，因此，当上游子任务的状态恢复之后，下游子任务按照其记录的消费位置继续消费即可，也就是说，下游子任务的状态无需恢复。当下游子任务出现异常时，根据下游子任务的状态快照恢复下游子任务的状态即可；状态恢复后，下游子任务从恢复的消费位置继续读取上游子任务的状态中的数据进行处理即可，也就是说，上游子任务的状态无需恢复。可见，本方案提供的容错方案实现了单个子任务的单独恢复，而无需全局恢复，可减少数据恢复后数据重算部分的成本。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1a为本申请一实施例提供的流处理系统的结构示意图；

图1b为本申请一实施例提供的流处理容错方法的示例图；

图2为本申请一实施例提供的状态恢复方法的流程示意图；

图3为本申请一实施例提供的流处理任务的分布示例图；

图4为本申请一实施例提供的状态表组的示例图；

图5为本申请一实施例提供的容错方案的示例图；

图6为本申请一实施例提供的电子设备的结构框图。

具体实施方式

现有的流处理容错方案是通过定期地制作全局快照来保存流处理任务所涉及的所有算子一致的状态的。

流处理任务对应的数据流(Dataflow)程序通常表现为有向无环图(Directedacyclic graph，DAG)，图中的节点称为算子(Operator)，表示计算，图中的边表述数据依赖关系。算子是数据流程序的基本功能单元，他们从输入流中获取数据，对其进行计算，然后产生数据并发往输出流以供后续处理。数据流程序通常由三部分算子组成。其中，数据源(Source)算子：负责获取输入数据；数据处理(Transformation)算子：对数据进行处理加工，通常数据处理算子为一个或多个；数据接收器(Sink)算子：负责输出数据。

在现有的流处理容错方案中，数据源算子读取外部数据并且定期地发出数据栅栏，数据栅栏(barrier)只是一个特殊的标记数据，其本身不需要做任何处理，只会从DAG中上游算子传入到下游算子最终一路流入到数据接收器算子中，数据栅栏将持续的数据流切分为一个个的阶段，这一个个不同的阶段反映了数据流中不同的位置。当每个数据栅栏流过某个算子时，都标识着该数据栅栏之前的流数据都被这个算子处理过，并且相应的处理后的数据也输出到了下游算子。

每个算子在接收到数据栅栏后都会将此时算子的状态数据做一个快照(snapshot)，表示当前时刻算子的状态，当该数据栅栏流过所有算子后，就得到了所有算子状态的快照，这个数据栅栏对应的所有算子状态的快照共同构成了全局的快照。全局快照中所有算子都对齐到了一个一致的状态，即数据栅栏所标识的位置处的状态，全局快照可用来做数据恢复，可使用最近一次的全局快照做恢复，所有算子都恢复到这个状态后，数据源算子再从这个状态后开始继续消费数据，这样就保障了失败恢复后流数据处理的只执行一次(Exactly-once)的语义。当某个算子发生处理错误或者失败，那么所有算子都需要进行恢复，失败恢复流程如下：

1、所有算子从最近一次持久化的全局快照中获取自己的状态数据作为恢复时的初始状态。

2、数据源算子从恢复的状态点位开始继续读取数据源的数据，并注入到整个流处理任务的数据流中。

3、所有其它算子重新从上游算子处拉取数据开始处理，整个任务恢复完成。

其方案的缺点是：一旦某个算子发生了失败，那么整个流处理任务的所有算子都需要从最近的全局快照进行恢复。对于复杂的流处理任务来说，可能频繁地发生失败恢复重启的情况，一旦其中一个算子发生失败，那么整个任务都需要恢复重启，对于复杂任务来说，整体恢复时间可能会很长，这是实时应用不可忍受的；并且，全局恢复导致的重算部分的成本也较高。

中心协调节点产生全局数据栅栏的频度不能过高，因为数据栅栏是全局的，会使得所有算子都做快照，影响任务整体性能；另一方面，如果数据栅栏产生频度过低的话又会导致数据恢复时得从一个较远的快照进行恢复，很多数据需要重算，拖慢了整体任务进度。因此数据栅栏产生的频度与性能之间是一种权衡。

数据仓库中，支持流式数据的物化视图技术的核心也是流数据处理模型。数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。数据仓库中数据分层，就跟代码分层一样。如果所有数据都放在一层，就跟代码都放在一个文件，肯定是可以运行的，但带来的问题就是阅读性差，复用性和维护性降低。数仓的分层的每一层都有自己的职责，同时都是基于下一层或者下面多层做数据处理之后的结果。使用数据分层机制，逐步将有价值信息进行汇总聚合。这样就跟分步操作一样，最终提炼出想要的结果。同时就算原始数据丢失了，只要中间结果还在，依然可以保证最上层数据的稳定性，类似加了一层缓冲一样。数据仓库中层与层之间的数据流转是通过流处理任务来实现的。

数据经过ETL(Extract-Transform-Load，抽取-转换-加载)后写入明细表中，用户只需基于明细表创建流式物化视图即可。流式物化视图会全增量一体化拉取消费源表中的数据，进行物化视图的构建和计算，最终生成物化视图的结果存储到结果表中。数仓每一层中的表数据通过物化视图流转到下一层。用户可以基于物化视图的结果做OLAP(OnlineAnalytical Processing，联机分析处理)分析，提供在线服务等，或者基于物化视图结果表再创建新的物化视图。支持流式数据的物化视图与源表是最终一致的，源表数据的变化会增量同步到物化视图中，延迟一般在秒级别。

举例来说：

一个DAG包括三个算子：数据源算子、聚合算子和数据接收器算子。其中，数据源算子全增量实时读取源表数据，同时将消费点位信息作为自己的状态数据保持下来，数据流向聚合算子做聚合计算后发往下游算子，同时将聚合结果作为算子状态进行保存，数据接收器算子将最终结果数据保存在自己状态表中作为物化视图的结果。也就是说，DAG中有状态的算子在处理数据的同时也会保存自己的状态。注：一个DAG除了包含有状态算子，还包含无状态算子。无状态算子只需要观察每个独立事件，根据当前输入的数据直接转换输出结果；有状态算子除当前数据外，还需要一些其他数据来得到计算结果。

容错是流处理模型非常重要的特性也是最基本的挑战，如何在提供高吞吐低延迟处理能力的同时保障失败恢复时数据处理的只执行一次(Exaclty-once)语义是每个流处理产品研究的课题。

针对有状态的数据流处理，我们提出了单节点状态恢复的解决方案，保障了失败恢复时数据处理Exactly-once的语义，该方案基本不会影响数据流处理的主链路，进而保障了系统原有的高吞吐低延迟的性能，此外单节点的失败处理方案更加灵活，不会因为一个节点的数据处理失败导致其它节点受到影响，因而缩短了整个系统失败恢复的时间以及降低了失败恢复后重算部分的成本。

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

此外，在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图1a示出了本申请一实施例提供的流处理系统的结构示意图。如图1a所示，该系统，包括：多个工作节点10；流处理任务的多个子任务分布在所述多个工作节点10上；所述多个子任务中包括上游子任务和下游子任务。一个上游子任务为多个子任务中的一个子任务；一个下游子任务也为多个子任务中的一个子任务。在一实例中，同一个工作节点上可分布有流处理任务的两个或两个以上的子任务，分布在同一个工作节点上的流处理任务的两个或两个以上的子任务由该工作节点上的不同进程来执行。在另一实例中，每一个工作节点只负责流处理任务中的一个子任务，也即：多个工作节点与多个子任务是一一对应关系。

所述上游子任务所在的工作节点101，用于：持久化存储所述上游子任务的状态；其中，所述上游子任务的状态中包括所述上游子任务分配给所述下游子任务的数据，所述上游子任务对应有状态快照；

所述下游子任务所在的工作节点102，用于：从所述上游子任务的状态中，获取所述上游子任务分配给所述下游子任务的数据；持久化存储所述下游子任务的状态；其中，所述下游子任务的状态中包括：所述下游子任务针对所述上游子任务的状态的消费位置；所述下游子任务对应有状态快照。

所谓的持久化(Persistence)存储，即把数据(如内存中的对象)保存到可永久保存的存储设备(如磁盘、数据库)中，使得在应用程序或机器重启后可以继续访问之前保存的数据。

如图1b所示，所述上游子任务所在的工作节点101用于执行：

S1：将上游子任务分配给下游子任务的数据作为上游子任务的状态的一部分进行持久化存储。

所述下游子任务所在的工作节点102用于执行：

S2、从上游子任务的状态中，获取所述上游子任务分配给下游子任务的数据。

S3、将针对所述上游子任务的状态的消费位置作为下游子任务的状态一部分进行持久化存储。

实际应用中，可根据流处理任务对应的执行图(ExecutionGraph)，来划分流处理任务，得到多个子任务。具体地，可针对流处理任务，生成逻辑图(StreamingGraph)；根据逻辑图，生成作业图(JobGraph)；根据作业图，生成执行图；根据执行图，确定流处理任务对应的多个子任务。流处理任务对应的多个子任务可调度到不同的工作节点中。每个子任务由多个算子构成；其中，多个算子构成一个有向无环图，该有向无环图中包括一个起始算子和一个结束算子。

流处理任务对应的多个子任务中包括上游子任务和下游子任务；其中，上游子任务可以是多个；多个上游子任务是并行子任务；下游子任务可以是多个，多个下游子任务也可以是并行子任务。

上游子任务的状态可包括：构成上游子任务的多个算子各自的状态。构成上游子任务的多个算子中结束算子是用于向下游子任务分配数据的，将该算子分配给下游子任务的数据作为该算子的状态进行保存。在一实例中，构成上游子任务的多个算子中起始算子可以是数据源算子，用于从数据源处获取数据，该算子将其针对数据源的消费位置作为自己的状态。消费位置可包括：消费点位信息。

上游子任务对应的状态快照用于恢复上游子任务的状态，也即恢复构成上游子任务的多个算子各自的状态。

下游子任务的状态可包括：构成下游子任务的多个算子各自的状态。构成下游子任务的多个算子中起始算子用于从上游子任务的状态中获取上游子任务(也即上游子任务中的结束算子)分配给下游子任务的数据，并将其针对上游子任务的状态的消费位置作为自己的状态。

下游子任务对应的状态快照用于恢复下游子任务的状态，也即恢复构成下游子任务的多个算子各自的状态。

本申请实施例提供的技术方案中，上游子任务将其分配给下游子任务的数据当作其状态进行持久化保存；下游子任务从上游子任务的状态中获取上游子任务分配给下游子任务的数据，并将其针对所述上游子任务的状态的消费位置当作其状态进行持久化保存；上下游子任务各自对应有状态快照。那么，当上游子任务出现异常时，根据上游子任务的状态快照恢复上游子任务的状态即可；由于下游子任务知道其针对所述上游子任务的状态的消费位置，因此，下游子任务的状态无需恢复。当下游子任务出现异常时，根据下游子任务的状态快照恢复下游子任务的状态即可；状态恢复后，下游子任务从恢复的消费位置继续读取上游子任务的状态中的数据进行处理即可，也就是说，上游子任务的状态无需恢复。可见，本方案提供的容错方案实现了单个子任务的单独恢复，而无需全局恢复，可减少数据恢复后数据重算部分的成本。

并且，只恢复出现故障的子任务，而无需恢复其他正常的子任务，还可缩短恢复时长，以降低对客户服务的影响程度。

实际应用中，如图1a所示，该系统中还可包括：用于管理所述多个工作节点10的中心协调节点11。中心协调节点11可用于：将流处理任务进行划分，得到多个子任务；将多个子任务调度到多个工作节点10上。

上游子任务所在的工作节点可持久化存储上游子任务的状态；下游子任务所在的工作节点也可持久化存储下游子任务的状态。

实际应用中，下游子任务的数量通常为多个，当下游子任务的数量为多个时，构成所述上游子任务的多个算子中可包括重分区算子；该重分区算子为构成所述上游子任务的多个算子中的结束算子。所述下游子任务为多个；多个所述下游子任务与多个分区一一对应，每个下游子任务负责处理其对应分区的数据。

所述上游子任务所在的工作节点101，具体用于：由所述重分区算子对其接收到的数据进行重分区，以从所述多个分区中确定所述接收到的数据所属的分区；将所述接收到的数据及其所属分区的分区信息确定为所述分区算子的状态。所述上游子任务的状态包括所述重分区算子的状态。

也即，上游子任务所在的工作节点可执行重分区算子对应的计算逻辑，以将重分区算子接收到的数据进行重分区，进而得到分配给各下游子任务的数据。上述重分区可以是按照指定的分组键进行重分区。

可选地，所述多个子任务中包括第一子任务；所述第一子任务由多个算子构成。其中，所述第一子任务指代的是上述多个子任务中的任意一个，可以是上文中的上游子任务，也可以是上文中的下游子任务。

在一种可实现的方案中，所述第一子任务所在的工作节点，用于：执行所述多个算子中起始算子以产生作为数据流一部分并随着数据流在所述多个算子之间流动的数据栅栏；当获取到所述多个算子各自对应于所述数据栅栏的状态时，执行原子写操作；所述原子写操作用于：将所述多个算子各自对应于所述数据栅栏的状态分别写入到所述多个算子各自对应的持久化状态表中；所述第一子任务的状态快照是针对所述多个算子的多个持久化状态表创建的。多个持久化状态表与多个算子一一对应。在LSM(Log-Structured-Merge-Tree，日志结构合并树)存储引擎中，持久化状态表由内存表和至少一个磁盘文件构成。当需要针对多个持久化状态表创建状态快照时，对各持久化状态表的内存表中的数据执行刷盘操作，以生成各持久化状态表的新磁盘文件；之后，针对多个持久化状态表的多个磁盘文件，生成状态快照。该状态快照中包含：多个持久化状态表的多个磁盘文件的文件标识信息。该文件标识信息可以是文件名。需要说明的是，在LSM存储引擎中，存在磁盘文件合并操作。为了确保后续基于状态快照能够恢复子任务的状态，在合并磁盘文件后，继续保存合并前的磁盘文件。当涉及合并前的磁盘文件的所有状态快照不被需要时，可删除合并前的磁盘文件，以释放存储空间。

算子对应于所述数据栅栏的状态包括：算子位于所述数据栅栏到上一个数据栅栏之间的多个状态。在执行原子写操作之前，各算子的对应于所述数据栅栏的状态可保存在各算子对应的状态队列中，具体地，可将各算子的对应于所述数据栅栏的状态与所述数据栅栏的标识对应保存在各算子对应的状态队列中。当多个算子中各算子对应的状态队列中均保存有所述数据栅栏的标识时，从多个算子各自对应的状态队列中，获取多个算子各自对应于所述数据栅栏的状态，并执行上述原子写操作。

上述状态队列可以是上述工作节点中的一个内存队列。

上述多个算子中的起始算子可每隔第一预设时间间隔产生一个数据栅栏，不同的数据栅栏对应有不同的标识。

在一实例中，所述多个算子中包括第一算子；所述第一算子指的是多个算子中的任意一个；所述第一子任务所在的工作节点，用于：当所述第一算子获取到所述数据栅栏时，将所述数据栅栏的标识与所述第一算子的对应于所述数据栅栏的状态对应存储在所述第一算子对应的状态队列中；当所述多个算子对应的状态队列中均记录有所述数据栅栏的标识时，从所述多个算子对应的状态队列中获取所述多个算子的对应于所述数据栅栏的状态。

具体地，第一子任务所在的工作节点上可运行有状态后端；当所述第一算子获取到所述数据栅栏时，可调用所述状态后端将所述数据栅栏的标识与所述第一算子的对应于所述数据栅栏的状态对应存储在所述第一算子对应的状态队列中。

在上述实施例中，多个算子各自对应于同一数据栅栏的状态时原子性地写入到各自对应的持久化状态表中的，也就是说多个算子各自对应的持久化状态表是对齐到同一数据栅栏的，这样针对多个算子各自对应的持久化状态表创建快照，该快照内多个算子各自的状态本身就是对齐的，这样，后续基于快照进行恢复时，不会存在某个算子需要按照某个一致的数据栅栏做回滚的情况，不仅简化了方案，还能够缩短数据恢复的时长。

当然，在实际应用中，每个算子在接收到数据栅栏后，可直接将该算子对应于该数据栅栏的状态写入其对应的持久化状态表中，而无需等到第一算子链内所有算子都接收到该数据栅栏后再统一原子地写入。但是，这样一来，就无法保证多个算子各自对应的持久化状态表同时对应于同一个数据栅栏，也就是说，同一个快照中，不同的状态表对应于不同的数据栅栏。这就需要在失败恢复时，按照某一个一致的数据栅栏对快照中所记录的状态表执行回滚操作；然后基于回滚后的快照进行状态恢复。其中，回滚操作复杂且费时。

在一实例中，如图1a所示，上述系统还可包括：存储节点12；所述多个算子各自对应的持久化状态表位于所述存储节点12上；

所述存储节点，用于：每隔预设时间间隔，针对位于所述存储节点上的所述多个算子各自对应的持久化状态表创建快照，以作为所述第一子任务的状态快照。

在本实例中，由存储节点异步执行状态快照的创建，可减少对流处理任务的性能影响。

在一实例中，所述下游子任务对应的算子链中可包括：读取算子。

所述下游子任务所在的工作节点，用于：由所述读取算子按照所述读取算子所负责分区的分区信息，从存储的所述上游子任务的状态中读取所述上游子任务分配给所述下游子任务的数据；并将所述读取算子针对存储的所述上游子任务的状态的消费位置确定为所述读取算子的状态。其中，所述分区信息可以是分区标识；所述下游子任务的状态包括所述读取算子的状态。

具体地，由所述读取算子按照所述读取算子所负责分区的分区信息以及针对所述分区的消费位置，从存储的所述上游子任务的状态中读取所述上游子任务分配给所述下游子任务的数据。

图2示出了本申请又一实施例提供的状态恢复方法的流程示意图。该方法的执行主体可以是上述系统中的中心协调节点。如图2所示，该方法包括：

201、确定流处理任务对应的多个子任务中各子任务是否出现异常。

202、当流处理任务对应的多个子任务中第一子任务出现异常时，对所述第一子任务进行状态恢复。

其中，所述状态恢复是基于所述第一子任务对应的状态快照实现的；所述流处理系统包括：多个工作节点；流处理任务的多个子任务分布在所述多个工作节点上；所述多个子任务中包括上游子任务和下游子任务；

所述上游子任务所在的工作节点，用于：持久化存储所述上游子任务的状态；其中，所述上游子任务的状态中包括所述上游子任务分配给所述下游子任务的数据，所述上游子任务对应有状态快照；

所述下游子任务所在的工作节点，用于：从所述上游子任务的状态中，获取所述上游子任务分配给所述下游子任务的数据；持久化存储所述下游子任务的状态；其中，所述下游子任务的状态中包括：所述下游子任务针对所述上游子任务的状态的消费位置；所述下游子任务对应有状态快照。

上述201中，在一实例中，各子任务所在的工作节点当发现其上运行的子任务出现异常时，可通知中心协调节点该子任务的异常情况。这样，中心协调节点即可确定出哪个子任务出现异常。

在另一实例中，获取流处理任务对应的多个子任务各自的运行情况；根据所述运行情况，确定流处理任务对应的多个子任务中各子任务是否出现异常。

各子任务所在的工作节点可定期将其上运行的子任务的运行情况发送给中心协调节点，中心协调节点可根据各子任务的运行情况，来确定各子任务是否出现异常。

上述202中，在一实例中，中心协调节点可获取第一子任务的状态快照，基于第一子任务的状态快照恢复所述第一子任务的状态。

在另一实例中，第一子任务的状态及其状态快照持久化存储在存储节点中，中心协调节点可向存储节点发送状态恢复请求；所述状态恢复请求中携带有所述第一子任务的子任务标识信息。存储节点接收到状态恢复请求后，根据状态恢复请求中第一子任务的子任务标识信息，获取第一子任务的状态快照；根据所述第一子任务的状态快照恢复所述第一子任务的状态。

实际应用中，所述状态恢复成功后，重新启动所述第一子任务。

这里需要说明的是：本申请实施例提供的所述方法中各步骤未尽详述的内容可参见上述实施例中的相应内容，此处不再赘述。此外，本申请实施例提供的所述方法中除了上述各步骤以外，还可包括上述各实施例中其他部分或全部步骤，具体可参见上述各实施例相应内容，在此不再赘述。

实际应用中，用户表的数据是分布在多个分区(shard)上的，能更均衡地分散数据，提高写入吞吐，在横向扩展上更灵活。分区是提供读写服务，持久化快照以及工作节点之间调度的基本单元。一个分区只会分布在某台工作节点上，分区内部一般有多个表的数据，其中每个表在本分区上的数据称之为一个表(tablet)，表是响应读写服务的最小单元。

物化视图流处理任务对应的多个子任务也是按照分区分布的，每个子任务不会跨计算节点，只会分布在一个工作节点的某个分片上。图3示出了一个物化视图流处理任务，该物化视图流处理任务主要是做聚合计算。该任务分成了四个子任务包括：第一上游子任务1、第二上游子任务2、第一下游子任务3和第二下游子任务4。其中第一上游子任务1、第二上游子任务2负责从源表中读取数据并按照聚合的分组键进行数据重分区，第一下游子任务3、第二下游子任务4读取第一上游子任务1和第二上游子任务2重分区之后的数据进行聚合计算，并将计算结果写入物化视图结果表中。

可以看到每个子任务都是不跨网络的，只在单节点内部的分片上，因此每个子任务内各算子状态表数据也分布在本分片上。上游子任务在需要跨网络传输数据的地方使用重分区算子对数据进行重分区，并将重分区后的数据写入到持久化存储中；下游子任务中的读取算子通过远程过程调用(Remote Procedure Call，RPC)读取上游重分区后的数据。流式物化视图流处理任务采用的是“拉取”模型，即下游算子会从上游算子拉取数据进行处理。每个子任务恢复后，该子任务的起始算子会从所恢复的状态之后的位置开始重新拉取数据因此每个子任务只需保障自己状态恢复时只执行一次的语义即可。

物化视图流处理中，每个子任务分别自己做快照，自行维护内部所有算子状态一致性。流式物化视图流处理任务中的快照是每个子任务自己独立的快照。每个子任务内部所有算子的状态表组成了一个状态表组，图4示出了第一下游子任务对应的状态表组，其由读取算子100对应的持久化状态表T1、聚合算子200对应的持久化状态表T2和数据接收器算子300对应的持久化状态表T3组成。

每个子任务会保证创建快照时，其对应的状态表组中所有状态表的一致性。物化视图流处理任务也采用了数据栅栏的机制来标识数据流中的位置，只不过数据栅栏是每个子任务内的局部数据栅栏。在每个子任务内部，数据源算子或读取算子定期产生数据栅栏，一路向下游流动到该子任务的重分区算子或数据接收器算子为止。每个算子在接收到数据栅栏时，其状态后端会在其对应的状态队列中将对应于该数据栅栏的状态进行打包，等待之后做持久化存储；等到状态表组中所有状态表中都存在该数据栅栏对应的状态后，将状态表组中所有状态表中对应于所述数据栅栏的状态一并原子地写入存储引擎中，存储引擎之后会将状态表组中所有状态表创建一个快照，每个状态表都对齐到了这个数据栅栏标识的位置，从而保证了每个状态表之间的一致性。

下面将结合图5对下游子任务的快照创建过程进行阐述：

(a)读取算子发出数据栅栏1，与此同时其状态后端将读取算子在数据栅栏1之前未持久化的增量状态(也即读取算子对应于该数据栅栏1的状态)打包，放入读取算子对应的写队列中(也即状态队列)。

(b)聚合算子接收到数据栅栏1后，通过其状态后端将其在数据栅栏1之前未持久化的增量状态数据打包，放入聚合算子对应的写队列中；然后向下游发送数据栅栏1。

(c)数据接收器算子接收到数据栅栏1后，通过其状态后端将其在数据栅栏1之前未持久化的增量状态数据打包，放入数据接收器算子对应的写队列中。

(d)执行异步持久化增量状态数据的任务，以定期查看下游子任务中多个算子对应的写队列；一旦所有写队列都包含了数据栅栏1标识的增量状态，就将算子的对应于数据栅栏1的增量状态从各自写队列拿出，通过存储引擎统一原子地写入各自的持久化状态表中。存储引擎之后会对状态表组中的所有状态表创建快照。

由于子任务内所有算子的增量状态数据都是对齐到同一个数据栅栏之后才持久化的，因此所有算子持久化的状态数据本身就是一致的。失败恢复时只需要存储引擎依据最新的快照恢复即可，恢复流程比较简单：存储引擎将异常子任务对应的最新状态快照做恢复；失败的子任务重新启动各个算子进行处理，数据源算子或读取算子读取自己状态表最新的点位信息，从这一点位之后开始拉取数据并发送给下游算子；下游算子恢复自己的状态表后继续处理流数据，整个任务恢复完成。

本申请实施例提供的技术方案不需要中心协调节点来产生全局的数据栅栏，只需要每个子任务内部自己生成数据栅栏，且数据栅栏不需要跨网络传递，这种数据栅栏生成方式更加灵活，不需要创建全局快照，局部快照开销小，因此产生数据栅栏可以更加高频，创建快照可以更加高频，这样以来失败恢复后可以避免很多需要重算的工作。每个子任务独立做快照，失败恢复时只需恢复失败算子所在的子任务即可，不影响其它正常的子任务，因此，增强了容错性，还缩短了失败恢复时间。持久化算子增量状态数据以及做快照是后台异步任务完成的，不会阻塞算子读写状态数据的链路，算子正常读写处理状态数据不受影响，状态数据持久化以及做快照对算子透明，算子读写及处理数据的性能几乎不受影响。算子状态增量数据按照数据栅栏对齐之后再原子地写入存储引擎并持久化，同一子任务内算子状态数据本身就是对齐的，失败恢复时各个算子不需要按照某个一致的数据栅栏做回滚，进一步缩短了失败恢复时间。这套方案易扩展，每当新增算子的时候，新算子不需要实现快照接口，即算子不需关注如何做快照，只需使用状态后端来读写数据即可。状态数据的持久化及做快照交给异步任务和存储引擎来完成，方便开发者只需关注算子本身的处理逻辑即可。异步增量状态数据对齐写入及快照任务对算子读写处理性能几乎无影响，维护了流处理任务的高吞吐和低延迟。

图6示出了本申请一实施例提供的电子设备的结构示意图。如图6所示，所述电子设备包括存储器1101以及处理器1102。存储器1101可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器1101可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(Static RandomAccess Memory，SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable read only memory)，EEPROM)，可擦除可编程只读存储器(Electrical Programmable Read Only Memory，EPROM)，可编程只读存储器(Programmable Read Only Memory，PROM)，只读存储器(Read Only Memory，ROM)，磁存储器，快闪存储器，磁盘或光盘。

所述存储器1101，用于存储程序；

所述处理器1102，与所述存储器1101耦合，用于执行所述存储器1101中存储的所述程序，以实现上述各方法实施例提供的方法。

进一步，如图6所示，电子设备还包括：通信组件1103、显示器1104、电源组件1105、音频组件1106等其它组件。图6中仅示意性给出部分组件，并不意味着电子设备只包括图6所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各方法实施例提供的方法的步骤或功能。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM(Read Only Memory，只读存储器)/RAM(RandomAccess Memory，随机存取存储器)、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (11)

1.一种流处理系统，其特征在于，包括：多个工作节点；流处理任务的多个子任务分布在所述多个工作节点上；所述多个子任务中包括上游子任务和下游子任务；

所述上游子任务所在的工作节点，用于：持久化存储所述上游子任务的状态；其中，所述上游子任务的状态中包括所述上游子任务分配给所述下游子任务的数据，所述上游子任务对应有状态快照；

所述下游子任务所在的工作节点，用于：从所述上游子任务的状态中，获取所述上游子任务分配给所述下游子任务的数据；持久化存储所述下游子任务的状态；其中，所述下游子任务的状态中包括：所述下游子任务针对所述上游子任务的状态的消费位置；所述下游子任务对应有状态快照。

2.根据权利要求1所述的系统，其特征在于，所述上游子任务中包含重分区算子；所述下游子任务为多个；多个所述下游子任务与多个分区一一对应，每个下游子任务负责处理其对应分区的数据；

所述上游子任务所在的工作节点，具体用于：执行所述重分区算子，以从所述多个分区中确定所述重分区算子接收到的数据所属的分区；将所述接收到的数据及其所属分区的分区信息确定为所述重分区算子的状态；

其中，所述上游子任务的状态包括所述重分区算子的状态。

3.根据权利要求2所述的系统，其特征在于，所述下游子任务中包含：读取算子；

所述下游子任务所在的工作节点，用于：执行所述读取算子，以按照所述下游子任务所负责分区的分区信息，从所述上游子任务的状态中读取所述上游子任务分配给所述下游子任务的数据；并将所述读取算子针对所述上游子任务的状态的消费位置确定为所述读取算子的状态；

其中，所述下游子任务的状态包括所述读取算子的状态。

4.根据权利要求1至3中任一项所述的系统，其特征在于，所述多个子任务中包括第一子任务；所述第一子任务由多个算子构成；

所述第一子任务所在的工作节点，用于：执行所述多个算子中起始算子，以产生数据栅栏；所述数据栅栏作为数据流一部分并随着数据流在所述多个算子之间流动；当获取到所述多个算子各自对应于所述数据栅栏的状态时，执行原子写操作，所述原子写操作用于：将所述多个算子各自对应于所述数据栅栏的状态分别写入到所述多个算子各自的持久化状态表中；

所述第一子任务的状态快照是针对所述多个算子的多个持久化状态表创建的。

5.根据权利要求4所述的系统，其特征在于，还包括：存储节点；所述多个算子各自对应的持久化状态表位于所述存储节点上；

所述存储节点，用于：每隔预设时间间隔，针对位于所述存储节点上的所述多个算子各自对应的持久化状态表创建快照，以作为所述第一子任务的状态快照。

6.根据权利要求4所述的系统，其特征在于，所述多个算子中包括第一算子；

所述第一子任务所在的工作节点，用于：当所述第一算子获取到所述数据栅栏时，将所述数据栅栏的标识与所述第一算子的对应于所述数据栅栏的状态对应存储在所述第一算子对应的状态队列中；当所述多个算子对应的状态队列中均记录有所述数据栅栏的标识时，从所述多个算子对应的状态队列中获取所述多个算子的对应于所述数据栅栏的状态。

7.一种流处理系统的状态恢复方法，其特征在于，包括：

确定流处理任务对应的多个子任务中各子任务是否出现异常；

当流处理任务对应的多个子任务中第一子任务出现异常时，对所述第一子任务进行状态恢复；

其中，所述状态恢复是基于所述第一子任务对应的状态快照实现的；所述流处理系统包括：多个工作节点；流处理任务的多个子任务分布在所述多个工作节点上；所述多个子任务中包括上游子任务和下游子任务；

所述上游子任务所在的工作节点，用于：持久化存储所述上游子任务的状态；其中，所述上游子任务的状态中包括所述上游子任务分配给所述下游子任务的数据，所述上游子任务对应有状态快照；

所述下游子任务所在的工作节点，用于：从所述上游子任务的状态中，获取所述上游子任务分配给所述下游子任务的数据；持久化存储所述下游子任务的状态；其中，所述下游子任务的状态中包括：所述下游子任务针对所述上游子任务的状态的消费位置；所述下游子任务对应有状态快照。

8.根据权利要求7所述的方法，其特征在于，还包括：

所述状态恢复成功后，重新启动所述第一子任务。

9.根据权利要求7所述的方法，其特征在于，确定流处理任务对应的多个子任务中各子任务是否出现异常，包括：

获取流处理任务对应的多个子任务各自的运行情况；

根据所述运行情况，确定流处理任务对应的多个子任务中各子任务是否出现异常。

10.一种电子设备，其特征在于，包括：存储器和处理器，其中，

所述存储器，用于存储程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以实现权利要求1至9中任一项所述的方法。

11.一种存储有计算机程序的计算机可读存储介质，其特征在于，所述计算机程序被计算机执行时能够实现权利要求1至9中任一项所述的方法。

Images