2.1 Flink 系统架构 (Client, JobManager, TaskManager)

原创于 2025-08-18 11:36:47 发布 · 561 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#flink #系统架构 #大数据

Flink驯服指南：让大数据乖乖听话专栏收录该内容

7 篇文章

订阅专栏

想象一下，你开了一家大型的、现代化的“数据处理工厂”，而 Flink 就是这家工厂的总操作系统。你的目标是高效、准确地处理源源不断送来的数据原料。为了让工厂运转起来，你需要三个关键角色：

客户 (Client)：你自己，或者说你的代码提交工具。
项目经理 (JobManager)：工厂的总指挥，负责管理和调度。
工人 (TaskManager)：真正干活的员工，负责执行具体的任务。

这三个角色，就精确地对应了 Flink 的三大核心组件：Client、JobManager 和 TaskManager。

在这里插入图片描述
(图片来源: Apache Flink 官网)

1. 客户 (Client)：运筹帷幄的“幕后老板”

首先，我们来看看 Client。Client 不是集群的一部分，它更像是一个“幕后老板”或者“项目发起人”。它的主要职责是准备和提交任务。
作为工厂老板，接到了一个大订单（一个 Flink 作业）。你不会亲自下车间干活，而是会做以下几件事：

制定蓝图：编写你的 Flink 代码，定义好数据从哪里来 (Source)，经过哪些处理步骤 (Transformation)，最终到哪里去 (Sink)。
优化方案：Client 会将你的代码转换成一个叫做“数据流图 (Dataflow Graph)”的执行计划。这就像是把你的生产流程图纸化、最优化，确保每个环节都清晰明了。
提交给项目经理：最后，Client 将这份优化后的执行计划和所有需要的资源（比如你的代码 JAR 包）一同提交给 JobManager，并对他说：“这是我们的新任务，交给你了！”

一旦任务提交成功，Client 的使命就基本完成了。你可以选择离开（分离模式），让任务在集群上独立运行；也可以选择留下，等待并接收任务的最终执行结果（附加模式）。

代码示例：

我们平时在 IDEA（开发工具）里点击“运行”一个 Flink 程序，或者在服务器上通过 flink run 命令提交一个作业，这个“点击运行”或“执行命令”的动作，就是 Client 在发挥作用。

# 假设我们打包好了一个名为 FlinkWordCount.jar 的项目
# ./bin/flink run 命令就是 Client 的入口
# 它负责解析参数，将 JAR 包和执行计划提交给 JobManager

./bin/flink run -c com.example.MyStreamingJob ./FlinkWordCount.jar

在上面的命令中，flink run 就是在扮演 Client 的角色。它负责启动一个 JVM 进程，解析你的代码，生成数据流图，然后将其发送给远端的 JobManager。

小知识：
提交的命令参数丰富多样，在实际使用时可以查阅手册，根据具体的业务场景配置合适的参数。

2. 项目经理 (JobManager)：集群的“最强大脑”

JobManager 是整个 Flink 集群的协调者和管理者，是名副其实的“最强大脑”。它负责接收来自 Client 的任务，并像一位经验丰富的项目经理一样，调度和管理整个作业的执行。

通俗理解：

项目经理 (JobManager) 从老板 (Client) 手里拿到了生产计划（数据流图），他会立即开始工作：

资源评估与分配：他会检查工厂里有多少空闲的工人 (TaskManager) 和可用的设备 (Task Slot)。然后，他会根据生产计划的复杂程度，决定需要多少工人，并给他们分配具体的任务。这个过程叫做“任务调度”。
发布指令：他会对每个被选中的工人 (TaskManager) 说：“你，负责数据清洗；你，负责数据聚合……” 他会将一个个具体的“子任务 (SubTask)”分发下去。
进度监控：在整个生产过程中，项目经理会持续监控每个工人的工作状态。如果某个工人“生病”了（节点故障），他会立刻发现，并尝试将任务重新分配给其他健康的工人，以确保整个生产流程的稳定性和容错性。这个过程叫做“故障恢复”。
协调快照：为了防止意外断电导致所有工作白干，他会定期命令所有工人：“大家停一下，记录下你们手头的工作进度！” 这个动作就是 Flink 的检查点 (Checkpoint) 机制（），用于保证数据的一致性和Exactly-Once语义。

在一个高可用的 Flink 集群中，通常会有多个 JobManager，一个担任“总指挥 (Leader)”，其他则处于“待命 (Standby)”状态。一旦总指挥出现意外，待命的 JobManager 会立刻接管，保证工厂管理工作不中断。

小知识：
从Flink 1.11 (2020年7月发布) 开始，引入了非对齐 Checkpoint (Unaligned Checkpoint, UAC)，可以在 barrier 到达时直接带上未处理的数据 buffer 一起写入 checkpoint，从而避免了任务阻断。

3. 工人 (TaskManager)：踏实肯干的“执行单元”

TaskManager 是 Flink 集群中的工作节点，是真正执行数据处理任务的“工人”。集群中有多少个 TaskManager，就意味着有多少个工人。

工人 (TaskManager) 是工厂的核心生产力。他们的特点是：

拥有资源：每个工人都有自己的一块“工作台”，上面有固定数量的“工具槽 (Task Slot)”。这些工具槽代表了固定的计算资源（如内存、CPU）。一个工人可以同时处理多个不同的任务，只要他的工具槽没被占满。
听从指挥：他们不关心整个生产计划的全貌，只专注于 JobManager 分配给自己的那一部分具体任务。他们从上游任务接收数据，处理完毕后，再发送给下游任务。
勤奋汇报：他们会定期向 JobManager 汇报自己的心跳（表示自己还活着）和任务执行的状态。

多个 TaskManager 之间通过网络进行数据交换，这个过程在 Flink 中被称为“数据混洗 (Shuffle)”。这就像工厂里不同工序的工人之间通过传送带传递半成品一样。

总结：一场完美的团队合作

现在，让我们把这三个角色串起来，回顾一下 Flink 作业的完整生命周期：

你 (Client) 在你的开发电脑上编写代码，然后通过 flink run 命令提交作业。
Client 将代码编译成“数据流图”，然后将其和相关资源发送给集群的“大脑”——JobManager。
JobManager 收到任务后，分析执行计划，并向集群中空闲的“工人”——TaskManager 分配具体的子任务。
TaskManager 们从 JobManager 处领到任务指令和所需资源，开始埋头干活，在各自的“工具槽 (Slot)”中处理数据。处理过程中，它们之间会通过网络交换数据。
在整个过程中，JobManager 持续监控所有 TaskManager 的状态，确保作业稳定运行，并在出现问题时进行恢复。

通过 Client -> JobManager -> TaskManager 这样一套清晰、高效的协作模式，Flink 实现了强大的分布式计算能力。Client 负责“出谋划策”，JobManager 负责“统筹全局”，TaskManager 负责“落地执行”，三者各司其职，共同上演了一场数据处理的“权力的游戏”。