Gestione delle esecuzioni di processi utilizzando la AWS CLI - Amazon EMR

Gestione delle esecuzioni di processi utilizzando la AWS CLI

In questo argomento viene descritto come gestire le esecuzioni di processo utilizzando la AWS Command Line Interface (AWS CLI).

Invio di un'esecuzione di processo

Invio di un'esecuzione di processo utilizzando un file JSON con parametri specificati

  1. Crea un file start-job-run-request.json e specifica i parametri richiesti per l'esecuzione di processo, come illustrato nel file JSON di esempio seguente. Per ulteriori informazioni sui parametri, consulta Opzioni per la configurazione di un'esecuzione di processo.

    { "name": "myjob", "virtualClusterId": "123456", "executionRoleArn": "iam_role_name_for_job_execution", "releaseLabel": "emr-6.2.0-latest", "jobDriver": { "sparkSubmitJobDriver": { "entryPoint": "entryPoint_location", "entryPointArguments": ["argument1", "argument2", ...], "sparkSubmitParameters": "--class <main_class> --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1" } }, "configurationOverrides": { "applicationConfiguration": [ { "classification": "spark-defaults", "properties": { "spark.driver.memory":"2G" } } ], "monitoringConfiguration": { "persistentAppUI": "ENABLED", "cloudWatchMonitoringConfiguration": { "logGroupName": "my_log_group", "logStreamNamePrefix": "log_stream_prefix" }, "s3MonitoringConfiguration": { "logUri": "s3://my_s3_log_location" } } } }
  2. Utilizza il comando start-job-run con un percorso per il file start-job-run-request.json archiviato localmente o in Amazon S3.

    aws emr-containers start-job-run \ --cli-input-json file://./start-job-run-request.json

Avvio di un'esecuzione di processo utilizzando il comando start-job-run

  • Fornisci tutti i parametri specificati nel comando StartJobRun, come illustrato nell'esempio seguente.

    aws emr-containers start-job-run \ --virtual-cluster-id 123456 \ --name myjob \ --execution-role-arn execution-role-arn \ --release-label emr-6.2.0-latest \ --job-driver '{"sparkSubmitJobDriver": {"entryPoint": "entryPoint_location", "entryPointArguments": ["argument1", "argument2", ...], "sparkSubmitParameters": "--class <main_class> --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"}}' \ --configuration-overrides '{"applicationConfiguration": [{"classification": "spark-defaults", "properties": {"spark.driver.memory": "2G"}}], "monitoringConfiguration": {"cloudWatchMonitoringConfiguration": {"logGroupName": "log_group_name", "logStreamNamePrefix": "log_stream_prefix"}, "persistentAppUI":"ENABLED", "s3MonitoringConfiguration": {"logUri": "s3://my_s3_log_location" }}}'

Opzioni per la configurazione di un'esecuzione di processo

