登陆

深化了解 Flink 容错机制

admin 2019-12-14 269人围观 ,发现0个评论

本文作者是网易游戏的林小铂(社区ID:Paul Lam),文章质量很高。

作为分布式体系,尤其是对推迟灵敏的实时核算引擎,Apache Flink 需求有强壮的容错机制,以确保在呈现机器毛病或网络分区等不行预知的问题时能够快速主动康复并仍旧能发作精确的核算成果。事实上,Flink 有一套先进的快照机制来耐久化作业状况[1],确保中心数据不会丢掉,这一般需求和过错康复机制(作业重启战略或 failover 战略)合作运用。在遇到过错时,Flink 作业会依据重启战略主动重启并从最近一个成功的快照(checkpoint)康复状况。适宜的重启战略能够削减作业不行用时刻和防止人工介入处理毛病的运维本钱,因而关于 Flink 作业稳定性来说有着无足轻重的效果。下文就将详细解读 Flink 的过错康复机制。

Flink 容错机制首要有作业履行的容错以及看护进程的容错两方面,前者包含 Flink runtime 的 ExecutionGraph 和 Execution 的容错,后者则包含 JobManager 和 TaskManager 的容错。

作业履行容错

众所周知,用户运用 Flink 编程 API(DataStream/DataSet/Table/SQL)编写的作业终究会被翻译为 JobGraph 目标再提交给 JobManager 去履行,而后者会将 JobGraph 结合其他装备生成详细的 Task 调度到 TaskManager 上履行。

信任不少读者应该见过来自官网文档的这张架构图(图1),它明晰地描绘了作业的分布式履行机制: 一个作业有多个 Operator,彼此没有数据 shuffle 、并行度相同且契合其他优化条件的相邻 Operator 能够合并成 OperatorChain,然后每个 Operator 或许 OperatorChain 称为一个 JobVertex;在分布式履行时,每个 JobVertex 会作为一个 Task,每个 Task 有其并行度数意图 SubTask,而这些 SubTask 则是作业调度的最小逻辑单元。

图1. 作业的分布式履行

该图首要从 TaskManager 视点动身,而其真实 JobManager 端也存在一个中心的数据结构来映射作业的分布式履行,即 ExecutionGraph。ExecutionGraph 类似于图中并行视角的 Streaming Dataflow,它代表了 Job 的一次履行。从某种意义上讲,假如 JobGraph 是一个类的话,ExecutionGraph 则是它的一个实例。ExecutionGraph 中包含的节点称为 ExecutionJobVertex,对应 JobGrap 的一个 JobVertex 或许说图中的一个 Task。ExecutionJobVertex 能够有多个并行实例,即 ExecutionVertex,对应图中的一个 SubTask。在一个 ExecutionGraph 的生命周期中,一个 ExecutionVertex 能够被履行(重启)屡次,每次则称为一个 Execution。小结一下,ExecutionGraph 对应 Flink Job 的一次履行,Execution 对应 SubTask 的一次履行。

相对地,Flink 的过错康复机制分为多个等级,即 Execution 等级的 Failover 战略和 ExecutionGraph 等级的 Job Restart 战略。当呈现过错时,Flink 会先测验触发规模小的过错康复机制,假如仍处理不了才会晋级为更大规模的过错康复机制,详细能够用下面的序列图来表达(其间省掉了Exection 和 ExecutionGraph 的非要害状况转化深化了解 Flink 容错机制)。

图2. 作业履行容错

当 Task 发作过错,TaskManager 会经过 RPC 告诉 JobManager,后者将对应 Execution 的状况转为 failed并触发 Failover 战略。假如契合 Failover 战略,JobManager 会重启 Execution,不然晋级为 ExecutionGraph 的失利。ExecutionGraph 失利则进入failing的状况,由 Restart 战略决议其重启(restarting状况)仍是反常退出(failed状况)。

下面别离剖析两个过错康复战略的场景及完结。

