## What changes were proposed in this pull request? Add AL2 license to metadata of all .md files. This seemed to be the tidiest way as it will get ignored by .md renderers and other tools. Attempts to write them as markdown comments revealed that there is no such standard thing. ## How was this patch tested? Doc build Closes #24243 from srowen/SPARK-26918. Authored-by: Sean Owen <sean.owen@databricks.com> Signed-off-by: Sean Owen <sean.owen@databricks.com>
153 lines
7.1 KiB
Markdown
153 lines
7.1 KiB
Markdown
---
|
|
layout: global
|
|
title: Cluster Mode Overview
|
|
license: |
|
|
Licensed to the Apache Software Foundation (ASF) under one or more
|
|
contributor license agreements. See the NOTICE file distributed with
|
|
this work for additional information regarding copyright ownership.
|
|
The ASF licenses this file to You under the Apache License, Version 2.0
|
|
(the "License"); you may not use this file except in compliance with
|
|
the License. You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
---
|
|
|
|
This document gives a short overview of how Spark runs on clusters, to make it easier to understand
|
|
the components involved. Read through the [application submission guide](submitting-applications.html)
|
|
to learn about launching applications on a cluster.
|
|
|
|
# Components
|
|
|
|
Spark applications run as independent sets of processes on a cluster, coordinated by the `SparkContext`
|
|
object in your main program (called the _driver program_).
|
|
|
|
Specifically, to run on a cluster, the SparkContext can connect to several types of _cluster managers_
|
|
(either Spark's own standalone cluster manager, Mesos or YARN), which allocate resources across
|
|
applications. Once connected, Spark acquires *executors* on nodes in the cluster, which are
|
|
processes that run computations and store data for your application.
|
|
Next, it sends your application code (defined by JAR or Python files passed to SparkContext) to
|
|
the executors. Finally, SparkContext sends *tasks* to the executors to run.
|
|
|
|
<p style="text-align: center;">
|
|
<img src="img/cluster-overview.png" title="Spark cluster components" alt="Spark cluster components" />
|
|
</p>
|
|
|
|
There are several useful things to note about this architecture:
|
|
|
|
1. Each application gets its own executor processes, which stay up for the duration of the whole
|
|
application and run tasks in multiple threads. This has the benefit of isolating applications
|
|
from each other, on both the scheduling side (each driver schedules its own tasks) and executor
|
|
side (tasks from different applications run in different JVMs). However, it also means that
|
|
data cannot be shared across different Spark applications (instances of SparkContext) without
|
|
writing it to an external storage system.
|
|
2. Spark is agnostic to the underlying cluster manager. As long as it can acquire executor
|
|
processes, and these communicate with each other, it is relatively easy to run it even on a
|
|
cluster manager that also supports other applications (e.g. Mesos/YARN).
|
|
3. The driver program must listen for and accept incoming connections from its executors throughout
|
|
its lifetime (e.g., see [spark.driver.port in the network config
|
|
section](configuration.html#networking)). As such, the driver program must be network
|
|
addressable from the worker nodes.
|
|
4. Because the driver schedules tasks on the cluster, it should be run close to the worker
|
|
nodes, preferably on the same local area network. If you'd like to send requests to the
|
|
cluster remotely, it's better to open an RPC to the driver and have it submit operations
|
|
from nearby than to run a driver far away from the worker nodes.
|
|
|
|
# Cluster Manager Types
|
|
|
|
The system currently supports several cluster managers:
|
|
|
|
* [Standalone](spark-standalone.html) -- a simple cluster manager included with Spark that makes it
|
|
easy to set up a cluster.
|
|
* [Apache Mesos](running-on-mesos.html) -- a general cluster manager that can also run Hadoop MapReduce
|
|
and service applications.
|
|
* [Hadoop YARN](running-on-yarn.html) -- the resource manager in Hadoop 2.
|
|
* [Kubernetes](running-on-kubernetes.html) -- an open-source system for automating deployment, scaling,
|
|
and management of containerized applications.
|
|
|
|
A third-party project (not supported by the Spark project) exists to add support for
|
|
[Nomad](https://github.com/hashicorp/nomad-spark) as a cluster manager.
|
|
|
|
# Submitting Applications
|
|
|
|
Applications can be submitted to a cluster of any type using the `spark-submit` script.
|
|
The [application submission guide](submitting-applications.html) describes how to do this.
|
|
|
|
# Monitoring
|
|
|
|
Each driver program has a web UI, typically on port 4040, that displays information about running
|
|
tasks, executors, and storage usage. Simply go to `http://<driver-node>:4040` in a web browser to
|
|
access this UI. The [monitoring guide](monitoring.html) also describes other monitoring options.
|
|
|
|
# Job Scheduling
|
|
|
|
Spark gives control over resource allocation both _across_ applications (at the level of the cluster
|
|
manager) and _within_ applications (if multiple computations are happening on the same SparkContext).
|
|
The [job scheduling overview](job-scheduling.html) describes this in more detail.
|
|
|
|
# Glossary
|
|
|
|
The following table summarizes terms you'll see used to refer to cluster concepts:
|
|
|
|
<table class="table">
|
|
<thead>
|
|
<tr><th style="width: 130px;">Term</th><th>Meaning</th></tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>Application</td>
|
|
<td>User program built on Spark. Consists of a <em>driver program</em> and <em>executors</em> on the cluster.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Application jar</td>
|
|
<td>
|
|
A jar containing the user's Spark application. In some cases users will want to create
|
|
an "uber jar" containing their application along with its dependencies. The user's jar
|
|
should never include Hadoop or Spark libraries, however, these will be added at runtime.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Driver program</td>
|
|
<td>The process running the main() function of the application and creating the SparkContext</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Cluster manager</td>
|
|
<td>An external service for acquiring resources on the cluster (e.g. standalone manager, Mesos, YARN)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Deploy mode</td>
|
|
<td>Distinguishes where the driver process runs. In "cluster" mode, the framework launches
|
|
the driver inside of the cluster. In "client" mode, the submitter launches the driver
|
|
outside of the cluster.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Worker node</td>
|
|
<td>Any node that can run application code in the cluster</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Executor</td>
|
|
<td>A process launched for an application on a worker node, that runs tasks and keeps data in memory
|
|
or disk storage across them. Each application has its own executors.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Task</td>
|
|
<td>A unit of work that will be sent to one executor</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Job</td>
|
|
<td>A parallel computation consisting of multiple tasks that gets spawned in response to a Spark action
|
|
(e.g. <code>save</code>, <code>collect</code>); you'll see this term used in the driver's logs.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Stage</td>
|
|
<td>Each job gets divided into smaller sets of tasks called <em>stages</em> that depend on each other
|
|
(similar to the map and reduce stages in MapReduce); you'll see this term used in the driver's logs.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|