flink的作业提交和任务调度

1. Runtime层总体架构图
   

2. 作业提交和任务调度流程

   1.用户提交编写的应用程序时，Client端会对提交作业进行一系列编译和优化，最终将作业的DataFlow转化成JobGraph。
   然后作业准备提交了，根据集群类型分为SessionCluster和Per-JobCluster，分开说明。
   Session Cluster：
   2.此时AM 和TM都已通过脚本事先启动，Client直接向AM的Dispatcher提交作业。
   3.Dispatcher启动一个新的JM进程。
   4.JM获得JobGraph，获得所有需要执行的task。然后向RM申请资源，RM收到请求后向TM申请资源(slot)，TM收到请求后将符合条件的slot提供给JM。
   5.JM收到TM的资源反馈后，将task调度到相应的slot上。
   6.TM会为每个task启动一个线程，然后执行task。多个task都启动起来之后，通过shuffle模块交换数据。
   Per-Job Cluster：
   2.此时AM 和TM都还未启动，client需要先向资源管理系统(如yarn)申请资源，启动AM。
   3.Client向AM的Dispatcher提交作业。
   4.Dispatcher启动一个新的JM进程。
   5.JM获得JobGraph，向RM申请资源，RM会向资源管理系统(yarn)申请资源，启动TM。
   6.RM向TM申请资源(slot)。
   7.后续步骤和SessionCluster一样。
   在整个任务执行过程中，相关元数据会写到外部系统(如RM地址，JM地址会写到ZK，任务状态信息写到RocksDB或FileSystem)。
   那么，我们的代码是经过一步步的转化变成最终可执行的task的呢？这就要讲到flink中执行图的概念。

3. 执行图

   flink中的执行图可以分成四层：
   StreamGraph(dataflow) -> JobGraph -> ExecutionGraph -> 物理执行图

   • StreamGraph：是根据用户通过Stream API编写的代码生成的最初的图，用来表示程序的拓扑结构，类似于一个DAG。
   • JobGraph：StreamGraph经过优化生成的，提交给JM的数据结构，不考虑并发。主要的优化是合并可以合并的task形成operator chain，检查各个task的输入输出类型等。
   • ExecutionGraph：JM根据JobGraph生成的。它是JobGraph的并行化版本，是调度层最核心的数据结构。
   • 物理执行图：JM根据ExecutionGraph对job进行调度后，在各个TM上部署task后形成的图，它并不是一个具体的数据结构。

4. task调度策略

   • eager调度
     适用于流作业；一次性调度所有的task。
   • lazy_from_source调度
     适用于批作业；上游作业执行完成后，调度下游的作业。