Task Failover 战略

作为核算的最小履行单位,Task 过错是非常常见的,比方机器毛病、用户代码抛出过错或许网络毛病等等都或许形成 Task 过错。关于分布式体系来说,一般单个 Task 过错的处理方法是将这个 Task 从头调度至新的 worker 上,不影响其他 Task 和全体 Job 的运转,可是这个方法关于流处理的 Flink 来说并不行用。

Flink 的容错机制首要分为从 checkpoint 康复状况和重流数据两步,这也是为什么 Flink 一般要求数据源的数据是能够重复读取的。关于重启后的新 Task 来说,它能够经过读取 checkpoint 很容易地康复状况信息,可是却不能独登时重流数据,由于 checkpoint 是不包含数据的,要重流数据只能够要求依托到的悉数上游 Task 从头核算,一般来说会一向追溯到数据源 Task。了解 Spark 的同学大概会联想到 Spark 的血缘机制。简略来说,Spark 依据是否需求 shuffle 将作业分划为多个 Stage,每个 Stage 的核算都是独立的 Task,其成果能够被缓存起来。假如某个 Task 履行失利,那么它只需重读上个 Stage 的核算缓存成果即可,不影响其他 Task 的核算。Spark 能够独登时康复一个 Task,很大程度上是由于它的批处理特性,这答应了作业经过缓存中心核算成果来解耦上下游 Task 的联络。而 Flink 作为流核算引擎,明显是无法简略做到这点的。

要做到细粒度的过错康复机制,减小单个 Task 过错关于全体作业的影响,Flink 需求完结一套愈加杂乱的算法,也便是 FLIP-1 [2] 引进的 Task Failover 战略。Task Failover 战略现在有三个,别离是

RestartAllRestartIndividualStrategyRestartPipelinedRegionStrategy

图3. Restart Region 战略重启有数据交换的 Task

  • RestartAll: 重启悉数 Task,是康复作业一致性的最安全战略,会在其他 Failover 战略失利时作为保底战略运用。

    现在是默许的 Task Failover 战略。

  • RestartPipelinedRegionStrategy: 重启过错 Task 地点 Region 的悉数 Task。

    Task Region 是由 Task 的数据传输决议的,有数据传输的 Task 会被放在同一个 Region,而不同 Region 之间没有数据交换。

  • RestartIndividualStrategy: 康复单个 Task。

    由于假如该 Task 没有包含数据源,这会导致它不能重流数据而导致一部分数据丢掉。

    考虑到至少供给精确一次的投递语义,这个战略的运用规模比较有限,只运用于 Task 间没有数据传输的作业。

    不过也有部分事务场景或许需求这种 at-most-once 的投递语义,比方对推迟灵敏而对数据一致性要求相对低的引荐体系。

整体来说,RestartAll较为保存会形成资源糟蹋,而RestartIndividualStrategy则过分急进不能确保数据一致性,而RestartPipelinedRegionStrategy重启的是一切 Task 里最小必要子集,其实是最好的 Failover 战略。而实际上 Apache 社区也正准备在 1.9 版别将其设为默许的 Failover 战略[3]。不过值得留意的是,在 1.9 版别曾经RestartPipelinedRegionStrategy有个严峻的问题是在重启 Task 时并不会康复其状况[4],所以请在 1.9 版别今后才运用它,除非你在跑一个无状况的作业。

Job Restart 战略

假如 Task 过错终究触发了 Full Restart,此刻 Job Restart 战略将会操控是否需求康复作业。Flink 供给三种 Job 详细的 Restart Strategy。

  • FixedDelayRestartStrategy: 答应指定次数内的 Execution 失利,假如超越该次数则导致 Job 失利。

    FixedDelayRestartStrategy 重启能够设置必定的推迟,以削减频频重试对外部体系带来的负载和不必要的过错日志。

    现在 FixedDelayRestartStrategy 是默许的 Restart Strategy。

  • FailureRateRestartStrategy: 答应在指定时刻窗口内的指定次数内的 Execution 失利,假如超越这个频率则导致 Job 失利。

    同样地,FailureRateRestartStrategy 也能够设置必定的重启推迟。

  • NoRestartStrategy: 在 Execution 失利时直接让 Job 失利。

