Flink部署与应用——Flink集群模式

Flink 集群模式

在大数据处理领域，Apache Flink 凭借其卓越的流批一体化处理能力，成为众多企业的首选框架。而 Flink 集群模式的选择与运用，对于充分发挥 Flink 的性能优势、满足不同业务场景的需求至关重要。接下来，我们将深入探讨 Flink 的多种集群模式，剖析其特点、适用场景及相互间的差异。

集群部署模式对比

Flink 的集群部署模式可依据两个关键维度进行分类：一是集群的生命周期和资源隔离方式；二是根据程序 main () 方法的执行位置，即在 client 端还是 JobManager 端。基于这两个维度，Flink 主要有三种集群部署模式：Session 模式、Per-Job 模式和 Application 模式。

根据集群的生命周期和资源隔离

• Session 模式：在 Session 模式下，集群会预先启动并保持运行状态，就像一个随时待命的 “大舞台”。所有提交到该集群的作业都共享这个已存在的集群资源。这意味着集群在启动时就确定了资源总量，后续作业在执行过程中会竞争这些有限的资源。例如，若集群启动时分配了 100GB 内存和 10 个 CPU 核心，那么所有作业都将在这 100GB 内存和 10 个 CPU 核心的资源池里争夺资源来执行任务。当某个作业需要大量内存进行数据处理时，可能会导致其他作业因资源不足而执行缓慢甚至失败。不过，这种模式的优势在于，对于那些执行时间短、资源需求相对较小的作业而言，无需等待集群启动的时间开销，可快速提交并执行，能有效提高集群的整体利用率。
• Per-Job 模式：为了解决 Session 模式下资源竞争的问题，Per-Job 模式应运而生。在这种模式下，每提交一个作业，都会单独启动一个全新的集群。每个作业都拥有自己独立的 JobManager 和 TaskManager 等资源，实现了作业间的完全资源隔离。举例来说，如果同时提交作业 A 和作业 B，系统会为作业 A 启动一个包含特定资源配置的集群，为作业 B 启动另一个具有独立资源的集群。这样，即使作业 A 所在的 TaskManager 出现故障，也不会对作业 B 产生任何影响，极大地提高了作业执行的稳定性和可靠性。但这种模式的缺点也很明显，每次提交作业都要启动新集群，会带来额外的时间和资源开销，尤其是在提交大量作业时，资源的重复分配和集群启动时间可能会成为性能瓶颈。
• Application 模式：Application 模式是对 Per-Job 模式的进一步优化。它同样为每个应用程序创建一个独立的集群，实现了资源隔离。与 Per-Job 模式不同的是，在 Application 模式下，应用程序的 main () 方法直接在 JobManager 上执行，而不是像前两种模式那样在客户端执行。这一改变带来了显著的优势，客户端无需再承担下载依赖、发送二进制文件等繁重任务，大大减轻了客户端的压力。例如，在一个数据量庞大、依赖复杂的 Flink 应用中，使用 Application 模式可避免客户端因处理这些任务而导致的性能瓶颈，使应用能够更高效地在集群中运行。

根据程序 main () 方法执行位置

• Client 端执行：在 Session 模式和 Per-Job 模式中，应用程序的 main () 方法都是在客户端执行的。客户端需要负责解析用户代码，构建作业执行计划，下载作业所需的依赖包，并将作业的二进制文件和相关配置发送给 JobManager。这个过程中，客户端会消耗大量的系统资源，包括 CPU、内存和网络带宽等。如果客户端性能不足或网络不稳定，可能会影响作业的提交和执行效率。例如，当客户端需要处理一个包含大量第三方依赖库的复杂作业时，下载这些依赖可能会花费较长时间，并且在发送作业二进制文件过程中，若网络出现波动，还可能导致传输失败，需要重新提交作业。
• JobManager 端执行：Application 模式打破了传统，将应用程序的 main () 方法的执行转移到了 JobManager 端。客户端只需将应用程序提交给 JobManager，JobManager 负责调用 main () 方法并执行应用程序。这种方式减少了客户端的负担，使得客户端只需专注于作业的提交请求，而无需进行复杂的作业构建和资源准备工作。对于那些需要频繁提交作业或者客户端资源有限的场景，Application 模式具有明显的优势。

Session 模式

模式概述

