Akamas Docs
3.2.0
Search
⌃K

Optimizing a Spark application

In this example study we’ll tune the parameters of SparkPi, one of the examples applications provided by most of the Apache Spark distributions, to minimize its execution time. Application monitoring is provided by the Spark History Server APIs.

Environment setup

The test environment includes the following instances:
  • Akamas: instance running Akamas
  • Spark cluster: composed of instances with 16 vCPUs and 64 GB of memory, where the Spark binaries are installed under /usr/lib/spark. In particular, the roles are:
    • 1x master instance: the Spark node running the resource manager and Spark History Server (host: sparkmaster.akamas.io)
    • 2x worker instances: the other instances in the cluster

Telemetry Infrastructure setup

To gather metrics about the application we will leverage the Spark History Server. If it is not already running, start it on the master instance with the following command:
/usr/lib/spark/sbin/start-history-server.sh

Application and Test tools

To make sure the tested application is available on your cluster and runs correctly, execute the following commands:
file /usr/lib/spark/examples/jars/spark-examples.jar
spark-submit \
--master yarn --deploy-mode client \
--class 'org.apache.spark.examples.SparkPi' \
/usr/lib/spark/examples/jars/spark-examples.jar 100

Optimization setup

In this section, we will guide you through the steps required to set up on Akamas the optimization of the Spark application execution.

System

System spark

Here’s the definition of the system we will use to group our components and telemetry instances for this example:
1
name: spark
2
description: A system to tune the Spark Pi example application
To create the system run the following command:
akamas create system system.yaml

Component sparkPi

We’ll use a component of type Spark Application 2.3.0 to represent the application running on the Apache Spark framework 2.3.
In the snippet shown below, we specify:
  • the field properties required by Akamas to connect via SSH to the cluster master instance
  • the parameters required by spark-submit to execute the application
  • the sparkApplication flag required by the telemetry instance to associate the metrics from the History Server to this component
1
name: sparkPi
2
description: The Spark Application used to calculate KPIs for ContentWise Analytics
3
componentType: Spark Application 2.3.0
4
5
properties:
6
hostname: sparkmaster.akamas.io
7
username: hadoop
8
key: ssh_key
9
10
master: yarn
11
deployMode: client
12
className: org.apache.spark.examples.SparkPi
13
file: /usr/lib/spark/examples/jars/spark-examples.jar
14
args: [ 1000 ]
15
16
sparkApplication: 'true'
To create the component in the system run the following command:
akamas create component sparkPi.yaml spark

Workflow

The workflow used for this study contains only a single stage, where the operator submits the application along with the Spark parameters under test.
Here’s the definition of the workflow:
1
name: Run SparkPi
2
tasks:
3
- name: run application
4
operator: SSHSparkSubmit
5
arguments:
6
component: sparkPi
7
retries: 0
To create the workflow run the following command:
akamas create workflow workflow.yaml

Telemetry

If you have not installed the Spark History Server telemetry provider yet, take a look at the telemetry provider page Spark History Server Provider to proceed with the installation.
Here’s the definition of the component, specifying the History Server endpoint:
1
provider: SparkHistoryServer
2
config:
3
address: sparkmaster.akamas.io
4
port: 18080
5
6
importLevel: job
To create the telemetry instance in the system run the following command:
akamas create telemetry-instance telemetry.yaml spark
This telemetry instance will be able to bind the fetched metrics to the related sparkPi component thanks to the sparkApplication attribute we previously added in its definition.

Study

The goal of this study is to find a Spark configuration that minimizes the execution time for the example application.
To achieve this goal we’ll operate on the number of executor processes available to run the application job, and the memory and CPUs allocated for both driver and executors. The domains are configured so that the single driver/executor process does not exceed the size of the underlying instance, and the constraints make it so that the application overall does not require more resources than the ones available in the cluster, also taking into account that some resources must be reserved for other services such as the cluster manager.
Note that this study uses two constraints on the total number of resources to be used by the spark application. This example refers to a cluster of three nodes with 16 cores and 64 GB of memory each, and at least one core per instance should be reserved for the system.
Here’s the definition of the study:
1
name: Speedup SparkPi execution
2
system: spark
3
workflow: Run SparkPi
4
5
goal:
6
objective: minimize
7
function:
8
formula: sparkPi.spark_application_duration
9
10
parametersSelection:
11
- name: sparkPi.driverCores
12
domain: [1, 10]
13
- name: sparkPi.driverMemory
14
domain: [32, 2048]
15
- name: sparkPi.executorCores
16
domain: [1, 15]
17
- name: sparkPi.executorMemory
18
domain: [32, 2048]
19
- name: sparkPi.numExecutors
20
domain: [1, 45]
21
22
parameterConstraints:
23
- name: cap_total_allocated_cpus
24
formula: (spark.driverCores + spark.executorCores*spark.numExecutors) <= 15*3
25
26
- name: cap_total_allocated_memory
27
formula: (spark.driverMemory + spark.executorMemory*spark.numExecutors) <= 60*3
28
29
steps:
30
- name: baseline
31
type: baseline
32
33
- name: tune
34
type: optimize
35
numberOfExperiments: 200
36
maxFailedExperiments: 200
To create and run the study execute the following commands:
akamas create study study.yaml
akamas start study 'Speedup SparkPi execution'