现在的 Restart Strategy 能够根本满意“主动重启挂掉的作深化了解 Flink 容错机制业”这样的简略需求,可是并没有区别作业犯错的原因,这导致或许会对不行康复的过错(比方用户代码抛出的 NPE 或许某些操作报 Permission Denied)进行不必要的重试,进一步的结果是没有第一时刻退出,或许导致用户没有及时发现问题,其外关于资源来说也是一种糟蹋,最终还或许导致一些副效果(比方有些 at-leaset-once 的操作被履行屡次)。

对此,社区在 1.7 版别引进了 Exception 的分类[5],详细会将 Runtime 抛出的 Exception 分为以下几类:

  • NonRecoverableError: 不行康复的过错。

    不对此类过错进行重试。

  • PartitionDataMissingError: 当时 Task 读不到上游 Task 的某些数据,需求上游 Task 重跑和重发数据。

  • EnvironmentError: 履行环境的过错,一般是 Flink 以外的问题,比方机器问题、依托问题。

    这种过错的一个显着特征是会在某些机器上履行成功,但在别的一些机器上履行失利。

    Flink 后续能够引进黑名单机器来更聪明地进行 Task 调度以暂时防止这类问题的影响。

  • RecoverableError: 可康复过错。

    不属于上述类型的过错都暂设为可康复的。

其实这个分类会运用于 Task Failover 战略和 Job Restart 战略,不过现在只要后者会分类处理,并且 Job Restart 战略对 Flink 作业的稳定性影响明显更大,因而放在这个当地讲。值得留意的是,到现在(1.8 版别)这个分类只处于很初级的阶段,像 NonRecoverable 只包含了作业 State 命名抵触等少量几个内部过错,而 PartitionDataMissingError 和 EnvironmentError 还未有运用,所以绝大多数的过错仍是 RecoverableError。

看护进程容错

关于分布式体系来说,看护进程的容错是根本要求并且现已比较老练,根本包含毛病检测和毛病康复两个部分:毛病检测一般经过心跳的方法来完结,心跳能够在内部组件间完结或许依托于 zookeeper 等外部服务;而毛病康复则一般要求将状况耐久化到外部存储,然后在毛病呈现时用于初始化新的进程。

以最为常用的 on YARN 的布置形式来讲,Flink 要害的看护进程有 JobManager 和 TaskManager 两个,其间 JobManager 的首要责任和谐资源和办理作业的履行别离为 ResourceManager 和 JobMaster 两个看护线程承当,三者之间的联系如下图所示。

图4. ResourceManager、JobMaster 和 TaskManager 三者联系

在容错方面,三个人物两两之间彼此发送心跳来进行一起的毛病检测[7]。此外在 HA 场景下,ResourceManager 和 JobMaster 都会注册到 zookeeper 节点上以完结 leader 锁。

TaskManager 的容错

假如 ResouceManager 经过心跳超时检测到或许经过集群办理器的告诉了解到 TaskManager 毛病,它会告诉对应的 JobMaster 并发动一个新的 TaskManager 以做替代。留意 ResouceManager 并不关怀 Flink 作业的状况,这是 JobMaster 的责任去办理 Flink 作业要做何种反响。

假如 JobMaster 经过 ResouceManager 的告诉了解到或许经过心跳超时检测到 TaskManager 毛病,它首先会从自己的 slot pool 中移除该 TaskManager,并将该 TaskManager 上运转的一切 Tasks 标记为失利,然后触发 Flink 作业履行的容错机制以康复作业。

