2 Flink1.11.0 原理及编程模型介绍

偏执的太偏执、 2023-02-24 13:26 79阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70][]

你将在本章学习到以下内容：

*  如何实现流数据处理管道（pipelines）
 *  Flink 如何管理状态以及为何需要管理状态
 *  如何使用事件时间（event time）来一致并准确地进行计算分析
 *  如何在源源不断的数据流上构建事件驱动的应用程序
 *  Flink 如何提供具有精确一次（exactly-once）计算语义的可容错、有状态流处理

本章教程着重介绍四个概念：源源不断的流式数据处理、事件时间、有状态流处理和状态快照。基本概念介绍如下。

## 1 流处理 ##

在自然环境中，数据的产生原本就是流式的。无论是来自 Web 服务器的事件数据，证券交易所的交易数据，还是来

自工厂车间机器上的传感器数据，其数据都是流式的。但是当你分析数据时，可以围绕 ***有界流*（*bounded*）或 *无界流***

**（*unbounded*）**两种模型来组织处理数据，当然，选择不同的模型，程序的执行和处理方式也都会不同。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 1][]

**批处理**是有界数据流处理的范例。在这种模式下，你可以选择在计算结果输出之前输入整个数据集，这也就意味着你可以

**对整个数据集的数据**进行**排序、统计或汇总**计算后再输出结果。

**流处理**正相反，其涉及无界数据流。至少理论上来说，它的数据输入永远不会结束，因此程序必须持续不断地对到达的数

据进行处理。

在 Flink 中，应用程序由用户自定义**算子**转换而来的**流式 dataflows** 所组成。这些流式 dataflows 形成了有向图，以一个

或多个**源**（source）开始，并以一个或多个**汇**（sink）结束。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 2][]

通常，程序代码中的 transformation 和 dataflow 中的算子（operator）之间是一一对应的。但有时也会出现一个

transformation 包含多个算子的情况，如上图所示。

**Flink 应用程序**可以消费来自消息队列或分布式日志这类流式数据源（例如 Apache Kafka 或 Kinesis）的实时数据，

也可以从各种的数据源中消费有界的历史数据。同样，Flink 应用程序生成的结果流也可以发送到各种数据汇中。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 3][]

### 2 并行 Dataflows ###

Flink 程序本质上是分布式并行程序。在程序执行期间，一个流有一个或多个**流分区**（Stream Partition），每个算子有

一个或多个**算子子任务**（Operator Subtask）。每个子任务彼此独立，并在不同的线程中运行，或在不同的计算机或容

器中运行。

算子子任务数就是其对应算子的**并行度**。在同一程序中，不同算子也可能具有不同的并行度。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 4][]

Flink 算子之间可以通过*一对一*（*直传*）模式或*重新分发*模式传输数据：

> **一对一**模式（例如上图中的 *Source* 和 *map()* 算子之间）可以保留元素的分区和顺序信息。这意味着 *map()* 算子的
> 
> subtask\[1\] 输入的数据以及其顺序与 *Source* 算子的 subtask\[1\] 输出的数据和顺序完全相同，即同一分区的数据只会
> 
> 进入到下游算子的同一分区。
> 
> **重新分发**模式（例如上图中的 *map()* 和 *keyBy/window* 之间，以及 *keyBy/window* 和 *Sink* 之间）则会更改数据所在
> 
> 的流分区。当你在程序中选择使用不同的 *transformation*，每个*算子子任务*也会根据不同的 transformation 将数据发
> 
> 送到不同的目标子任务。例如以下这几种 transformation 和其对应分发数据的模式：
> 
> *keyBy()*（通过散列键重新分区）、
> 
> *broadcast()*（广播）或 *rebalance()*（随机重新分发）。
> 
> 在*重新分发*数据的过程中，元素只有在每对输出和输入子任务之间才能保留其之间的顺序信息
> 
> （例如，*keyBy/window*的 subtask\[2\] 接收到的 *map()* 的 subtask\[1\] 中的元素都是有序的）。
> 
> 因此，上图所示的 *keyBy/window* 和 *Sink* 算子之间数据的重新分发时，不同键（key）的聚合结果到达 Sink 的顺序是不确定的。

## 3 Task和算子链 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 5][]

clients、JobManager、TaskManager

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 6][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 7][]

每个 Flink 应用都需要有执行环境，在该示例中为 `env`。

流式应用需要用到 `StreamExecutionEnvironment`。批处理需要用到`ExecutionEnvironment。`

**任务执行原理：**

DataStream API 将创建的应用构建为一个 job graph，并附加到 `StreamExecutionEnvironment` 。当调用 `env.execute()` 时此 graph 就被打包并发送到 JobManager 上，后者对作业并行处理并将其子任务分发给 Task Manager 来执行。每个作业的并行子任务将在 *task slot*中执行。如果没有调用 execute()，应用就不会运行。

Flink运行时包含两种类型的进程：

