CN111752545B - 一种支持数据重放的流计算方法 - Google Patents

Abstract

本发明涉及信息技术领域，提供了一种支持数据重放的流计算方法。其目的在于解决当前的Flink等流计算框架只支持源端数据调整后的恢复执行的机制，并不支持对任务自身程序修改后的重放的问题。主要方案包括，步骤1、流平台中定义task任务的备份保存机制以及task任务需要实现的快照备份和恢复接口SnapShotInterface；步骤2、用户在task任务的实现中编写SnapShotInterface的实现类，最终形态为打包后的jar包；步骤3、将jar包提交至流平台进行处理，同时流计算平台定期调用实现类的backup方法，将备份的数据保存到hdfs上；步骤4、当task任务执行失败后，重新启动task任务时流处理平台执行SnapShotInterface的实现类的recover方法从hdfs读取保存点文件并恢复数据，然后重新执行task任务。

Description

一种支持数据重放的流计算方法

技术领域

本发明涉及信息技术领域，提供了一种支持数据重放的流计算方法。

背景技术

在商业银行，目前运用较多的流计算为Kafka+Flink，kafka作为流计算消息队列负责接收实时数据流，flink负责根据用户提交的任务来从kafka中读取数据流并实时处理和计算。

如下为一个标准的Flink流计算平台运行机制：

如图2，右侧蓝色框内为流平台运行组件，Task为用户通过jar包的方式提交到流平台运行的任务，该任务需要从kafka1和kafka2两个流数据存储队列读取记录并处理，kafka Consumer可以理解为flink到kafka的连接器，其中的offset表示从kafka中读取的数据的刻度，比如consumer1的offset=1,则表示读取的数据为“B1”(绿色框中)，consumer2中offset为4，表述消费到第4条记录，即绿框中的“D2”;result为任务执行中产生的结果值，上图中结果值只有一个：“result1”。

当任务被提交到流平台运行时，流平台会连续不断的从kafka中读取数据进行消费和计算，并将task产生的结果值诙谐到外部的设备如文件或mysql数据库，随着流数据的不断处理，结果值也随时在不断的变化。

以上流程基本为流平台标准的数据处理流程，下面我讲解一下已flink为例的备份会恢复机制。

Flink本身的只提供了标准的快照备份和恢复方法起流程基本如下：

1、flink平台在任务执行过程中会定期将任务运行中数据备份到快照中，该快照包括kafkaConsumer的offset和运行结果值result。如图1所示，若flink平台在此时备份快照时将备份kafkaconsumer1的offset=2和kafka consumer2的offset=4的值以及此时的结果值X1。

2、当程序已经执行到offset=100或其他值时若重新进行数据回放处理时，flink平台提供如下如下功能：在启动任务时指定对应的快照版本，flink会从快照文件中恢复consumer的offset和result的值，然后task重新从当时的offset的result开始进行流数据的处理和加工。

Flink平台为了尽量减少备份快照时对平台运行造成的性能开销（理论上备份快照时需要暂停任务的执行，flink对此基于复杂的算法对此做了很多优化）。这样这种优化也带来了一个问题，那就是不支持用户针对自己的任务来编写自定义的备份快照的方法和从快照恢复的方法。

例如，当任务执行一段时间后发现由于业务逻辑调整需要新增加一个flinkconsumer时，就无法再使用之前的快照让从flink平台从某个时间点来启动任务，如图2，如果task任务相比之前增加了一个kafka consumer3和结果值result2,那么，当我们指定从task之前的某个备份来启动任务时就会报错，因为当flink尝试从快照中恢复数据时 发现快照中没有consumer3和result2的数据，则会抛出异常进而启动失败。

总的来说，flink目前只支持由于数据原因或程序主体输入输出没有改变的情况下的快照备份和恢复机制。一旦任务的数据和输出发生变化，flink就会认为这是一个全新的任务，不能使用之前的任何快照数据。

在金融行业中，由于业务快速发展，系统版本的快速迭代上线，数据加工的口径也可能随时都会变化。

