CN105871603A

CN105871603A - 一种基于内存数据网格的实时流式数据处理失效恢复系统及方法

Info

Publication number: CN105871603A
Application number: CN201610186150.5A
Authority: CN
Inventors: 黄涛; 钟华; 魏峻; 王伟; 支孟轩; 郑莹莹
Original assignee: Institute of Software of CAS
Current assignee: Institute of Software of CAS
Priority date: 2016-03-29
Filing date: 2016-03-29
Publication date: 2016-08-17
Anticipated expiration: 2036-03-29
Also published as: CN105871603B

Abstract

本发明涉及一种基于内存数据网格的实时流式数据处理失效恢复系统及方法，包括：调度器、状态服务器、任务队列和任务操作中心四个部分。本发明通过记录和状态信息的分离存储，使得快照中存储的状态信息减少，在降低数据处理的延迟的同时，提供更加轻便快照机制；通过数据窗口实现微批次的快照持久化，并通过双buffer的存储结构确保了“恰好一次”的语义保障；不需借助于第三方的集群对数据进行管理，在一定程度上降低了网络延迟。

Description

一种基于内存数据网格的实时流式数据处理失效恢复系统及方法

技术领域

本发明涉及一种实时流式数据处理的失效恢复系统及方法，尤其涉及一种基于分布式流式处理框架实现的轻量高效、“恰好一次”的失效恢复方法，属于软件技术领域。

背景技术

随着互联网等信息技术的飞速发展，导致全球数据量急剧增长，针对这些大数据背后隐藏的价值的挖掘，成为了当今时代的主流。早期出现的批量计算使用先存储后计算的策略，这种方式计算精准但是无法应对实时数据的要求，流式计算已成为了解决实时数据处理的主流应用。流式处理框架是一个处理具有时序性特征的流式数据的数据处理框架。一个好的流式处理框架都会有围绕以下两个重要属性的需求，即系统的延迟和系统的高可用性(S Kamburugamuve,G Fox,D Leake,J Qiu:Survey of Distributed StreamProcessing for Large Stream Sources,December 2013)。任何流式处理系统都可能会出现节点失效、网络失效、软件错误以及资源限制(例如：CPU不足，内存不足等)等故障情况。如何从故障中快速的恢复过来，对于保障系统的高可用性是极其重要的，因此失效恢复就显得尤为重要。目前，实时流式数据处理系统通过状态备份和失效恢复策略来实现其高可用性，保障系统的容错能力，从而确保流式计算的流畅性。

