共计 2200 个字符，预计需要花费 6 分钟才能阅读完成。
工作提交流程
- Flink 提交工作，Client 向 HDFS 上传 Flink 的 Jar 包和配置
- 之后向 Yarn ResourceManager 提交工作
- ResourceManager 调配 Container 资源并告诉对应的 NodeManager 启动 ApplicationMaster，ApplicationMaster 启动后加载 Flink 的 Jar 包和配置来构建环境，而后启动 JoManager。
- 之后 ApplicationMaster 向 ResourceManager 申请资源启动 TaskManager
- ResourceManager 调配 Container 资源后，由 ApplicationMaster 告诉资源所在节点的 NodeManager 启动 TaskManager，NodeManager 加载 Jar 和配置构建环境并启动 TaskManager
- TaskManager 启动后向 JobManager 发送心跳包，并期待 JobManager 向其分配任务。
任务调度原理
- Client：提交 Job 的客户端。
- JobManager: 从 Client 处接到 Job 和 Jar 包后，以 Task 的单元调度到各个 TaskManager 去执行。即次要负责调度 Job 并协调 Task 做 checkpoint。
- TaskManager：从 JobManager 接管须要部署的 Task，与自已的上游建设 Netty 连贯。在启动是设置好槽位数 Slot，每个 Slot 能启动一个 Task 线程。
当 Flink 集群启动后，首先会启动一个 JobManager 和一或多个 TaskManager。JobManager 再调度各个 Task 到 TaskManager 执行，TaskManager 将心跳和统计信息汇报给 JobManager。
Graph
Flink 中的执行图能够分成四层：StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行图
- StreamGraph：依据用户通过 Stream API 编写的代码生成最后的图，示意程序的拓扑构造。
- JobGraph：StreamGraph 通过优化后生成了 JobGraph，是提交给 JobManager 的数据结构。次要优化位，将多个符合条件的节点 chain 在一起作为一个节点，这样能够缩小数据在节点之间流动所须要的序列化 / 反序列化 / 传输耗费。
- ExecutionGraph：JobManager 依据 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 JobGraph 的并行化版本，是调度层最外围的数据结构。
- 物理执行图：JobManager 依据 ExecutionGraph 对 Job 进行调度后，在各个 TaskManager 上部署 Task 后造成的“图”
Stream 和 Transformation
Flink 是由 Stream 和 Transformation 这两个根本构建块组成，其中 Stream 是一个两头后果数据，Transformation 是一个操作，，它对一个或多个输出 Stream 进行计算解决，输入一个或多个后果 Stream。
Flink 程序被执行的时候，会被映射为 Streaming Dataflow。一个 Streaming Dataflow 是由一组 Stream 和 Transformation Opearator 组成。
并行数据流
一个 Stream 能够被分成多个 Stream Partition，一个 Operator 能够被分成多个 Operator Subtask，每一个 Operator Subtask 是在不同的线程中独立执行的。一个 Operator 的并行度，等于 Operator Subtask 的个数，一个 Stream 的并行度总是等于生成它的 Operator 的并行度。
One-to-one 模式 : 比如说从 Source[1] 到 map[1]，他放弃了 Source 的分区个性和分区内元素解决的有序性，也就是说 map()[1]的 Subtask 看到的数据流中记录的数据，与 Source[1]看到的记录程序是一样的。
Redistribution 模式 ：这种模式扭转了输出数据流的分区，比方从 map()[1]、map()[2] 到 keyBy()/window()/apply()[1]、keyBy()/window()/apply()[2]，上游的 Subtask 向上游的多个不同的 Subtask 发送数据，扭转了数据流的分区，这与理论利用所抉择的 Operator 有关系。
工作链
Fink 分布式执行环境中，会将多个 Operator Subtask 串起来组成一个 Operator Chain，实际上就是一个执行链，每个执行链会在 TaskManager 上一个独立的线程中执行。
Checkpoint 机制
- CheckpointCoordinator 周期性的向该数据流，所有的 source 算子发送 barrier。
- Source 算子接管到一个 barrier 后，便暂停解决数据，将以后的状态制作成快照，并保留到指定的长久化存储中，最初它再向 CheckpointCoordinator 报告本人的快照制作状况。同时向本身上游所有算子播送该 barrier。而后复原该算子的数据处理工作。
- 上游的算子接管到 barrier 后，也会暂停自的数据处理过程，同 2 过程。
- 最初 CheckpointCoordinator 会确认它接管到的报告，如果收到本周期的所有算子的快照就认为快照制作胜利，否则失败。