TaskManager 的状况现已写入 checkpoint 并会在重启后主动康复,因而不会形成数据不一致的问题。

ResourceManager 的容错

假如 TaskManager 经过心跳超时检测到 ResourceManager 毛病,或许收到 zookeeper 的关于 ResourceManager 失掉 leadership 告诉,TaskManager 会寻觅新的 leader ResourceManager 并将自己重启注册到其上,期间并不会中止 Task 的履行。

假如 JobMaster 经过心跳超时检测到 ResourceManager 毛病,或许收到 zookeeper 的关于 ResourceManager 失掉 leadership 告诉,JobMaster 同样会等候新的 ResourceManager 变成 leader,然后从头恳求一切的 TaskManager。考虑到 TaskManager 也或许成功康复,这样的话 JobMaster 新恳求的 TaskManager 会在闲暇一段时刻后被开释。

ResourceManager 上坚持了许多状况信息,包含活泼的 container、可用的 TaskManager、TaskManager 和 JobMaster 的映射联系等等信息,不过这些信息并不是 ground truth,能够从与 JobMaster 及 TaskManager 的状况同步中再从头取得,所以这些信息并不需求耐久化。

JobMaster 的容错

假如 TaskManager 经过心跳超时检测到 JobMaster 毛病,或许收到 zookeeper 的关于 JobMaster 失掉 leadership 告诉,TaskManager 会触发自己的过错康复(现在是开释一切 Task),然后等候新的 JobMaster。假如新的 JobMaster 在必定时刻后仍未呈现,TaskManager 会将其 slot 标记为闲暇并奉告 ResourceManager。

假如 ResourceManager 经过心跳超时检测到 JobMaster 毛病,或许收到 zookeeper 的关于 JobMaster 失掉 leadership 告诉,ResourceManager 会将其奉告 TaskManager,其他不作处理。

JobMaster 保存了许多对作业履行至关重要的状况,其间 JobGraph 和用户代码会从头从 HDFS 等耐久化存储中获取,checkpoint 信息会从 zookeeper 取得,Task 的履行信息能够不康复由于整个作业会从头调度,而持有的 slot 则从 ResourceManager 的 TaskManager 的同步信息中康复。

并发毛病

在 on YARN 布置形式下,由于 JobMaster 和 ResourceManager 都在 JobManager 进程内,假如 JobManager 进程出问题,一般是 JobMaster 和 ResourceManager 并发毛病,那么 TaskManager 会按以下过程处理:

  1. 依照一般的 JobMaster 毛病处理。

  2. 在一段时刻内不断测验将 slot 供给给新的 JobMaster。

  3. 不断测验将自己注册到 ResourceManager 上。

值得留意的是,新 JobManager 的拉起是依托 YARN 的 Application attempt 重试机制来主动完结的,而依据 Flink 装备的 YARN Application keep-containers-across-application-attempts行为,TaskManager 不会被整理,因而能够从头注册到新发动的 Flink ResourceManager 和 JobMaster 中。

Flink 容错机制确保了 Flink 的可靠性和耐久性,是 Flink 运用于企业级出产环境的重要确保,详细来说它包含作业履行的容错和看护进程的容错两个方面。在作业履行容错方面,Flink 供给 Task 等级的 Failover 战略和 Job 等级的 Restart 战略来进行毛病状况下的主动重试。在看护进程的容错方面,在on YARN 形式下,Flink 经过内部组件的心跳和 YARN 的监控进行毛病检测。TaskManager 的毛病会经过请求新的 TaskManager 并重启 Task 或 Job 来康复,JobManager 的毛病会经过集群办理器的主动拉起新 JobManager 和 TaskManager 的从头注册到新 leader JobManager 来康复。

  1. Flink 轻量级异步快照 ABS 完结原理

  2. FLIP-1 : Fine Grained Recovery from Task Failures

  3. [FLINK-13223] Set jobmanager.execution.failover-strategy to region in default flink-conf.yaml

  4. [FLINK-10712] RestartPipelinedRegionStrategy does not restore state

  5. [FLINK-10289] Classify Exceptions to different category for apply different failover strategy

  6. [FLINK-10288] Failover Strategy improvement

  7. FLIP-6 - Flink Deployment and Process Model - Standalone, Yarn, Mesos, Kubernetes, etc.

