스파크 본문 내용 번역 : http://spark.apache.org/docs/latest/submitting-applications.html
작성중
Application들 보내기
spark-submit스크립트는 Spark의 bin디렉토리에 있다. 이 스크립트는 cluster에서 application을 실행할때 사용된다.
이것은 공통된 인터페이스를 통해 cluster managers를 지원하는 Spark의 모든곳에서 사용된다. (cluster manager : Standalone, mesos, yarn)
그래서 당신은 각 서버에서 특별하게 당신의 application을 구성할 필요가 없다.
Application의 의존성 묶기
만약 당신의 코드가 다른 프로젝트들을 의존하고 있다면, Spark Cluster에 코드를 배포하기 위해, 너는 너의 application과 함께 그것을 패키지로 만드는게 필요할 것이다. 이것을 위해서, 너의 코드와 그것의 의존성들을 포함한 조립jar (=assembly jar (or “uber” jar))를 만든다. sbt나 Maven 은 조립하는 플러그인을 가지고 있다.
jar를 파일을 만들때, Spark와 Hadoop을 제공된 의존성으로 리스트에 포함시킨다.; 런타임에 cluster manager가 그들을 제공할때까지 이것들은 묶어지지 않아도 된다. 만약 너가 조립된 jar를 가진다면, 너는bin/spark-submit스크립트를 호출하면 된다. jar를 보내는 동안 여기에 보여지기 위해서,
파이썬에선, 너는 application과 함께 배포되어지는 파일들(.py, .zip or .egg)을 추가하기 위해,spark-submit의 --py-files를 사용하면 된다.
만약 여러개의 파이썬 파일을 의존하고 있다면, 그것들을 .zip or .egg 으로 패키징하기를 권장한다.
spark-submit을 이용한 Applications 실행하기
유저의 application이 묶여 있다면, 그것은 bin/spark-submit스크립트를 이용하여 실행할수 있다. 이 스크립트는 spark와 이것의 의존성들과 Spark의 classPath를 셋팅하는 것, 다른 cluster managers, 스파크가 지원하는 배포모드를 제공한다.
--class : application 진입 포인트 ( ex. java라면 main 메소드가 있는 클래스를 작성하면 된다.)
--master : 클러스터의 master URL
--deploy-mode : worker nodes에 너의 driver를 배포할지, 내부에서 외부 client로 보낼지
--conf : key=value 포맷으로 구성된다. space를 포함한 값들은 "큰 따옴표로 작성한다.
application-jar :
application-arguments : main class 실행시 필요한 argument ( 필요하면 작성, 안필요하면 작성안해도 됨)
Submitting Applications
The spark-submit script in Spark’s bin directory is used to launch applications on a cluster. It can use all of Spark’s supported cluster managersthrough a uniform interface so you don’t have to configure your application specially for each one.
Bundling Your Application’s Dependencies
If your code depends on other projects, you will need to package them alongside your application in order to distribute the code to a Spark cluster. To do this, create an assembly jar (or “uber” jar) containing your code and its dependencies. Both sbt and Maven have assembly plugins. When creating assembly jars, list Spark and Hadoop as provided dependencies; these need not be bundled since they are provided by the cluster manager at runtime. Once you have an assembled jar you can call the bin/spark-submit script as shown here while passing your jar.
For Python, you can use the --py-files argument of spark-submit to add .py, .zip or .egg files to be distributed with your application. If you depend on multiple Python files we recommend packaging them into a .zip or .egg.
Launching Applications with spark-submit
Once a user application is bundled, it can be launched using the bin/spark-submit script. This script takes care of setting up the classpath with Spark and its dependencies, and can support different cluster managers and deploy modes that Spark supports:
--class: The entry point for your application (e.g. org.apache.spark.examples.SparkPi)
--master: The master URL for the cluster (e.g. spark://23.195.26.187:7077)
--deploy-mode: Whether to deploy your driver on the worker nodes (cluster) or locally as an external client (client) (default: client) †
--conf: Arbitrary Spark configuration property in key=value format. For values that contain spaces wrap “key=value” in quotes (as shown).
application-jar: Path to a bundled jar including your application and all dependencies. The URL must be globally visible inside of your cluster, for instance, an hdfs:// path or a file:// path that is present on all nodes.
application-arguments: Arguments passed to the main method of your main class, if any
† A common deployment strategy is to submit your application from a gateway machine that is physically co-located with your worker machines (e.g. Master node in a standalone EC2 cluster). In this setup, client mode is appropriate. In client mode, the driver is launched directly within the spark-submit process which acts as a client to the cluster. The input and output of the application is attached to the console. Thus, this mode is especially suitable for applications that involve the REPL (e.g. Spark shell).
Alternatively, if your application is submitted from a machine far from the worker machines (e.g. locally on your laptop), it is common to usecluster mode to minimize network latency between the drivers and the executors. Note that cluster mode is currently not supported for Mesos clusters. Currently only YARN supports cluster mode for Python applications.
For Python applications, simply pass a .py file in the place of <application-jar> instead of a JAR, and add Python .zip, .egg or .py files to the search path with --py-files.
There are a few options available that are specific to the cluster manager that is being used. For example, with a Spark standalone cluster withcluster deploy mode, you can also specify --supervise to make sure that the driver is automatically restarted if it fails with non-zero exit code. To enumerate all such options available to spark-submit, run it with --help. Here are a few examples of common options:
# Run application locally on 8 cores
./bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master local[8]\
/path/to/examples.jar \
100
# Run on a Spark standalone cluster in client deploy mode
./bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master spark://207.184.161.138:7077 \
--executor-memory 20G \
--total-executor-cores 100\
/path/to/examples.jar \
1000
# Run on a Spark standalone cluster in cluster deploy mode with supervise
./bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master spark://207.184.161.138:7077 \
--deploy-mode cluster
--supervise
--executor-memory 20G \
--total-executor-cores 100\
/path/to/examples.jar \
1000
# Run on a YARN clusterexport HADOOP_CONF_DIR=XXX
./bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master yarn \
--deploy-mode cluster \ # can be client for client mode
--executor-memory 20G \
--num-executors 50\
/path/to/examples.jar \
1000
# Run a Python application on a Spark standalone cluster
./bin/spark-submit \
--master spark://207.184.161.138:7077 \
examples/src/main/python/pi.py \
1000
# Run on a Mesos cluster in cluster deploy mode with supervise
./bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master mesos://207.184.161.138:7077 \
--deploy-mode cluster
--supervise
--executor-memory 20G \
--total-executor-cores 100\
http://path/to/examples.jar \
1000
Master URLs
The master URL passed to Spark can be in one of the following formats:
Master URL
Meaning
local
Run Spark locally with one worker thread (i.e. no parallelism at all).
local[K]
Run Spark locally with K worker threads (ideally, set this to the number of cores on your machine).
local[*]
Run Spark locally with as many worker threads as logical cores on your machine.
spark://HOST:PORT
Connect to the given Spark standalone cluster master. The port must be whichever one your master is configured to use, which is 7077 by default.
mesos://HOST:PORT
Connect to the given Mesos cluster. The port must be whichever one your is configured to use, which is 5050 by default. Or, for a Mesos cluster using ZooKeeper, use mesos://zk://.... To submit with --deploy-mode cluster, the HOST:PORT should be configured to connect to the MesosClusterDispatcher.
yarn
Connect to a YARN cluster in client or cluster mode depending on the value of --deploy-mode. The cluster location will be found based on the HADOOP_CONF_DIR or YARN_CONF_DIR variable.
yarn-client
Equivalent to yarn with --deploy-mode client, which is preferred to `yarn-client`
yarn-cluster
Equivalent to yarn with --deploy-mode cluster, which is preferred to `yarn-cluster`
Loading Configuration from a File
The spark-submit script can load default Spark configuration values from a properties file and pass them on to your application. By default it will read options from conf/spark-defaults.conf in the Spark directory. For more detail, see the section on loading default configurations.
Loading default Spark configurations this way can obviate the need for certain flags to spark-submit. For instance, if the spark.master property is set, you can safely omit the --master flag from spark-submit. In general, configuration values explicitly set on a SparkConf take the highest precedence, then flags passed to spark-submit, then values in the defaults file.
If you are ever unclear where configuration options are coming from, you can print out fine-grained debugging information by running spark-submit with the --verbose option.
Advanced Dependency Management
When using spark-submit, the application jar along with any jars included with the --jars option will be automatically transferred to the cluster. Spark uses the following URL scheme to allow different strategies for disseminating jars:
file: - Absolute paths and file:/ URIs are served by the driver’s HTTP file server, and every executor pulls the file from the driver HTTP server.
hdfs:, http:, https:, ftp: - these pull down files and JARs from the URI as expected
local: - a URI starting with local:/ is expected to exist as a local file on each worker node. This means that no network IO will be incurred, and works well for large files/JARs that are pushed to each worker, or shared via NFS, GlusterFS, etc.
Note that JARs and files are copied to the working directory for each SparkContext on the executor nodes. This can use up a significant amount of space over time and will need to be cleaned up. With YARN, cleanup is handled automatically, and with Spark standalone, automatic cleanup can be configured with the spark.worker.cleanup.appDataTtl property.
Users may also include any other dependencies by supplying a comma-delimited list of maven coordinates with --packages. All transitive dependencies will be handled when using this command. Additional repositories (or resolvers in SBT) can be added in a comma-delimited fashion with the flag --repositories. These commands can be used with pyspark, spark-shell, and spark-submit to include Spark Packages.
For Python, the equivalent --py-files option can be used to distribute .egg, .zip and .py libraries to executors.
More Information
Once you have deployed your application, thecluster mode overviewdescribes the components involved in distributed execution, and how to monitor and debug applications.