1.  **JobManger:**也叫作masters,协调分布式执行，调度task,协调checkpoint，协调故障恢复。在Flink程序中至少有一个JobManager,高可用可以设置多个JobManager,其中一个是Leader,其他都是standby状态。
2.  **TaskManager:**也叫workers,执行dataflow生成的task,负责缓冲数据，及TaskManager之间的交换数据。Flink程序中必须有一个TaskManager.

Flink程序可以运行在standalone集群，Yarn或者Mesos资源调度框架中。

clients不是Flink程序运行时的一部分，作用是向JobManage准备和发送dataflow,之后，客户端可以断开连接或者保持连接。

### 4 TaskSlots 任务槽 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 8][]

每个Worker（TaskManager）是一个JVM进程，可以执行一个或者多个task,这些task可以运行在任务槽上，

每个worker上**至少有一个任务槽。**每个任务槽都有固定的资源。

例如：TaskManager有三个TaskSlots,那么每个TaskSlot会将TaskMananger中的内存均分，即每个任务槽的

内存是总内存的1/3。**任务槽的作用就是分离任务的托管内存，不会发生cpu隔离。**

通过调整任务槽的数据量，用户可以指定每个TaskManager有多少任务槽，更多的任务槽意味着更多的task可以

共享同一个JVM,同一个JVM中的task共享TCP连接和心跳信息，共享数据集和数据结构，从而减少TaskManager中的task开销。

**总结：task slot****的个数代表TaskManager****可以并行执行的task****数。**

## 5 自定义时间流处理 ##

对于大多数流数据处理应用程序而言，能够使用处理实时数据的代码重新处理历史数据并产生确定并一致的结果非

常有价值。

**在处理流式数据时，我们通常更需要关注事件本身发生的顺序而不是事件被传输以及处理的顺序，**因为这能够帮助

我们推理出一组事件（事件集合）是何时发生以及结束的。例如电子商务交易或金融交易中涉及到的事件集合。

为了满足上述这类的实时流处理场景，我们**通常会使用记录在数据流中的事件时间的时间戳**，而不是处理数据的机器

时钟的时间戳。

## 6 有状态流处理 ##

Flink 中的算子可以是有状态的。这意味着**如何处理一个事件可能取决于该事件之前所有事件数据的累积结果**。

Flink 中的状态不仅可以用于简单的场景（例如统计仪表板上每分钟显示的数据），也可以用于复杂的场景

（例如训练作弊检测模型）。

Flink 应用程序可以在分布式群集上并行运行，其中每个算子的各个并行实例会在单独的线程中独立运行，

并且通常情况下是会在不同的机器上运行。

有状态算子的并行实例组在存储其对应状态时通常是按照键（key）进行分片存储的。每个并行实例算子负责处理

一组特定键的事件数据，并且这组键对应的状态会保存在本地。

如下图的 Flink 作业，其前三个算子的并行度为 2，最后一个 sink 算子的并行度为 1，其中第三个算子是有状态的，

并且你可以看到第二个算子和第三个算子之间是全互联的（fully-connected），它们之间通过网络进行数据分发。

通常情况下，实现这种类型的 Flink 程序是为了通过某些键对数据流进行分区，以便将需要一起处理的事件进行汇合，

然后做统一计算处理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 9][]

Flink 应用程序的状态访问都在本地进行，因为这有助于其提高吞吐量和降低延迟。

**通常情况下 Flink 应用程序都是将状态存储在 JVM 堆上**，**但如果状态太大，我们也可以选择将其以结构化数据格式**

**存储在高速磁盘中。**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 10][]

## 7  通过状态快照实现的容错 ##

通过**状态快照**和**流重放**两种方式的组合，Flink 能够提供可容错的，精确一次计算的语义。

这些状态快照在执行时会获取并存储分布式 pipeline 中整体的状态，它会将数据源中消费数据的偏移量（offsets）记录下来，

并将整个 job graph 中算子获取到该数据（记录的偏移量对应的数据）时的状态记录并存储下来。当发生故障时，

Flink 作业会恢复上次存储的状态，重置数据源从状态中记录的上次消费的偏移量开始重新进行消费处理。

而且状态快照在执行时会异步获取状态并存储，并不会阻塞正在进行的数据处理逻辑。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70]: /images/20230209/623d709a372b437c905ec66a8d2c6331.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 1]: /images/20230209/184c24eda0fe4d808546948d00e4e784.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 2]: /images/20230209/a25be4b1bbca4a7fb14141bb029b30f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 3]: /images/20230209/dbcab6574639457fba3786f23f7867f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 4]: /images/20230209/e446060e95fd47bc8d60c7c32530a5d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 5]: /images/20230209/24a191f714014fb982a16dfb8f472a94.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 6]: /images/20230209/41dca9c874f14537b98d1736dc67626c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 7]: /images/20230209/a88cd45046cd4e18b507304e706b28d9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 8]: /images/20230209/1d42f801a6a64481b3568fc349c1c58a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 9]: /images/20230209/b64d61063b6d41f7966a51db00f23fc5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODIwMTkzNg_size_16_color_FFFFFF_t_70 10]: /images/20230209/6a9e33c4e88e43ac823ee0b527418acc.png