Flink-执行拓扑图与作业调度

2023-11-29 09:30

本文主要是介绍Flink-执行拓扑图与作业调度,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

算子与作业提交

  • 一、Flink执行模式
    • 1.流执行模式
    • 2.批执行模式
  • 二、Flink拓扑图
    • 1.基本概念
    • 2.拓扑图生成过程
  • 三、拓扑生成和优化
    • 1.应用程序
    • 2.逻辑视图
    • 3.算子链
    • 4.Task Slots
  • 四、作业调度
    • 1.调度
    • 2.拓扑图数据结构
    • 3.Job状态转化
    • 4.Task状态转化
  • 总结
    • 参考链接


一、Flink执行模式

Flink对流处理和批处理采用统一的处理方式,执行模式可以通过execute.runtime-mode来配置。有三种可选的值:STREAMING:流模式,BATCH:批模式,AUTOMATIC:由系统决定。

1.流执行模式

在流模式下,所有任务需要一直在线运行,所以集群需要一次性分配足够的资源来运行所有任务。这样每个任务都可以立即执行新的记录,达到连续和低延迟的流处理。
流执行模式下,网络shuffle是流水式的,在网络层进行一些缓冲然后传递到下一个处理节点,在任务之间没有数据点。

2.批执行模式

在批处理模式下,作业可以一个阶段接一个阶段执行,集群只需要分配单个阶段的资源就可以运行任务。分阶段处理时Flink会将任务的中间结果保存到一些非永久性存储中,上游任务执行完毕可以下线,下游任务从存储中读取中间结果继续执行。

二、Flink拓扑图

1.基本概念

flink程序从编写到提交过程中执行图的转化涉及很多概念,在进行介绍执行图之前先了解一下Job、Operation、Task、SubTask、Task Slot等。

  • Operation:由Flink Stream API提供的一系列操作算子,包括输入算子、计算算子和输出算子。
  • Job:由用户将一系列Operation组合而成的程序,一个Job就是一个可以提交给Flink执行的作业。
  • Task:在JobGraph中由一个算子或者多个算子链接在一起转化而来的逻辑上的运算节点
  • SubTask:flink是一个并行的程序,因此按照并行度每个算子Task可以有多个算子子任务SubTask,每个算子子任务是彼此独立并在不同的线程中执行。
  • TaskSlot:每个TaskManager都是一个JVM进程,包含的多个Task Slot是线程,每个TaskSlot可以执行一个或者多个SubTask。

2.拓扑图生成过程

Flink的应用程序是由flink算子组合而的dataflow所组成,Flink会将程序直接映射成数据流图StreamGraph,在提交到集群前会优化生成JobGraph。JobManager会根据并发度生成执行图ExecutionGraph,然后调度部署到TaskManager的TaskSlot中形成物理执行图。
在这里插入图片描述
Flink中从程序到最后的物理执行分为四层:StreamGraph->JobGraph->ExecutionGraph->物理执行。

  • StreamGraph:是将用户Stream API算子组成的代码生成的数据流算子拓扑图。
  • JobGraph:将数据流拓扑图中一些算子进行优化合并成一个Task拓扑图,这样可以减少两个算子之间数据的交换产生的延迟和消耗。
  • ExecutionGraph:由JobManager根据JobGraph和并发度生产的可调度的subTask拓扑图。
  • 执行图:集群调度时,各个TaskManager上Task Slot部署subTask的部署情况。

三、拓扑生成和优化

1.应用程序

在这里插入图片描述
应用程序用用户自定义的算子组成,由输入算子、计算算子、输出算子三类组成。

2.逻辑视图

在这里插入图片描述
在程序执行过程中,一个流可以有多个分区,也就是每个算子可以有多个子任务,每个任务并行的处理各自的数据。每个算子子任务的数量就是这个算子的并行度。

