Flink--运行架构

任务提交流程

1. Flink提交任务，Client向HDFS上传Flink的Jar包和配置
2. 之后向Yarn ResourceManager提交任务
3. ResourceManager分配Container资源并通知对应的NodeManager启动ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置来构建环境，然后启动JoManager。
4. 之后ApplicationMaster向ResourceManager申请资源启动TaskManager
5. ResourceManager分配Container资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager，NodeManager加载Jar和配置构建环境并启动TaskManager
6. TaskManager启动后向JobManager发送心跳包，并等待JobManager向其分配任务。

任务调度原理

1. Client：提交Job的客户端。
2. JobManager: 从Client处接到Job和Jar包后，以Task的单元调度到各个TaskManager去执行。即主要负责调度Job并协调Task做checkpoint。
3. 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机制

1. CheckpointCoordinator周期性的向该数据流，所有的source算子发送barrier。
2. Source算子接收到一个barrier后，便暂停处理数据，将当前的状态制作成快照，并保存到指定的持久化存储中，最后它再向CheckpointCoordinator报告自己的快照制作情况。同时向自身下游所有算子广播该barrier。然后恢复该算子的数据处理工作。
3. 下游的算子接收到barrier后，也会暂停自的数据处理过程，同2过程。
4. 最后CheckpointCoordinator会确认它接收到的报告，如果收到本周期的所有算子的快照就认为快照制作成功，否则失败。