发明内容

本发明的目的在于解决当前的Flink等流计算框架只支持源端数据调整后的恢复执行的机制，并不支持对任务自身程序修改后的重放的问题。

本发明为解决上述技术问题，采用以下技术方案：

一种支持数据重放的流计算方法，包括以下步骤：

步骤1、流平台中定义task任务的备份保存机制以及task任务需要实现的快照备份和恢复接口Snapshot Interface；

步骤2、用户在task任务的实现中编写SnapShotInterface的实现类，最终形态为打包后的jar包；

步骤3、将jar包提交至流平台进行处理，同时流计算平台定期调用实现类的backup方法，将备份的数据保存到hdfs上；

步骤4、当任务执行一段时间后由于业务逻辑调整需要新增加一个flinkconsumer时，就无法再使用之前的快照让flink平台从某个时间点来启动task任务，当task任务相比之前增加了一个kafka consumer和结果值result,则指定从task任务之前的某个备份来启动task任务时就会报错，因为当flink尝试从快照中恢复数据时 发现快照中没有增加的kafka consumer和结果值result的数据，则会抛出异常进而task任务执行失败，当task任务执行失败后，重新启动task任务时流处理平台执行SnapShotInterface的实现类的recover方法从hdfs读取保存点文件并恢复数据，然后重新执行task任务。

上述技术方案中，上述步骤1具体包括以下步骤：

步骤1.1：在流平台中定义接口SnapShotInterface，该接口包含两个抽象方法backpup和recover；

步骤1.2：流平台实现对task任务的快照保存逻辑，流平台在间隔固定时间会执行SnapShotInterface实现类的backup方法，并将该方法的结果值序列化保存到hdfs或其他文件系统；

步骤1.3：流平台实现对task任务的恢复逻辑，流平台在检查用户提交任务的命令中监测到有从快照恢复的指令，会执行SnapShotInterface实现类的recover方法，在此之前流平台从hdfs或其他文件系统反序列化文件为内存对象后再作为参数传递给recove方法。

上述技术方案中，上述步骤2中：

在task任务中定义一个类文件并继承SnapShotInterface接口，同时编写backup和recover方法的具体实现：

backup方法：定义一个Map类型的集合，将源数据流处理的刻度、中间结果以键值对的形式保存到Map中；

recover方法：从该Map类型的集合中读取对应的值并赋值到源数据流处理的刻度、中间结果，除了可以从快照的Map中初始化task任务的状态，也可以通过配置文件或默认值的方式来初始化task任务的状态；

检验代码格式并打包存jar形式。

上述技术方案中，步骤3具体包括以下步骤：

步骤3.1：通过命令行的方式提交jar包至流平台运行；

步骤3.2：流平台在接收到jar包后，解析jar包后得到task任务后除了运行业务逻辑的代码外，还会根据备份机制定期执行task任务中SnapShotInerface接口实现类的backup方法，并将backup方法执行后返回的Map类型的集合序列化后保存到hdfs；

步骤3.3：该backup方法每间隔一个固定的周期就会执行一次，每次都会保存到不同的hdfs文件中。

上述技术方案中，步骤4具体包括以下步骤：

步骤4.1：用户重新提交task任务时，在命令行中指定保存点的hdfs文件路径；

步骤4.2：流计算平台接收到请求后会根据保存点的路径从hdfs加载该文件并反序列化成Map类型的集合；

步骤4.3：调用task任务的SnapShotInerface实现类的recover方法，并将上述Map类型的作为参数传递到recover的方法中；

步骤4.4：在数据快照恢复的过程中，平台会初始化task任务的源数据流的刻度和中间计算结果；

步骤4.5：初始化完成之后开始执行task任务，此时数据恢复任务就能从指定的保存点恢复执行。

因为本发明采用上述技术方案，因此具备以下有益效果：

（1）解决了由于任务计算口径变化不能使用之前快照数据进行恢复执行的问题。

（2）可以灵活的定义快照文件备份和恢复的介质和路径，例如：除了使用默认的将快照文件保存到hdfs，还可以保存到sftp、ftp、nas等存储介质。