Utilizza le seguenti opzioni per configurare i parametri dell'esecuzione di processo:

  • --execution-role-arn: è necessario fornire un ruolo IAM per eseguire i processi. Per ulteriori informazioni, consulta . Utilizzo dei ruoli di esecuzione dei processi con Amazon EMR su EKS.

  • --release-label: è possibile implementare Amazon EMR su EKS con le versioni Amazon EMR 5.32.0, 6.2.0 e versioni successive. Amazon EMR su EKS non è supportato nelle versioni precedenti di Amazon EMR. Per ulteriori informazioni, consulta . Versioni di rilascio di Amazon EMR su EKS.

  • --job-driver: il driver di processo viene utilizzato per fornire input sul processo principale. Si tratta di un campo di tipo unione in cui è possibile far passare solo uno dei valori per il tipo di processo che si desidera eseguire. I tipi di processo supportati includono:

    • Processi Spark Submit: utilizzati per eseguire un comando tramite Spark Submit. È possibile utilizzare questo tipo di processo per eseguire Scala, Pyspark, SparkR, SparkSQL e qualsiasi altro processo supportato tramite Spark Submit. Questo tipo di processo include i seguenti parametri:

      • Entrypoint: questo è il riferimento HCFS (file system compatibile con Hadoop) al file jar/py principale che si desidera eseguire.

      • EntryPointArguments - Questo è un array di argomenti che si desidera passare al file jar/py principale. Dovrai gestire la lettura di questi parametri con il tuo codice di entrypoint. Ogni argomento nell'array deve essere separato da una virgola.

      • SparkSubmitParameters: questi sono i parametri Spark aggiuntivi che si desidera inviare al processo. Utilizza questo parametro per sovrascrivere le proprietà Spark di default, come la memoria del driver o il numero di executor, tra cui —conf o —class. Per ulteriori informazioni, consulta Avvio delle applicazioni con spark-submit.

  • --configuration-overrides: è possibile sovrascrivere le configurazioni di default per le applicazioni fornendo un oggetto di configurazione. È possibile utilizzare una sintassi abbreviata per fornire la configurazione o è possibile fare riferimento all'oggetto di configurazione in un file JSON. Gli oggetti di configurazione sono composti da una classificazione, proprietà e configurazioni nidificate opzionali. Le proprietà sono costituite dalle impostazioni da ignorare in un dato file. Puoi specificare diverse classificazioni per più applicazioni in un singolo oggetto JSON. Le classificazioni di configurazione disponibili variano a seconda della versione di rilascio di Amazon EMR. Per un elenco delle classificazioni di configurazione disponibili per ciascuna versione di rilascio di Amazon EMR, consulta Versioni di rilascio di Amazon EMR su EKS.

    Se si passa la stessa configurazione nella sostituzione di un'applicazione e nei parametri Spark Submit, i parametri Spark Submit hanno la precedenza. Segue l'elenco completo delle priorità di configurazione, ordinate dalla più alta alla più bassa.

    • Configurazione fornita durante la creazione di SparkSession.

    • Configurazione fornita come parte di sparkSubmitParameters tramite —conf.

    • Configurazione fornita come parte delle sostituzioni dell'applicazione.

    • Configurazioni ottimizzate scelte da Amazon EMR per il rilascio.

    • Configurazioni open source predefinite per l'applicazione.

    Per monitorare le esecuzioni di processi utilizzando Amazon CloudWatch o Amazon S3, occorre fornire i dettagli di configurazione per CloudWatch. Per ulteriori informazioni, consulta Configurazione di un'esecuzione di processo per utilizzare i log S3 e Configurazione di un'esecuzione di processo per utilizzare Amazon CloudWatch Logs. Se il bucket S3 o il gruppo di log CloudWatch non esiste, Amazon EMR lo crea prima di caricare i log nel bucket.

  • Per un elenco aggiuntivo delle opzioni di configurazione di Kubernetes, consulta Proprietà Spark su Kubernetes.

    Le seguenti configurazioni Spark non sono supportate:

    • spark.kubernetes.authenticate.driver.serviceAccountName

    • spark.kubernetes.authenticate.executor.serviceAccountName

    • spark.kubernetes.container.image

    • spark.kubernetes.namespace

    • spark.kubernetes.driver.pod.name

    • spark.kubernetes.container.image.pullPolicy

Configurazione di un'esecuzione di processo per utilizzare i log S3

Per poter monitorare l'avanzamento del processo e risolvere i problemi, è necessario configurare i processi per inviare le informazioni di registro ad Amazon S3, Amazon CloudWatch Logs o entrambi. Questo argomento fornisce le nozioni di base per inviare i log dell'applicazione ad Amazon S3 sui processi avviati con Amazon EMR su EKS.

Policy IAM dei registri S3