算子之间传输数据分为两种情况:

  • 一对一模式:保留元素分区和顺序信息,也就是上游算子的输出的数据和顺序跟下游算子完全一致,也就是同一个分区数据只会进入下游算子的同一分区。
  • 重新分发模式:会改变数据的分区信息,不同的算子会根据一些信息将数据重新发送到不同分区的下游算子。比如keyBy()会根据散列值重新分区。

3.算子链

如果将每个算子都转化成一个任务,这样计算过程可能会需要线程切换、中间结果缓冲等,增加了调度开销和系统的延迟,所以会把一些算子算作一个任务进行调度,可以减少开销和延迟。如果增加算子链优化后,逻辑执行图如下:

在这里插入图片描述

4.Task Slots

每个TaskManager都是一个JVM进程,包含的多个TaskSlot是线程,每个TaskSlot可以执行一个或者多个SubTask。
在这里插入图片描述
Flink支持SubTask共享slot,即来自同一个作业的SubTask由同一个TaskSlot执行。这样所需要的TaskSlot和作业并行度一致,可以更好的利用资源,增加并行度。

在这里插入图片描述

四、作业调度

1.调度

Flink集群中JobManager负责调度SubTask在TaskManager上的执行。TaskManager通过TaskSlot来定义执行资源,每个TaskSlot可以执行一个SubTask或者来自同一个作业的多个SubTask。
比如:由一个数据源、并行度为4的Map和并行度为3的Reduce组成的作业。那么在TaskManager实际分配资源如下。
在这里插入图片描述

2.拓扑图数据结构

在JobGraph中的Task由数据结构JobVertex表示,包含并行度和运行的代码。
在ExecutionGraph中的SubTask由数据结构ExecutionVertex表示,ExecutionVertex负责跟踪子任务的执行状态,而数据结构ExecutionJobVertex会负责跟踪任务的执行状态。
在这里插入图片描述

3.Job状态转化

Flink 作业刚开始会处于 created 状态,然后切换到 running 状态,当所有任务都执行完之后会切换到 finished 状态。

  • 如果遇到失败的话,作业首先切换到 failing 状态以便取消所有正在运行的 task。
  • 如果所有 job 节点都到达最终状态并且 job无法重启, 那么 job 进入 failed 状态。
  • 如果作业可以重启,那么就会进入到 restarting状态,当作业彻底重启之后会进入到 created 状态。
  • 如果用户取消了 job 话,它会进入到 cancelling 状态,并取消所有正在运行的 task。当所有正在运行的 task 进入到最终状态的时候,job 进入 cancelled 状态。

Finished、canceled 和 failed 会导致全局的终结状态,并且触发作业的清理。跟这些状态不同,suspended 状态只是一个局部的终结。局部的终结意味着作业的执行已经被对应的 JobManager 终结,但是集群中另外的 JobManager 依然可以从高可用存储里获取作业信息并重启。因此一个处于 suspended 状态的作业不会被彻底清理掉。
在这里插入图片描述

4.Task状态转化

在整个 ExecutionGraph 执行期间,每个并行 task 都会经历多个阶段,从 created 状态到 finished 或 failed。下图展示了各种状态以及他们之间的转换关系。由于一个 task 可能会被执行多次(比如在异常恢复时),ExecutionVertex 的执行是由 Execution 来跟踪的,每个 ExecutionVertex 会记录当前的执行,以及之前的执行。
在这里插入图片描述

总结

主要介绍Flink执行模式以及Flink作业提交过程中拓扑图的生产和优化,还有作业调度和其中涉及的数据结构。


参考链接

1.Flink官网

这篇关于Flink-执行拓扑图与作业调度的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/432299

相关文章

作业提交过程之HDFSMapReduce

作业提交全过程详解 (1)作业提交 第1步:Client调用job.waitForCompletion方法,向整个集群提交MapReduce作业。 第2步:Client向RM申请一个作业id。 第3步:RM给Client返回该job资源的提交路径和作业id。 第4步:Client提交jar包、切片信息和配置文件到指定的资源提交路径。 第5步:Client提交完资源后,向RM申请运行MrAp

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3