Hwang J H等人(Hwang J H,Balazinska M,Rasin A,et al.High-availability algorithmsfor distributed stream processing[C]//Data Engineering,2005.ICDE 2005.Proceedings.21stInternational Conference on.IEEE,2005:779-790.)将故障恢复类型总结为以下三种：精确恢复、回滚恢复、有损恢复。精确恢复实现较为困难而有损恢复不是理想的结果，因此一般将回滚恢复作为失效恢复的实现目标。崔星灿等人(崔星灿,禹晓辉,刘洋,等.分布式流处理技术综述[J].计算机研究与发展,2015,52(2):318-332.)将现有的恢复方法归结为以下三种策略：被动等待/上游备份、主动等待和同步检查点。被动等待策略是一种异步备份策略，即会将主节点上的数据周期性的备份到副本节点上，由于不能保证主节点发生故障时副本节点与其状态一致，因此需要上游备份的支持，重新发送部分数据。如果仅通过上游节点的数据存储和重发来实现容错，则为上游备份策略。主动等待策略中主节点和副本节点同时从上游接收数据并以并行的方式向下游传递数据，当主节点出现故障时，副本节点可以完全接管接下来的操作，因为它和主节点有着相同的系统资源分配。同步检查点策略同被动等待策略相似，唯一不同是主节点数据备份到副本节点是同步进行的。不同的失效恢复策略都会在快速恢复、低延时以及资源利用上做一个权衡。被动等待策略有适当的资源消耗和处理延迟，但是如果备份的数据存储在文件系统或是磁盘上，故障恢复的时间会很长；主动等待策略虽然能快速恢复，但是占用了大量的系统资源，对于故障出现较少的情况下会造成严重的资源浪费；同步检查点策略以牺牲处理延迟为代价，保证了快速恢复和较低的资源占用。

对于流式处理框架的失效恢复的能力可以通过其对语义保障的程度来划分。一般分为“至多处理一次”(at most once)、“至少处理一次”(at least once)和“恰好一次”(exactlyonce)。

现有的流式处理框架所选择的失效恢复的策略也是不尽相同的。Apache Storm(http://storm.apache.org/)在失效恢复机制中采用上游备份策略，通过使用Spouts提供的唯一标识ID来保障每个元组都能在任务拓扑中被执行，在恢复时只能保障“至少处理一次”的语义执行，且其作业级容错限制了系统的可扩展性。S4采用被动等待策略，通过Apache Zookeeper(https://zookeeper.apache.org/)对各节点进行协调，采用了基于检查点的状态恢复机制，它会定期的检测PE(处理单元)的状态，当检测到失效时，才会触发检查点来记录下当前的PE状态，这种恢复机制是滞后的，且只提供部分容错，节点失效转移时会丢失内存中的状态信息。Samza(http://samza.apache.org/)采用上游备份策略，通过Apache Kafka(http://kafka.apache.org/)的分布式队列管理数据流，可以轻松的实现“至少处理一次”的处理语义，但只能提供部分容错，无法保证“恰好一次”的语义。Flink(http://flink.apache.org/)是一种新型的状态流处理系统，通过ApacheZookeeper管理并备份主节点，通过Apache Kafka管理数据流，使用异步快照机制进行失效恢复，为数据源中的记录标记顺序编号，恢复时下游节点丢掉那些编号小于当前已经处理过的记录编号的记录，从而保证“恰好一次”的处理。但其将记录保存在磁盘上大大的降低了失效恢复的速度。

通过分析现有流式处理框架中的失效恢复方法可以看出，提供一种轻量高效、“恰好一次”语义保障、尽可能低延时的失效恢复方法是顺应时代的潮流且拥有广阔发展前景的。

发明内容

本发明技术解决问题：针对上述流式处理框架中失效恢复方法中的不足，提供一种基于内存数据网格的实时流式数据处理失效恢复系统及方法，通过一个内存数据网格平台高效且能快速实现该平台上流式数据处理的失效恢复。

本发明技术解决方案：一种基于内存数据网格的实时流式数据处理失效恢复系统，包括：调度器、状态服务器、任务队列和任务操作中心四个部分：

调度器，负责将从数据源接收到的数据流按照一致性哈希算法，路由到内存数据网格集群中各个内存数据网格节点进行相应的数据处理；当感知到节点失效发生时，会停止向失效节点发送数据，并自动修复和重启失效节点；

任务队列，是一组基于内存的、可串行协作的分布式任务队列，队列中存放的具有时序特征的任务是从调度器路由过来的数据源或是经过任务操作中心处理后得到的中间结果；任务出队后进入下一个任务操作中心执行具体的数据处理逻辑；向任务操作中心输送任务的称为输入任务队列，从任务操作中心取出任务的称为输出任务队列；

任务操作中心，提供用于任务处理的数据处理逻辑和快照机制，数据处理逻辑由用户自定义，可以是简单的数据操作，也可以是复杂的连接、聚合操作，快照机制在任务处理过程中随时捕获由任务的操作状态等信息构成的快照，并将该快照信息异步持久化到状态服务器中；任务操作中心从输入任务队列中取出任务，根据用户定义的数据处理逻辑进行相应的数据处理，并将逻辑处理后得到的新的记录信息传递给输出任务队列；

状态服务器，一种基于内存的分布式存储系统，用于存储任务操作中心中进行逻辑处理的记录的操作状态信息；当需要进行内存数据网格节点失效恢复时，状态服务器提供全面准确的记录操作状态，从而精确的恢复到失效前一刻的状态，实现“恰好一次”的语义保障；状态服务器支持数据备份，集群节点可动态扩展，对于内存数据网格节点失效的状态信息，能够定期的清理，保障内存空间的高效利用。

一种基于内存数据网格的实时流式数据处理失效恢复方法，于实现步骤如下：

(1)节点启动，初始化任务队列以及任务操作中心，读取系统配置文件获取数据窗口大小，任务队列初始创建时，需给定一个唯一标识JobContainerID，并为每个任务操作中心分配一个唯一标识JobOperatorID和一块用于存储快照状态信息的内存空间，这块内存空间被分成两部分：一部分用于存储一个数据窗口内的所有记录的快照信息，并在数据窗口离开时异步持久化到状态服务器中，这部分存储空间称为WindowSnapshot，即所有记录的检查点信息；另一部分用于存储当前最新的快照信息，这部分存储空间称为LatestSnapshot；

(2)任务操作中心从输入任务队列中取出一个任务item，并更新LatestSnapshot为M：(r＝item、lv＝lastState、fun、Os＝false、offset＝o)，其中item是刚取出的任务，lastState是上次更新的状态，Os为false表示该任务还没有被处理；

(3)任务操作中心对item进行用户定义的逻辑处理得到中间结果item’，并将中间结果item’传递给输出任务队列同时更新LatestSnapshot为M’＝(r＝item、lv＝newState、fun、Os＝true、offset＝o+1)，任务操作中心将中间结果item’和快照M’作为一个原子操作；然后将快照M’保存到WindowSnapshot中，如果M’是当前数据窗口的最后一位，则会触发持久化操作，将WindowSnapshot中存储的所有快照持久化到状态服务器；

(4)节点A失效后，任务队列会通过其标识JobContainerID从集群中获取到失效前的所有数据源或中间结果，将任务队列恢复到失效前的状态；获得LatestSnapshot中存储的快照信息M*＝(r＝task、lv＝state、fun、Os＝os、offset＝offset)，如果os为true，说明任务task已经处理完，直接将中间结果state传递给任务输出队列，如果os为false，说明任务task没有处理完，此时的state是上次处理的中间结果，需要对task重新进行逻辑处理，得到新的中间结果state’,并将state’传递给任务输出队列；

所述快照的形式化表示方式如下：M＝(r,lv,fun,Os,offset)，其中r指当前的任务记录，lv指当前逻辑状态值(如本地变量、key/value对等)，fun指当前操作逻辑(该操作逻辑是由用户自定义的，可应用框架提供的接口)，Os指当前操作状态(初始时设为false，即没有完成该JobOperator上的逻辑操作，当任务操作器JobOperator处理完当前任务后，便更新为true),offset表示该记录在当前窗口中的位置。

所述数据窗口是指微批次的数据流，数据窗口的大小由配置文件中读取，快照的异步持久化在一个数据窗口到达尾端时执行，不会影响任务的逻辑处理过程，所述数据窗口的形式化表示如下：W＝(d1,d2,d3...dn)。

与现有流式数据处理框架中的失效恢复技术相比，本发明具有如下优势：

(1)本发明通过记录和状态信息的分离存储，使得快照中存储的状态信息减少，在降低数据处理的延迟的同时，提供更加轻便快照机制。

(2)本发明通过数据窗口实现微批次的快照持久化，并通过双buffer的存储结构确保了“恰好一次”的语义保障。

(3)本发明不需借助于第三方的集群(如Kafka)对数据进行管理，在一定程度上降低了网络延迟。

附图说明

图1为本发明基于内存数据网格的流式数据处理框架图；

图2为本发明中异步快照生成方法流程图；

图3为本发明中内存数据网格节点失效后调度器运行流程图；

图4为本发明内存数据网格节点失效恢复流程图。

具体实施方式

以下结合附图和具体实施例对本发明进行详细说明。

本发明提出的基于内存数据网格的实时流式数据处理框架的失效恢复方法，在Hazelcast内存数据网格平台上，对出租车设备上发来的车辆信息进行转换、聚合等操作，通过异步快照保存车辆记录的操作状态信息，以及数据窗口的微批次处理，实现一种轻量高效、“恰好一次”并尽可能低延时的失效恢复方法。

本实例的应用框架如图1所示。本发明实例所使用的Hazelcast是一种提供数据备份、数据分区以及各种分布式数据结构的内存数据网格，其中JobContainer1、JobContainer2为内存数据网格工具Hazelcast的分布式队列。JobOperator1提供设备信息转换功能，JobOperator2提供设备相关性的聚合操作。

内存数据网格(IMDG)是一种提供基于分布式内存的低时延、可扩展数据访问，即CPU直接从内存，而不是硬盘上读取数据，并进行计算、分析的新型中间件，同时提供各种数据结构的分布式实现，且所有数据存储在内存中。

本发明中的基于内存数据网格平台的实时流式数据处理系统包含调度器、状态服务器、任务队列、任务操作中心四个组成部分：

1.调度器(Scheduler)

在本发明的基于内存数据网格的流式处理系统中，调度器通过一致性哈希算法，将数据流路由到不同的节点，每个节点仅需维护少量相邻节点的信息，并且在节点加入/退出系统时，仅有相关的少量节点参与到拓扑的维护中。保证了整个框架的负载均衡，同时还确保了集群的可扩展性。

2.任务队列(JobContainer)

在本发明的基于内存数据网格的流式处理系统中，基于其拥有数据备份的独特性，本发明提供的任务队列(JobContainer)是一组基于内存的、可串行协作的分布式任务队列，队列中存放具有时序特征的数据处理任务。每个队列配置了一个任务线程池，实现队列中任务出队与任务执行的并发性。任务出队时将执行具体的数据处理逻辑，然后进入下一阶段的任务队列。开发人员可以利用多个阶段的任务队列设计实现较为复杂的数据处理流程。

3.任务操作中心(JobOperator)

在本发明的基于内存数据网格的流式处理框架中，任务操作中心(JobOperator)是从输入JobContainer(IJC)中取出任务，并进行相应的数据处理逻辑的模块，然后将逻辑处理后得到的新的记录信息传递给输出JobContainer(OJC)。JobOperator提供的数据处理逻辑是由用户自定义，可能是简单的数据操作，也可能是复杂的连接、聚合等操作，且包含了驱动和恢复快照的方法。对于某些复杂的操作，为保证失效恢复的精确性，需要加锁阻塞，保证逻辑运算和输出新纪录到输出队列的原子性。

4.状态服务器(State Server)

在本发明的基于内存数据网格的流式处理框架中，状态服务器将进行流式处理的记录的操作状态信息存储在分布式内存中，当需要失效恢复时，状态服务器可以提供全面准确的记录操作状态，从而精确的恢复到失效前一刻的状态，实现“恰好一次”的语义保障。状态服务器支持数据备份，集群节点可动态扩展，对于失效的状态信息，能够定期的清理，保障内存空间的高效利用。

本实施例快照获取方法流程如图2所示。

1.节点启动，初始化任务队列JobContainer1、JobContainer2，其唯一标识分别为JobContainerID1、JobContainerID2(实际应包含节点所在的机器IP信息、节点标号信息等)。读取配置文件获取窗口大小w。为JobOperator1和JobOperator2分配一个唯一标识JobOperatorID1和JobOperatorID2。并通过哈希表存储WindowSnapshot和LatestSnapshot。

2.JobOperator1从JobContainer1中取出记录r1，更新其LatestSnapshot中存储的快照M：(r＝item、lv＝null、fun、Os＝false、offset＝0)。由于这是取出的第一个记录，因此没有lastState信息。

3.JobOperator1对r1进行数据格式转换，得到转换后的数据r1’。

4.JobOperator1将r1’传递给JobContainer2，并更新LatestSnapshot为M’＝(r＝r1’、lv＝r1’、fun、Os＝true、offset＝1)，并将该快照保存到WindowSnapshot中。如果该记录是当前窗口的最后一个记录，则会触发持久化操作，将WindowSnapshot中的快照异步持久化到状态服务器，WindowSnapshot会继续下个窗口的快照信息的存储。

5.JobOperator2从JobContainer2中取出记录rr1，更新JobOperator2上的LatestSnapshot中存储的快照MM＝(r＝rr1、lv＝null、fun、Os＝false、offset＝0)。

6.JobOperator2将rr1按照设备相关性存储到分布式Map中相应的key值对应的value中，这是一个追加操作，需要将rr1包含的经纬度以及时间等信息添加到设备号为key值的value中，如原来的<key＝1111，value＝”111,112；”>，现在需要在value中增加rr1中包含的经纬度信息，如<key＝1111,value＝”111,112；113,115；”>。更新JobOperator2上的LatestSnapshot中存储的快照MM’＝(r＝rr1、lv＝<key＝1111,value＝”111,112；113,115；”>、fun、Os＝true、offset＝1)。

7.JobOperator2从JobContainer2中取出的任务为空时，即任务队列JobContainer2中此时没有任务，JobOperator2便会将JobContainer2阻塞起来，并将分布式Map中的数据持久化到数据库中。

本实施例在节点A失效后，调度器运行流程如图3，节点A失效恢复具体流程如图4所示。

1.节点A失效后，调度器感知到A节点失效，会终止向该节点继续传递数据流，同时将原本传向A节点的流式数据通过一致性哈希算法路由到其他的节点，并尝试重新启动该失效的节点A。

2.节点A重新启动后，JobContainer1和JobContainer2会通过其标识JobContainerID1,和JobContainerID2将其原有的数据从集群中其他节点中的备份迁移后恢复到失效之前的状态。

3.JobOperator1需要通过其LatestSnapshot中的状态信息，恢复到失效之前。在获取到JobOperator1的最新的快照ls1：(r＝item、lv＝state、fun、Os＝isFinish、offset＝o)后，检查该快照中的状态信息，如果isFinish为true，说明记录item已经处理完成，直接将其传递给JobContainer2即可；如果isFinish为false，说明记录item还没有完成JobOperator1中的逻辑操作，此时需要通过lv＝state将其状态恢复到state，并重新执行记录item的逻辑操作，将得到的新的记录item’传递给JobContainer2。

4.JobOperator2需要通过其LatestSnapshot中的状态信息，恢复到失效之前。在获取到JobOperator2的最新的快照ls2：(r＝item、lv＝state、fun、Os＝isFinish、offset＝o)后，检查该快照中的状态信息，如果isFinish为true，说明记录item已经处理完成；如isFinish为false，说明记录item还没有完成JobOperator2中的逻辑操作，此时需要通过lv＝state将其状态恢复到state，并重新执行记录item的逻辑操作。

5.节点A启动后状态全部被重置到失效之前的状态，调度器会继续向节点A路由数据流，在短时间内使整个集群重新回到一个平衡状态。

尽管为说明目的公开了本发明的具体实施例和附图，其目的在于帮助理解本发明的内容并据以实施，但是本领域的技术人员可以理解：在不脱离本发明及所附的权利要求的精神和范围内，各种替换、变化和修改都是可能的。因此，本发明不应局限于最佳实施例和附图所公开的内容。

Claims

1.一种基于内存数据网格的实时流式数据处理失效恢复系统，其特征在于：包括调度器、状态服务器、任务队列和任务操作中心四个部分：

2.一种基于内存数据网格的实时流式数据处理失效恢复方法，其特征在于实现步骤如下：

(4)节点A失效后，任务队列会通过其标识JobContainerID从集群中获取到失效前的所有数据源或中间结果，将任务队列恢复到失效前的状态；获得LatestSnapshot中存储的快照信息M*＝(r＝task、lv＝state、fun、Os＝os、offset＝offset)，如果os为true，说明任务task已经处理完，直接将中间结果state传递给任务输出队列，如果os为false，说明任务task没有处理完，此时的state是上次处理的中间结果，需要对task重新进行逻辑处理，得到新的中间结果state’,并将state’传递给任务输出队列。

3.根据权利要求2所述的基于内存数据网格的实时流式数据处理失效恢复方法，其特征在于：所述快照的形式化表示方式如下：M＝(r,lv,fun,Os,offset)，其中r指当前的任务记录，lv指当前逻辑状态值，fun指当前操作逻辑该操作逻辑是由用户自定义的，可应用框架提供的接口；Os指当前操作状态，初始时设为false，即没有完成该JobOperator上的逻辑操作，当任务操作器JobOperator处理完当前任务后，便更新为true；offset表示该记录在当前窗口中的位置。

4.根据权利要求2所述的基于内存数据网格的实时流式数据处理失效恢复方法，其特征在于：所述数据窗口是指微批次的数据流，数据窗口的大小由配置文件中读取，快照的异步持久化在一个数据窗口到达尾端时执行，不会影响任务的逻辑处理过程，所述数据窗口的形式化表示如下：W＝(d1,d2,d3...dn)。