Design principles
To ensure efficient and robust execution of Spark jobs, the spark-submit process within ModelOp Center has been meticulously designed and architected. The following principles and features have been incorporated to optimize the integration and operation of Spark jobs in both local and cluster deploy modes:
Code Implementation: Whenever possible, implement Python and/or PySpark components using Python. This approach ensures easier testing and debugging in both local and cluster deploy modes.
Job Monitoring: The spark-runtime-service monitors jobs in the WAITING and RUNNING states until they reach COMPLETE, ERROR, or CANCELLED states. Any detected changes in job status will trigger updates in the model manager.
Job Submission Process: Before submitting a job to the Spark cluster, the ModelOpPySparkDriver extracts
inputData
,outputData
, andstoredModel.modelAssets
from the MODEL_BATCH_JOB, MODEL_BATCH_TEST_JOB, or MODEL_BATCH_TRAINING_JOB and passes them as parameters to the function to be executed. These external file assets are provided as lists of assets:input_data
– [{"filename": "test.csv", "assetType": "EXTERNAL_FILE", "fileUrl": "hdfs:///hadoop/test.csv"}]output_data
– [{"filename": "output.csv", "assetType": "EXTERNAL_FILE", "fileUrl": "hdfs:///hadoop/output.csv"}]
Logging: The YarnMonitorService component listens for and stores the stdout and stderr outputs produced by the running job on the Spark cluster. The storage of stdout and stderr in jobMessages is configurable.
Architecture Overview
The following diagram represents a high level overview on how core components interact with each other, when a Spark job is submitted to the cluster.
Pre spark submit process flow
The following diagram illustrates the transformation process from a ModelOp Center Batch job into a SparkLauncher:
Monitoring Spark jobs
ModelOp Center has a component called ModelOpJobMonitor
in charge of:
Submitting jobs to the
Spark
clusterMonitoring job statuses
In order to successfully fulfill these responsibilities, it relies on three key services:
SparkLauncherService
– component in charge of translating jobs intoSparkLauncher
objectsYarnMonitorService
– component in charge of fetching job statuses and output produced from theSpark
clusterKerberizedYarnMonitorService
– component that is an instance ofYarnMonitorService
and in charge of authenticating the principal withKerberos
before delegating control toYarnMonitorService
Supported Spark jobs types
Scoring jobs
Metrics jobs - these jobs produce a
ModelTestResult
PySpark Job Inputs and Outputs
Spark jobs
support the next two types of input and output assets:
HDFS asset(s) by URL also known as External File asset(s)
Embedded asset(s) also known as File asset(s)
With the next set of rules and restrictions:
Input
Input Assets by URL
When the job includes input HDFS asset(s) by URL, it’s required that all HDFS asset(s) are present and available inside the Spark
cluster before the job is submitted to the Spark
cluster for execution.
Input Data Embedded
When a job includes embedded input data assets, the process will generate temporary HDFS files for each of these embedded assets. These newly created HDFS files will be represented as HDFS assets by their URLs and will be used as input data when the job is submitted to the Spark cluster for execution.
This change from embedded assets to HDFS assets by URL is not visible to the user, as the ModelOp Center Job is not updated to reflect this transformation. Instead, this change is managed internally by the PySparkPreprocessorService.
Output
Output Data by URL
When a job includes predefined output HDFS asset(s) by URL, the job output will be generated and stored at the predefined HDFS file locations.
Output Data Embedded
When the user provides embedded output data assets, the spark-runtime-service will create a temporary HDFS directory for the job if one does not already exist. The following steps are then performed in sequence:
Represent each embedded output data asset as an HDFS asset by URL, where the file URL of the new HDFS asset corresponds to the temporary HDFS directory and the filename matches the original embedded asset.
Update the ModelOp Center job by storing the HDFS assets by URL in its job parameters map, using the key TMP_EXTERNAL_OUTPUT.
Use the newly created HDFS assets by URL as the output data when submitting the job to the Spark cluster for execution.
Download each HDFS asset by URL and store its content as the file content for the corresponding embedded output data asset in the MODEL_BATCH_JOB, MODEL_BATCH_TEST_JOB, or MODEL_BATCH_TRAINING_JOB.
Remove TMP_EXTERNAL_OUTPUT from the job parameters map.
This change from embedded assets to HDFS assets by URL is not visible to the user, as the ModelOp Center Job is not updated to reflect this transformation. Instead, this change is managed internally by the PySparkPreprocessorService.
ModelOpPySparkDriver.py
ModelOp Center utilizes a predefined PySpark class called ModelOpPySparkDriver.py
to manage execution and job orchestration for Spark jobs. This class abstracts the complexity of these processes by taking ModelOp Center Batch Jobs as input and translating them into the necessary format for job execution.