Prima che i processi possano inviare i dati dei log ad Amazon S3, nella policy delle autorizzazioni per il ruolo di esecuzione del processo devono essere incluse le seguenti autorizzazioni. Sostituisci DOC-EXAMPLE-BUCKET-LOGGING con il nome del bucket di registrazione.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-BUCKET-LOGGING", "arn:aws:s3:::DOC-EXAMPLE-BUCKET-LOGGING/*", ] } ] }
Nota

Amazon EMR su EKS può anche creare un bucket Amazon S3. Se un bucket Amazon S3 non è disponibile, la policy IAM dovrebbe includere l'autorizzazione “s3:CreateBucket”.

Dopo aver assegnato al ruolo di esecuzione le autorizzazioni appropriate per l'invio dei registri ad Amazon S3, i dati dei registro vengono inviati ai seguenti alle seguenti posizioni di Amazon S3 quando s3MonitoringConfiguration viene passato nella sezione monitoringConfiguration di una richiesta start-job-run, come mostrato in Gestione delle esecuzioni di processi utilizzando la AWS CLI.

  • Log del controller: /logUri/virtual-cluster-id/jobs/job-id/containers/pod-name/(stderr.gz/stdout.gz)

  • Log del driver: /logUri/virtual-cluster-id/jobs/job-id/containers/spark-application-id/spark-job-id-driver/(stderr.gz/stdout.gz)

  • Log dell'executor: /logUri/virtual-cluster-id/jobs/job-id/containers/spark-application-id/executor-pod-name/(stderr.gz/stdout.gz)

Configurazione di un'esecuzione di processo per utilizzare Amazon CloudWatch Logs

Per monitorare l'avanzamento del processo e per risolvere i fallimenti, è necessario configurare i processi per inviare le informazioni di registro ad Amazon S3, Amazon CloudWatch Logs o entrambi. Questo argomento fornisce le nozioni di base per utilizzare CloudWatch Logs sui processi avviati con Amazon EMR su EKS. Per maggiori informazioni su CloudWatch Logs, consulta Monitoraggio dei file di log nella Guida per l'utente di Amazon CloudWatch.

Policy IAM di CloudWatch Logs

Affinché i tuoi lavori inviino dati di registro a CloudWatch Logs, nella policy delle autorizzazioni per il ruolo di esecuzione del processo devono essere incluse le seguenti autorizzazioni. Sostituisci my_log_group_name e my_log_stream_prefix con i nomi del gruppo di registro e i nomi del flusso di registro di CloudWatch, rispettivamente. Amazon EMR su EKS crea il gruppo di log e il flusso di log se non ancora creati, purché l'ARN del ruolo di esecuzione disponga delle autorizzazioni appropriate.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:*:*:*" ] }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:*:*:log-group:my_log_group_name:log-stream:my_log_stream_prefix/*" ] } ] }
Nota

Amazon EMR su EKS può anche creare un flusso di registro. Se un flusso di registro non esiste, la policy IAM deve includere l'autorizzazione "logs:CreateLogGroup".

Dopo aver assegnato al ruolo di esecuzione le autorizzazioni appropriate, l'applicazione invia i dati del registro a CloudWatch Logs quando cloudWatchMonitoringConfiguration viene passato nella sezione monitoringConfiguration di una richiesta start-job-run, come mostrato in Gestione delle esecuzioni di processi utilizzando la AWS CLI.

Nell'API di StartJobRun, log_group_name è il nome del gruppo di log per CloudWatch e log_stream_prefix è il prefisso del nome del flusso di log per CloudWatch. Puoi visualizzare e ricercare tali log in AWS Management Console.

  • Log del controller: logGroup/logStreamPrefix/virtual-cluster-id/jobs/job-id/containers/pod-name/(stderr/stdout)

  • Log del driver: logGroup/logStreamPrefix/virtual-cluster-id/jobs/job-id/containers/spark-application-id/spark-job-id-driver/(stderrstdout)

  • Log dell'executor: logGroup/logStreamPrefix/virtual-cluster-id/jobs/job-id/containers/spark-application-id/executor-pod-name/(stderr/stdout)

Elenco delle esecuzioni di processi

Puoi eseguire list-job-run per visualizzare gli stati delle esecuzioni di processi, come illustrato nell'esempio seguente.

aws emr-containers list-job-runs --virtual-cluster-id <cluster-id>

Descrizione di un'esecuzione di processo

Puoi eseguire describe-job-run per ottenere ulteriori dettagli sul processo, ad esempio lo stato del processo, i dettagli dello stato e il nome del processo, come illustrato nell'esempio seguente.

aws emr-containers describe-job-run --virtual-cluster-id cluster-id --id job-run-id

Annullamento di un'esecuzione di processo

Puoi eseguire cancel-job-run per annullare i processi in esecuzione, come illustrato nell'esempio seguente.

aws emr-containers cancel-job-run --virtual-cluster-id cluster-id --id job-run-id