前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Flink架构

Flink架构

作者头像
神秘的寇先森
发布2020-02-19 10:50:32
1.1K0
发布2020-02-19 10:50:32
举报
文章被收录于专栏:Java进阶之路

一、整体架构

Flink整体由JobManager和TaskManager组成,遵循主从设计原则,JobManager为Master节点,TaskManager为worker节点,组件之间通信是借助Akka Framework;

  1. JobManager:负责整个Flink集群任务的调度和资源分配。从client获取提交的任务后,JobManager根据TaskManager中资源(TaskSlots)使用的情况,分配资源并命令TaskManager启动任务。在这个过程中,JobManager会触发checkpoint操作,Taskmanager执行checkpoint操作,其中所有的checkpoint协调的过程都是在JobManager中完成。此外,如果任务失败了,也有JobManager协调失败任务的恢复。
  2. TaskManager:负责具体任务执行和节点上资源申请和管理,多节点之间数据交换也是在TaskManager上执行;Flink中每个TaskManager对应一个JVM进程。
  3. task slot:每个task slot是TaskManager的一部分,若一个taskManager有三个taskSlot,则这三个taskSlot会均分这个TaskManager的资源(仅内存,不包括CPU)。有多个slot意味着同一个JVM中会有多个子任务,这些任务会共享JVM的TCP连接和心跳信息。这里要说明的是,slot的个数不是subtask的个数是一一对应,一个slot中可以有多个subtask。在默认情况下,同一个job中的子任务(subtask)是可以共享一个slot的。 参考:flink solt和并行度
  4. client客户端:不是runtime的一部分,换句话说,Flink集群启动client提交的任务之后,client客户端时可以断开的,是可以不需要的。client不像JobManager和TaskManager对应着 flink集群中的结点(或是物理机、或是虚拟机、或是容器),是触发执行的一个抽象化,若程序在JobManager所在结点执行,则称client在JobManager结点上,同样,其也可以在TaskManager结点上。
  • 提交一个任务的正常流程是:client与JobManager构建Akka连接,将任务提交到JobManager上,JobManager根据已经注册在JobManager中TaskManager的资源(TaskSlot)情况,将任务分配给有资源的TaskManager,并命令TaskManager启动任务,TaskManager则从JobManager接受需所部属的任务,使用slot资源启动task,建立数据接入的网络连接,然后接受数据并开始处理。

二、资源管理

一、集群部署阶段

集群部署这里指的是Flink standalone模式,因为在Yarn模式(包括session、single job模式也成Per-job模式)是可以仅通过Flink client提交任务到Yarn上,所以是否手动部署Flink集群对任务的执行是没有影响的。下图[1]是简单的Flink的集群构成情况,包括一个master(JobManager)、两个worker(TaskManager)。至于Flink standalone模式的HA(一般有两个JobManager加上若干个TaskManager组成)是通过zookeeper实现的,其主要思想是通过zookeeper选举出JobManager的active节点,该结点负责资源分配等,另一个节点为standby。Flink的Yarn模式的高可用的通过在container中对JobManager的重启实现的,其具体过程在此不详细说明。 部署阶段主要有以下两个参数:

代码语言:javascript
复制
#每个TaskManager中slot的个数,在conf/flink-conf.yaml中,默认为1
2 taskmanager.numberOfTaskSlots
3 #任务的并行度,默认为1
4 parallelism.default
  1. taskmanager.numberOfTaskSlots:每个TaskManager中slot的数量,官方文档推荐:和每个TaskManager中物理CPU的个数成比例,比如:等于CPU的个数,或者是CPU个数的一半;
  2. parallelism.default:任务的并行度,默认值为1,该值可以通过在程序中设定setParallesim()改变,并行度与slot的关系见下详解;
二、任务提交阶段

Flink集群资源的使用情况除了和已分配的资源有关外,还与并行度有关,已分配的资源表示Flink可以利用这么多资源,而实际能利用多少资源还和并行度有关。任务并行度的最大值由TaskManager集群的Slot总数决定,如:slot总数为10,则任务最大的并行度为10. 在standalone模式中,Flink任务能利用的总资源已在启动集群时确定,其并行通过在执行./flink run 时,通过可选参数[-p]确定(不指定则为默认值1)。 在Yarn模式中,均是先Yarn集群中分配资源给新建的Flink集群,如下图,其详细过程见文档[2]。

