zoukankan      html  css  js  c++  java
  • Flink的Job启动JobManager端(源码分析)

    通过前面的文章了解到

    Driver将用户代码转换成streamGraph再转换成Jobgraph后向Jobmanager端提交

    JobManager启动以后会在Dispatcher.java起来RPC方法submitJob(jobGraph),用于接收来自Driver转化得到的JobGraph来启动任务

    具体来看jobGraph提交到JobManager的submitJob方法

    前面都是一些调用链没有什么好讲的,最后到createJobManager( )方法这里

    先看一下1,创建了一个jobmanagerRunner并且将中Driver端得到的JobGraph传递了进去

     在创建JobManagerRunner的过程中它调用了

    这里主要是为了创建一个jobMaster,在jobMaster的构造方法中

    在这里它先是create传入了jobgraph然后又通过createAndRestoreExecutionGraph()方法转换得到executionGraph

    这个executionGraph就可以用来调度启动任务了

    具体看一下他的转化逻辑

    可以看到它从createExecutionGraph方法中得到了executionGraph

    并且通过getCheckpointCoordinator()方法得到了一个coordinator(主要是用于周期性触发checkpoint,调用对应TaskManager的rpc生成barriers往下游发送)

    继续看一下他的转化逻辑

    在createExecutionGraph中通过ExecutionGraphBuilder.buildGraph()返回了一个executionGraph

    在buildGraph()方法中

    创建了一个executionGraph

     

    为executionGraph设置一些基础信息,包括调度方式等(这里stream是eager的调度方法)

    然后

    1处得到了一个的拓扑图包含了所有jobGraph的所有jobVertex节点

    2处就是具体遍历所有jobGraph的jobVertex生成executionGraph的顶点ExecutionJobVertex

    遍历所有jobGraph的顶点jobVertex

    在这里就具体生成了ExecutionJobVertex中的每一个ExecutionVertex[] taskVertices

    当然这里还会配置很多ExecutionGraph的信息,就不一一列举了

    配置了一些ExecutionGraph的属性以后

    调用了

    可以看到我的注释,就是说这个地方其实是和coordinator的创建有关,在这个方法中

    创建了一个coordinator对象

    在这里注册了一个JobStatus的监听

    来看一下这个监听的作用

    可以看到源码上的注解就是说用于监听job状态的改变,具体监听

    看到这里就非常明显了

    当监听到jobstutes的状态改变时

    当jobstatus变成Running时调用了coordinator的.startCheckpointScheduler()方法其中

    这里可以看到创建了一个周期的调度线程

    看下线程的run方法

    这里就真相大白了,调用了triggerCheckpoint方法触发一次checkpoint(触发checkpoint的逻辑以后随缘更新到再讲)

    注意,前面说到只是注册了一个监听,也就是说这个coordinator现在其实还没有启动起来的!!要到监听到jobStatus变成running才会启动

    回到最开始的这里

    1处转化成executionGraph以后

    2处具体看一下这个startJobManagerRunner()方法

    把jobManager启动了起来

     

    在其中

    启动了这个jobMasterService

    在这里开启了jobmaster的一些RPC,像什么cancel job的stop job 的还有register TM的

    然后startJobExecution()方法中

    这里其实会向jobManager中启动的resourceManager的RPC请求solt信息初始化自己的的soltPool这里不细讲了,我还没有研究

    后面

    这个地方就是修改job状态和调度运行了

    其中调用了scheduleExecutionGraph(),在其中又调用了

    这个地方比较重要,在其中先

    这里它就通过CAS修改了jobStatue从Created变成了Running

    修改完了以后还没完,还通过这个方法notifyJobStatusChange(),这个方法里面具体看一看

    他遍历了所有的listener,也就是说会触发我们前面注册的那个coordinator的监听监听到job状态改变为running

    这里coordinator就启动完成了

    继续往下,在修改完job状态以后

    因为流模式这里是用的EAGER,flink批处理我不熟这里就不展开了

    在这个schduleEager方法中

    然后

    看到这里它创建了一个TaskDeploymentDescriptor一个用于调度TaskManager端任务的tdd对象

    看过前面几篇博客的同学,就应该有印象了,在TaskManager启动会启动很多的RPC接口

    其中有一个

    一目了然了,这个东西是用来发送给TaskManager用于启动TaskManager端任务的!!!!

    到这里jobManager端的job启动任务就差不多完成了

    接下来就是TaskManager端的任务了,随缘更新的时候在说一下真正TaskManager节点是如何启动我们job任务的

  • 相关阅读:
    E. XOR and Favorite Number (莫队板子题)
    bzoj 2038: [2009国家集训队]小Z的袜子(hose)
    世风日下的哗啦啦族I (简单分块模板)
    Turtles (非纯分块)
    楼房重建
    智商问题
    A
    51 Nod 1640 天气晴朗的魔法( Kruskall )
    后缀数组
    51nod 1562 玻璃切割 (set)
  • 原文地址:https://www.cnblogs.com/ljygz/p/11429758.html
Copyright © 2011-2022 走看看