第四章 Flink 运行架构
4.1 Yarn 模式任务提交流程
(1)Flink任务提交后，Client将Flink的Jar包和配置上传到HDFS
(2)向Yarn的ResourceManager提交任务
(3)ResourceManager启动AM并为该任务分配一个Container容器
(4)ResourceManager通知对应的NodeManager启动ApplicationMaster
(5)ApplicationMaster启动后加载Flink的Jar包和配置构建环境，然后启动JobManager
(6)启动只有与ApplicationMaster通讯，要求ApplicationMaster向ResourceManager申请资源启动 TaskManager
(7)ResourceManager分配Container资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager
(8)NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager
(9)TaskManager启动后向JobManager发送心跳包，并等待JobManager向其分配任务。
4.2 任务调度流程
客户端不是运行时和程序执行的一部分，但它用于准备并发送 dataflow 给Master，然后，客户端断开连接或者维持连接以等待接收计算结果。
客户端可以以两种方式运行：要么作为 Java/Scala 程序的一部分被程序触发执行，要么以命令行./bin/flink run 的方式执行。
客户端首先会把代码抽象成dataFlow graph，然后通过actorSystem程序将dataflow graph发送给JobManager，JobManager将会根据dataflow的分区的变化的情况去划分task，然后将每个task通过actorSystem程序发送给taskManager里面的slot去执行一个task
当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager，JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。
Client为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程（Streaming的任务），也可以不结束并等待结果返回。
JobManager主要负责调度 Job 并协调 Task 做 checkpoint，职责上很像 Storm 的 Nimbus。从 Client 处接收到 Job 和 JAR 包等资源后，会生成优化后的执行计划，并以 Task 的单元调度到各个 TaskManager 去执行。
TaskManager在启动的时候就设置好了槽位数（Slot），每个 slot 能启动一个 Task，Task 为线程。从 JobManager 处接收需要部署的 Task，部署启动后，与自己的上游建立 Netty 连接，接收数据并处理。
Tips：slot代表着taskManager能够最大并行执行的task个数，一个slot运行一个task，如果需要一个taskManager同时运行多个task，就需要并行度的支持
关于执行图
Flink 中的执行图可以分成四层：StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行图。
StreamGraph：是根据用户通过 Stream API 编写的代码生成的最初的图。用来表示程序的拓扑结构。
JobGraph：StreamGraph经过优化后生成了 JobGraph，提交给 JobManager 的数据结构。主要的优化为，将多个符合条件的节点 chain 在一起作为一个节点，这样可以减少数据在节点之间流动所需要的序列化/反序列化/传输消耗。
ExecutionGraph：JobManager 根据 JobGraph 生成ExecutionGraph。ExecutionGraph是JobGraph的并行化版本，是调度层最核心的数据结构。
物理执行图：JobManager 根据 ExecutionGraph 对 Job 进行调度后，在各个TaskManager 上部署 Task 后形成的“图”，并不是一个具体的数据结构。