END

重视

大众号(zhisheng)里回复 面经、ES、Flink、Spring、Java、Kafka、监控 等要害字能够检查更多要害字对应的文章

Flink 实战

1、《从0到1学习Flink》—— Apache Flink 介绍

2、《从0到1学习Flink》—— Mac 上建立 Flink 1.6.0 环境并构建运转简略程序入门

3、《从0到1学习Flink》—— Flink 装备文件详解

4、《从0到1学习Flink》—— Data Source 介绍

5、《从0到1学习Flink》—— 怎样自定义 Data Source ?

6、《从0到1学习Flink》—— Data Sink 介绍

7、《从0到1学习Flink》—— 怎样自定义 Data Sink ?

8、《从0到1学习Flink》—— Flink Data transformation(转化)

9、《从0到1学习Flink》—— 介绍 Flink 中的 Stream Windows

10、《从0到1学习Flink》—— Flink 中的几种 Time 详解

11、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 ElasticSearch

12、《从0到1学习Flink》—— Flink 项目怎样运转?

13、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 Kafka

14、《从0深化了解 Flink 容错机制到1学习Flink》—— Flink JobManager 高可用性装备

15、《从0到1学习Flink》—— Flink parallelism 和 Slot 介绍

16、《从0到1学习Flink》—— Flink 读取 Kafka 数据批量写入到 MySQL

17、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 RabbitMQ

18、《从0到1学习Flink》—— 你上传的 jar 包藏到哪里去了

19、大数据“重磅炸弹”——实时核算结构 Flink

20、《Flink 源码解析》—— 源码编译运转

21、为什么说流处理即未来?

22、OPPO数据中台之柱石:根据Flink SQL构建实数据仓库

23、流核算结构 Flink 与 Storm 的功能比照

24、Flink状况办理和容错机制介绍

25、原理解析 | Apache Flink 结合 Kafka 构建端到端的 Exactly-Once 处理

26、Apache Flink 是怎样办理好内存的?

27、《从0到1学习Flink》——Flink 中这样办理装备,你知道?

28、《从0到1学习Flink》——Flink 不行以接连 Split(分流)?

29、Flink 从0到1学习—— 共享四本 Flink 的书和二十多篇 Paper 论文

30、360深度实践:Flink与Storm协议级比照

31、Apache Flink 1.9 严重特性提早解读

32、怎样根据Flink+TensorFlow打造实时智能反常检测渠道?只看这一篇就够了

33、美团点评根据 Flink 的实时数仓建造三位一体实践

34、Flink 魂灵两百问,这谁顶得住?

35、一文搞懂 Flink 的 Exactly Once 和 At Least Once

36、你公司究竟需不需求引进实时核算引擎?

37、Flink 从0到1学习 —— 怎样运用 Side Output 来分流?

38、一文让你完全了解大数据实时核算引擎 Flink

39、根据 Flink 完结的产品实时引荐体系(附源码)

40、怎样运用 Flink 每天实时处理百亿条日志?

41、Flink 在趣头条的运用与实践

42、Flink Connector 深度解析

43、滴滴实时核算开展之路及渠道架构实践

44、Flink Back Pressure(背压)是怎样完结的?有什么绝妙之处?

45、Flink 实战 | 贝壳找房根据Flink的实时渠道建造

46、怎样运用 Kubernetes 布置 Flink 运用

47、一文完全搞懂 Flink 网络流控与反压机制

Flink 源码解析

常识星球里边能够看到下面文章

请关注微信公众号
微信二维码
不容错过
Powered By Z-BlogPHP