Skip to content

Commit 151c298

Browse files
author
Neelesh Srinivas Salian
committed
SPARK-3629: Improvement of the Spark on YARN document
1 parent 4f8a155 commit 151c298

File tree

1 file changed

+79
-77
lines changed

1 file changed

+79
-77
lines changed

‎docs/running-on-yarn.md‎

Lines changed: 79 additions & 77 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,53 @@ Support for running on [YARN (Hadoop
77
NextGen)](http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/YARN.html)
88
was added to Spark in version 0.6.0, and improved in subsequent releases.
99

10+
# Launching Spark on YARN
11+
12+
Ensure that `HADOOP_CONF_DIR` or `YARN_CONF_DIR` points to the directory which contains the (client side) configuration files for the Hadoop cluster.
13+
These configs are used to write to the dfs and connect to the YARN ResourceManager. The
14+
configuration contained in this directory will be distributed to the YARN cluster so that all
15+
containers used by the application use the same configuration. If the configuration references
16+
Java system properties or environment variables not managed by YARN, they should also be set in the
17+
Spark application's configuration (driver, executors, and the AM when running in client mode).
18+
19+
There are two deploy modes that can be used to launch Spark applications on YARN. In yarn-cluster mode, the Spark driver runs inside an application master process which is managed by YARN on the cluster, and the client can go away after initiating the application. In yarn-client mode, the driver runs in the client process, and the application master is only used for requesting resources from YARN.
20+
(Default: --deploy-mode client)
21+
22+
Unlike in Spark standalone and Mesos mode, in which the master's address is specified in the "master" parameter, in YARN mode the ResourceManager's address is picked up from the Hadoop configuration. Thus, the master parameter is yarn.
23+
24+
To launch a Spark application in yarn-cluster mode:
25+
26+
./bin/spark-submit --class path.to.your.Class --master yarn-cluster [options] <app jar> [app options]
27+
28+
For example:
29+
30+
$ ./bin/spark-submit --class org.apache.spark.examples.SparkPi \
31+
--master yarn-cluster \
32+
--num-executors 3 \
33+
--driver-memory 4g \
34+
--executor-memory 2g \
35+
--executor-cores 1 \
36+
--queue thequeue \
37+
lib/spark-examples*.jar \
38+
10
39+
40+
The above starts a YARN client program which starts the default Application Master. Then SparkPi will be run as a child thread of Application Master. The client will periodically poll the Application Master for status updates and display them in the console. The client will exit once your application has finished running. Refer to the "Debugging your Application" section below for how to see driver and executor logs.
41+
42+
To launch a Spark application in yarn-client mode, do the same, but replace "yarn-cluster" with "yarn-client". To run spark-shell:
43+
44+
$ ./bin/spark-shell --master yarn-client
45+
46+
## Adding Other JARs
47+
48+
In yarn-cluster mode, the driver runs on a different machine than the client, so `SparkContext.addJar` won't work out of the box with files that are local to the client. To make files on the client available to `SparkContext.addJar`, include them with the `--jars` option in the launch command.
49+
50+
$ ./bin/spark-submit --class my.main.Class \
51+
--master yarn-cluster \
52+
--jars my-other-jar.jar,my-other-other-jar.jar
53+
my-main-jar.jar
54+
app_arg1 app_arg2
55+
56+
1057
# Preparations
1158

1259
Running Spark-on-YARN requires a binary distribution of Spark which is built with YARN support.
@@ -17,6 +64,38 @@ To build Spark yourself, refer to [Building Spark](building-spark.html).
1764

1865
Most of the configs are the same for Spark on YARN as for other deployment modes. See the [configuration page](configuration.html) for more information on those. These are configs that are specific to Spark on YARN.
1966

