Skip to main content
The Sparks Job API is a set of endpoints for configuring and running Spark jobs. For more information, view the API specification.

Spark job subtypes

For the Spark job type, the available subtypes are listed below.
  • SQL Aggregation job
    A Spark SQL aggregation job where user-defined parameters are injected into a built-in SQL template at runtime.
  • Custom Python job
    The Custom Python job provides user the ability to run Python code via Fusion. This job supports Python 3.6+ code.
  • Script
    This job lets you run a custom Scala script in Fusion.
To create a Script job, sign in to Fusion and click Collections > Jobs. Then click Add+ and in the Custom and Others Jobs section, select Script. You can enter basic and advanced parameters to configure the job. If the field has a default value, it is populated when you click to add the job.

Basic parameters

To enter advanced parameters in the UI, click Advanced. Those parameters are described in the advanced parameters section.
  • Spark job ID. The unique ID for the Spark job that references this job in the API. This is the id field in the configuration file. Required field.
  • Scala script. The Scala script to be executed in Fusion as a Spark job. This is the script field in the configuration file.

Advanced parameters

If you click the Advanced toggle, the following optional fields are displayed in the UI.
  • Spark Settings. This section lets you enter parameter name:parameter value options to use for Spark configuration. This is the sparkConfig field in the configuration file.
  • Spark shell options. This section lets you enter parameter name:parameter value options to send to the Spark shell when the job is run. This is the shellOptions field in the configuration file.
  • Interpreter params. This section lets you enter parameter name:parameter value options to bind the key:value pairs to the Scala interpreter. This is the interpreterParams field in the configuration file.
See Additional Spark jobs for more information.

Spark Configuration Properties

Fusion passes all configuration properties with prefix “spark.” to the Spark master, Spark worker and each Spark application, both for aggregation jobs and custom-scripted processing. These properties are stored in Fusion’s ZooKeeper and can be updated via requests to Fusion endpoint api/configurations which will update the stored value without restarting the service, therefore existing jobs and SparkContexts will not be affected. The Fusion endpoint api/configurations returns all configured properties for that installation. You can examine spark default configurations in a Unix shell using the utilities curl and grep. Here is an example that checks a local Fusion installation running on port FUSION_PORT:
The default SparkContext that Fusion uses for aggregation jobs can be assigned a fraction of cluster resources (executor memory and/or available CPU cores). This allows other applications (such as scripted jobs, or shell sessions) to use the remaining cluster resources even when some aggregation jobs are running. Fusion also supports dynamic allocation for all applications. This can be overridden per application. In practice, this means that even when there is an already running SparkContext with a relatively long idle time (eg. 10 minutes) but there are no active jobs that use it, its resources (CPU cores and executor memory) will be released for use by other applications. For scripted Spark jobs, users can specify per-job configuration overrides as a set of key / value pairs in a “sparkConfig” property element of a script job configuration, which takes precedence over values stored in ZooKeeper. The following is an example of a scripted job with a “sparkConfig” section:
The following table lists those Spark configuration properties that Fusion overrides or uses in order to determine applications’ resource allocations.

Fusion Configuration Properties