【Flink】Flink核心概念简述

一、Flink 简介

Apache Flink 的前身是柏林理工大学一个研究性项目，在 2014 被 Apache 孵化器所接受，然后迅速地成为了Apache Software Foundation的顶级项目之一。2019 年 1 年，阿里巴巴收购了 Flink 的母公司 Data Artisans，并宣布开源内部的 Blink，Blink 是阿里巴巴基于 Flink 优化后的版本，增加了大量的新功能，并在性能和稳定性上进行了各种优化，经历过阿里内部多种复杂业务的挑战和检验。

Flink 是一个分布式的流处理框架，它能够对有界和无界的数据流进行高效的处理。

二、Flink 组件栈

Flink 采用分层的架构设计，从而保证各层在功能和职责上的清晰。如下图所示，由上而下分别是 API & Libraries 层、Runtime 核心层以及物理部署层：

在这里插入图片描述

1. API & Libraries 层

API层主要实现了面向无界Stream的流处理和面向Batch的批处理API，其中面向流处理对应DataStream API，面向批处理对应DataSet API
在API层之上构建的满足特定应用的实现计算框架，也分别对应于面向流处理和面向批处理两类

这里的API可以进行更具体的划分
在这里插入图片描述
API 的一致性由下至上依次递增，接口的表现能力由下至上依次递减

SQL 和 Table API 同时适用于批处理和流处理，这意味着可以对有界数据流和无界数据流以相同的语义进行查询，并产生相同的结果。
DataStream 和 DataSet API 是 Flink 数据处理的核心 API，支持使用 Java 语言或 Scala 语言进行调用，提供了数据读取，数据转换和数据输出等一系列常用操作的封装。
Stateful Stream Processing 是最低级别的抽象，它通过 Process Function 函数内嵌到 DataStream API 中。 Process Function 是 Flink 提供的最底层 API，具有最大的灵活性，允许开发者对于时间和状态进行细粒度的控制。

2. runtime层

这一层是 Flink 分布式计算框架的核心实现层，包括作业转换，任务调度，资源分配，任务执行等功能，基于这一层的实现，可以在流式引擎下同时运行流处理程序和批处理程序。

3. 物理部署层

Flink 的物理部署层，用于支持在不同平台上部署运行 Flink 应用

Flink支持多种部署模式：本地、集群（Standalone/YARN）、云（GCE/EC2）

在这里插入图片描述

三、Flink 集群架构

Flink采用标准的 Master - Slave 结构，其中，Master 部分包含了三个核心组件：Dispatcher、ResourceManager 和 JobManager，而 Slave 则主要是 TaskManager 进程。它们的功能分别如下：

JobManager：负责所有需要中央协调的操作，比如说检查点（checkpoints）的协调
- 接收由 Dispatcher 传递过来的执行程序，该执行程序包含了作业图 (JobGraph)，逻辑数据流图 (logical dataflow graph) 及其所有的 classes 文件以及第三方类库 (libraries) 等等。
- JobManagers 会将 JobGraph 转换为执行图 (ExecutionGraph)
- 向 ResourceManager 申请资源来执行该任务，一旦申请到资源，就将执行图分发给对应的 TaskManagers 。因此每个作业 (Job) 至少有一个 JobManager；高可用部署下可以有多个 JobManagers，其中一个作为 leader，其余的则处于 standby 状态。
TaskManagers：负责实际的子任务 (subtasks) 的执行
- 每个 TaskManagers 都拥有一定数量的 slots。Slot 是一组固定大小的资源的合集 (如计算能力，存储空间)
- TaskManagers 启动后，会将其所拥有的 slots 注册到 ResourceManager 上，由 ResourceManager 进行统一管理
- 在执行过程中，一个TaskManager可以跟其它运行同一应用程序的 TaskManager交换数据
ResourceManager ：负责管理 slots 并协调集群资源
- ResourceManager 接收来自 JobManager 的资源请求，并将存在空闲 slots 的 TaskManagers 分配给 JobManager 执行任务
- Flink 基于不同的部署平台，如 YARN , Mesos，K8s 等提供了不同的资源管理器
- 当 TaskManagers 没有足够的 slots 来执行任务时，它会向第三方平台发起会话来请求额外的资源。
Dispatcher
- 负责接收客户端提交的执行程序，并传递给 JobManager
- 提供了一个 WEB UI 界面，用于监控作业的执行情况
- 在架构中可能并不是必需的，这取决于应用提交运行的方式。
  
  Flink任务 on yarn

四、Flink基本编程模型

所有的Flink程序都是由三部分组成的： Source 、Transformation 和 Sink

Source 负责读取数据源
Transformation 利用各种算子进行处理加工
Sink 负责输出

每一个dataflow以一个或多个sources开始以一个或多个sinks结束。dataflow 类似于任意的有向无环图（DAG）

下面是一个由Flink程序映射为Streaming Dataflow的示意图:

在这里插入图片描述
转化为并行的数据流时

五、Flink 的部署模式

前文介绍一共有三种部署模式，分别是部署在本地、集群和云上。其中常见的部署模式是本地和集群，细分为下面三种

Local：以单机模式运行，无需启动分布式资源管理器
Standalone：作为一个独立的集群运行，独占集群中的资源，不依赖任何外部的资源管理平台，只能运行Flink
Flink On Yarn：在yarn之上运行，利用YARN来管理资源分配和任务调度，集群中可运行其他系统

六、Flink 任务的执行模式

Session Mode：会话模式

需要先启动一个集群，保持一个会话，在这个会话中通过客户端提交作业。集群启动时所有资源就都已经确定，所有提交的作业会竞争集群中的资源。适合任务规模小，执行时间短的大量作业。

Flink的作业执行环境会一直保留在集群上，直到会话被显式终止。这样，可以提交多个作业，它们可以共享相同的集群资源和状态，从而实现更高的效率和资源利用。
Per-Job Mode：单作业模式

每个Flink应用程序作为一个独立的作业被提交和执行。每次提交的Flink应用程序都会创建一个独立的作业执行环境，该作业执行环境仅用于执行该特定的作业。当作业完成后，作业执行环境会被释放，集群关闭，资源释放
Application Mode：应用模式

前2种模式中，Flink程序代码是在客户端执行，应用模式中，代码在在集群上执行

在这里插入图片描述