Flink学习1——运行时架构(standalone模式)

最新推荐文章于 2025-07-13 10:30:48 发布

原创最新推荐文章于 2025-07-13 10:30:48 发布 · 1.1k 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#flink

Flink 专栏收录该内容

26 篇文章

订阅专栏

本文详细介绍了Flink Standalone模式的运行时架构，包括JobManager和TaskManager的角色，以及它们如何通过Akka进行通信。JobManager相当于ResourceManager，负责任务管理和资源分配，而TaskManager作为NodeManager，执行具体任务并管理资源。TaskManager通过TaskSlots分配任务，每个Slot代表内存资源。数据交互如shuffle发生在TaskManager之间，且心跳机制确保集群稳定性。Flink的容错机制，如Checkpoint，由JobManager协调。

本篇主要讲述Flink Standalone模式下的运行时架构以及各个组件负责的功能，Flink的运行方式有很多，但都大同小异，本文基本可以满足对flink运行时架构的学习。

正文

Flink系统是主从模式，主要有两个组件构成分别是JobManager（Master）和TaskManager（Slave）。组件之间的通信借助于Akka。下图是standalone模式下的运行时架构图

JobManager相当于Yarn中的ResourceManager，TaskManager相当于Yarn中的NodeManager，TaskSlot相当于Yarn的Container，上图相当于spark的Standalone，需要Flink自己管理资源的情况。但是类别归类比，最终Flink的TaskManager是在yarn的container中启动的！因为container可以任务是一块独立的物理内存。在这个内存中可以启动一个JVM（可以是TM也可以是JM），如果是TM，那么TM中包含slot，slot也可以任务是一块内存区域，但是这个内存区域应该是JVM堆内存（也可能包含一部分堆外内存）。所以从都是内存区域的这个角度来讲，他们是类似的。
客户端用于提交Flink程序，可以像Spark那样通过命令行提交，Flink还支持通过Web UI提交（这个功能在实际生产环境中一般会被禁用）。比如我们在服务器命令行提交flink程序，那这个提交程序的命令行就可以理解为是客户端。
一个集群中只有一个活跃的JobManager，负责整个集群的任务管理和资源管理，TM心跳信息，状态统计信息等会发给JM。
TaskManager负责任务的具体执行和对应任务在每个节点上的资源申请和管理，程序运行时会在TM之间交换数据，比如有些算子的数据交换可能是跨slot，类似于Spark的shuffle操作。
客户端提交的应用会给JobManager，JobManager会根据注册给自己的TaskManager的情况分配资源给应用程序。
TaskManager是一个JVM进程，它可能会在独立的线程上运行一个或者多个子任务，每个任务就是一个task，运行在TaskSlot里面。
为了控制一个TaskManager能接受多少task，TaskManager通过task slot来控制（一个TaskManager至少有一个task slot）。上面说了，slot就类似于container，是对资源（内存、CPU）的封装。CPU是无法独享的，但是内存是独享的，也就是每个task都有自己的内存空间。

总结

1. 本文主要讲述了Flink不同组件在flink任务执行时的作用。

2. 上图中有画出TaskManager之间的数据交互。因为DataSource中的数据在分发给TaskSlot以后并不是一成不变的，类似Spark中的shuffle，有些算子中的数据会发往不同的slot（像keyBy算子），在发往不同slot的时候这不同的slot很可能就是跨TaskManager的，因此不同TM会存在大量的数据交互操作。

3. 上图还有画出不管是TaskManager还是JobManager都有一个Actor System。这便是负责通信的akka的重要组件。TaskManager需要定时发送心跳给JobManager告诉它自己还在正常工作。

4. 上图JobManager中有一个Checkpoint Coordinator，还有一条箭头指向TaskManager。首先Checkpoint是Flink用于容错定时触发的报错现在状态的轻量级快照，这个后面会讲。现在知道是JM通知TM触发的即可。