Session 模式是一种较为传统且直观的 Flink 集群部署方式。在这种模式下，用户首先需要手动启动一个 Flink 集群，这个集群会一直运行，直到用户手动停止它。可以将其想象成一个长期开放的 “数据处理工厂”，所有提交的作业都在这个工厂中进行处理。集群启动时，会根据配置分配固定的资源，包括内存、CPU 等，这些资源在集群运行期间保持不变。当用户有作业需要执行时，通过客户端将作业提交到这个已启动的集群中，作业会在集群提供的资源环境下竞争资源并执行。

共享机制：在 Session 模式下，所有提交的 Job 共享同一套 JobManager 和 TaskManager 资源，它们都运行在同一个 Runtime 环境中。这意味着各个 Job 在执行过程中会共同竞争集群已分配的资源，例如内存、CPU 核心等。

运行模式​

资源共享架构：JobManager 与 TaskManager 在整个集群运行期间持续工作，为所有提交的作业提供服务。这种共享模式使得集群资源在启动时就已确定并分配好，后续作业在此基础上进行资源竞争。​

客户端连接方式：客户端通过 RPC（远程过程调用）或 RestAPI 与集群的管理节点（即 JobManager）建立连接。客户端负责将作业相关信息发送给 JobManager，以便 JobManager 对作业进行调度和管理。​

依赖上传流程：Deployer（部署器，通常由客户端承担此角色）需要将作业运行所依赖的 DependencesJar 上传至集群。这些依赖包包含了作业执行所需的各种类库和资源，确保作业在集群环境中能够顺利运行。​

作业提交流程：Deployer 负责生成 JobGraph，JobGraph 是 Flink 作业的一种数据结构，它描述了作业的拓扑结构和执行逻辑。生成 JobGraph 后，Deployer 将其提交到集群的管理节点（JobManager），由 JobManager 负责后续的作业调度和执行。​

JobManager 生命周期：JobManager 的生命周期与提交的单个 Job 无关，它在集群启动时开始运行，并持续运行直至集群被手动停止。这使得在集群运行期间，新的作业可以随时提交并执行，无需等待 JobManager 的启动过程。

工作流程

1. 集群启动：用户通过执行特定的启动脚本，启动 Flink 集群。在启动过程中，系统会初始化 JobManager 和 TaskManager 等组件，并根据配置文件（如 flink-conf.yaml）分配资源。例如，配置文件中指定分配 20GB 内存给 TaskManager，那么在启动时，每个 TaskManager 实例将获得相应的内存资源。
2. 作业提交：用户编写好 Flink 应用程序并打包成 JAR 文件后，通过 Flink 命令行工具（如 flink run 命令）或者 Flink 的 REST API 将作业提交到已启动的集群中。客户端会将作业的 JAR 文件、相关配置以及作业执行计划发送给 JobManager。JobManager 接收到作业后，会根据集群的资源状况和作业的并行度等配置信息，将作业分配到各个 TaskManager 上执行。
3. 作业执行与资源管理：在作业执行过程中，TaskManager 会从输入源读取数据，按照作业定义的算子逻辑进行处理，并将结果输出到指定的目的地。由于所有作业共享集群资源，TaskManager 需要动态管理资源的分配和使用。例如，当一个作业需要更多内存来处理大量数据时，TaskManager 会在剩余可用资源范围内尽量满足其需求，但这可能会导致其他作业可获取的资源减少。当作业执行完成后，TaskManager 会释放该作业占用的资源，以便其他作业使用。

适用场景

• 小型作业频繁提交：对于那些处理逻辑简单、数据量较小且需要频繁提交的作业，Session 模式非常适用。由于集群已经预先启动，作业无需等待集群启动时间，可快速提交并执行，大大提高了作业的处理效率。例如，在实时监控系统中，可能每隔几分钟就需要执行一次简单的数据统计作业，使用 Session 模式可确保这些作业能够及时、高效地运行。
• 交互式数据分析：在进行交互式数据分析时，用户希望能够快速得到查询结果。Session 模式下，集群随时待命，用户提交的查询作业可以立即在已有的资源上执行，减少了等待时间，提升了用户体验。比如，数据分析师在进行数据探索时，可能会频繁提交不同的查询语句来分析数据，Session 模式能够满足这种快速响应的需求。

优缺点分析

优点