（3）对于任务中新添加的源数据流刻度和目标值，支持初始话为默认值或从配置文件中读取的值。

（4）备份时，可以自定义备份哪些数据，除了输入和输出之外，对于task任务的中间结果也可以按实际需要进行快照备份。

（5）恢复时，可以自定义如何恢复数据，对于新增加的输入输出，如果无法从快照中获取，可以自定义从配置文件或默认值恢复，然后再开始任务的执行。如图2 ，我们可以指定consumer3的offset=1，result2=Y2。

附图说明

图1为本发明流程简图；

图2为标准的Flink流计算平台运行机制示意图；

图3为无法再使用之前的快照让从flink平台从某个时间点来启动任务示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明，即所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明提供了一种支持数据重放的流计算方法，包括以下步骤：

一种支持数据重放的流计算方法，包括以下步骤：

步骤1、流平台中定义task任务的备份保存机制以及task任务需要实现的快照备份和恢复接口Snapshot Interface；

步骤2、用户在task任务的实现中编写SnapShotInterface的实现类，最终形态为打包后的jar包；

步骤3、将jar包提交至流平台进行处理，同时流计算平台定期调用实现类的backup方法，将备份的数据保存到hdfs上；

步骤4、当任务执行一段时间后由于业务逻辑调整需要新增加一个flinkconsumer时，就无法再使用之前的快照让flink平台从某个时间点来启动task任务，当task任务相比之前增加了一个kafka consumer和结果值result,则指定从task任务之前的某个备份来启动task任务时就会报错，因为当flink尝试从快照中恢复数据时 发现快照中没有增加的kafka consumer和结果值result的数据，则会抛出异常进而task任务执行失败，当task任务执行失败后，重新启动task任务时流处理平台执行SnapShotInterface的实现类的recover方法从hdfs读取保存点文件并恢复数据，然后重新执行task任务。

上述技术方案中，上述步骤1具体包括以下步骤：

步骤1.1：在流平台中定义接口SnapShotInterface，该接口包含两个抽象方法backpup和recover；

步骤1.2：流平台实现对task任务的快照保存逻辑，流平台在间隔固定时间会执行SnapShotInterface实现类的backup方法，并将该方法的结果值序列化保存到hdfs或其他文件系统；

步骤1.3：流平台实现对task任务的恢复逻辑，流平台在检查用户提交任务的命令中监测到有从快照恢复的指令，会执行SnapShotInterface实现类的recover方法，在此之前流平台从hdfs或其他文件系统反序列化文件为内存对象后再作为参数传递给recove方法。

上述技术方案中，上述步骤2中：

在task任务中定义一个类文件并继承SnapShotInterface接口，同时编写backup和recover方法的具体实现：

backup方法：定义一个Map类型的集合，将源数据流处理的刻度、中间结果以键值对的形式保存到Map中；

recover方法：从该Map类型的集合中读取对应的值并赋值到源数据流处理的刻度、中间结果，除了可以从快照的Map中初始化task任务的状态，也可以通过配置文件或默认值的方式来初始化task任务的状态；

检验代码格式并打包存jar形式。

上述技术方案中，步骤3具体包括以下步骤：

步骤3.1：通过命令行的方式提交jar包至流平台运行；

步骤3.2：流平台在接收到jar包后，解析jar包后得到task任务后除了运行业务逻辑的代码外，还会根据备份机制定期执行task任务中SnapShotInerface接口实现类的backup方法，并将backup方法执行后返回的Map类型的集合序列化后保存到hdfs；

步骤3.3：该backup方法每间隔一个固定的周期就会执行一次，每次都会保存到不同的hdfs文件中。

上述技术方案中，步骤4具体包括以下步骤：

步骤4.1：用户重新提交task任务时，在命令行中指定保存点的hdfs文件路径；

步骤4.2：流计算平台接收到请求后会根据保存点的路径从hdfs加载该文件并反序列化成Map类型的集合；

