Flink架构和运行流程

Flink概述

Flink是什么

Flink是一个框架和分布式处理引擎,用于对无界和有界数据流进行有状态计算

Flink特点

• 高吞吐和低延迟. 每秒处理数百万个事件,毫秒级延迟

• 结果的准确性. Flink提供事件时间和处理时间,对于乱序事件流, 任然能保持一致且准确

• 精确一次的状态一致性保证

• 可以连接到最常用的外部系统,Kafka

• 高可用

Flink部署模式

会话模式, 单作业模式, 应用模式

区别在于 : 集群的生命周期以及资源的分配方式; 以及应用的main方法到底在客户端还是jobManager执行

会话模式

先启动一个集群,保持一个会话,通过客户端提交作业,因为集群以及启动,所以所有提交的作业会竞争集群中的资源

适合于单个规模小,执行时间短的大量作业

单作业模式

为每个提交的作业启动一个集群

作业完成后,集群就会关闭,所有资源也会释放

但需要借助一些资源管理框架来启动集群,YARN

应用模式

将应用直接提交到JobManger上运行,需要为每一个提交的应用单独启动一个JobManger,也就是创建一个集群,执行结束JobManger也关闭了

和单作业不同的是:

• 单作业是通过客户端来提交的,客户端来执行应用代码

• 应用模式是由JobManger来执行

YARN运行模式(重点)

YARN上部署的过程是：

客户端把Flink应用提交给Yarn的ResourceManager，

Yarn的ResourceManager会向Yarn的NodeManager申请容器。

在这些容器上，Flink会部署JobManager和TaskManager的实例，从而启动集群。

Flink会根据运行在JobManger上的作业所需要的Slot数量动态分配TaskManager资源。

以上细节看文档

Flink运行时架构

Standalone会话模式为例

作业管理器（JobManager）

1. JobManager是一个Flink集群中任务管理和调度的核心，是控制应用执行的主进程。

   JobManger又包含3个不同的组件

   1. JobMaster

      JobMaster是JobManager中最核心的组件，负责处理单独的作业（Job）。

      在作业提交时，JobMaster会先接收到要执行的应用。

      JobMaster会把JobGraph转换成一个物理层面的数据流图，这个图被叫作“执行图”（ExecutionGraph），它包含了所有可以并发执行的任务。

      JobMaster会向资源管理器（ResourceManager）发出请求，申请执行任务必要的资源。

      获取到了足够的资源，就会将执行图分发到真正运行它们的TaskManager上。

      而在运行过程中，JobMaster会负责所有需要中央协调的操作，比如说检查点（checkpoints）的协调。

   2. 资源管理器（ResourceManager）

      ResourceManager主要负责资源的分配和管理，在Flink 集群中只有一个。

      所谓“资源”，主要是指TaskManager的任务槽（task slots）。任务槽就是Flink集群中的资源调配单元，包含了机器用来执行计算的一组CPU和内存资源。每一个任务（Task）都需要分配到一个slot上执行。

      这里注意要把Flink内置的ResourceManager和其他资源管理平台（比如YARN）的ResourceManager区分开。

   3. 分发器（Dispatcher）

Dispatcher主要负责提供一个REST接口，用来提交应用，并且负责为每一个新提交的作业启动一个新的JobMaster 组件。

任务管理器（TaskManager）

TaskManager是Flink中的工作进程，数据流的具体计算就是它来做的。Flink集群中必须至少有一个TaskManager；

每一个TaskManager都包含了一定数量的任务槽（task slots）。Slot是资源调度的最小单位，slot的数量限制了TaskManager能够并行处理的任务数量。

启动之后，TaskManager会向资源管理器注册它的slots；

收到资源管理器的指令后，TaskManager就会将一个或者多个槽位提供给JobMaster调用，JobMaster就可以分配任务来执行了。

在执行过程中，TaskManager可以缓冲数据，还可以跟其他运行同一应用的TaskManager交换数据。

Flink核心概念

并行度（Parallelism）

在Flink执行过程中，每一个算子（operator）可以包含一个或多个子任务（operator subtask），这些子任务在不同的线程、不同的物理机或不同的容器中完全独立地执行。

