Module Contents

class airflow.contrib.hooks.spark_submit_hook.SparkSubmitHook(conf=None, conn_id='spark_default', files=None, py_files=None, archives=None, driver_class_path=None, jars=None, java_class=None, packages=None, exclude_packages=None, repositories=None, total_executor_cores=None, executor_cores=None, executor_memory=None, driver_memory=None, keytab=None, principal=None, proxy_user=None, name='default-name', num_executors=None, status_poll_interval=1, application_args=None, env_vars=None, verbose=False, spark_binary=None)[source]

Bases: airflow.hooks.base_hook.BaseHook, airflow.utils.log.logging_mixin.LoggingMixin

This hook is a wrapper around the spark-submit binary to kick off a spark-submit job. It requires that the “spark-submit” binary is in the PATH or the spark_home to be supplied.

  • conf (dict) – Arbitrary Spark configuration properties

  • conn_id (str) – The connection id as configured in Airflow administration. When an invalid connection_id is supplied, it will default to yarn.

  • files (str) – Upload additional files to the executor running the job, separated by a comma. Files will be placed in the working directory of each executor. For example, serialized objects.

  • py_files (str) – Additional python files used by the job, can be .zip, .egg or .py.

  • driver_class_path (str) – Additional, driver-specific, classpath settings.

  • jars (str) – Submit additional jars to upload and place them in executor classpath.

  • java_class (str) – the main class of the Java application

  • packages (str) – Comma-separated list of maven coordinates of jars to include on the driver and executor classpaths

  • exclude_packages (str) – Comma-separated list of maven coordinates of jars to exclude while resolving the dependencies provided in ‘packages’

  • repositories (str) – Comma-separated list of additional remote repositories to search for the maven coordinates given with ‘packages’

  • total_executor_cores (int) – (Standalone & Mesos only) Total cores for all executors (Default: all the available cores on the worker)

  • executor_cores (int) – (Standalone, YARN and Kubernetes only) Number of cores per executor (Default: 2)

  • executor_memory (str) – Memory per executor (e.g. 1000M, 2G) (Default: 1G)

  • driver_memory (str) – Memory allocated to the driver (e.g. 1000M, 2G) (Default: 1G)

  • keytab (str) – Full path to the file that contains the keytab

  • principal (str) – The name of the kerberos principal used for keytab

  • proxy_user (str) – User to impersonate when submitting the application

  • name (str) – Name of the job (default airflow-spark)

  • num_executors (int) – Number of executors to launch

  • status_poll_interval (int) – Seconds to wait between polls of driver status in cluster mode (Default: 1)

  • application_args (list) – Arguments for the application being submitted

  • env_vars (dict) – Environment variables for spark-submit. It supports yarn and k8s mode too.

  • verbose (bool) – Whether to pass the verbose flag to spark-submit process for debugging

  • spark_binary (str) – The command to use for spark submit. Some distros may use spark2-submit.


archives: Archives that spark should unzip (and possibly tag with #ALIAS) into the application working directory.


Determines whether or not this hook should poll the spark driver status through subsequent spark-submit status requests after the initial spark-submit request :return: if the driver status should be tracked

_mask_cmd(self, connection_cmd)[source]
_build_spark_submit_command(self, application)[source]

Construct the spark-submit command to execute.


application (str) – command to append to the spark-submit command


full command to be executed


Construct the command to poll the driver status.


full command to be executed

submit(self, application='', **kwargs)[source]

Remote Popen to execute the spark-submit job

  • application (str) – Submitted application, jar or py file

  • kwargs – extra arguments to Popen (see subprocess.Popen)

_process_spark_submit_log(self, itr)[source]

Processes the log files and extracts useful information out of it.

If the deploy-mode is ‘client’, log the output of the submit command as those are the output logs of the Spark worker directly.

Remark: If the driver needs to be tracked for its status, the log-level of the spark deploy needs to be at least INFO (


itr – An iterator which iterates over the input of the subprocess

_process_spark_status_log(self, itr)[source]

parses the logs of the spark driver status query process


itr – An iterator which iterates over the input of the subprocess


Polls the driver based on self._driver_id to get the status. Finish successfully when the status is FINISHED. Finish failed when the status is ERROR/UNKNOWN/KILLED/FAILED.

Possible status:


Submitted but not yet scheduled on a worker


Has been allocated to a worker to run


Previously ran and exited cleanly


Exited non-zero or due to worker failure, but has not yet started running again


The status of the driver is temporarily not known due to master failure recovery


A user manually killed this driver


The driver exited non-zero and was not supervised


Unable to run or restart due to an unrecoverable error (e.g. missing jar file)


Construct the spark-submit command to kill a driver. :return: full command to kill a driver


Was this entry helpful?