You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
如需了解具体的目录结构，请参阅 [FLIP-549: Support Application Management](https://cwiki.apache.org/confluence/display/FLINK/FLIP-549%3A+Support+Application+Management)。
Copy file name to clipboardExpand all lines: docs/content.zh/docs/deployment/overview.md
+27-13Lines changed: 27 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -73,8 +73,8 @@ When deploying Flink, there are often multiple options available for each buildi
73
73
JobManager is the name of the central work coordination component of Flink. It has implementations for different resource providers, which differ on high-availability, resource allocation behavior and supported job submission modes. <br />
74
74
JobManager <a href="#deployment-modes">modes for job submissions</a>:
75
75
<ul>
76
-
<li><b>Application Mode</b>: runs the cluster exclusively for one application. The job's main method (or client) gets executed on the JobManager. Calling `execute`/`executeAsync` multiple times in an application is supported.</li>
77
-
<li><b>Session Mode</b>: one JobManager instance manages multiple jobs sharing the same cluster of TaskManagers</li>
76
+
<li><b>Application Mode</b>: runs the cluster exclusively for one application. The application's main method (or client) gets executed on the JobManager. Calling `execute`/`executeAsync` multiple times in an application is supported.</li>
77
+
<li><b>Session Mode</b>: one JobManager instance manages multiple applications (and all jobs within them) sharing the same cluster of TaskManagers</li>
78
78
</ul>
79
79
</td>
80
80
<td>
@@ -168,6 +168,10 @@ while subsuming them as part of the usual CompletedCheckpoint management. These
168
168
not covered by the repeatable cleanup, i.e. they have to be deleted manually, still. This is
169
169
covered by [FLINK-26606](https://issues.apache.org/jira/browse/FLINK-26606).
170
170
171
+
The application resource cleanup is similar (see the
@@ -184,14 +188,14 @@ Flink can execute applications in two modes:
184
188
185
189
#### Application Mode
186
190
187
-
In all the other modes, the application's `main()` method is executed on the client side. This process
191
+
If the application's `main()` method is executed on the client side, this process
188
192
includes downloading the application's dependencies locally, executing the `main()` to extract a representation
189
193
of the application that Flink's runtime can understand (i.e. the `JobGraph`) and ship the dependencies and
190
194
the `JobGraph(s)` to the cluster. This makes the Client a heavy resource consumer as it may need substantial
191
195
network bandwidth to download dependencies and ship binaries to the cluster, and CPU cycles to execute the
192
196
`main()`. This problem can be more pronounced when the Client is shared across users.
193
197
194
-
Building on this observation, the *Application Mode* creates a cluster per submitted application, but this time,
198
+
Building on this observation, the *Application Mode* creates a cluster per submitted application, and
195
199
the `main()` method of the application is executed on the JobManager. Creating a cluster per application can be
196
200
seen as creating a session cluster shared only among the jobs of a particular application, and torn down when
197
201
the application finishes. With this architecture, the *Application Mode* provides the application granularity resource isolation
@@ -213,12 +217,14 @@ execution of the "next" job being postponed until "this" job finishes. Using `e
213
217
non-blocking, will lead to the "next" job starting before "this" job finishes.
214
218
215
219
{{< hint warning >}}
216
-
The Application Mode allows for multi-`execute()` applications but
217
-
High-Availability is not supported in these cases. High-Availability in Application Mode is only
218
-
supported for single-`execute()` applications.
219
-
220
-
Additionally, when any of multiple running jobs in Application Mode (submitted for example using
221
-
`executeAsync()`) gets cancelled, all jobs will be stopped and the JobManager will shut down.
220
+
The Application Mode allows for multi-job applications (by calling `execute()` or `executeAsync()` multiple times in the `main()` method) but
221
+
High-Availability is limited in these cases. High-Availability in Application Mode is only
222
+
supported for applications with a single streaming job or multiple batch jobs.
223
+
For more details, see [FLIP-560](https://cwiki.apache.org/confluence/display/FLINK/FLIP-560%3A+Application+Capability+Enhancement).
224
+
225
+
Additionally, when any of multiple running jobs in Application Mode (submitted for example using
226
+
`executeAsync()`) gets cancelled, all jobs will be stopped and the JobManager will shut down by default.
227
+
This behavior can be configured through the [`execution.terminate-application-on-any-job-terminated-exceptionally`]({{< ref "docs/deployment/config" >}}#execution-terminate-application-on-any-job-terminated-exceptionally) option.
222
228
Regular job completions (by the sources shutting down) are supported.
223
229
{{< /hint >}}
224
230
@@ -234,13 +240,21 @@ restarting jobs accessing the filesystem concurrently and making it unavailable
234
240
Additionally, having a single cluster running multiple jobs implies more load for the JobManager, who
235
241
is responsible for the book-keeping of all the jobs in the cluster.
236
242
243
+
In Session Mode, the application's `main()` method can be executed either on the client or on the cluster.
244
+
When submitting applications via Command-Line Interface (CLI) or the SQL Client, the `main()` method is executed on the client.
245
+
However, when submitting applications via the REST API `/jars/:jarid/run-application`,
246
+
the `main()` method is executed on the cluster.
247
+
This provides the same benefits as Application Mode in terms of resource usage and network bandwidth for the client,
248
+
while still maintaining the shared cluster resource model of Session Mode.
237
249
238
250
#### Summary
239
251
240
-
In *Session Mode*, the cluster lifecycle is independent of that of any job running on the cluster
241
-
and the resources are shared across all jobs. The
242
-
*Application Mode* creates a session cluster per application and executes the application's `main()`
252
+
In *Session Mode*, the cluster lifecycle is independent of that of any application running on the cluster
253
+
and the resources are shared across all applications. The application's `main()` method can be executed either on the client or on the cluster.
254
+
*Application Mode* creates a session cluster per application and executes the application's `main()`
243
255
method on the cluster.
256
+
It thus comes with better resource isolation as the resources are only used by the job(s) launched from a single `main()` method.
257
+
This comes at the price of spinning up a dedicated cluster for each application.
0 commit comments