maven 编译构建可以执行的jar包

💝💝💝欢迎莅临我的博客,很高兴能够在这里和您见面!希望您在这里可以感受到一份轻松愉快的氛围,不仅可以获得有趣的内容和知识,也可以畅所欲言、分享您的想法和见解。 推荐:「stormsha的主页」👈,「stormsha的知识库」👈持续学习,不断总结,共同进步,为了踏实,做好当下事儿~ 专栏导航 Python系列: Python面试题合集,剑指大厂Git系列: Git操作技巧GO

jenkins 插件执行shell命令时,提示“Command not found”处理方法

首先提示找不到“Command not found,可能我们第一反应是查看目标机器是否已支持该命令,不过如果相信能找到这里来的朋友估计遇到的跟我一样,其实目标机器是没有问题的通过一些远程工具执行shell命令是可以执行。奇怪的就是通过jenkinsSSH插件无法执行,经一番折腾各种搜索发现是jenkins没有加载/etc/profile导致。 【解决办法】: 需要在jenkins调用shell脚

一种改进的red5集群方案的应用、基于Red5服务器集群负载均衡调度算法研究

转自: 一种改进的red5集群方案的应用: http://wenku.baidu.com/link?url=jYQ1wNwHVBqJ-5XCYq0PRligp6Y5q6BYXyISUsF56My8DP8dc9CZ4pZvpPz1abxJn8fojMrL0IyfmMHStpvkotqC1RWlRMGnzVL1X4IPOa_  基于Red5服务器集群负载均衡调度算法研究 http://ww

Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

在 Redis 中,Lua 脚本具有原子性是因为 Redis 保证在执行脚本时,脚本中的所有操作都会被当作一个不可分割的整体。具体来说,Redis 使用单线程的执行模型来处理命令,因此当 Lua 脚本在 Redis 中执行时,不会有其他命令打断脚本的执行过程。脚本中的所有操作都将连续执行,直到脚本执行完成后,Redis 才会继续处理其他客户端的请求。 Lua 脚本在 Redis 中原子性的原因

Smarty模板执行原理

为了实现程序的业务逻辑和内容表现页面的分离从而提高开发速度,php 引入了模板引擎的概念,php 模板引擎里面最流行的可以说是smarty了,smarty因其功能强大而且速度快而被广大php web开发者所认可。本文将记录一下smarty模板引擎的工作执行原理,算是加深一下理解。 其实所有的模板引擎的工作原理是差不多的,无非就是在php程序里面用正则匹配将模板里面的标签替换为php代码从而将两者

Golang进程权限调度包runtime

关于 runtime 包几个方法: Gosched:让当前线程让出 cpu 以让其它线程运行,它不会挂起当前线程,因此当前线程未来会继续执行GOMAXPROCS:设置最大的可同时使用的 CPU 核数Goexit:退出当前 goroutine(但是defer语句会照常执行)NumGoroutine:返回正在执行和排队的任务总数GOOS:目标操作系统NumCPU:返回当前系统的 CPU 核数量 p

Flink任务重启策略

概述 Flink支持不同的重启策略,以在故障发生时控制作业如何重启集群在启动时会伴随一个默认的重启策略,在没有定义具体重启策略时会使用该默认策略。如果在工作提交时指定了一个重启策略,该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被使用。常用的重启策略: 固定间隔 (Fixe

(function() {})();只执行一次

测试例子: var xx = (function() {     (function() { alert(9) })(); alert(10)     return "yyyy";  })(); 调用: alert(xx); 在调用的时候,你会发现只弹出"yyyy"信息,并不见弹出"10"的信息!这也就是说,这个匿名函数只在立即调用的时候执行一次,这时它已经赋予了给xx变量,也就是只是