一个特定算子的子任务（subtask）的个数被称之为其并行度（parallelism）。这样，包含并行子任务的数据流，就是并行数据流，它需要多个分区（stream partition）来分配并行任务。一般情况下，一个流程序的并行度，可以认为就是其所有算子中最大的并行度。一个程序中，不同的算子可能具有不同的并行度。

算子链（Operator Chain）

一个数据流在算子之间传输数据的形式可以是一对一（one-to-one）的直通（forwarding）模式，也可以是打乱的重分区（redistributing）模式

看图就能明白,不解释

合并算子链

在Flink中，并行度相同的一对一（one to one）算子操作，可以直接链接在一起形成一个“大”的任务（task），这样原来的算子就成为了真正任务里的一部分，如下图所示。每个task会被一个线程执行。这样的技术被称为“算子链”（Operator Chain）。

上图中Source和map之间满足了算子链的要求，所以可以直接合并在一起，形成了一个任务；因为并行度为2，所以合并后的任务也有两个并行子任务。这样，这个数据流图所表示的作业最终会有5个任务，由5个线程并行执行。

将算子链接成task是非常有效的优化：可以减少线程之间的切换和基于缓存区的数据交换，在减少时延的同时提升吞吐量。

Flink默认是进行链接合并

任务槽（Task Slots）

任务槽（Task Slots）

为了控制并发量，我们需要在TaskManager上对每个任务运行所占用的资源做出明确的划分，这就是所谓的任务槽（task slots）。

每个任务槽（task slot）其实表示了TaskManager拥有计算资源的一个固定大小的子集。这些资源就是用来独立执行一个子任务的。

任务槽数量的设置

在Flink的/opt/module/flink-1.17.0/conf/flink-conf.yaml配置文件中，可以设置TaskManager的slot数量，默认是1个slot。

需要注意的是，slot目前仅仅用来隔离内存，不会涉及CPU的隔离。在具体应用时，可以将slot数量配置为机器的CPU核心数，尽量避免不同任务之间对CPU的竞争。这也是开发环境默认并行度设为机器CPU数量的原因。

任务对任务槽的共享

只要属于同一个作业，那么对于不同任务节点（算子）的并行子任务，就可以放到同一个slot上执行。

所以对于第一个任务节点source→map，它的6个并行子任务必须分到不同的slot上，而第二个任务节点keyBy/window/apply的并行子任务却可以和第一个任务节点共享slot。

任务槽和并行度的关系

任务槽和并行度都跟程序的并行执行有关，但两者是完全不同的概念

1. 任务槽是静态的概念，是指TaskManager具有的并发执行能力

2. 并行度是动态概念，也就是TaskManager运行程序时实际使用的并发能力

这里看文档更好理解

Flink作业提交流程

逻辑流图（StreamGraph）→ 作业图（JobGraph）→ 执行图（ExecutionGraph）→ 物理图（Physical Graph）。

逻辑流图（StreamGraph）

这是根据用户通过 DataStream API编写的代码生成的最初的DAG图，用来表示程序的拓扑结构。这一步一般在客户端完成。

作业图（JobGraph）

逻辑流图经过优化后生成的就是作业图（JobGraph），这是提交给 JobManager 的数据结构，确定了当前作业中所有任务的划分。主要的优化为：将多个符合条件的节点链接在一起合并成一个任务节点，形成算子链，这样可以减少数据交换的消耗。JobGraph一般也是在客户端生成的，在作业提交时传递给JobMaster。

执行图（ExecutionGraph）

JobMaster收到作业图（JobGraph）后，会根据它来生成执行图（ExecutionGraph）。ExecutionGraph是JobGraph的并行化版本，是调度层最核心的数据结构。与JobGraph最大的区别就是按照并行度对并行子任务进行了拆分，并明确了任务间数据传输的方式。

物理图（Physical Graph）

JobMaster生成执行图后，会将它分发给TaskManager

物理图主要就是在执行图的基础上，进一步确定数据存放的位置和收发的具体方式。有了物理图，TaskManager就可以对传递来的数据进行处理计算了。

Yarn应用模式作业提交流程