步骤4.3：调用task任务的SnapShotInerface实现类的recover方法，并将上述Map类型的作为参数传递到recover的方法中；

步骤4.4：在数据快照恢复的过程中，平台会初始化task任务的源数据流的刻度和中间计算结果；

步骤4.5：初始化完成之后开始执行task任务，此时数据恢复任务就能从指定的保存点恢复执行。

Claims (2)

1.一种支持数据重放的流计算方法，其特征在于，包括以下步骤：

步骤1、流平台中定义task任务的备份保存机制以及task任务需要实现的快照备份和恢复接口Snapshot Interface；

步骤2、用户在task任务的实现中编写SnapShotInterface的实现类，最终形态为打包后的jar包；

步骤3、将jar包提交至流平台进行处理，同时流计算平台定期调用实现类的backup方法，将备份的数据保存到hdfs上；

步骤4、当task任务执行一段时间后由于业务逻辑调整需要新增加一个flinkconsumer时，就无法再使用之前的快照让flink平台从某个时间点来启动task任务，当task任务相比之前增加了一个kafka consumer和结果值result，则指定从task任务之前的某个备份来启动task任务时就会报错，因为当flink尝试从快照中恢复数据时 发现快照中没有增加的kafka consumer和结果值result的数据，则会抛出异常进而task任务执行失败，当task任务执行失败后，重新启动task任务时流处理平台执行SnapShotInterface的实现类的recover方法从hdfs读取保存点文件并恢复数据，然后重新执行task任务；

步骤4.1：用户重新提交task任务时，在命令行中指定保存点的hdfs文件路径；

步骤4.2：流计算平台接收到请求后会根据保存点的路径从hdfs加载该文件并反序列化成Map类型的集合；

步骤4.3：调用task任务的SnapShotInerface实现类的recover方法，并将上述Map类型的作为参数传递到recover的方法中；

步骤4.4：在数据快照恢复的过程中，平台会初始化task任务的源数据流的刻度和中间计算结果；恢复时，自定义如何恢复数据，对于新增加的输入输出，如果无法从快照中获取，自定义从配置文件或默认值恢复；

步骤4.5：初始化完成之后开始执行task任务，此时数据恢复任务就能从指定的保存点恢复执行；

上述步骤1具体包括以下步骤：

步骤1.1：在流平台中定义接口SnapShotInterface，该接口包含两个抽象方法backpup和recover；

步骤1.2：流平台实现对task任务的快照保存逻辑，流平台在间隔固定时间会执行SnapShotInterface实现类的backup方法，并将该方法的结果值序列化保存到hdfs或其他文件系统；

步骤1.3：流平台实现对task任务的恢复逻辑，流平台在检查用户提交任务的命令中监测到有从快照恢复的指令，会执行SnapShotInterface实现类的recover方法，在此之前流平台从hdfs或其他文件系统反序列化文件为内存对象后再作为参数传递给recove方法；

上述步骤2中：

在task任务中定义一个类文件并继承SnapShotInterface接口，同时编写backup和recover方法的具体实现：

backup方法：定义一个Map类型的集合，将源数据流处理的刻度、中间结果以键值对的形式保存到Map中；

recover方法：从该Map类型的集合中读取对应的值并赋值到源数据流处理的刻度、中间结果，除了可以从快照的Map中初始化task任务的状态，也可以通过配置文件或默认值的方式来初始化task任务的状态；

检验代码格式并打包存jar形式。

2.根据权利要求1所述的一种支持数据重放的流计算方法，其特征在于：步骤3具体包括以下步骤：

步骤3.1：通过命令行的方式提交jar包至流平台运行；

步骤3.2：流平台在接收到jar包后，解析jar包后得到task任务后除了运行业务逻辑的代码外，还会根据备份机制定期执行task任务中SnapShotInerface接口实现类的backup方法，并将backup方法执行后返回的Map类型的集合序列化后保存到hdfs；

步骤3.3：该backup方法每间隔一个固定的周期就会执行一次，每次都会保存到不同的hdfs文件中。

Images