Yarn资源分配

Flink的Yarn模式session、single job模式在实现方法上还是存在一定的区别: 1)session模式是先利用yarn-session.sh在yarn新建一个Flink集群,然后利用./flink run flinkExample.jar提交任务,其资源分配的方式和standalone模式一致;

代码语言:javascript
复制
./yarn-session.sh -n 4 -s 8 -jm 3072 -tm 32768 

-n:在yarn上分配了4个container,即分配了4个TaskManager; -s:每个TaskManager有8个slot; -jm:每个JobManager中的内存数; -tm:每个TaskManager中的内存数; 2)single job模式在命令中在申请资源的同时,提交任务,常用命令如下:

代码语言:javascript
复制
./flink run -m yarn-cluster -yn 7 -ys 8 -yjm 1024 -ytm 1024 example.jar

-yn:yarn上分配的container个数,即TaskManager的个数; -ys:每个TaskManager中slot的个数 其他参数的具体使用方法可以在控制台中执行./flink、./yarn-session.sh得到说明。 说明:session模式和single job的区别: 1)session模式:Flink任务运行结束后,从yarn上申请到的资源是不被释放的,等待下一个Flink的提交,类似一个常住在yarn上永远不会结束的yarn任务。因为,yarn的资源分配模式中比如fair策略还是存在资源的竞争的,session模式资源的不释放性,这样可以在Yarn提供资源分配上的基础上进行实现资源隔离,也实现了对集群物理环境的屏蔽,但在一定的程度上造成了资源的浪费; 2)single job模式和一般的yarn任务一样,任务结束后就会释放申请到的资源,使资源得到重复利用。

  • 所以session、single job模式的实际应用应根据需求使用,一般情况下:
  1. single job模式是按需申请资源,一般适合执行时间较长的大任务。此外,该模式下,每次提交任务都需单独启动Flink集群自己的ResourceManager会造成一定的时延;
  2. session模式共享资源,一般适合执行时间短的小任务。此模式下,会共享ResourceManager,所以启动快。

【说明】这里所说的ResourceManager不是Yarn的组件,是Flink本身的,关于深层的分析,见后续博客。

三、任务运行阶段

假定一个3个TaskManager的集群,每个TaskManager有3个slot,集群一个9个slot,从下图中可以得到[3]:任务的并行度为1时,只会用一个slot,并行度为2会用2个slot,依次类推,当并行度为9时,9个slot都会被利用,当然从example4中可知,可以针对不同的算子(operator)定义并行度。

taskmanager和slot关系.png

三、 常见概念:Task,Operator Chain(算子链)

一、Task和Operator Chains   Flink会在生成JobGraph阶段,将代码中可以优化的算子优化成一个算子链(Operator Chains)以放到一个task(一个线程)中执行,以减少线程之间的切换和缓冲的开销,提高整体的吞吐量和延迟。

Operator Chain.png

算子之间是否可以组成一个Operator Chains,看是否满足以下条件:

  • 上下游算子的并行度一致
  • 下游节点的入度为1
  • 上下游节点都在同一个 slot group 中
  • 下游节点的 chain 策略为 ALWAYS(可以与上下游链接,map、flatmap、filter等默认是ALWAYS)
  • 上游节点的 chain 策略为 ALWAYS 或 HEAD(只能与下游链接,不能与上游链接,Source默认是HEAD)
  • 两个节点间数据分区方式是 forward
  • 用户没有禁用 chain(代码中是否配置disableChain())

算子被定义后,先根据条件优化算子链 ,然后组成一个个subtask,最后根据是否可以共享slot分布在taskManager的slot中执行。

Operator Chain参考:Operator Chains 未完待续!!!

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、整体架构
  • 二、资源管理
    • 二、任务提交阶段
      • 三、任务运行阶段
      • 三、 常见概念:Task,Operator Chain(算子链)
      相关产品与服务
      大数据
      全栈大数据产品,面向海量数据场景,帮助您 “智理无数,心中有数”!
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档