「Flink实时数据分析系列」3. Apache Flink的体系架构

最新推荐文章于 2025-04-29 13:42:10 发布

原创

最新推荐文章于 2025-04-29 13:42:10 发布 · 567 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #大数据 #分布式 #hadoop #数据库

来源 | 「Stream Processing with Apache Flink」

作者 | Fabian Hueske and Vasiliki Kalavri

翻译 | 吴邪大数据4年从业经验，目前就职于广州一家互联网公司，负责大数据基础平台自研、离线计算&实时计算研究

校对 | gongyouliu

编辑 | auroral-L

全文共17850字，预计阅读时间80分钟。

一、系统架构

1.Flink架构组件

2.应用部署

3.任务执行

4.高可用配置

二、Flink数据传输

1.基于信用（Credit-Based）的流量控制

2.任务链

三、事件时间处理

1.时间戳

2.水位线（Watermarks）

3.水位线传播和事件时间

4.时间戳分配与水位线生成

四、状态管理

1.非键控状态（Operator State）

2.键控状态（Keyed State）

3.状态后端（State Backends）

4.有状态算子的扩缩容

5.检查点、保存点和状态恢复

❤结束语

第二章「流处理基本概念」介绍了分布式流处理的重要概念，比如并行化、时间和状态。在本章中，我们将对Flink的体系架构做更高层次的介绍，并阐述Flink是如何处理我们之前讨论过的关于流处理方面的问题的。我们将展示Flink的体系架构以及了解Flink是如何处理流应用程序中的时间和状态，并讨论其容错机制。本章提供了使用Apache Flink成功实现和操作高级流处理应用程序的相关背景信息，它将有助于你理解Flink的内部原理以及高性能的秘密。

一、系统架构

Flink是一个用于有状态并行数据流处理的分布式计算引擎，一个Flink基本架构通常由分布在不同机器的多个进程组成，对于分布式计算系统来说，最大的挑战就是解决集群计算资源的分配和管理、协调进程、数据持久化以及故障恢复这些核心问题。

Flink本身并没有实现以上所有提到的功能，恰恰相反，它专注于其核心的功能--分布式数据流处理，通过利用现有的集群基础设施和服务来发挥作用。Flink支持很多种资源管理器，比如Apache Mesos、YARN和Kubernetes，能够非常友好地进行集成，同时Flink也支持基于standalone模式部署，自己管理资源，无需借助其他资源组件，但是这种方式的资源管理效率相对来说不高。Flink作为分布式流式计算引擎，本身不提供数据持久化，但是他利用了分布式文件系统实现数据持久化，常见的优秀分布式文件系统有HDFS和S3，如果需要实现Flink的高可用，那就需要依赖于Apache Zookeeper进行leader的选举。

在本节中，我们将重点介绍Flink的架构组成，以及组件之间是如何进行通信和执行任务的，不仅如此，我们还会讨论Flink两种不同的部署模式，了解基于不同的部署模式下，应用程序是如何分配的以及任务执行的过程是怎样的，最后，我们还会解释Flink的高可用模式是如何运行的。

1.Flink架构组件

Flink通常由四大组件构成，每个组件有不同的功能，共同管理流应用程序的运行，四大组件分别是：JobManager、ResourceManager、TaskManager和Dispatcher。由于Apache Flink是基于Java和Scala开发实现的，因此所有的组件都是在Java虚拟机上运行的，接下来我们针对每个组件的功能以及组件之间是如何进行交互的进行讨论。

