数据流容错机制

该文档翻译自Data Streaming Fault Tolerance,文档描述flink在流式数据流图上的容错机制。

-------------------------------------------------------------------------------------------------

一、介绍

flink提供了可以一致地恢复数据流应用的状态的容错机制,该机制保证即使在错误发生后,反射回数据流记录的程序的状态操作最终仅执行一次。值得注意的是,该保证可以降低为“至少执行一次”,具体描述见下。

容错机制持续地从分布式数据流图中取得快照。对于拥有少量状态的流式应用,这些快照是非常轻量级的,故它们可以在频繁获取时仍然不过多影响运行效率。流式应用的状态将被存储在一个配置位置中(如一个master节点、HDFS中等)。

在程序失效时(不论源自硬件、网络、软件等),flink将会停止分布式数据流图,而后系统将会重启Operator并重置它们到最近成功的检查点。输入流将会被充值到状态快照的时间点。flink保证重启的并行数据流图中的所有已处理的记录都不会出现在检查点状态之前的部分中。

Note:要使得机制支持其所有的保证,数据流source需要能够将流倒回到指定的之前的点。Apache Kafka有这个方法,flink与Kafka的connector可以利用该方法完成倒回的功能

Note:由于Flink的检查点由分布快照实现,以下的“检查点”和“快照”是同意义的。

二、检查点

Flink容错机制的核心是获取数据流和Operator状态的一致分布式快照。这些快照作为系统可以撤回的一致检查点。Flink的机制所获取的快照在"

Lightweight Asynchronous Snapshots for Distributed Dataflows"中有所描述。它发展自分布式快照的标准Chandy-Lamport算法,并且经过定制适配了Flink的执行模型。

2.1 Barriers

Flink的分布式快照的核心元素是stream barriers。这些barriers被注入到数据流中,作为数据流的一部分和其他数据一同流动(正如InfoSphere的punctuation),barriers不会超过其他数据到达(乱序到达)。一个Barrier将数据流中的数据分割成两个数据集,即进入当前快照的数据和进入下一次快照的数据。每个Barrier带有一个ID,该ID为将处于该Barrier之前的数据归入快照的检查点的ID。Barrier不会打断数据流的流动,所以它是十分轻量级的。来自不同的快照的多个Barrier可以同一时间存在于同一个流中,也就是说,不同的快照可以并行同时发生。

图1 Barriers

数据流中的Barrier是在数据流的source处被插入到并行数据流图的。快照n的barrier被插入的点(成为Sn),就是在源数据流中快照n能覆盖到的数据的最近位置,如在Apache Kafaka中,这个位置就是上一个数据(record)在分区(partition)中的偏移量(offset)。这个位置Sn将会交给checkpoint coordinator(Flink的JobManager中)。

这些Barrier随数据流流动向下游,当一个中间Operator在其输入流接收到快照n的barrier时,它在其所有的输出流中都发送一个快照n的Barrier。当一个sink operator(流DAG的终点)从其输入流接收到n的Barrier,它将快照n通知给checkpoint coordinator。在所有Sink都通知了一个快照后,这个快照就完成了。

当快照n完成后,由于数据源中先于Sn的的数据已经通过了整个data flow topology,我们就可以确定不再需要这些数据了。

图2 对齐操作

接受多于1个输入流的Operator在处理快照的Barrier时,需要对多输入流进行对齐(align)操作,具体过程如上图所示:

  1. Operator一旦从输入流中收到快照n的barrier,它在其他所有的输入流中都收到快照n的barrier之前,都不能继续处理新的数据。否则,它将把属于快照n和快照n+1的数据混起来。

  2. 收到Barrier n的数据流将被暂时搁置起来,从这些数据流中收到的数据将不会被进一步处理,而是放进一个输入缓存中(input buffer)

  3. 当最后的数据流收到Barrier n,Operator将所有等待的输出数据发送出去,然后发送Barrier n。

  4。 在这之后,Operator将恢复处理输入流的数据,先处理input buffer中的数据,再处理新接收的数据。

2.2 状态(State)