• 集群启动一次，长期使用，资源利用率提升：由于所有作业共享集群资源，在集群资源配置合理且作业资源需求分布较为均衡的情况下，能够充分利用集群的资源，避免资源闲置，从而提高整体资源利用率，同时避免了每次提交作业都启动集群的时间开销，对于频繁提交作业的场景，能显著提高整体效率。例如，当多个小型作业同时运行时，它们可以共享集群的内存和 CPU 资源，使得集群资源得到更充分的利用。
• 资源集中管理，运维管理简化：所有作业都在 Flink Session 集群中统一管理，运维人员只需关注单个集群的运行状态，包括资源监控、任务调度等方面。相比管理多个独立的集群，这种集中式管理方式大大降低了运维的复杂性和工作量。例如，在监控作业执行情况时，运维人员只需通过一个控制台或监控界面即可查看所有作业的状态，而无需分别登录到多个不同的集群管理界面。

缺点

• 资源竞争问题，资源隔离性差：因为作业共享资源，当某些作业资源需求较大时，可能会占用过多资源，导致其他作业因资源不足而执行缓慢甚至失败。例如，一个计算密集型作业可能会消耗大量 CPU 资源，使得其他对 CPU 资源有一定需求的作业无法获得足够的资源来正常运行。
• 故障影响范围广：如果某个 TaskManager 出现故障，在该 TaskManager 上运行的所有作业都会受到影响，可能导致作业失败，需要重新提交和执行。
• 非 Native 类型部署限制：在非 Native 类型部署（如基于 Yarn 等资源管理器的部署）下，TaskManager 的扩展相对困难。由于集群启动时已确定资源分配，后续难以根据作业的实际需求动态灵活地扩展 TM 的计算资源，即 Slot 计算资源的伸缩性较差。这可能导致在作业量突然增加或作业资源需求大幅变化时，集群无法及时调整资源分配以满足需求。

Per-Job 模式

模式概述

Per-Job 模式为每个提交的作业创建一个独立的 Flink 集群，每个作业都有自己专属的 JobManager 和 TaskManager。这种模式就像是为每个作业量身定制了一个 “独立的数据处理车间”，作业之间的资源完全隔离，互不干扰。每个作业的执行环境都是独立的，包括资源分配、任务调度等，确保了作业执行的稳定性和可靠性。

独享机制：每个 Job 拥有独立的 JobManager 和 TaskManager，相当于为每个 Job 单独启动一个独立的 Runtime 环境。这种模式确保了不同 Job 之间的资源完全隔离，一个 Job 的执行不会受到其他 Job 的影响。

运行模式

• 独立资源架构：每个 Job 都有自己专属的 JobManager 和 TaskManager，它们仅为该 Job 服务。从资源分配的角度来看，每个 Job 在启动时，系统会根据该 Job 的资源需求为其分配独立的 TaskManager 资源，包括内存、CPU 等。
• Slot 资源定制：在 TaskManager 中，Slot 资源根据每个 Job 的具体需求进行指定。不同的 Job 可以根据自身的并行度、数据处理量等因素，要求不同数量和规格的 Slot 资源，从而实现资源的精准分配。
• 依赖上传流程：与 Session 模式类似，Deployer 需要将作业依赖的 DependencesJar 上传至集群，以确保作业在其独立的运行环境中有足够的依赖支持。
• 作业提交流程：客户端负责生成 JobGraph，描述作业的执行逻辑和拓扑结构。生成后，将 JobGraph 提交到管理节点（该 Job 专属的 JobManager），由专属的 JobManager 负责后续的作业调度和执行。
• JobManager 生命周期：JobManager 的生命周期与对应的 Job 紧密绑定。当 Job 开始提交并启动时，专属的 JobManager 随之启动；当 Job 执行完成或因故障终止时，该 JobManager 也会停止运行，相关资源被释放。

工作流程

1. 作业提交触发集群启动：当用户通过客户端提交一个作业时，系统会检测到这是一个新的作业，然后立即启动一个全新的 Flink 集群来运行该作业。这个过程中，会根据作业的资源需求和配置信息，动态分配资源给新启动的集群。例如，作业 A 需要 4GB 内存和 2 个 CPU 核心，系统会为其启动的集群分配相应的资源。
2. 作业执行与资源独立管理：新启动的 JobManager 负责接收客户端发送的作业 JAR 文件、配置和执行计划，并根据作业的并行度等信息，将任务分配到集群中的 TaskManager 上执行。由于每个作业都有自己独立的集群，TaskManager 在执行任务时，无需考虑与其他作业的资源竞争问题，可专注于本作业的任务处理。当作业执行完成后，该作业对应的集群会自动关闭，释放所有占用的资源。
3. 多作业并行提交处理：如果同时有多个作业提交，系统会为每个作业分别启动独立的集群，并并行处理这些作业。每个作业的执行进度和状态都由其对应的 JobManager 独立管理，互不影响。例如，作业 B 和作业 C 同时提交，系统会为作业 B 启动集群 B，为作业 C 启动集群 C，两个集群并行运行，各自处理对应的作业。