67+
# Debugging your Application
68+
69+
In YARN terminology, executors and application masters run inside "containers". YARN has two modes for handling container logs after an application has completed. If log aggregation is turned on (with the `yarn.log-aggregation-enable` config), container logs are copied to HDFS and deleted on the local machine. These logs can be viewed from anywhere on the cluster with the "yarn logs" command.
70+
71+
yarn logs -applicationId <app ID>
72+
73+
will print out the contents of all log files from all containers from the given application. You can also view the container log files directly in HDFS using the HDFS shell or API. The directory where they are located can be found by looking at your YARN configs (`yarn.nodemanager.remote-app-log-dir` and `yarn.nodemanager.remote-app-log-dir-suffix`).
74+
75+
When log aggregation isn't turned on, logs are retained locally on each machine under `YARN_APP_LOGS_DIR`, which is usually configured to `/tmp/logs` or `$HADOOP_HOME/logs/userlogs` depending on the Hadoop version and installation. Viewing logs for a container requires going to the host that contains them and looking in this directory. Subdirectories organize log files by application ID and container ID.
76+
77+
To review per-container launch environment, increase `yarn.nodemanager.delete.debug-delay-sec` to a
78+
large value (e.g. 36000), and then access the application cache through `yarn.nodemanager.local-dirs`
79+
on the nodes on which containers are launched. This directory contains the launch script, JARs, and
80+
all environment variables used for launching each container. This process is useful for debugging
81+
classpath problems in particular. (Note that enabling this requires admin privileges on cluster
82+
settings and a restart of all node managers. Thus, this is not applicable to hosted clusters).
83+
84+
To use a custom log4j configuration for the application master or executors, there are two options:
85+
86+
- upload a custom `log4j.properties` using `spark-submit`, by adding it to the `--files` list of files
87+
to be uploaded with the application.
88+
- add `-Dlog4j.configuration=<location of configuration file>` to `spark.driver.extraJavaOptions`
89+
(for the driver) or `spark.executor.extraJavaOptions` (for executors). Note that if using a file,
90+
the `file:` protocol should be explicitly provided, and the file needs to exist locally on all
91+
the nodes.
92+
93+
Note that for the first option, both executors and the application master will share the same
94+
log4j configuration, which may cause issues when they run on the same node (e.g. trying to write
95+
to the same log file).
96+
97+
If you need a reference to the proper location to put log files in the YARN so that YARN can properly display and aggregate them, use `spark.yarn.app.container.log.dir` in your log4j.properties. For example, `log4j.appender.file_appender.File=${spark.yarn.app.container.log.dir}/spark.log`. For streaming application, configuring `RollingFileAppender` and setting file location to YARN's log directory will avoid disk overflow caused by large log file, and logs can be accessed using YARN's log utility.
98+
2099
#### Spark Properties
21100

22101
<table class="table">
@@ -222,83 +301,6 @@ Most of the configs are the same for Spark on YARN as for other deployment modes
222301
</tr>
223302
</table>
224303