当Operator包含任何形式的状态,该状态一定也是快照的一部分。Operator的状态有着不同的形式:

  1. 用户定义状态(User-defined state):该状态直接由transformation方法(如map(), filter())来创建和修改。用户定义状态可以简单地是一个Java对象函数的变量,或函数的相关的key-value状态(具体见于流应用的状态

  2. 系统状态(System state):该状态指在Operator计算中的数据缓存。窗口缓存就是一个典型例子,系统内部收集、聚集(aggregate)窗口数据直到窗口数据逐出(如窗口滑动、evaluated and evicted)。

当Operator在它所有的输入流都收到Barrier时,在将Barrier发送到输出流之前,它将会对其状态进行快照。此时,所有在Barrier之前的数据对状态的更新操作都将完成,而在Barrier之后的数据对状态的更新操作都不会执行。由于快照的状态可能会很大,它将会在后台被保存的一个可配置状态中。默认地,它使用JobManager拥有的内存,但对于严谨的配置来说,应当配置一个可靠的分布式存储(如HDFS)。在保存状态之后,Operator通知checkpoint,并发送快照Barrier到期输出流中,并继续其他处理。

目前的快照包括2个部分:

  1. 对每个并行数据流的数据源,快照开始时,数据流的偏移量(offset)或位置(position)。

  2. 每个Operator存储的该快照的状态的指针。

图3 检查点存储状态

2.3 只执行一次 VS. 至少执行一次

对齐操作可能会给流应用增加延迟(latency),通常这些额外时延都仅是毫秒级的,但也有在一些异常情况下延迟明显增长的情况。一些应用对所有数据都严格要求极低延迟(几毫秒),在这些应用中,Flink提供一个可以跳过检查点中对齐操作的开关接口。检查点快照依然将在Operator在所有输入流接收到检查点Barrier时生成。

当选择跳过对齐操作时,即使Operator在一些输入流中接收到检查点n的Barrier,它仍将继续处理所有输入数据。在这种情况下,Operator在检查点n快照生成之前,也会处理属于快照n+1的数据。在恢复时,这些数据将会重复出现,因为它们既属于检查点n的状态快照,也会在检查点n之后的数据重放(replay)中出现。

NOTE: 对齐操作仅用于拥有多前驱的Operator(Join)或多发送方的Operator(如一个重分区(repartitioning)/洗牌(shuffle)后的流)。由于这一点,对于仅带有“

embarrassingly parallel streaming operations”的数据流图,即使在至少执行一次(at least once的模式下也会给出只执行一次(exact once的保证。【这段我没有看懂。。】

2.4 恢复

Flink恢复时的机制是十分直接的:在系统失效时,Flink选择最近的已完成的检查点k,系统接下来重部署整个数据流图,然后给每个Operator在检查点k时的相应状态。数据源则被设置为从数据流的Sk位置开始读取。例如,在Apache Kaffa执行恢复时,系统会通知消费者从偏移Sk开始获取数据。

如果状态是以递增的形式快照的,则Operator会从最近的完整快照开始,然后应用一系列的递增快照来更新该种状态。

Flink资料(2)-- 数据流容错机制的更多相关文章

  1. Apache Flink - 数据流容错机制

    Apache Flink提供了一种容错机制,可以持续恢复数据流应用程序的状态.该机制确保即使出现故障,程序的状态最终也会反映来自数据流的每条记录(只有一次). 从容错和消息处理的语义上(at leas ...

  2. 总结Flink状态管理和容错机制

    本文来自8月11日在北京举行的 Flink Meetup会议,分享来自于施晓罡,目前在阿里大数据团队部从事Blink方面的研发,现在主要负责Blink状态管理和容错相关技术的研发.   本文主要内容如 ...

  3. Flink状态管理和容错机制介绍

    本文主要内容如下: 有状态的流数据处理: Flink中的状态接口: 状态管理和容错机制实现: 阿里相关工作介绍: 一.有状态的流数据处理# 1.1.什么是有状态的计算# 计算任务的结果不仅仅依赖于输入 ...

  4. Flink学习(三)状态机制于容错机制,State与CheckPoint

    摘自Apache官网 一.State的基本概念 什么叫State?搜了一把叫做状态机制.可以用作以下用途.为了保证 at least once, exactly once,Flink引入了State和 ...

  5. Flink原理(五)——容错机制

    本文是博主阅读Flink官方文档以及<Flink基础教程>后结合自己理解所写,若有表达有误的地方欢迎大伙留言指出. 1.  前言 流式计算分为有状态和无状态两种情况,所谓状态就是计算过程中 ...

  6. Flink 容错机制与状态

    简介 Apache Flink提供了一种容错机制,可以持续恢复数据流应用程序的状态. 该机制确保即使出现故障,经过恢复,程序的状态也会回到以前的状态. Flink 主持 at least once 语 ...

  7. 大数据计算引擎之Flink Flink状态管理和容错

    这里将介绍Flink对有状态计算的支持,其中包括状态计算和无状态计算的区别,以及在Flink中支持的不同状态类型,分别有 Keyed State 和 Operator State .另外针对状态数据的 ...

  8. 【原】Storm 守护线程容错机制

    Storm入门教程 1. Storm基础 Storm Storm主要特点 Storm基本概念 Storm调度器 Storm配置 Guaranteeing Message Processing(消息处理 ...

  9. Spark RDD概念学习系列之RDD的容错机制(十七)

    RDD的容错机制 RDD实现了基于Lineage的容错机制.RDD的转换关系,构成了compute chain,可以把这个compute chain认为是RDD之间演化的Lineage.在部分计算结果 ...

随机推荐

  1. Oracle_双机备份

    1.dataguard http://jingyan.baidu.com/article/f96699bb956ef2894e3c1b39.html http://blog.itpub.net/262 ...

  2. 正益工作是何许APP?凭什么作为第一届大会的“闪亮”点

    参加过很多发布会,看过很多宣传稿,渐渐的你也读懂了“大会亮点”,这是技术人.市场人绞尽脑汁.加班加点的成果,更渗透着企业未来的战略思路.在2016AppCan移动开发者大会的官方新闻发布后,很多人留言 ...

  3. Selenium中expected_conditions下text_to_be_present_in_element_value方法的使用

    text_to_be_present_in_element: 判断某个元素中的text是否包含了预期的字符串 text_to_be_present_in_element_value: 判断某个元素中的 ...

  4. 亲测!Jquery2.0不支持IE8-了

    最近由于测试需要,Win7回退到了官方更新的IE8浏览器,惊人的发现: <script src="//cdn.bootcss.com/jquery/2.0.0/jquery.min.j ...

  5. 【★】Web精彩实战之

    JS精彩实战之<智能迷宫>      ---宝贵编程经验分享会--- hello大家好,这里是Web云课堂,之前的一年里我们经历了Html和CSS的系统攻城,此时的你们已经是做静态(动静结 ...

  6. 3行代码快速实现Spring Boot Oauth2服务

    这里的3行代码并不是指真的只需要写3行代码,而是基于我已经写好的一个Spring Boot Oauth2服务.仅仅需要修改3行数据库配置信息,即可得到一个Spring Boot Oauth2服务. 项 ...

  7. SAP MM 事务代码MI31之思考

    SAP MM 事务代码MI31之思考 1 - MI01之痛 多年SAP项目实施实践中,笔者之前对于SAP系统里盘点凭证创建(MI01)事务代码里的输入界面很是不爽: 第一,MI01输入了一行数据以后, ...

  8. swift 头尾式动画

    1.0 头尾式动画 UIView.beginAnimations(nil, context: nil) UIView.setAnimationDuration(1.0) // 设置执行动画所需要的时间 ...

  9. poj 1066 Treasure Hunt (未完)

    #include<stdio.h> #include<math.h> #include<stdlib.h> #define eps 1e-8 #define zer ...

  10. Linux命令应用大词典-第16章 归档和压缩

    16.1 tar:进行归档和压缩 16.2 gzip:压缩或解压缩gzip文件 16.3 gunzip:解压缩gzip文件 16.4 zcmp:比较gzip压缩文件 16.5 zdiff:比较gzip ...