作业管理器（JobManager）：是单个应用程序的主线程，每个应用程序有单独的JobManager控制，JobManager会接收要执行的应用程序，一般来说，一个应用程序包含了一个JobGraph、一个逻辑数据流图（参见第二章）和一个JAR文件这三个要素，JAR文件打包了程序运行所必需的类、库以及其他资源。JobManager将JobGraph转换为ExecutionGraph，即物理数据流图，其中包含了可以并行执行的任务，JobManager向ResourceManager请求执行任务所需要的资源(slot)，一旦它接收到足够的TaskManager slots，就会将ExecutionGraph中的任务分配给执行它们的TaskManager，同时在任务执行期间，JobManager负责所有需要中心协调的操作，比如checkpoint、savepoint和state recovery等。
资源管理器（ResourceManager）：Flink提供了多种资源管理器，常见的有YARN、Mesos、Kubernetes和standalone模式，资源管理器负责管理TaskManager的slots，即Flink的计算资源基本单元，当JobManager申请TaskManager slots时，ResourceManager会将空闲的TaskManager slot分配给JobManager，如果ResourceManager没有足够的资源来满足JobManager的请求时，资源管理器还可以向资源提供方申请容器用来启动TaskManager进程，除此之外，资源管理器还负责终止空闲的TaskManager进程，从而释放计算资源。
任务管理器（TaskManager）：Flink的工作进程，通常情况下，一个Flink集群下会运行多个TaskManager进程，每个TaskManager会提供一定量的slots，slots的数量决定了TaskManager能够运行多少个计算任务，TaskManager启动之后，就会向ResourceManager注册它的slots，当收到ResourceManager的指令时，TaskManager会向JobManager提供一个或多个slot资源，然后JobManager就可以将slot分配到任务中去执行了，在执行任务的过程中，同一个应用程序中不同的TaskManager进程可以进行数据交换。关于任务的执行流程以及slot的概念留到后面的内容再做讨论。
分发器（Dispatcher）：用于跨作业执行任务，并且提供了REST接口去提交应用程序，一旦应用程序被提交执行，它会启动一个JobManager去管理提交的应用程序，REST接口使dispatcher能够作为集群（位于防火墙之后）的HTTP入口对外提供服务。此外，Dispatcher也会启动一个WEB UI面板，用来展示作业的执行信息，在Flink的架构中，Dispatcher不是必需的，取决于应用提交的方式，关于这点，我们会在“应用部署”这一小节进行讨论。

图3-1展示了当应用程序提交执行后，Fink组件之间是如何进行交互的。

注意，图3-1只是大致描述了Flink各个组件的职责以及组件之间交互的情况。根据部署环境的不同，比如采用不同的资源管理器，如基于YARN、Mesos、Kubernetes或者standalone部署，在执行步骤上会存在差别，基于这些差别组件或许可以在相同的JVM进程中运行。例如，在standalone集群中，集群是没有资源管理器的，ResourceManager只能分发可用的TaskManager的slots，而无法单独启动新的TaskManager。在“部署模式”的章节中，我们将讨论在不同环境下部署和配置Flink。

2.应用部署

Flink应用程序有两种部署方式。

框架模式（Framework）：在这种模式下，Flink应用程序会被打包到一个JAR文件中，并且由客户端提交到正在运行的服务中，该服务可以是一个Flink Dispatcher，Flink JobManager或者YARN资源管理器等等，在任何情况下，必须要有这样的一个正在运行的服务，确保能够接收应用程序并且执行。如果一个应用程序被提交到JobManager，它会立即启动并开始执行应用程序，如果这个应用程序是提交到Dispatcher或者YARN资源管理器，那么它会启动一个JobManager，并将应用程序移交给JobManager处理，然后JobManager就会开始执行该应用程序。
库模式（Library）：在这种模式下，Flink应用程序会绑定在指定应用程序的容器镜像中，比如Docker镜像，这个镜像同样包含了运行JobManager和ResourceManager的代码，当启动镜像中的容器后，它会自动启动ResourceManager和JobManager，并且提交绑定的应用程序去执行，此外，还会有单独用于部署TaskManager从而进行独立作业的镜像，当镜像中的容器启动时，会自动启动一个TaskManager，随后与ResourceManager建立连接并注册slots信息。通常来说，基于Kubernetes这样的外部资源管理器可以用于启动镜像并且确保发生故障时自动重启容器。

以上这两种部署方式，相对而言，框架模式（Framework）比较偏向于传统方法，通过客户端将应用程序提交给正在运行的服务，而库模式（Library）则完全不同，不存在Flink服务，相反是将Flink和容器镜像中的应用程序绑定在一起，这种部署模式常见于微服务架构中。我们会在“运行和管理流式应用”这一章节内容中讨论更多关于应用部署的细节。

3.任务执行

一个TaskManager可以同时执行多个任务，这些任务可以是同一个算子的子任务，也就是Flink中的数据并行度，或者分属不同的算子，即任务并行度，甚至可以是其他应用程序的子任务，即作业并行度。一个TaskManager通过提供一定数量的slot从而控制任务的并发数，一个slot可以执行应用程序的一个切片，即应用程序中的一个算子的一个并行任务，下图3-2展示了TaskManager、slots、tasks和operators之间的关系。