适用场景

• 大规模、长时间运行的作业：对于那些数据量巨大、处理逻辑复杂且需要长时间运行的作业，Per-Job 模式提供了更好的资源隔离和稳定性保障。由于作业拥有独立的资源，不会受到其他作业的干扰，能够确保作业在整个执行过程中稳定运行。比如，在进行全量数据的离线分析时，作业可能需要处理数 TB 甚至更大的数据量，并且运行时间可能长达数小时甚至数天，使用 Per-Job 模式可保证作业的顺利执行。
• 对作业稳定性要求极高的场景：在一些对作业执行稳定性要求极为严格的场景，如金融交易数据处理、医疗数据实时分析等，任何作业的失败都可能导致严重后果。Per-Job 模式下，即使某个作业所在的集群出现故障，也不会影响其他作业的正常运行，大大提高了整个系统的可靠性。

优缺点分析

优点

• 资源隔离性强：各个 Job 之间资源完全隔离，一个 Job 出现资源耗尽、内存泄漏或其他异常情况，不会影响其他 Job 的正常运行。这在对作业稳定性和可靠性要求极高的场景中，如金融交易数据处理、医疗数据实时分析等，尤为重要。例如，在金融交易系统中，不同的交易处理作业相互隔离，确保了某个交易作业的故障不会波及其他交易的正常处理。
• 故障隔离：一个作业的故障不会影响其他作业，每个作业的执行环境相互独立，提高了系统的容错能力。

• 资源按需申请：每个 Job 可以根据自身的实际需求申请资源，TaskManager 中的 Slots 数量可以根据 Job 的特点进行灵活配置。对于数据量较大、计算复杂的作业，可以分配较多的 Slots；而对于简单的作业，则可以分配较少的 Slots，从而实现资源的合理利用。

缺点

• 集群启动开销大：每次提交作业都要启动一个新的集群，这会带来额外的时间和资源开销，尤其是在提交大量作业时，资源的重复分配和集群启动时间可能会成为性能瓶颈。
• 资源利用率相对较低：由于每个作业都有自己独立的集群，即使作业的资源需求较小，也会占用一定的固定资源，导致在整体资源利用上可能不如 Session 模式高效。

• 资源浪费：每个 Job 都需要独立的 JobManager，这会额外消耗一定的资源，包括内存、CPU 等。在提交大量作业且每个作业资源需求相对较小的情况下，这种资源的重复消耗可能导致整体资源利用率不高。例如，每个作业的 JobManager 都需要占用一定的内存空间来管理作业的状态和调度任务，当作业数量众多时，这些 JobManager 所占用的内存总和可能会相当可观。

• 管理复杂度增加：由于每个 Job 都有自己独立的集群（由专属的 JobManager 和 TaskManager 组成），管理员需要分别对每个 Job 对应的集群进行管理，包括资源分配、监控、维护等。在一个拥有大量作业的系统中，管理如此众多的独立集群实例会大大增加管理的复杂性和工作量，容易出现管理混乱的情况。例如，在排查某个作业的故障时，管理员需要在众多的 JobManager 和 TaskManager 实例中准确找到与该作业相关的实例，定位和解决问题的难度较大。

Session 集群和 Per-Job 类型集群问题

Flink作业的工作流程通常分为以下四个步骤：

1. 下载 Application's dependencies 到本地 (BinaryPackage)
2. 在 Client 中执行 main（）方法，抽取 JobGraph 对象
3. 将 JobGraph 和 Dependencies 一起提交给集群运行
4. 等待 Job 运行结果

其中Session 集群和 Per-Job 类型集群的主要问题在前两步中：