225-
# Launching Spark on YARN
226-
227-
Ensure that `HADOOP_CONF_DIR` or `YARN_CONF_DIR` points to the directory which contains the (client side) configuration files for the Hadoop cluster.
228-
These configs are used to write to the dfs and connect to the YARN ResourceManager. The
229-
configuration contained in this directory will be distributed to the YARN cluster so that all
230-
containers used by the application use the same configuration. If the configuration references
231-
Java system properties or environment variables not managed by YARN, they should also be set in the
232-
Spark application's configuration (driver, executors, and the AM when running in client mode).
233-
234-
There are two deploy modes that can be used to launch Spark applications on YARN. In yarn-cluster mode, the Spark driver runs inside an application master process which is managed by YARN on the cluster, and the client can go away after initiating the application. In yarn-client mode, the driver runs in the client process, and the application master is only used for requesting resources from YARN.
235-
236-
Unlike in Spark standalone and Mesos mode, in which the master's address is specified in the "master" parameter, in YARN mode the ResourceManager's address is picked up from the Hadoop configuration. Thus, the master parameter is simply "yarn-client" or "yarn-cluster".
237-
238-
To launch a Spark application in yarn-cluster mode:
239-
240-
./bin/spark-submit --class path.to.your.Class --master yarn-cluster [options] <app jar> [app options]
241-
242-
For example:
243-
244-
$ ./bin/spark-submit --class org.apache.spark.examples.SparkPi \
245-
--master yarn-cluster \
246-
--num-executors 3 \
247-
--driver-memory 4g \
248-
--executor-memory 2g \
249-
--executor-cores 1 \
250-
--queue thequeue \
251-
lib/spark-examples*.jar \
252-
10
253-
254-
The above starts a YARN client program which starts the default Application Master. Then SparkPi will be run as a child thread of Application Master. The client will periodically poll the Application Master for status updates and display them in the console. The client will exit once your application has finished running. Refer to the "Debugging your Application" section below for how to see driver and executor logs.
255-
256-
To launch a Spark application in yarn-client mode, do the same, but replace "yarn-cluster" with "yarn-client". To run spark-shell:
257-
258-
$ ./bin/spark-shell --master yarn-client
259-
260-
## Adding Other JARs
261-
262-
In yarn-cluster mode, the driver runs on a different machine than the client, so `SparkContext.addJar` won't work out of the box with files that are local to the client. To make files on the client available to `SparkContext.addJar`, include them with the `--jars` option in the launch command.
263-
264-
$ ./bin/spark-submit --class my.main.Class \
265-
--master yarn-cluster \
266-
--jars my-other-jar.jar,my-other-other-jar.jar
267-
my-main-jar.jar
268-
app_arg1 app_arg2
269-
270-
# Debugging your Application
271-
272-
In YARN terminology, executors and application masters run inside "containers". YARN has two modes for handling container logs after an application has completed. If log aggregation is turned on (with the `yarn.log-aggregation-enable` config), container logs are copied to HDFS and deleted on the local machine. These logs can be viewed from anywhere on the cluster with the "yarn logs" command.
273-
274-
yarn logs -applicationId <app ID>
275-
276-
will print out the contents of all log files from all containers from the given application. You can also view the container log files directly in HDFS using the HDFS shell or API. The directory where they are located can be found by looking at your YARN configs (`yarn.nodemanager.remote-app-log-dir` and `yarn.nodemanager.remote-app-log-dir-suffix`).
277-
278-
When log aggregation isn't turned on, logs are retained locally on each machine under `YARN_APP_LOGS_DIR`, which is usually configured to `/tmp/logs` or `$HADOOP_HOME/logs/userlogs` depending on the Hadoop version and installation. Viewing logs for a container requires going to the host that contains them and looking in this directory. Subdirectories organize log files by application ID and container ID.
279-
280-
To review per-container launch environment, increase `yarn.nodemanager.delete.debug-delay-sec` to a
281-
large value (e.g. 36000), and then access the application cache through `yarn.nodemanager.local-dirs`
282-
on the nodes on which containers are launched. This directory contains the launch script, JARs, and
283-
all environment variables used for launching each container. This process is useful for debugging
284-
classpath problems in particular. (Note that enabling this requires admin privileges on cluster
285-
settings and a restart of all node managers. Thus, this is not applicable to hosted clusters).
286-
287-
To use a custom log4j configuration for the application master or executors, there are two options:
288-
289-
- upload a custom `log4j.properties` using `spark-submit`, by adding it to the `--files` list of files
290-
to be uploaded with the application.
291-
- add `-Dlog4j.configuration=<location of configuration file>` to `spark.driver.extraJavaOptions`
292-
(for the driver) or `spark.executor.extraJavaOptions` (for executors). Note that if using a file,
293-
the `file:` protocol should be explicitly provided, and the file needs to exist locally on all
294-
the nodes.
295-
296-
Note that for the first option, both executors and the application master will share the same
297-
log4j configuration, which may cause issues when they run on the same node (e.g. trying to write
298-
to the same log file).
299-
300-
If you need a reference to the proper location to put log files in the YARN so that YARN can properly display and aggregate them, use `spark.yarn.app.container.log.dir` in your log4j.properties. For example, `log4j.appender.file_appender.File=${spark.yarn.app.container.log.dir}/spark.log`. For streaming application, configuring `RollingFileAppender` and setting file location to YARN's log directory will avoid disk overflow caused by large log file, and logs can be accessed using YARN's log utility.
301-
302304
# Important notes
303305

304306
- Whether core requests are honored in scheduling decisions depends on which scheduler is in use and how it is configured.

0 commit comments

Comments
 (0)