Flink(2)系统架构

1 Flink系统架构

官网：https://nightlies.apache.org/flink/flink-docs-release-1.16/docs/concepts/flink-architecture/

JobManager：集群的主节点，负责集群的管理工作，从节点的管理，和从节点通信，任务提交，Checkpoint容错等。JobManager这个角色有三个子组件：

ResourceManager（负责Flink集群的资源管理器，和Yarn的ResourceManager没关系）
JobMaster（任务调度，负责任务的调度）
Dispacher（分发器，负责构建并启动WebUI（Standalone，session））

TaskManager：集群的从节点，负责该节点资源的管理，任务的运行，槽的分配，和主节点通信。
Scheduler：Flink中任务调度器，负责任务的调度，这里的调度就是把任务提交给集群运行。
Spark中StageScheduler（粗粒度调度，逻辑调度）、TaskScheduler（细粒度调度，物理调度）
Checkpoint Coordinator（检查点协调器）：负责集群的容错，checkpoint等。
Memory & IO Manager：内存和IO管理，负责该节点的内存和IO管理。
Network Manager：网络管理器。在任务执行过程中，可能需要从其他节点拉取数据时，要走网络管理器。
Client：只是负责任务的提交。提交成功后，其实可以断开了。在命令提交任务时，可以指定-d参数来配置。如果配置了-d，则说明客户端和集群断开了。

2 任务提交流程

抽象提交流程：不管是在什么模式下运行，大体上都是这个流程，如Standalone和Yarn

（1）任务提交给JobManager的Dispacher（分发器）
（2）Dispacher（分发器）收到任务后，启动JobMaster（调度器），并且把任务提交给JobMaster
（3）JobMaster收到任务后，它会找JobManager的ResourceManager（资源管理器）要资源
（4）不管采用什么方式，最终JobManager的ResourceManager（资源管理器）会向JobMaster提供资源（slot）
（5）JobMaster收到slot（槽）后，会把任务提交（分发）给TaskManager上运行
（6）TaskManager收到任务后，就会在slot里运行任务，任务运行完后，再根据提交模式销毁相应的进程

2.1 Standalone模式下的提交流程

（1）客户端提交任务到Dispacher（分发器）
（2）Dispacher分发器启动JobMaster
（3）JobMaster启动后，它会向JobManager的ResourceManager（资源管理器）请求资源（slot）
（4）JobManager的ResourceManager（资源管理器）向TaskManager请求资源（slot）
（5）TaskManager会向JobMaster提供资源（slot）
（6）JobMaster收到资源后，会向TaskManager提交（分发）任务
（7）TaskManager收到任务后，就在Slot上执行
（8）任务执行完后，释放资源

2.2 Yarn-Session模式下任务提交

分为2步，第一步：初始化Yarn-session集群


（1）请求Yarn的ResourceManager（资源管理器）
（2）Yarn的ResourceManager收到请求后，会启动一个Container（容器），当然这个容器就是AppMaster
（3）这个AppMaster就是Flink的JobManager，这个JobManager会初始化Dispacher和ResourceManager（资源管理器）
这里还没有初始化TaskManager，因此集群没有slot资源

第二步：提交任务

（1）客户端提交任务给JobManager（AppMaster）的分发器（Dispacher）
（2）分发器收到任务后，会启动JobMaster
（3）JobMaster启动后，会向JobManager（AppMaster）请求资源（slot）
（4）JobManager会向Yarn的ResourceManager请求资源
（5）Yarn的ResourceManager收到请求后，会在闲置的节点动态启动Container（TaskManager）
（6）Container启动成功后，会注册给AppMaster（JobManager）的ResourceManager
（7）Container会向AppMaster（JobManager）的JobMaster提供资源（slot）
（8）JobMaster会把任务分发给Container（TaskManager）去执行
（9）待任务执行完后，Container（TaskManager）会被AppMaster（JobManager），最终留下JobManager，这个不会被销毁

2.3 Yarn-Per-job模式下任务提交

（1）客户端提交任务给Yarn的ResourceManager
（2）Yarn的ResourceManager收到请求后，会启动一个Container（AppMaster），这个AppMaster就是Flink的JobManager
（3）JobManager里有任务调度器和资源管理器，任务调度器就会开始调度任务，向JobManager的资源管理器申请资源
（4）JobManager的资源管理器它会向Yarn的ResourceManager申请资源
（5）Yarn的ResourceManager会动态启动Container（TaskManager），这些Container就是资源
（6）这些Container启动后，会反向注册给AppMaster（JobManager）
（7）这些Container向JobMaster提供资源
（8）JobMaster收到资源后，把任务分发给Container（TaskManager）去执行
（9）任务执行完后，AppMaster（JobManager）会把Container（TaskManager）注销
（10）AppMaster（JobManager）会向Yarn的ResourceManager注销自己

3 程序流程图

1.DataFlow Graph（数据流图）：程序代码写完就有了。
2.Job Graph（作业图）：客户端对数据流图的优化
3.Execution Graph（执行图）：JobManager对任务图的优化
4.Physical Graph（物理图）：TaskManager对执行图的优化

并行度

1.默认，在配置文件中，优先级最低：在flink-conf.yaml中可配置
2.任务提交时指定：bin/flink run -p 3 xxxx.jar
3.在全局代码中配置：env.setParallelism(1)
4.在算子中，优先级最高：...sum(1).setParllelism(1)

宽依赖与窄依赖：

Spark中，宽依赖：Shuffle Dependency；窄依赖：Narrow Dependency
Flink中，宽依赖：redistributing dependency‘窄依赖：one-to-one dependency

槽&槽共享：

槽：slot，是集群的静态资源，在Standalone模式下，槽是预先配置的，不能更改。如果要改，改完后需要重启集群。
slot是运行Flink的单位。Flink任务必须运行在slot里。
slot和并行度是有关联的。并行度的数量不能超过slot的数量。
槽共享：一个槽可以运行多个SubTask。
不同的Task下的相同SubTask，一定会在同一个slot上执行，这是为了提升程序的执行效率。
相同的Task下的SubTask，一定不会在同一个slot上执行，这是为了充分利用集群资源，达到并行效果。