1. 下载 Application's dependencies 到本地 (BinaryPackage)：在 Session 模式和 Per-Job 模式中，客户端需要在本地下载和安装相关依赖，形成 BinaryPackage。这一过程可能会遇到依赖版本冲突、下载速度慢等问题。例如，当作业依赖的某些类库版本较新，而客户端本地环境中已存在旧版本的相同类库时，可能会导致依赖冲突，影响作业的正常提交和执行。
2. 在 Client 中执行 main（）方法，抽取 JobGraph 对象
   • 带宽消耗大：客户端需要从远程仓库下载作业所需的各种依赖包，这些依赖包可能体积较大，尤其是对于包含大量第三方库的复杂作业。每次作业提交时都需要下载这些依赖，会消耗大量的网络带宽。例如，一个依赖众多机器学习框架的 Flink 作业，其依赖包的总大小可能达到几百 MB 甚至 GB，每次提交作业时都下载这些依赖会严重占用网络带宽。
   • CPU 资源消耗：生成 JobGraph 的过程需要客户端执行复杂的逻辑，包括解析用户代码、构建作业执行计划等，这会消耗大量的 CPU 资源。当客户端同时处理多个作业的提交时，CPU 资源可能会成为瓶颈，导致作业提交速度变慢。例如，在一个需要频繁提交作业的大数据处理平台中，如果客户端 CPU 性能不足，可能会出现作业提交排队等待的情况。
   • 客户端压力增大：在任务较多的情况下，客户端不仅要处理多个作业的依赖下载、JobGraph 生成，还需要与集群管理节点进行频繁的通信以提交作业和获取作业状态。这会使客户端的负载急剧增加，可能导致客户端出现卡顿甚至崩溃的情况。例如，在一个电商促销活动期间，大量的实时数据分析作业需要提交，客户端可能会因为压力过大而无法及时响应作业提交请求。

Application 模式（1.11 版本提出）

模式概述

Application 模式是 Flink 1.11 版本引入的一种新的集群部署模式，旨在解决传统模式中存在的一些问题，特别是客户端资源消耗和作业执行效率方面的问题。在这种模式下，应用程序的 main () 方法直接在 JobManager 上执行，客户端只负责将应用程序提交给 JobManager，大大减轻了客户端的负担。可以将其理解为一种更加 “去中心化” 的模式，让 JobManager 承担更多的应用执行职责，提高了整个系统的执行效率和稳定性。

运行机制：Application 的 main () 方法在 Cluster（集群）上执行，而非客户端。每个 Application 对应一个独立的 Runtime，并且一个 Application 中可以包含多个 Job。这种模式改变了传统模式中客户端承担大量工作的情况，将主要执行逻辑转移到了集群端。

运行模式

• JobManager 与 Application 关系：每个 Application 都有一个对应的 JobManager，该 JobManager 负责管理和执行该 Application 中的所有 Job。与 Per - Job 模式不同，这里不是每个 Job 都有独立的 JobManager，而是多个 Job 共享一个为该 Application 服务的 JobManager，从而在一定程度上提高了资源的利用效率。
• 客户端职责简化：客户端无需将作业的 Dependencies 上传到 JobManager，其主要职责变为负责管理 Job 的提交与管理，如提交作业请求、查看作业状态等简单操作。这大大减轻了客户端的负担，使得客户端在资源有限的情况下也能顺利完成作业提交任务。
• JobGraph 生成位置改变：main () 方法在 JobManager 中执行，JobGraph 的生成也在集群上完成。这减少了客户端在生成 JobGraph 过程中的资源消耗，同时避免了因客户端性能问题导致的 JobGraph 生成缓慢或失败的情况。例如，对于一个数据量巨大、依赖复杂的 Flink 应用，在客户端生成 JobGraph 可能会因客户端资源不足而失败，而在 Application 模式下，由集群端的 JobManager 负责生成 JobGraph，利用集群丰富的资源可以高效地完成生成过程。

工作流程

1. 应用提交：用户将编写好的 Flink 应用程序打包成 JAR 文件，并通过 Flink 命令行工具或者 REST API 提交给 JobManager。与传统模式不同的是，客户端在提交应用时，无需在本地执行 main () 方法和进行复杂的作业构建工作，只需将应用程序和相关配置发送给 JobManager 即可。
2. JobManager 执行应用：JobManager 接收到应用程序后，会直接调用应用程序的 main () 方法，在 JobManager 所在的节点上执行应用程序的逻辑。在执行过程中，JobManager 会根据应用程序的需求，动态分配资源给 TaskManager，并将任务分发给 TaskManager 执行。例如，应用程序需要处理大量数据，JobManager 会根据数据量和并行度要求，为 TaskManager 分配足够的内存和 CPU 资源。
3. 资源管理与作业执行：TaskManager 在接收到 JobManager 分配的任务后，从输入源读取数据，按照应用程序定义的算子逻辑进行处理，并将结果输出到指定的目的地。在这个过程中，JobManager 会实时监控作业的执行状态，动态调整资源分配，确保作业能够高效执行。当作业执行完成后，JobManager 会释放相关资源，关闭应用程序对应的集群（如果是为该应用程序单独创建的集群）。

