Foresight is a deadline-oriented resource optimizer for SparkSQL applications. It leverages the stage-level information from the DAGs of a small number of SparkSQL queries to build a performance model to accurately predict the execution time of unseen queries. As such, a provider can correctly answer whether the deadline of an unseen SparkSQL application can be met.
Moreover, Foresight employs a critical-path based approach to optimize the CPU resources and a stage input/output data size based method to optimize the memory resources of a SparkSQL application.
In general, Foresight consists of five components: data size predictor (DSP), stage performance predictor (SPP), stage memory predictor (SMP), CPU resource opti- mizer (CRO), and memory resource optimizer (MRO).
We implement Foresight with python 3.9.
Since Foresight focuses on predicting deadline violation of Spark SQL in a cluster. Please install the Spark 3.4.5 and hadoop 3.3.2 in the cluster following the two links below.
- Spark 3.4.5. https://spark.apache.org/docs/latest/
- Hadoop 3.3.2 http://apache.github.io/hadoop/hadoop-project-dist/hadoop-common/ClusterSetup.html
To run the python scripts of Foresight, please install the third-party libraries.
pip install -r requirements.txt
We use the version of TPC-DS v3 of SparkSQL queries to evaluate Foresight.
The following links shows the instruction to generate 100 GB and 500 GB datasets for TPC-DS.
https://github.com/xinjinhan/BaBench
The entry of Foresight the script "foresight_main.py". There are three parameters for this scritpt. The first is the deadline,
python3 foresight_main.py --deadline 3 --query 91 --datasize 500
Foresight will iterate all possible CPU cores in the cluster to explore whether the deadline of the specified query can be met.
If there is no deadline violation, Foresight will output the following message sigifying a success.
"The deadline can be met.
The predicted runtime by Foresight is 112 seconds, which is less than the deadline 180 seconds."
Otherwise, Foresight will report a deadline violation as follows.
"A deadline violation"
Both DSP and SSP leverage the stage-level information and machine learning algorithms to build their respective models. We provide a number of training samples to show how to train them. The details can be found in first_stage_performance_model.py and normal_stage_performance_model.py.
This script (analytical_memory_executor.py) introduces the analytical model of memory optimizer.
The details of CRO and MRO are implemented in the file called foresight_main.py.
This script is to perform the stage-level performance prediction for a given Query with varying executor counts (i.e., CPU cores) to see if the deadline of it can be satisfied. Plus, if the deadline can be satisfied, Foresight ouputs the minimum exeuctor count (i.e., minimum CPU cores) accordingly.
To be specific, the function predict_runtime (Line 173) is the online usage of Foresight. If the predicted runtime is below the user specified deadline, Foresight reports the optimized amount of CPU and resource resources as well. Lines 173-256 corresponds to extract the DAG comprising a number of stages from the physical plan of a query.
In practice, the Algorithm 1 (Predicting Output Datasize of Each Stage) and Algorithm 2 ( Optimizing CPU resources of a SparkSQL Query) can be coalesced into a function from Lines 451 - 484.
This script introduces the analytical model of memory optimizer for a SparkSQL application, which is used in the "foresight_stage_level_prediction_varying_resources.py" above.
the performance prediction for the first stage which includes the aggregate operators.
the performance prediction for the first stage which excludes the aggregate operators. the first stage also maps to the initial stages called in our paper.
the performance prediction for the normal stages.
generating the corresponding DAG comprising a number of stages from the physical plan of a query. getting the depth, dag_width, stage_count, predicted_runtime, operators dictionary of each query. Foresight: Runtime prediction for a query.
generating one sql according to the physical plan.