适用场景

• 客户端资源有限的场景：在一些场景中，客户端可能是资源受限的设备，如移动设备或者资源紧张的边缘计算节点。使用 Application 模式，客户端无需承担大量的资源消耗任务，只需简单地提交应用程序，即可在 Flink 集群中执行复杂的任务。例如，在物联网场景中，传感器设备作为客户端，资源有限，通过 Application 模式可将数据处理任务提交到云端的 Flink 集群中执行。
• 大规模作业频繁提交：对于需要频繁提交大规模作业的场景，Application 模式能够有效提高作业提交和执行的效率。由于客户端负担减轻，提交作业的速度更快，并且 JobManager 直接执行应用程序，减少了中间环节，使得作业能够更快地开始执行。比如，在互联网广告投放系统中，可能需要频繁根据用户行为数据进行广告投放策略的调整，使用 Application 模式可快速提交和执行相关的数据分析作业。

优缺点分析

优点

• 降低带宽与客户端负载：客户端无需下载和上传大量的依赖包，也无需在本地执行复杂的 JobGraph 生成操作，有效减少了网络带宽的消耗和客户端的负载。这使得在客户端资源有限（如移动设备、边缘计算节点等）的场景下，也能顺利提交和运行复杂的 Flink 应用。例如，在物联网场景中，传感器设备作为客户端，资源有限，通过 Application 模式可以将数据处理任务提交到云端的 Flink 集群中执行，而不会因自身资源不足而受到限制。

• 资源隔离与共享平衡：一方面，不同的 Application 之间实现了资源隔离，一个 Application 的故障或资源过度消耗不会影响其他 Application 的正常运行；另一方面，在一个 Application 内部，多个 Job 可以共享该 Application 对应的集群资源，提高了资源的利用效率。例如，在一个电商平台的实时数据分析系统中，用户行为分析 Application 和订单处理 Application 相互隔离，各自独立运行，而在用户行为分析 Application 中，多个不同的用户行为统计 Job 可以共享该 Application 的集群资源，避免了资源的重复分配和浪费。

缺点

• 对 JobManager 要求较高：JobManager 需要承担应用程序的执行任务，这对 JobManager 的性能和资源提出了更高的要求。如果 JobManager 资源不足，可能会影响应用程序的执行效率。
• 兼容性问题：作为一种新的模式，在与一些旧版本的 Flink 组件或者第三方工具集成时，可能会存在兼容性问题，需要进行额外的测试和调整。

• 部署环境限制：目前 Application 模式仅支持 Yarn 和 Kubernetes 这两种部署环境。这意味着在使用其他资源管理平台或部署方式时，无法采用 Application 模式，限制了其在一些特定环境中的应用。例如，对于一些已经搭建了自定义资源管理系统且无法轻易切换到 Yarn 或 Kubernetes 的企业，无法享受到 Application 模式带来的优势。

总结

Flink 作为大数据处理领域的领先框架，其不同的集群模式为满足多样化业务需求提供了灵活选择。Session 模式、Per-Job 模式和 Application 模式在资源分配、作业管理、性能表现等方面各有千秋，深刻理解它们的特性有助于开发者和企业根据实际场景做出最优决策。

Session 模式以资源共享为核心，所有作业在同一 Runtime 环境下共用 JobManager 和 TaskManager。其优势在于资源利用率高，运维管理便捷，适合小型作业频繁提交和交互式数据分析场景，能快速响应作业请求，减少集群启动开销。但资源隔离性差和非 Native 部署下的资源伸缩受限，可能导致作业相互干扰，难以应对资源需求动态变化的情况。

Per-Job 模式则强调资源隔离，为每个作业创建独立的 Runtime 环境，JobManager 与作业生命周期绑定。这种模式在大规模、长时间运行作业以及对稳定性要求极高的场景中表现出色，作业间互不影响，资源可按需分配。然而，其弊端在于集群启动开销大，资源浪费明显，管理复杂度也随着作业数量增加而显著上升。

Application 模式是 Flink 1.11 版本的创新成果，将 main () 方法的执行移至 JobManager，减轻客户端负担，实现了资源隔离与共享的平衡。它有效降低带宽消耗和客户端负载，适用于客户端资源有限以及大规模作业频繁提交的场景。不过，目前仅支持 Yarn 和 Kubernetes 部署环境，限制了其在部分场景的应用。