Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Exécution de tâches
Après avoir soumis votre candidature, soumettez-y des offres d'emploi. Cette section explique comment utiliser le AWS CLI pour exécuter ces tâches. Cette section identifie également les valeurs par défaut pour chaque type d'application disponible sur EMR Serverless.
**Topics**
+ [États d'exécution de la tâche](job-states.md)
+ [Annulation de l'exécution d'une tâche EMR sans serveur avec délai de grâce](job-cancellation-grace-period.md)
+ [Exécution de tâches depuis la console EMR Studio](jobs-studio.md)
+ [Exécution de tâches à partir du AWS CLI](jobs-cli.md)
+ [Politique d'exécution IAM](jobs-cli-execution.md)
+ [Utilisation de disques optimisés pour le shuffle](jobs-shuffle-optimized-disks.md)
+ [Utilisation du stockage sans serveur pour Amazon EMR Serverless](jobs-serverless-storage.md)
+ [Tâches de streaming pour le traitement de données diffusées en continu](jobs-streaming.md)
+ [Utilisation des configurations Spark lorsque vous exécutez des tâches EMR sans serveur](jobs-spark.md)
+ [Utilisation de configurations Hive lorsque vous exécutez des tâches EMR sans serveur](jobs-hive.md)
+ [Résilience des tâches EMR sans serveur](jobs-resiliency.md)
+ [Configuration du métastore pour EMR Serverless](metastore-config.md)
+ [Accès aux données S3 depuis un autre AWS compte depuis EMR Serverless](jobs-s3-access.md)
+ [Résolution des erreurs dans EMR Serverless](jobs-troubleshoot.md)
+ [Permettre la répartition des coûts au niveau des tâches](jobs-job-level-cost-allocation.md)
# États d'exécution de la tâche
Lorsque vous soumettez une tâche exécutée à une file d'attente de tâches Amazon EMR Serverless, la tâche exécutée entre dans l'état. `SUBMITTED` L'état d'une tâche passe de « à » `SUBMITTED` `RUNNING` jusqu'à ce qu'il atteigne `FAILED``SUCCESS`, ou`CANCELLING`.
Les exécutions de tâches peuvent avoir les états suivants :
****
| State | Description |
| --- | --- |
| Soumis | État initial de la tâche lorsque vous soumettez une tâche exécutée à EMR Serverless. Le poste attend d'être programmé pour la candidature. EMR Serverless commence à prioriser et à planifier l'exécution de la tâche. |
| En file d’attente | L'exécution de la tâche attend dans cet état lorsque la simultanéité d'exécution des tâches au niveau de l'application est entièrement occupée. Pour plus d'informations sur la mise en file d'attente et la simultanéité, reportez-vous à. [Job simultané et mise en file d'attente pour une application EMR sans serveur](applications-concurrency-queuing.md) |
| En suspens | Le planificateur évalue l'exécution du travail afin de prioriser et de planifier l'exécution de l'application. |
| Programmé | EMR Serverless a planifié l'exécution de la tâche pour l'application et alloue des ressources pour exécuter la tâche. |
| En cours d'exécution | EMR Serverless a alloué les ressources dont la tâche avait initialement besoin, et la tâche est en cours d'exécution dans l'application. Dans les applications Spark, cela signifie que le processus du pilote Spark est en état running. |
| Échec | EMR Serverless n'a pas réussi à envoyer la tâche exécutée à l'application, ou elle s'est terminée sans succès. Reportez-vous à StateDetails pour plus d'informations sur cet échec de tâche. |
| Succès | L'exécution de la tâche s'est terminée avec succès. |
| Annulation | L'CancelJobRunAPI a demandé l'annulation de l'exécution du travail ou le délai d'exécution du travail a expiré. EMR Serverless essaie d'annuler la tâche dans l'application et de libérer les ressources. |
| Annulée | L'exécution de la tâche a été annulée avec succès et les ressources utilisées ont été libérées. |
# Annulation de l'exécution d'une tâche EMR sans serveur avec délai de grâce
Dans les systèmes de traitement des données, les interruptions brusques peuvent entraîner un gaspillage de ressources, des opérations incomplètes et des incohérences potentielles dans les données. Amazon EMR Serverless vous permet de définir un délai de grâce lors de l'annulation de l'exécution d'une tâche. Cette fonctionnalité laisse le temps de procéder au nettoyage approprié et de terminer les travaux en cours avant la fin du travail.
Lorsque vous annulez l'exécution d'une tâche, spécifiez un délai de grâce (en secondes) à l'aide du paramètre `shutdownGracePeriodInSeconds` pendant lequel la tâche peut effectuer des opérations de nettoyage avant son arrêt final. Le comportement et les paramètres par défaut varient entre les tâches par lots et les tâches de streaming.
## Période de grâce pour les tâches par lots
Pour les tâches par lots, EMR Serverless vous permet de mettre en œuvre des opérations de nettoyage personnalisées qui s'exécutent pendant la période de grâce. Vous pouvez enregistrer ces opérations de nettoyage dans le cadre du hook d'arrêt de la JVM dans le code de votre application.
**Comportement par défaut**
Le comportement par défaut pour l'arrêt est de n'avoir aucun délai de grâce. Il comprend les deux actions suivantes :
+ Résiliation immédiate
+ Les ressources sont débloquées immédiatement
**Options de configuration**
Vous pouvez définir des paramètres qui se traduiront par un arrêt progressif :
+ Plage valide pour la période de grâce d'arrêt : 15 à 1800 secondes (facultatif)
+ Résiliation immédiate (sans délai de grâce) : 0 seconde
### Activer l'arrêt progressif
Pour implémenter un arrêt progressif pour les tâches par lots, procédez comme suit :
1. Ajoutez un hook d'arrêt dans le code de votre application contenant une logique d'arrêt personnalisée.
------
#### [ Example in Scala ]
```
import org.apache.hadoop.util.ShutdownHookManager
// Register shutdown hook with priority (second argument)
// Higher priority hooks run first
ShutdownHookManager.get().addShutdownHook(() => {
logger.info("Performing cleanup operations...")
}, 100)
```
Utilisation de [ShutdownHookManager](https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-common/api/org/apache/hadoop/util/ShutdownHookManager.html)
------
#### [ Example in PySpark ]
```
import atexit
def cleanup():
# Your cleanup logic here
print("Performing cleanup operations...")
# Register the cleanup function
atexit.register(cleanup)
```
------
1. Spécifiez un délai de grâce lors de l'annulation de la tâche afin de laisser le temps aux hooks ajoutés précédemment de s'exécuter
**Exemple**
```
# Default (immediate termination)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID
# With 5-minute grace period
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 300
```
## Période de grâce pour les emplois de streaming
Dans Spark Structured Streaming, où les calculs impliquent la lecture ou l'écriture dans des sources de données externes, les arrêts brusques peuvent entraîner des résultats indésirables. Les tâches de streaming traitent les données par microlots, et l'interruption de ces opérations en cours de route peut entraîner un double traitement lors de tentatives ultérieures. Cela se produit lorsque le dernier point de contrôle du microlot précédent n'a pas été écrit, ce qui entraîne le nouveau traitement des mêmes données au redémarrage de la tâche de streaming. Un tel traitement dupliqué gaspille non seulement des ressources informatiques, mais peut également avoir un impact sur les opérations commerciales, d'où la nécessité d'éviter les arrêts brusques.
EMR Serverless fournit un support intégré pour un arrêt progressif via un écouteur de requêtes en streaming. Cela garantit l'achèvement correct des microlots en cours avant la fin du travail. Le service gère automatiquement l'arrêt progressif entre les microlots pour les applications de streaming, en veillant à ce que le microlot en cours termine le traitement, que les points de contrôle soient correctement écrits et que le contexte de diffusion soit correctement arrêté sans ingestion de nouvelles données pendant le processus d'arrêt.
**Comportement par défaut**
+ Période de grâce de 120 secondes activée par défaut.
+ L'écouteur de requêtes de streaming intégré gère un arrêt progressif.
**Options de configuration**
+ Plage valide pour la période de grâce d'arrêt : 15 à 1800 secondes (facultatif)
+ Fin immédiate : 0 seconde
### Activer Graceful Shutdown
Pour implémenter un arrêt progressif pour les tâches de streaming, procédez comme suit :
Spécifiez une période de grâce lors de l'annulation de la tâche afin de laisser le temps au microlot en cours d'être terminé.
**Exemple**
```
# Default graceful shutdown (120 seconds)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID
# Custom grace period (e.g. 300 seconds)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 300
# Immediate Termination
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 0
```
### Ajoutez des crochets d'arrêt personnalisés (facultatif)
Alors qu'EMR Serverless gère l'arrêt progressif par défaut via son écouteur de requêtes de streaming intégré, vous pouvez éventuellement implémenter une logique d'arrêt personnalisée pour les requêtes de streaming individuelles. EMR Serverless enregistre son écouteur d'arrêt progressif avec la priorité 60 (utilisation). ShutdownHookManager Étant donné que les hooks à priorité plus élevée s'exécutent en premier, vous pouvez enregistrer vos opérations de nettoyage personnalisées avec une priorité supérieure à 60 pour vous assurer qu'elles s'exécutent avant le début du processus d'arrêt d'EMR Serverless.
Pour ajouter un hook personnalisé, reportez-vous au premier exemple de cette rubrique qui montre comment ajouter un hook d'arrêt dans le code de votre application. Ici, 100 est la priorité, ce qui est supérieur à 60. Par conséquent, un tel crochet d'arrêt s'exécute en premier.
**Note**
Les hooks d'arrêt personnalisés sont facultatifs et ne sont pas nécessaires pour la fonctionnalité d'arrêt progressif, qui est gérée automatiquement par EMR Serverless.
### Frais liés à la période de grâce et durée du Batch
Si la valeur par défaut du délai de grâce (120 secondes) est utilisée :
+ Si la durée de votre lot est inférieure à 120 secondes, vous ne serez facturé que pour le temps réellement nécessaire pour terminer le lot.
+ Si la durée de votre lot dépasse 120 secondes, le délai de grâce maximal (120 secondes) vous sera facturé, mais la requête risque de ne pas s'arrêter correctement car elle sera interrompue de force.
Pour optimiser les coûts et garantir un arrêt progressif :
+ Pour les durées de lot supérieures à 120 secondes : envisagez d'augmenter le délai de grâce pour qu'il corresponde à la durée de votre lot
+ Pour les durées de lot inférieures à 120 secondes : il n'est pas nécessaire d'ajuster le délai de grâce car vous ne serez facturé que pour le temps de traitement réel
## Considérations
### Comportement du délai de grâce
+ La période de grâce vous donne le temps de terminer les interruptions enregistrées.
+ Job se termine dès que le crochet d'arrêt est terminé, même si c'est bien avant la période de grâce.
+ Si les opérations de nettoyage dépassent le délai de grâce, le travail sera résilié de force.
### Comportement du service
+ L'arrêt par période de grâce n'est disponible que pour les tâches en cours d'exécution.
+ Les demandes d'annulation suivantes pendant l'état CANCELING sont ignorées.
+ Si EMR Serverless ne parvient pas à initier l'arrêt du délai de grâce en raison d'erreurs de service internes :
+ Le service réessaiera pendant 2 minutes au maximum.
+ Si les nouvelles tentatives échouent, la tâche sera interrompue de force.
### Facturation
Les tâches sont facturées en fonction des ressources informatiques utilisées jusqu'à leur arrêt complet, y compris le temps nécessaire pendant la période de grâce.
# Exécution de tâches depuis la console EMR Studio
Vous pouvez envoyer des exécutions de tâches aux applications EMR Serverless et accéder aux tâches depuis la console EMR Studio. [Pour créer ou accéder à votre application EMR Serverless sur la console EMR Studio, suivez les instructions de la section Démarrage depuis la console.](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html#gs-console)
## Envoi d’une tâche
Sur la page **Soumettre une tâche**, soumettez une tâche à une application EMR Serverless comme suit.
------
#### [ Spark ]
1. Dans le champ **Nom**, saisissez le nom de l'exécution de votre tâche.
1. Dans le champ **Rôle d'exécution**, entrez le nom du rôle IAM que votre application EMR Serverless peut assumer pour l'exécution de la tâche. Pour en savoir plus sur les rôles d'exécution, reportez-vous à[Rôles d'exécution des tâches pour Amazon EMR Serverless](security-iam-runtime-role.md).
1. Dans le champ **Emplacement du script**, entrez l'emplacement Amazon S3 du script ou du JAR que vous souhaitez exécuter. Pour les tâches Spark, le script peut être un fichier Python (`.py`) ou un fichier JAR (`.jar`).
1. Si l'emplacement de votre script est un fichier JAR, entrez le nom de classe qui est le point d'entrée de la tâche dans le champ **Classe principale**.
1. (Facultatif) Entrez des valeurs pour les autres champs.
+ **Arguments du script** — Entrez les arguments que vous souhaitez transmettre à votre script JAR ou Python principal. Votre code lit ces paramètres. Séparez chaque argument du tableau par une virgule.
+ **Propriétés de Spark** — Développez la section des propriétés de Spark et entrez les paramètres de configuration de Spark dans ce champ.
**Note**
Si vous spécifiez la taille du pilote et de l'exécuteur Spark, tenez compte de la surcharge mémoire. Spécifiez les valeurs de surcharge de mémoire dans les propriétés `spark.driver.memoryOverhead` et`spark.executor.memoryOverhead`. La surcharge mémoire a une valeur par défaut de 10 % de la mémoire du conteneur, avec un minimum de 384 Mo. La mémoire de l'exécuteur et la surcharge de mémoire réunies ne peuvent pas dépasser la mémoire de travail. Par exemple, le maximum `spark.executor.memory` d'un travailleur de 30 Go doit être de 27 Go.
+ **Configuration de la tâche** — Spécifiez n'importe quelle configuration de tâche dans ce champ. Vous pouvez utiliser ces configurations de tâches pour remplacer les configurations par défaut des applications.
+ **Paramètres supplémentaires** — Activez ou désactivez le catalogue de données AWS Glue en tant que métastore et modifiez les paramètres du journal des applications. Pour en savoir plus sur les configurations de métastore, reportez-vous à. [Configuration du métastore pour EMR Serverless](metastore-config.md) Pour en savoir plus sur les options de journalisation des applications, reportez-vous à[Stockage des journaux](logging.md).
+ **Balises** — Attribuez des balises personnalisées à l'application.
1. Choisissez **Soumettre une tâche**.
------
#### [ Hive ]
1. Dans le champ **Nom**, saisissez le nom de l'exécution de votre tâche.
1. Dans le champ **Rôle d'exécution**, entrez le nom du rôle IAM que votre application EMR Serverless peut assumer pour l'exécution de la tâche.
1. Dans le champ **Emplacement du script**, entrez l'emplacement Amazon S3 du script ou du JAR que vous souhaitez exécuter. Pour les jobs Hive, le script doit être un fichier Hive (`.sql`).
1. (Facultatif) Entrez des valeurs pour les autres champs.
+ **Emplacement du script d'initialisation** : entrez l'emplacement du script qui initialise les tables avant l'exécution du script Hive.
+ **Propriétés de la ruche** — Développez la section des propriétés de la ruche et entrez les paramètres de configuration de la ruche dans ce champ.
+ **Configuration de la tâche** : spécifiez n'importe quelle configuration de tâche. Vous pouvez utiliser ces configurations de tâches pour remplacer les configurations par défaut des applications. Pour les tâches Hive, `hive.exec.scratchdir` et `hive.metastore.warehouse.dir` sont des propriétés obligatoires dans la `hive-site` configuration.
```
{
"applicationConfiguration": [
{
"classification": "hive-site",
"configurations": [],
"properties": {
"hive.exec.scratchdir": "s3://DOC-EXAMPLE_BUCKET/hive/scratch",
"hive.metastore.warehouse.dir": "s3://DOC-EXAMPLE_BUCKET/hive/warehouse"
}
}
],
"monitoringConfiguration": {}
}
```
+ **Paramètres supplémentaires** — Activez ou désactivez le catalogue de données AWS Glue en tant que métastore et modifiez les paramètres du journal des applications. Pour en savoir plus sur les configurations de métastore, reportez-vous à. [Configuration du métastore pour EMR Serverless](metastore-config.md) Pour en savoir plus sur les options de journalisation des applications, reportez-vous à[Stockage des journaux](logging.md).
+ **Balises** — Attribuez des balises personnalisées à l'application.
1. Choisissez **Soumettre une tâche**.
------
## Exécution des tâches d'accès
À partir de l'onglet **Exécutions de tâches** sur la page **Détails** d'une application, accédez aux exécutions de tâches et effectuez les actions suivantes pour les exécutions de tâches.
**Annuler la tâche** : pour annuler l'exécution d'une tâche en l'`RUNNING`état, choisissez cette option. Pour en savoir plus sur les transitions d'exécution de tâches, reportez-vous à[États d'exécution de la tâche](job-states.md).
**Cloner une tâche** : pour cloner une tâche précédente et la soumettre à nouveau, choisissez cette option.
# Exécution de tâches à partir du AWS CLI
Vous pouvez créer, décrire et supprimer des tâches individuelles sur le AWS CLI. Vous pouvez également répertorier toutes vos offres d'emploi pour y accéder en un coup d'œil.
Pour soumettre une nouvelle offre d'emploi, utilisez`start-job-run`. Indiquez l'ID de l'application que vous souhaitez exécuter, ainsi que les propriétés spécifiques à la tâche. Pour des exemples de Spark, reportez-vous à[Utilisation des configurations Spark lorsque vous exécutez des tâches EMR sans serveur](jobs-spark.md). Pour des exemples de Hive, reportez-vous à. [Utilisation de configurations Hive lorsque vous exécutez des tâches EMR sans serveur](jobs-hive.md) Cette commande renvoie votre`application-id`, votre ARN et un nouveau`job-id`.
Chaque tâche exécutée a une durée de temporisation définie. Si la durée d'exécution de la tâche dépasse cette durée, EMR Serverless l'annulera automatiquement. Le délai d'expiration par défaut est de 12 heures. Lorsque vous démarrez l'exécution de votre tâche, configurez ce paramètre de délai d'expiration sur une valeur qui répond aux exigences de votre tâche. Configurez la valeur avec la `executionTimeoutMinutes` propriété.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--execution-timeout-minutes 15 \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/scripts/create_table.sql",
"parameters": "--hiveconf hive.exec.scratchdir=s3://amzn-s3-demo-bucket/hive/scratch --hiveconf hive.metastore.warehouse.dir=s3://amzn-s3-demo-bucket/hive/warehouse"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.client.cores": "2",
"hive.client.memory": "4GIB"
}
}]
}'
```
Pour décrire un travail, utilisez`get-job-run`. Cette commande renvoie les configurations spécifiques à la tâche et la capacité définie pour votre nouvelle tâche.
```
aws emr-serverless get-job-run \
--job-run-id job-id \
--application-id application-id
```
Pour répertorier vos offres d'emploi, utilisez`list-job-runs`. Cette commande renvoie un ensemble abrégé de propriétés qui inclut le type de tâche, l'état et d'autres attributs de haut niveau. Si vous ne souhaitez pas accéder à toutes vos tâches, spécifiez le nombre maximum de tâches auxquelles vous souhaitez accéder, jusqu'à 50. L'exemple suivant indique que vous souhaitez accéder à vos deux dernières exécutions de tâches.
```
aws emr-serverless list-job-runs \
--max-results 2 \
--application-id application-id
```
Pour annuler une tâche, utilisez`cancel-job-run`. Indiquez le `application-id` et le `job-id` nom du travail que vous souhaitez annuler.
```
aws emr-serverless cancel-job-run \
--job-run-id job-id \
--application-id application-id
```
Pour plus d'informations sur la façon d'exécuter des tâches à partir de AWS CLI, reportez-vous au manuel [EMR Serverless](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/Welcome.html) API Reference.
# Politique d'exécution IAM
Vous pouvez spécifier une politique IAM d'exécution, en plus d'un rôle d'exécution, lorsque vous soumettez des exécutions de tâches sur EMR Serverless. Les autorisations obtenues par l'exécution du job correspondent à l'intersection des autorisations du rôle d'exécution et de la politique IAM d'exécution spécifiée.
## Démarrage
Étapes pour utiliser la politique d'exécution IAM :
Créez une `emr-serverless` application ou utilisez une application existante, puis exécutez l'interface de ligne de commande aws suivante pour démarrer une tâche avec une politique IAM intégrée :
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options \
--execution-iam-policy '{"policy": "inline-policy"}'
```
## Exemples de commandes CLI
Si la politique suivante est enregistrée dans le `policy.json` fichier sur la machine :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket",
"arn:aws:s3:::my-test-bucket/*"
],
"Sid": "AllowS3Getobject"
}
]
}
```
------
Ensuite, nous pouvons démarrer un travail avec cette politique à l'aide de la AWS CLI commande suivante :
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policy": '$(jq -c '. | @json' policy.json)'
}'
```
Vous pouvez également utiliser les deux politiques AWS et les politiques gérées par le client, en les spécifiant par le biais de leurs ARNs :
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policyArns": [
"arn:aws:iam::aws:policy/AmazonS3FullAccess",
"arn:aws:iam::aws:policy/CloudWatchLogsFullAccess"
]
}'
```
Il est également possible de spécifier à la fois une stratégie IAM intégrée et une politique gérée ARNs dans la même demande :
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policy": '$(jq -c '. | @json' policy.json)',
"policyArns": [
"arn:aws:iam::aws:policy/AmazonS3FullAccess",
"arn:aws:iam::aws:policy/CloudWatchLogsFullAccess"
]
}'
```
## Remarques importantes
+ Le `execution-role-policy` `policy` champ s peut avoir une longueur maximale de 2 048 caractères.
+ La chaîne de politique IAM en ligne spécifiée dans le `execution-iam-policy` `policy` champ « s » doit être conforme à la norme de chaîne JSON, sans aucune nouvelle ligne ni aucun guillemet, comme dans l'exemple précédent.
+ Une liste contenant jusqu'à 10 politiques gérées ARNs peut être spécifiée sous forme de valeur `policyArns` dans `execution-iam-policy` le champ.
+ La politique gérée ARNs doit être une liste d'ARN de stratégie valides AWS ou gérés par le client. Lorsqu'un ARN de stratégie géré par le client est spécifié, la politique doit appartenir au même AWS compte de l'EMR-S JobRun.
+ Lorsque la stratégie IAM intégrée et les politiques gérées sont utilisées, le texte en clair que vous utilisez pour les politiques intégrées et gérées combinées ne peut pas dépasser 2 048 caractères.
+ Les autorisations obtenues par le JobRun sont l'intersection des autorisations du rôle d'exécution et de la politique IAM d'exécution spécifiée.
## Intersection des politiques
Les autorisations obtenues par l'exécution du job correspondent à l'intersection des autorisations du rôle d'exécution et de la politique IAM d'exécution spécifiée. Cela signifie que toute autorisation requise devra être spécifiée aux deux endroits pour JobRun pouvoir fonctionner. Cependant, il est possible de spécifier une instruction d'autorisation générale supplémentaire dans la politique intégrée pour toutes les autorisations que vous n'avez pas l'intention de mettre à jour ou de remplacer.
Exemple
Compte tenu de la politique de rôle IAM d'exécution suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"arn:aws:logs:us-west-2:123456789012:log-group::log-stream"
],
"Sid": "AllowLOGSDescribeloggroups"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/MyCompany1table"
],
"Sid": "AllowDYNAMODBDescribetable"
}
]
}
```
------
Et la politique IAM intégrée suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket/tenant1",
"arn:aws:s3:::my-test-bucket/tenant1/*"
],
"Sid": "AllowS3Getobject"
},
{
"Effect": "Allow",
"Action": [
"logs:*",
"dynamodb:*"
],
"Resource": [
"*"
],
"Sid": "AllowLOGS"
}
]
}
```
------
Les autorisations ainsi obtenues JobRun sont les suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket/tenant1",
"arn:aws:s3:::my-test-bucket/tenant1/*"
],
"Sid": "AllowS3Getobject"
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"arn:aws:logs:us-west-2:123456789012:log-group::log-stream"
],
"Sid": "AllowLOGSDescribeloggroups"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/MyCompany1table"
],
"Sid": "AllowDYNAMODBDescribetable"
}
]
}
```
------
# Utilisation de disques optimisés pour le shuffle
Avec les versions 7.1.0 et supérieures d'Amazon EMR, utilisez des disques optimisés pour le shuffle lorsque vous exécutez des tâches Apache Spark ou Hive (afin d'améliorer les performances (I/O-intensive workloads. Compared to standard disks, shuffle-optimized disks provide higher IOPS (I/Oopérations par seconde) afin d'accélérer le mouvement des données et de réduire la latence lors des opérations de shuffle. Les disques optimisés pour le shuffle vous permettent de connecter des disques d'une taille maximale de 2 To par utilisateur. Configurez donc la capacité adaptée aux exigences de votre charge de travail.
## Principaux avantages
Les disques optimisés pour le shuffle offrent les avantages suivants.
+ **Performances IOPS élevées** : les disques optimisés pour le shuffle fournissent des IOPS plus élevées que les disques standard, ce qui permet un brassage des données plus efficace et plus rapide lors des tâches Spark et Hive et d'autres charges de travail intensives en matière de brassage.
+ **Taille de disque plus importante** : les disques optimisés pour le shuffle prennent en charge des tailles de disque allant de 20 Go à 2 To par utilisateur. Choisissez donc la capacité appropriée en fonction de vos charges de travail.
## Prise en main
Consultez les étapes suivantes pour utiliser des disques optimisés pour le shuffle dans vos flux de travail.
------
#### [ Spark ]
1. Créez une application EMR Serverless version 7.1.0 à l'aide de la commande suivante.
```
aws emr-serverless create-application \
--type "SPARK" \
--name my-application-name \
--release-label emr-7.1.0 \
--region
```
1. Configurez votre tâche Spark pour inclure les paramètres `spark.emr-serverless.driver.disk.type` and/or `spark.emr-serverless.executor.disk.type` à exécuter avec des disques optimisés pour le shuffle. Vous pouvez utiliser l'un des paramètres ou les deux, selon votre cas d'utilisation.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi
--conf spark.executor.cores=4
--conf spark.executor.memory=20g
--conf spark.driver.cores=4
--conf spark.driver.memory=8g
--conf spark.executor.instances=1
--conf spark.emr-serverless.executor.disk.type=shuffle_optimized"
}
}'
```
Pour plus d'informations, reportez-vous aux [propriétés des tâches Spark](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults).
------
#### [ Hive ]
1. Créez une application EMR Serverless version 7.1.0 à l'aide de la commande suivante.
```
aws emr-serverless create-application \
--type "HIVE" \
--name my-application-name \
--release-label emr-7.1.0 \
--region
```
1. Configurez votre tâche Hive pour inclure les paramètres à exécuter avec des disques `hive.driver.disk.type` and/or `hive.tez.disk.type` optimisés pour le shuffle. Vous pouvez utiliser l'un des paramètres ou les deux, selon votre cas d'utilisation.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "s3:///emr-serverless-hive/query/hive-query.ql",
"parameters": "--hiveconf hive.log.explain.output=false"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.exec.scratchdir": "s3:///emr-serverless-hive/hive/scratch",
"hive.metastore.warehouse.dir": "s3:///emr-serverless-hive/hive/warehouse",
"hive.driver.cores": "2",
"hive.driver.memory": "4g",
"hive.tez.container.size": "4096",
"hive.tez.cpu.vcores": "1",
"hive.driver.disk.type": "shuffle_optimized",
"hive.tez.disk.type": "shuffle_optimized"
}
}]
}'
```
Pour plus d'informations, consultez les [propriétés des tâches Hive](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-hive.html#hive-defaults).
------
**Configuration d'une application avec une capacité pré-initialisée**
Consultez les exemples suivants pour créer des applications basées sur Amazon EMR version 7.1.0. Les propriétés de ces applications sont les suivantes :
+ 5 pilotes Spark préinitialisés, chacun doté de 2 vCPU, de 4 Go de mémoire et de 50 Go de disque optimisé pour le shuffle.
+ 50 exécuteurs préinitialisés, chacun doté de 4 vCPU, 8 Go de mémoire et 500 Go de disque optimisé pour le shuffle.
Lorsque cette application exécute des tâches Spark, elle consomme d'abord les tâches préinitialisées, puis fait évoluer les tâches à la demande jusqu'à la capacité maximale de 400 vCPU et 1 024 Go de mémoire. Vous pouvez éventuellement omettre la capacité pour l'un `DRIVER` ou `EXECUTOR` l'autre.
------
#### [ Spark ]
```
aws emr-serverless create-application \
--type "SPARK" \
--name \
--release-label emr-7.1.0 \
--initial-capacity '{
"DRIVER": {
"workerCount": 5,
"workerConfiguration": {
"cpu": "2vCPU",
"memory": "4GB",
"disk": "50GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
},
"EXECUTOR": {
"workerCount": 50,
"workerConfiguration": {
"cpu": "4vCPU",
"memory": "8GB",
"disk": "500GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
}
}' \
--maximum-capacity '{
"cpu": "400vCPU",
"memory": "1024GB"
}'
```
------
#### [ Hive ]
```
aws emr-serverless create-application \
--type "HIVE" \
--name \
--release-label emr-7.1.0 \
--initial-capacity '{
"DRIVER": {
"workerCount": 5,
"workerConfiguration": {
"cpu": "2vCPU",
"memory": "4GB",
"disk": "50GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
},
"EXECUTOR": {
"workerCount": 50,
"workerConfiguration": {
"cpu": "4vCPU",
"memory": "8GB",
"disk": "500GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
}
}' \
--maximum-capacity '{
"cpu": "400vCPU",
"memory": "1024GB"
}'
```
------
# Utilisation du stockage sans serveur pour Amazon EMR Serverless
Avec les versions 7.12 et supérieures d'Amazon EMR, utilisez le stockage sans serveur lorsque vous exécutez des tâches Apache Spark afin d'éliminer le provisionnement de disques locaux, de réduire les coûts de traitement des données et d'éviter les échecs de tâches dus à des contraintes de capacité de disque. Le stockage sans serveur gère automatiquement les opérations de shuffle, de déversement de disque et de mise en cache de disque pour vos tâches sans nécessiter de configuration de capacité et stocke les données intermédiaires gratuitement. Amazon EMR Serverless stocke les données intermédiaires dans un système de stockage sans serveur entièrement géré qui évolue automatiquement en fonction des demandes de charge de travail et permet à Spark de libérer du personnel informatique immédiatement en cas d'inactivité, réduisant ainsi les coûts de calcul.
## Principaux avantages
Le stockage sans serveur pour EMR Serverless offre les avantages suivants.
+ **Stockage sans configuration** : le stockage sans serveur élimine le besoin de configurer le type et la taille du disque local pour chaque application ou tâche. EMR Serverless gère automatiquement les opérations de données intermédiaires sans planification des capacités.
+ **Empêche les échecs de tâches grâce à une mise à l'échelle automatique** : la capacité de stockage évolue automatiquement en fonction de la charge de travail, ce qui permet d'éviter les échecs de travail dus à une capacité de disque insuffisante.
+ **Coûts de traitement des données réduits** : le stockage sans serveur réduit les coûts de traitement grâce à deux mécanismes. Tout d'abord, le stockage intermédiaire des données est fourni gratuitement : vous ne payez que pour les ressources de calcul et de mémoire. Deuxièmement, le stockage découplé avec l'allocation dynamique des ressources de Spark permet à Spark de libérer immédiatement les travailleurs lorsqu'ils sont inactifs plutôt que de les conserver pour préserver les données intermédiaires sur les disques locaux. Cela permet une évolutivité et une intégration plus rapides par étape Spark, réduisant ainsi les coûts de calcul pour les tâches où les étapes ultérieures nécessitent moins de travailleurs que les étapes initiales.
+ **Stockage crypté avec isolation au niveau** de la tâche : toutes les données intermédiaires sont cryptées en transit et au repos avec une isolation stricte au niveau de la tâche.
+ Prise en **charge précise du contrôle d'accès** : le stockage sans serveur permet un contrôle d'accès précis grâce à l'intégration d'AWS Lake Formation.
## Prise en main
Consultez les étapes suivantes pour utiliser le stockage sans serveur pour EMR Serverless dans vos flux de travail Spark.
1. **Création d'une application EMR sans serveur**
Créez une application EMR Serverless version 7.12 (ou ultérieure) avec le stockage sans serveur activé en définissant la propriété spark sur **true** dans la classification `spark.aws.serverlessStorage.enabled` spark-defaults.
```
aws emr-serverless create-application \
--type "SPARK" \
--name my-application \
--release-label emr-7.12.0 \
--runtime-configuration '[{
"classification": "spark-defaults",
"properties": {
"spark.aws.serverlessStorage.enabled": "true"
}
}]' \
--region
```
1. **Démarrer une tâche Spark**
Lancez l'exécution d'une tâche sur votre application. Le stockage sans serveur pour EMR Serverless gère automatiquement les opérations de données intermédiaires telles que le shuffle pour votre travail.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3:///script.py",
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=20g
--conf spark.driver.cores=4
--conf spark.driver.memory=8g
--conf spark.executor.instances=10"
}
}'
```
Vous pouvez également activer le stockage sans serveur pour EMR Serverless au niveau de la tâche, même s'il n'est pas activé au niveau de l'application. Cela lancera des nœuds de travail dotés d'un stockage sans serveur pour traiter vos tâches. Vous pouvez également désactiver le stockage sans serveur pour une tâche spécifique en définissant la même propriété Spark `spark.aws.serverlessStorage.enabled` sur **false**.
```
# Turn on serverless storage for EMR serverless for a specific job
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi
--conf spark.aws.serverlessStorage.enabled": "true"
}
}'
```
**Note**
**Pour continuer à utiliser le provisionnement de disque local traditionnel, omettez la `spark.aws.serverlessStorage.enabled` configuration ou définissez-la sur false.**
## Considérations et restrictions
+ **Version finale** : le stockage sans serveur est pris en charge sur Amazon EMR version 7.12 et versions ultérieures.
+ **Limites de volume de données** : chaque tâche peut lire et écrire jusqu'à 200 Go de données intermédiaires par tâche exécutée. Les tâches dépassant cette limite échoueront avec un message d'erreur indiquant que la limite de stockage sans serveur a été atteinte.
+ **Délai d'exécution des tâches : le** stockage sans serveur prend en charge les tâches dont le délai d'exécution peut atteindre 24 heures. Les tâches configurées pour des délais d'exécution plus longs échoueront avec un message d'erreur.
+ Capacité **préinitialisée : les opérateurs de capacité** préinitialisés ne prennent pas en charge le stockage sans serveur. Lorsque vous configurez la capacité préinitialisée, elle ne sera utilisée que par les tâches qui désactivent explicitement le stockage sans serveur au niveau de la tâche. Les tâches pour lesquelles le stockage sans serveur est activé fourniront toujours de nouveaux travailleurs à la demande et n'utiliseront aucune capacité préinitialisée, quelle que soit la configuration au niveau de l'application.
+ **Types de charge de travail** : le stockage sans serveur n'est pas pris en charge pour le streaming et les tâches interactives.
+ **Configuration du** serveur : le stockage sans serveur n'est pas pris en charge pour les utilisateurs utilisant 1 ou 2 v. CPUs
## Soutenu Régions AWS
EMR Serverless prend en charge le stockage sans serveur dans les régions suivantes :
+ USA Est (Virginie du Nord)
+ USA Ouest (Oregon)
+ Europe (Irlande)
# Tâches de streaming pour le traitement de données diffusées en continu
Une tâche de streaming dans EMR Serverless est un mode de travail qui vous permet d'analyser et de traiter des données de streaming en temps quasi réel. Ces tâches de longue durée interrogent les données de streaming et traitent les résultats en continu au fur et à mesure de leur arrivée. Les tâches de streaming sont particulièrement adaptées aux tâches qui nécessitent un traitement des données en temps réel, telles que les analyses en temps quasi réel, la détection des fraudes et les moteurs de recommandations. Les tâches de streaming EMR sans serveur offrent des optimisations, telles que la résilience intégrée des tâches, une surveillance en temps réel, une gestion améliorée des journaux et l'intégration avec des connecteurs de streaming.
Voici quelques exemples d'utilisation des jobs de streaming :
+ **Analyses en temps quasi réel** : les tâches de streaming dans Amazon EMR Serverless vous permettent de traiter les données de streaming en temps quasi réel. Vous pouvez ainsi effectuer des analyses en temps réel sur des flux de données continus, tels que les données de journal, les données de capteurs ou les données de parcours de navigation afin d'en tirer des informations et de prendre des décisions en temps opportun sur la base des informations les plus récentes.
+ **Détection des fraudes** : utilisez les tâches de streaming pour détecter les fraudes en temps quasi réel dans les transactions financières, les opérations de carte de crédit ou les activités en ligne lorsque vous analysez des flux de données et identifiez des modèles ou des anomalies suspects au fur et à mesure qu'ils se produisent.
+ **Moteurs de recommandation : les** tâches de streaming peuvent traiter les données d'activité des utilisateurs et mettre à jour les modèles de recommandations. Cela ouvre la voie à des recommandations personnalisées et en temps réel basées sur les comportements et les préférences.
+ **Analyse des réseaux sociaux** : les jobs de streaming peuvent traiter les données des réseaux sociaux, telles que les tweets, les commentaires et les publications, afin que les entreprises puissent suivre les tendances, analyser les sentiments et gérer la réputation de la marque en temps quasi réel.
+ **Analyse de l'Internet des objets (IoT)** : les tâches de streaming peuvent gérer et analyser des flux de données à haut débit provenant d'appareils IoT, de capteurs et de machines connectées. Ils peuvent donc exécuter la détection des anomalies, la maintenance prédictive et d'autres cas d'utilisation de l'analytique IoT.
+ **Analyse du flux de clics** : les tâches de streaming peuvent traiter et analyser les données du flux de clics provenant de sites Web ou d'applications mobiles. Les entreprises qui utilisent de telles données peuvent effectuer des analyses pour en savoir plus sur le comportement des utilisateurs, personnaliser les expériences utilisateur et optimiser les campagnes marketing.
+ **Surveillance et analyse des journaux** : les tâches de streaming peuvent également traiter les données des journaux provenant de serveurs, d'applications et de périphériques réseau. Cela vous permet de détecter les anomalies, de résoudre les problèmes, ainsi que de garantir l'état et les performances du système.
**Principaux avantages**
Les tâches de streaming dans EMR Serverless garantissent automatiquement la *résilience des* tâches, qui est une combinaison des facteurs suivants :
+ **Réessai automatique** : EMR Serverless réessaie automatiquement toutes les tâches qui ont échoué sans aucune intervention manuelle de votre part.
+ **Résilience de la zone de disponibilité (AZ)** : EMR Serverless fait automatiquement passer les tâches de streaming à une AZ saine si l'AZ d'origine rencontre des problèmes.
+ **Gestion des journaux :**
+ **Rotation des journaux** : pour une gestion plus efficace du stockage sur disque, EMR Serverless effectue régulièrement une rotation des journaux pour les tâches de streaming de longue durée. Cela permet d'éviter l'accumulation de journaux qui pourrait consommer tout l'espace disque.
+ **Compaction des journaux** : vous aide à gérer et à optimiser efficacement les fichiers journaux dans le cadre d'une persistance gérée. Le compactage améliore également l'expérience de débogage lorsque vous utilisez le serveur d'historique Spark géré.
**Sources de données et récepteurs de données pris en charge**
EMR Serverless fonctionne avec un certain nombre de sources de données d'entrée et de récepteurs de données de sortie :
+ Sources de données d'entrée prises en charge : Amazon Kinesis Data Streams, Amazon Managed Streaming for Apache Kafka et clusters Apache Kafka autogérés. Par défaut, les versions 7.1.0 et supérieures d'Amazon EMR incluent le connecteur [Amazon Kinesis Data Streams](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-structured-streaming-kinesis.html). Vous n'avez donc pas besoin de créer ou de télécharger de packages supplémentaires.
+ Récepteurs de données de sortie pris en charge : tables AWS Glue Data Catalog, Amazon S3, Amazon Redshift, MySQL, PostgreSQL Oracle, Oracle, Microsoft SQL, Apache Iceberg, Delta Lake et Apache Hudi.
## Considérations et restrictions
Lorsque vous utilisez des jobs de streaming, gardez à l'esprit les considérations et limites suivantes.
+ Les jobs de streaming sont pris en charge par les [versions 7.1.0 et supérieures d'Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-710-release.html).
+ EMR Serverless s'attend à ce que les tâches de streaming s'exécutent pendant une longue période. Vous ne pouvez donc pas définir un délai d'exécution pour limiter le temps d'exécution de la tâche.
+ Les jobs de streaming ne sont compatibles qu'avec le moteur Spark, qui repose sur le [framework de streaming structuré](https://spark.apache.org/streaming/).
+ EMR Serverless réessaie indéfiniment des tâches de streaming, et vous ne pouvez pas personnaliser le nombre maximum de tentatives. La prévention du thrash est automatiquement incluse pour arrêter la nouvelle tentative si le nombre de tentatives infructueuses a dépassé un seuil défini sur une fenêtre horaire. Le seuil par défaut est de cinq tentatives infructueuses en une heure. Vous pouvez configurer ce seuil pour qu'il soit compris entre 1 et 10 tentatives. Pour plus d'informations, reportez-vous à la section [Résilience du travail](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/SECTION-jobs-resiliency.xml.html).
+ Les tâches de streaming comportent des points de contrôle pour enregistrer l'état d'exécution et la progression, afin qu'EMR Serverless puisse reprendre la tâche de streaming à partir du dernier point de contrôle. Pour plus d'informations, reportez-vous à la section [Restaurer après un échec avec le point de contrôle dans](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#recovering-from-failures-with-checkpointing) la documentation d'Apache Spark.
# Commencer à diffuser des jobs
Consultez les instructions suivantes pour savoir comment démarrer avec les jobs de streaming.
1. Suivez [Getting started with Amazon EMR Serverless pour créer une application](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html). Notez que votre application doit exécuter [Amazon EMR version 7.1.0](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-710-release.html) ou supérieure.
1. Une fois que votre application est prête, définissez le `mode` paramètre `STREAMING` sur pour soumettre une tâche de streaming, comme dans l' AWS CLI exemple suivant.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3"
}
}'
```
# Connecteurs de streaming pris en charge
Les connecteurs de streaming facilitent la lecture des données depuis une source de streaming et peuvent également écrire des données sur un récepteur de streaming.
Les connecteurs de streaming pris en charge sont les suivants :
**Connecteur Amazon Kinesis Data Streams**
Le connecteur [Amazon Kinesis Data Streams](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-structured-streaming-kinesis.html) pour Apache Spark permet de créer des applications de streaming et des pipelines qui consomment des données depuis Amazon Kinesis Data Streams et y écrivent des données. Le connecteur prend en charge une consommation de ventilateur améliorée avec un débit de lecture dédié pouvant atteindre 2 Mo/seconde par partition. Par défaut, Amazon EMR Serverless 7.1.0 et versions ultérieures inclut le connecteur. Vous n'avez donc pas besoin de créer ou de télécharger de packages supplémentaires. Pour plus d'informations sur le connecteur, reportez-vous à la [ spark-sql-kinesis-connectorpage sur GitHub](https://github.com/awslabs/spark-sql-kinesis-connector/).
L'exemple suivant montre comment démarrer une tâche avec la dépendance du connecteur Kinesis Data Streams.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--jars /usr/share/aws/kinesis/spark-sql-kinesis/lib/spark-streaming-sql-kinesis-connector.jar"
}
}'
```
Pour vous connecter à Kinesis Data Streams, configurez l'application EMR Serverless avec un accès VPC et utilisez un point de terminaison VPC pour autoriser l'accès privé, ou utilisez une passerelle NAT pour obtenir un accès public. Pour plus d'informations, reportez-vous à la section [Configuration de l'accès au VPC.](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/vpc-access.html) Vous devez également vous assurer que votre rôle d'exécution des tâches dispose des autorisations de lecture et d'écriture nécessaires pour accéder aux flux de données requis. Pour en savoir plus sur la configuration d'un rôle d'exécution de tâche, consultez la section [Rôles d'exécution de tâches pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/security-iam-runtime-role.html) Serverless. Pour une liste complète de toutes les autorisations requises, consultez la [spark-sql-kinesis-connector page sur GitHub](https://github.com/awslabs/spark-sql-kinesis-connector/?tab=readme-ov-file#how-to-use-it).
**Connecteur Apache Kafka**
Le connecteur Apache Kafka pour le streaming structuré Spark est un connecteur open source créé par la communauté Spark et est disponible dans un référentiel Maven. Ce connecteur permet aux applications de streaming structuré Spark de lire et d'écrire des données depuis Apache Kafka autogéré et Amazon Managed Streaming for Apache Kafka. Pour plus d'informations sur le connecteur, reportez-vous au [guide d'intégration de Structured Streaming \$1 Kafka](https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html) dans la documentation d'Apache Spark.
L'exemple suivant montre comment inclure le connecteur Kafka dans votre demande d'exécution de tâche.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--packages org.apache.spark:spark-sql-kafka-0-10_2.12:"
}
}'
```
La version du connecteur Apache Kafka dépend de la version de votre EMR Serverless et de la version de Spark correspondante. Pour trouver la bonne version de Kafka, reportez-vous au Guide d'[intégration de Structured Streaming \$1 Kafka](https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html).
Pour utiliser Amazon Managed Streaming for Apache Kafka avec l'authentification IAM, incluez une autre dépendance pour permettre au connecteur Kafka de se connecter à Amazon MSK avec IAM. Pour plus d'informations, consultez le [aws-msk-iam-auth référentiel sur GitHub](https://github.com/aws/aws-msk-iam-auth). Vous devez également vous assurer que le rôle d'exécution des tâches dispose des autorisations IAM nécessaires. L'exemple suivant montre comment utiliser le connecteur avec l'authentification IAM.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--packages org.apache.spark:spark-sql-kafka-0-10_2.12:,software.amazon.msk:aws-msk-iam-auth:"
}
}'
```
Pour utiliser le connecteur Kafka et la bibliothèque d'authentification IAM d'Amazon MSK, configurez l'application EMR Serverless avec un accès VPC. Vos sous-réseaux doivent avoir accès à Internet et utiliser une passerelle NAT pour accéder aux dépendances Maven. Pour plus d'informations, reportez-vous à la section [Configuration de l'accès au VPC.](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/vpc-access.html) Les sous-réseaux doivent disposer d'une connectivité réseau pour accéder au cluster Kafka. Cela est vrai que votre cluster Kafka soit autogéré ou que vous utilisiez Amazon Managed Streaming pour Apache Kafka Kafka.
# Gestion des journaux de tâches en streaming
Les tâches de streaming prennent en charge la rotation des journaux pour les journaux des applications Spark et les journaux d'événements, ainsi que le compactage des journaux pour les journaux d'événements Spark. Cela vous permet de gérer efficacement vos ressources.
**Rotation du journal**
Les tâches de streaming prennent en charge la rotation des journaux des applications Spark et des journaux d'événements. La rotation des journaux empêche les longues tâches de streaming de générer des fichiers journaux volumineux susceptibles d'occuper tout l'espace disque disponible. La rotation des journaux vous permet d'économiser de l'espace disque et d'éviter les échecs de tâches dus à un espace disque insuffisant. Pour plus d'informations, reportez-vous à [Rotation des journaux](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/rotating-logs.html).
**Compactage des bûches**
Les tâches de streaming prennent également en charge le compactage des journaux d'événements Spark chaque fois que la journalisation gérée est disponible. Pour plus de détails sur la journalisation gérée, reportez-vous à la section [Journalisation avec stockage géré](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html#jobs-log-storage-managed-storage). Les tâches de streaming peuvent s'exécuter pendant une longue période, et la quantité de données d'événements peut s'accumuler au fil du temps et augmenter considérablement la taille des fichiers journaux. Le serveur d'historique Spark lit et charge ces événements en mémoire pour l'interface utilisateur de l'application Spark. Ce processus peut entraîner des latences et des coûts élevés, en particulier si les journaux d'événements stockés dans Amazon S3 sont très volumineux.
Le compactage des journaux réduit la taille du journal des événements, de sorte que le serveur d'historique Spark n'a pas besoin de charger plus de 1 Go de journaux d'événements à tout moment. Pour plus d'informations, reportez-vous à la section [Surveillance et instrumentation](https://spark.apache.org/docs/latest/monitoring.html) de la documentation d'Apache Spark.
# Utilisation des configurations Spark lorsque vous exécutez des tâches EMR sans serveur
Vous pouvez exécuter des tâches Spark sur une application dont le `type` paramètre est défini sur`SPARK`. Les tâches doivent être compatibles avec la version de Spark compatible avec la version de lancement d'Amazon EMR. Par exemple, lorsque vous exécutez des tâches avec Amazon EMR version 6.6.0, celles-ci doivent être compatibles avec Apache Spark 3.2.0. Pour plus d'informations sur les versions de l'application pour chaque version, reportez-vous à[Versions de lancement d'Amazon EMR Serverless](release-versions.md).
## Paramètres de la tâche Spark
Lorsque vous utilisez l'[`StartJobRun`API](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html) pour exécuter une tâche Spark, spécifiez les paramètres suivants.
**Topics**
+ [Rôle d'exécution de la tâche Spark](#spark-defaults-executionRoleArn)
+ [Paramètre du pilote de tâche Spark](#spark-defaults-jobDriver)
+ [Paramètre de remplacement de la configuration Spark](#spark-defaults-configurationOverrides)
+ [Optimisation dynamique de l'allocation des ressources](#spark-defaults-dynamicResourceAllocation)
### Rôle d'exécution de la tâche Spark
Permet **`executionRoleArn`**de spécifier l'ARN du rôle IAM que votre application utilise pour exécuter les tâches Spark. Ce rôle doit contenir les autorisations suivantes :
+ Lisez à partir de compartiments S3 ou d'autres sources de données où résident vos données
+ Lisez à partir de compartiments ou de préfixes S3 où réside votre PySpark script ou votre fichier JAR
+ Écrivez dans les compartiments S3 où vous avez l'intention d'écrire votre sortie finale
+ Écrire des journaux dans un compartiment ou un préfixe S3 qui spécifie `S3MonitoringConfiguration`
+ Accès aux clés KMS si vous utilisez des clés KMS pour chiffrer les données de votre compartiment S3
+ Accès au catalogue de données AWS Glue si vous utilisez SparkSQL
Si votre tâche Spark lit ou écrit des données depuis ou vers d'autres sources de données, spécifiez les autorisations appropriées dans ce rôle IAM. Si vous ne fournissez pas ces autorisations au rôle IAM, la tâche risque d'échouer. Pour plus d’informations, consultez [Rôles d'exécution des tâches pour Amazon EMR Serverless](security-iam-runtime-role.md) et [Stockage des journaux](logging.md).
### Paramètre du pilote de tâche Spark
**`jobDriver`**À utiliser pour fournir des informations sur la tâche. Le paramètre du pilote de tâche n'accepte qu'une seule valeur pour le type de tâche que vous souhaitez exécuter. Pour une tâche Spark, la valeur du paramètre est`sparkSubmit`. Vous pouvez utiliser ce type de tâche pour exécuter Scala PySpark, Java et toute autre tâche prise en charge via Spark Submit. Les tâches Spark ont les paramètres suivants :
+ **`sparkSubmitParameters`**— Il s'agit des paramètres Spark supplémentaires que vous souhaitez envoyer à la tâche. Utilisez ce paramètre pour remplacer les propriétés Spark par défaut, telles que la mémoire du pilote ou le nombre d'exécuteurs, telles que celles définies dans les arguments `--conf` or`--class`.
+ **`entryPointArguments`**— Il s'agit d'un tableau d'arguments que vous souhaitez transmettre à votre fichier JAR ou Python principal. Vous devez gérer la lecture de ces paramètres à l'aide de votre code entrypoint. Séparez chaque argument du tableau par une virgule.
+ **`entryPoint`**— Il s'agit de la référence dans Amazon S3 au fichier JAR ou Python principal que vous souhaitez exécuter. Si vous utilisez un fichier JAR Scala ou Java, spécifiez la classe d'entrée principale dans l'`--class`argument `SparkSubmitParameters` using the.
Pour plus d'informations, reportez-vous à la section [Lancement d'applications avec spark-submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit).
### Paramètre de remplacement de la configuration Spark
**`configurationOverrides`**À utiliser pour remplacer les propriétés de configuration au niveau de la surveillance et au niveau de l'application. Ce paramètre accepte un objet JSON avec les deux champs suivants :
+ **`monitoringConfiguration`**‐ Utilisez ce champ pour spécifier l'URL Amazon S3 (`s3MonitoringConfiguration`) où vous souhaitez que la tâche EMR Serverless stocke les journaux de votre tâche Spark. Assurez-vous d'avoir créé ce compartiment dans le même compartiment Compte AWS que celui qui héberge votre application et dans celui Région AWS où votre tâche est exécutée.
+ **`applicationConfiguration`**— Pour remplacer les configurations par défaut des applications, vous pouvez fournir un objet de configuration dans ce champ. Vous pouvez utiliser une syntaxe abrégée pour fournir la configuration, ou vous pouvez faire référence à l'objet de configuration dans un fichier JSON. Les objets de configuration sont composés d'une classification, de propriétés et de configurations imbriquées en option. Les propriétés sont les paramètres que vous souhaitez remplacer dans ce fichier. Vous pouvez spécifier plusieurs classifications pour plusieurs applications d'un seul objet JSON.
**Note**
Les classifications de configuration disponibles varient en fonction de la version EMR Serverless spécifique. Par exemple, les classifications pour Log4j personnalisées ne `spark-executor-log4j2` sont disponibles qu'avec les versions 6.8.0 `spark-driver-log4j2` et supérieures.
Si vous utilisez la même configuration dans une dérogation d'application et dans les paramètres d'envoi de Spark, les paramètres d'envoi de Spark sont prioritaires. Les configurations sont classées par ordre de priorité comme suit, du plus haut au plus bas :
+ Configuration fournie par EMR Serverless lors de sa création. `SparkSession`
+ Configuration que vous fournissez dans le cadre `sparkSubmitParameters` de l'`--conf`argument.
+ La configuration que vous fournissez dans le cadre de votre application remplace lorsque vous démarrez une tâche.
+ Configuration que vous fournissez `runtimeConfiguration` lors de la création d'une application.
+ Configurations optimisées utilisées par Amazon EMR pour cette version.
+ Configurations open-source par défaut pour l'application.
Pour plus d'informations sur la déclaration de configurations au niveau de l'application et sur le remplacement de configurations lors de l'exécution d'une tâche, reportez-vous à[Configuration d'application par défaut pour EMR Serverless](default-configs.md).
### Optimisation dynamique de l'allocation des ressources
`dynamicAllocationOptimization`À utiliser pour optimiser l'utilisation des ressources dans EMR Serverless. La définition de cette propriété sur `true` dans votre classification de configuration Spark indique à EMR Serverless d'optimiser l'allocation des ressources de l'exécuteur afin de mieux aligner le taux auquel Spark demande et annule des exécuteurs avec le taux auquel EMR Serverless crée et libère des travailleurs. EMR Serverless réutilise ainsi de manière plus optimale les travailleurs d'une étape à l'autre, ce qui permet de réduire les coûts lors de l'exécution de tâches comportant plusieurs étapes tout en maintenant les mêmes performances.
Cette propriété est disponible dans toutes les versions d'Amazon EMR.
Voici un exemple de classification de configuration avec`dynamicAllocationOptimization`.
```
[
{
"Classification": "spark",
"Properties": {
"dynamicAllocationOptimization": "true"
}
}
]
```
Tenez compte des points suivants si vous utilisez l'optimisation de l'allocation dynamique :
+ Cette optimisation est disponible pour les tâches Spark pour lesquelles vous avez activé l'allocation dynamique des ressources.
+ Pour obtenir le meilleur rapport coût-efficacité, nous vous suggérons de configurer une limite d'échelle supérieure pour les travailleurs en utilisant soit le paramètre au niveau de la tâche, soit le paramètre `spark.dynamicAllocation.maxExecutors` de [capacité maximale au niveau de l'application](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/app-behavior.html#max-capacity) en fonction de votre charge de travail.
+ Vous ne remarquerez peut-être pas d'amélioration des coûts dans le cas de tâches plus simples. Par exemple, si votre tâche s'exécute sur un petit ensemble de données ou s'exécute en une seule étape, Spark n'a peut-être pas besoin d'un plus grand nombre d'exécuteurs ou de plusieurs événements de dimensionnement.
+ Les tâches comportant une séquence composée d'une grande étape, d'étapes plus petites, puis d'une nouvelle étape de grande envergure peuvent connaître une régression au cours de l'exécution des tâches. Dans la mesure où EMR Serverless utilise les ressources de manière plus efficace, cela peut entraîner une diminution du nombre de travailleurs disponibles pour les étapes plus importantes, ce qui se traduit par une durée d'exécution plus longue.
## Propriétés de la tâche Spark
Le tableau suivant répertorie les propriétés Spark facultatives et leurs valeurs par défaut que vous pouvez remplacer lorsque vous soumettez une tâche Spark.
**Propriétés Spark facultatives et valeurs par défaut**
| Clé | Description | Valeur par défaut |
| --- | --- | --- |
| spark.archives | Liste d'archives séparées par des virgules que Spark extrait dans le répertoire de travail de chaque exécuteur. Les types de fichiers pris en charge incluent .jar .tar.gz, .tgz et.zip. Pour spécifier le nom du répertoire à extraire, ajoutez-le \$1 après le nom du fichier que vous souhaitez extraire. Par exemple, file.zip\$1directory. | NULL |
| spark.authenticate | Option qui active l'authentification des connexions internes de Spark. | TRUE |
| spark.driver.cores | Nombre de cœurs utilisés par le pilote. | 4 |
| spark.driver.extraJavaOptions | Options Java supplémentaires pour le pilote Spark. | NULL |
| spark.driver.memory | La quantité de mémoire utilisée par le pilote. | 14 G |
| spark.dynamicAllocation.enabled | Option qui active l'allocation dynamique des ressources. Cette option augmente ou diminue le nombre d'exécuteurs enregistrés auprès de l'application, en fonction de la charge de travail. | TRUE |
| spark.dynamicAllocation.executorIdleTimeout | Durée pendant laquelle un exécuteur peut rester inactif avant que Spark ne le supprime. Cela ne s'applique que si vous activez l'allocation dynamique. | Années 60 |
| spark.dynamicAllocation.initialExecutors | Le nombre initial d'exécuteurs à exécuter si vous activez l'allocation dynamique. | 3 |
| spark.dynamicAllocation.maxExecutors | Limite supérieure du nombre d'exécuteurs si vous activez l'allocation dynamique. | Pour les versions 6.10.0 et supérieures, `infinity` Pour les versions 6.9.0 et antérieures, `100` |
| spark.dynamicAllocation.minExecutors | Limite inférieure du nombre d'exécuteurs si vous activez l'allocation dynamique. | 0 |
| spark.emr-serverless.allocation.batch.size | Le nombre de conteneurs à demander dans chaque cycle d'allocation d'exécuteur. Il y a un intervalle d'une seconde entre chaque cycle d'allocation. | 20 |
| spark.emr-serverless.driver.disk | Le disque du pilote Spark. | 20G |
| spark.emr-serverless.driverEnv.[KEY] | Option qui ajoute des variables d'environnement au pilote Spark. | NULL |
| spark.emr-serverless.executor.disk | Le disque exécuteur Spark. | 20G |
| spark.emr-serverless.memoryOverheadFactor | Définit la surcharge de mémoire à ajouter à la mémoire du conteneur du pilote et de l'exécuteur. | 0.1 |
| spark.emr-serverless.driver.disk.type | Type de disque connecté au pilote Spark. | Standard |
| spark.emr-serverless.executor.disk.type | Type de disque attaché aux exécuteurs Spark. | Standard |
| spark.executor.cores | Le nombre de cœurs utilisés par chaque exécuteur. | 4 |
| spark.executor.extraJavaOptions | Options Java supplémentaires pour l'exécuteur Spark. | NULL |
| spark.executor.instances | Nombre de conteneurs d'exécuteurs Spark à allouer. | 3 |
| spark.executor.memory | La quantité de mémoire utilisée par chaque exécuteur. | 14 G |
| spark.executorEnv.[KEY] | Option qui ajoute des variables d'environnement aux exécuteurs Spark. | NULL |
| spark.files | Une liste de fichiers séparés par des virgules à placer dans le répertoire de travail de chaque exécuteur. Vous pouvez accéder aux chemins de ces fichiers dans l'exécuteur avecSparkFiles.get(fileName). | NULL |
| spark.hadoop.hive.metastore.client.factory.class | La classe d'implémentation du métastore Hive. | NULL |
| spark.jars | JAR supplémentaires à ajouter au chemin de classe d'exécution du pilote et des exécuteurs. | NULL |
| spark.network.crypto.enabled | Option qui active le chiffrement RPC basé sur AES. Cela inclut le protocole d'authentification ajouté dans Spark 2.2.0. | FALSE |
| spark.sql.warehouse.dir | Emplacement par défaut pour les bases de données et les tables gérées. | Pour \$1PWD/spark-warehouse |
| spark.submit.pyFiles | Liste séparée par des .zip virgules .egg de ou de .py fichiers à placer dans les applications PYTHONPATH Python. | NULL |
Le tableau suivant répertorie les paramètres d'envoi par défaut de Spark.
**Paramètres d'envoi par défaut de Spark**
| Clé | Description | Valeur par défaut |
| --- | --- | --- |
| archives | Liste d'archives séparées par des virgules que Spark extrait dans le répertoire de travail de chaque exécuteur. | NULL |
| class | Classe principale de l'application (pour les applications Java et Scala). | NULL |
| conf | Propriété de configuration arbitraire de Spark. | NULL |
| driver-cores | Nombre de cœurs utilisés par le pilote. | 4 |
| driver-memory | La quantité de mémoire utilisée par le pilote. | 14 G |
| executor-cores | Le nombre de cœurs utilisés par chaque exécuteur. | 4 |
| executor-memory | La quantité de mémoire utilisée par l'exécuteur. | 14 G |
| files | Liste de fichiers séparés par des virgules à placer dans le répertoire de travail de chaque exécuteur. Vous pouvez accéder aux chemins de ces fichiers dans l'exécuteur avecSparkFiles.get(fileName). | NULL |
| jars | Une liste de fichiers jar séparés par des virgules à inclure dans les chemins de classe du pilote et de l'exécuteur. | NULL |
| num-executors | Le nombre d'exécuteurs à lancer. | 3 |
| py-files | Une liste séparée par des virgules de .zip.egg, ou de .py fichiers à placer sur les applications PYTHONPATH Python. | NULL |
| verbose | Option qui active une sortie de débogage supplémentaire. | NULL |
## Bonnes pratiques en matière de configuration des ressources
### Configuration des ressources du pilote et de l'exécuteur via l'API StartJobRun
**Note**
Les cœurs du pilote et de l'exécuteur Spark ainsi que les propriétés de mémoire, s'ils sont spécifiés, doivent être spécifiés directement dans la demande StartJobRun d'API.
La configuration de vos ressources de cette manière garantit qu'EMR Serverless peut allouer les bonnes ressources avant d'exécuter la tâche. Cela contraste avec les paramètres fournis dans le script utilisateur, tels que dans le fichier .py ou .jar, qui sont évalués trop tard, car les pilotes et les exécuteurs sont parfois préconfigurés avant le début de l'exécution du script. Deux méthodes sont prises en charge pour configurer ces ressources lors de la soumission des tâches :
#### Option 1 : utilisation sparkSubmitParameters
```
"jobDriver": {
"sparkSubmit": {
"entryPoint": "s3://your-script-path.py",
"sparkSubmitParameters": "—conf spark.driver.memory=4g \
—conf spark.driver.cores=2 \
—conf spark.executor.memory=8g \
—conf spark.executor.cores=4"
}
}
```
#### Option 2 : utiliser ConfigurationOverrides pour la classification spark-defaults
```
"configurationOverrides": {
"applicationConfiguration": [
{
"classification": "spark-defaults",
"properties": {
"spark.driver.memory": "4g",
"spark.driver.cores": "2",
"spark.executor.memory": "8g",
"spark.executor.cores": "4"
}
}
]
}
```
## Exemples Spark
L'exemple suivant montre comment utiliser l'`StartJobRun`API pour exécuter un script Python. Pour un end-to-end didacticiel utilisant cet exemple, reportez-vous à[Commencer à utiliser Amazon EMR Serverless](getting-started.md). Vous trouverez d'autres exemples d'exécution de PySpark tâches et d'ajout de dépendances Python dans le référentiel [EMR Serverless](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/pyspark) Samples. GitHub
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://us-east-1.elasticmapreduce/emr-containers/samples/wordcount/scripts/wordcount.py",
"entryPointArguments": ["s3://amzn-s3-demo-destination-bucket/wordcount_output"],
"sparkSubmitParameters": "--conf spark.executor.cores=1 --conf spark.executor.memory=4g --conf spark.driver.cores=1 --conf spark.driver.memory=4g --conf spark.executor.instances=1"
}
}'
```
L'exemple suivant montre comment utiliser l'`StartJobRun`API pour exécuter un Spark JAR.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi --conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}'
```
# Utilisation de configurations Hive lorsque vous exécutez des tâches EMR sans serveur
Vous pouvez exécuter des tâches Hive sur une application dont le `type` paramètre est défini sur. `HIVE` Les tâches doivent être compatibles avec la version de Hive compatible avec la version de lancement d'Amazon EMR. Par exemple, lorsque vous exécutez des tâches sur une application avec Amazon EMR version 6.6.0, votre tâche doit être compatible avec Apache Hive 3.1.2. Pour plus d'informations sur les versions de l'application pour chaque version, reportez-vous à[Versions de lancement d'Amazon EMR Serverless](release-versions.md).
## Paramètres du job Hive
Lorsque vous utilisez l'[`StartJobRun`API](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html) pour exécuter une tâche Hive, spécifiez les paramètres suivants.
**Topics**
+ [Rôle d'exécution du job Hive](#hive-defaults-executionRoleArn)
+ [Paramètre du pilote de tâche Hive](#hive-defaults-jobDriver)
+ [Paramètre de remplacement de la configuration Hive](#hive-defaults-configurationOverrides)
### Rôle d'exécution du job Hive
Permet **`executionRoleArn`**de spécifier l'ARN du rôle IAM que votre application utilise pour exécuter les tâches Hive. Ce rôle doit contenir les autorisations suivantes :
+ Lisez à partir de compartiments S3 ou d'autres sources de données où résident vos données
+ Lisez à partir de compartiments ou de préfixes S3 où résident votre fichier de requête Hive et votre fichier de requête d'initialisation
+ Lisez et écrivez dans des compartiments S3 où se trouvent votre répertoire Hive Scratch et votre répertoire d'entrepôt Hive Metastore
+ Écrivez dans les compartiments S3 où vous avez l'intention d'écrire votre sortie finale
+ Écrire des journaux dans un compartiment ou un préfixe S3 qui spécifie `S3MonitoringConfiguration`
+ Accès aux clés KMS si vous utilisez des clés KMS pour chiffrer les données de votre compartiment S3
+ Accès au catalogue de données AWS Glue
Si votre tâche Hive lit ou écrit des données depuis ou vers d'autres sources de données, spécifiez les autorisations appropriées dans ce rôle IAM. Si vous ne fournissez pas ces autorisations au rôle IAM, votre tâche risque d'échouer. Pour plus d’informations, consultez [Rôles d'exécution des tâches pour Amazon EMR Serverless](security-iam-runtime-role.md).
### Paramètre du pilote de tâche Hive
**`jobDriver`**À utiliser pour fournir des informations sur la tâche. Le paramètre du pilote de tâche n'accepte qu'une seule valeur pour le type de tâche que vous souhaitez exécuter. Lorsque vous spécifiez `hive` le type de tâche, EMR Serverless transmet une requête Hive au paramètre. `jobDriver` Les jobs Hive possèdent les paramètres suivants :
+ **`query`**— Il s'agit de la référence dans Amazon S3 au fichier de requête Hive que vous souhaitez exécuter.
+ **`parameters`**— Il s'agit des propriétés de configuration supplémentaires de Hive que vous souhaitez remplacer. Pour remplacer les propriétés, transmettez-les à ce paramètre en tant que`--hiveconf property=value`. Pour remplacer des variables, transmettez-les à ce paramètre sous `--hivevar key=value` la forme.
+ **`initQueryFile`**— Il s'agit du fichier de requête init Hive. Hive exécute ce fichier avant votre requête et peut l'utiliser pour initialiser des tables.
### Paramètre de remplacement de la configuration Hive
**`configurationOverrides`**À utiliser pour remplacer les propriétés de configuration au niveau de la surveillance et au niveau de l'application. Ce paramètre accepte un objet JSON avec les deux champs suivants :
+ **`monitoringConfiguration`**— Utilisez ce champ pour spécifier l'URL Amazon S3 (`s3MonitoringConfiguration`) où vous souhaitez que la tâche EMR Serverless stocke les journaux de votre tâche Hive. Assurez-vous de créer ce compartiment dans le même compartiment Compte AWS que celui qui héberge votre application et dans celui Région AWS où votre tâche est exécutée.
+ **`applicationConfiguration`**— Vous pouvez fournir un objet de configuration dans ce champ pour remplacer les configurations par défaut des applications. Vous pouvez utiliser une syntaxe abrégée pour fournir la configuration, ou vous pouvez faire référence à l'objet de configuration dans un fichier JSON. Les objets de configuration sont composés d'une classification, de propriétés et de configurations imbriquées en option. Les propriétés sont les paramètres que vous souhaitez remplacer dans ce fichier. Vous pouvez spécifier plusieurs classifications pour plusieurs applications d'un seul objet JSON.
**Note**
Les classifications de configuration disponibles varient en fonction de la version EMR Serverless spécifique. Par exemple, les classifications pour Log4j personnalisées ne `spark-executor-log4j2` sont disponibles qu'avec les versions 6.8.0 `spark-driver-log4j2` et supérieures.
Si vous transmettez la même configuration dans une dérogation d'application et dans les paramètres Hive, les paramètres Hive sont prioritaires. La liste suivante classe les configurations de la priorité la plus élevée à la plus faible.
+ Configuration que vous fournissez dans le cadre des paramètres Hive avec`--hiveconf property=value`.
+ La configuration que vous fournissez dans le cadre de votre application remplace lorsque vous démarrez une tâche.
+ Configuration que vous fournissez `runtimeConfiguration` lors de la création d'une application.
+ Configurations optimisées attribuées par Amazon EMR à la publication.
+ Configurations open source par défaut pour l'application.
Pour plus d'informations sur la déclaration de configurations au niveau de l'application et sur le remplacement de configurations lors de l'exécution d'une tâche, reportez-vous à[Configuration d'application par défaut pour EMR Serverless](default-configs.md).
## Propriétés des tâches Hive
Le tableau suivant répertorie les propriétés obligatoires qui sont configurées lorsque vous soumettez une tâche Hive.
**Propriétés obligatoires du job Hive**
| Paramètre | Description |
| --- | --- |
| hive.exec.scratchdir | Emplacement Amazon S3 où EMR Serverless crée des fichiers temporaires pendant l'exécution de la tâche Hive. |
| hive.metastore.warehouse.dir | Emplacement Amazon S3 des bases de données pour les tables gérées dans Hive. |
Le tableau suivant répertorie les propriétés optionnelles de Hive et leurs valeurs par défaut que vous pouvez remplacer lorsque vous soumettez une tâche Hive.
**Propriétés Hive facultatives et valeurs par défaut**
| Paramètre | Description | Valeur par défaut |
| --- | --- | --- |
| fs.s3.customAWSCredentialsProvider | Le fournisseur AWS d'informations d'identification que vous souhaitez utiliser. | com.amazonaws.auth.default AWSCredentials ProviderChain |
| fs.s3a.aws.credentials.provider | Le fournisseur AWS d'informations d'identification que vous souhaitez utiliser avec un système de fichiers S3A. | com.amazonaws.auth.default AWSCredentials ProviderChain |
| hive.auto.convert.join | Option qui active la conversion automatique des jointures communes en mapjoins, en fonction de la taille du fichier d'entrée. | TRUE |
| hive.auto.convert.join.noconditionaltask | Option qui active l'optimisation lorsque Hive convertit une jointure commune en mapjoin en fonction de la taille du fichier d'entrée. | TRUE |
| hive.auto.convert.join.noconditionaltask.size | Une jointure est convertie directement en une jointure mapjoin inférieure à cette taille. | La valeur optimale est calculée en fonction de la mémoire des tâches Tez |
| hive.cbo.enable | Option qui active les optimisations basées sur les coûts avec le framework Calcite. | TRUE |
| hive.cli.tez.session.async | Possibilité de démarrer une session Tez en arrière-plan pendant que votre requête Hive se compile. Lorsqu'il est défini surfalse, Tez AM démarre après la compilation de votre requête Hive. | TRUE |
| hive.compute.query.using.stats | Option qui active Hive pour répondre à certaines requêtes avec des statistiques stockées dans le métastore. Pour les statistiques de base, définissez hive.stats.autogather surTRUE. Pour une collection de requêtes plus avancée, exécutezanalyze table queries. | TRUE |
| hive.default.fileformat | Format de fichier par défaut pour les CREATE TABLE instructions. Vous pouvez le remplacer explicitement si vous le spécifiez STORED AS [FORMAT] dans votre CREATE TABLE commande. | TEXTFILE |
| hive.driver.cores | Nombre de cœurs à utiliser pour le processus du pilote Hive. | 2 |
| hive.driver.disk | Taille du disque pour le pilote Hive. | 20G |
| hive.driver.disk.type | Type de disque pour le pilote Hive. | Standard |
| hive.tez.disk.type | La taille du disque pour les ouvriers. | Standard |
| hive.driver.memory | Quantité de mémoire à utiliser par processus de pilote Hive. La CLI Hive et le Tez Application Master partagent cette mémoire à parts égales avec 20 % de marge de manœuvre. | 6 G |
| hive.emr-serverless.launch.env.[KEY] | Option permettant de définir la variable d'KEYenvironnement dans tous les processus spécifiques à Hive, tels que votre pilote Hive, Tez AM et la tâche Tez. | |
| hive.exec.dynamic.partition | Options qui activent les partitions dynamiques en DML/DDL. | TRUE |
| hive.exec.dynamic.partition.mode | Option qui indique si vous souhaitez utiliser le mode strict ou le mode non strict. En mode strict, spécifiez au moins une partition statique au cas où vous remplaceriez accidentellement toutes les partitions. En mode non strict, toutes les partitions peuvent être dynamiques. | strict |
| hive.exec.max.dynamic.partitions | Le nombre maximum de partitions dynamiques créées par Hive au total. | 1 000 |
| hive.exec.max.dynamic.partitions.pernode | Nombre maximal de partitions dynamiques créées par Hive dans chaque nœud de mappage et de réduction. | 100 |
| hive.exec.orc.split.strategy | Attend l'une des valeurs suivantes : BIETL, ouHYBRID. Il ne s'agit pas d'une configuration au niveau de l'utilisateur. BIindique que vous souhaitez consacrer moins de temps à la génération fractionnée plutôt qu'à l'exécution de requêtes. ETLindique que vous souhaitez consacrer plus de temps à la génération fractionnée. HYBRIDspécifie un choix des stratégies précédentes sur la base de l'heuristique. | HYBRID |
| hive.exec.reducers.bytes.per.reducer | La taille de chaque réducteur. La valeur par défaut est de 256 Mo. Si la taille d'entrée est de 1 G, la tâche utilise 4 réducteurs. | 256000000 |
| hive.exec.reducers.max | Le nombre maximum de réducteurs. | 256 |
| hive.exec.stagingdir | Le nom du répertoire qui stocke les fichiers temporaires créés par Hive dans les emplacements des tables et dans l'emplacement du répertoire de travail spécifié dans la hive.exec.scratchdir propriété. | .hive-staging |
| hive.fetch.task.conversion | Attend l'une des valeurs suivantes : NONEMINIMAL, ouMORE. Hive peut convertir certaines requêtes en une seule FETCH tâche. Cela permet de minimiser le temps de latence. | MORE |
| hive.groupby.position.alias | Option qui oblige Hive à utiliser un alias de position de colonne dans les GROUP BY instructions. | FALSE |
| hive.input.format | Format de saisie par défaut. Réglez sur HiveInputFormat si vous rencontrez des problèmes avecCombineHiveInputFormat. | org.apache.hadoop.hive.ql.io.CombineHiveInputFormat |
| hive.log.explain.output | Option qui active les explications des sorties étendues pour toute requête de votre journal Hive. | FALSE |
| hive.log.level | Le niveau de journalisation de Hive. | INFO |
| hive.mapred.reduce.tasks.speculative.execution | Option qui active le lancement spéculatif pour les réducteurs. Compatible uniquement avec Amazon EMR 6.10.x et versions antérieures. | TRUE |
| hive.max-task-containers | Le nombre maximum de conteneurs simultanés. La mémoire du mappeur configurée est multipliée par cette valeur pour déterminer la mémoire disponible qui divise l'utilisation du calcul et de la préemption des tâches. | 1 000 |
| hive.merge.mapfiles | Option qui entraîne la fusion de petits fichiers à la fin d'une tâche cartographique uniquement. | TRUE |
| hive.merge.size.per.task | Taille des fichiers fusionnés à la fin de la tâche. | 256000000 |
| hive.merge.tezfiles | Option qui active la fusion de petits fichiers à la fin d'un Tez DAG. | FALSE |
| hive.metastore.client.factory.class | Nom de la classe d'usine qui produit les objets implémentant l'IMetaStoreClientinterface. | com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory |
| hive.metastore.glue.catalogid | Si le catalogue de données AWS Glue agit comme un métastore mais s'exécute sous une autre forme Compte AWS que les tâches, l'ID de l' Compte AWS endroit où les tâches sont exécutées. | NULL |
| hive.metastore.uris | L'URI Thrift que le client du metastore utilise pour se connecter au metastore distant. | NULL |
| hive.optimize.ppd | Option qui active le pushdown des prédicats. | TRUE |
| hive.optimize.ppd.storage | Option qui active le transfert des prédicats vers les gestionnaires de stockage. | TRUE |
| hive.orderby.position.alias | Option qui oblige Hive à utiliser un alias de position de colonne dans les ORDER BY instructions. | TRUE |
| hive.prewarm.enabled | Option qui active le préchauffage du récipient pour Tez. | FALSE |
| hive.prewarm.numcontainers | Le nombre de récipients à préchauffer pour Tez. | 10 |
| hive.stats.autogather | Option permettant à Hive de collecter automatiquement des statistiques de base lors de la INSERT OVERWRITE commande. | TRUE |
| hive.stats.fetch.column.stats | Option qui désactive l'extraction des statistiques des colonnes depuis le métastore. L'extraction des statistiques des colonnes peut s'avérer coûteuse lorsque le nombre de colonnes est élevé. | FALSE |
| hive.stats.gather.num.threads | Nombre de threads utilisés par les commandes partialscan et noscan analyze pour les tables partitionnées. Cela ne s'applique qu'aux formats de fichiers implémentés StatsProvidingRecordReader (comme ORC). | 10 |
| hive.strict.checks.cartesian.product | Options qui activent des contrôles de jointure cartésiens stricts. Ces contrôles interdisent un produit cartésien (une jointure croisée). | FALSE |
| hive.strict.checks.type.safety | Option qui active des contrôles de sécurité de type stricts et désactive la comparaison entre bigint les deux string etdouble. | TRUE |
| hive.support.quoted.identifiers | Attend une valeur de NONE ouCOLUMN. NONEimplique que seuls les caractères alphanumériques et les traits de soulignement sont valides dans les identifiants. COLUMNimplique que les noms de colonnes peuvent contenir n'importe quel caractère. | COLUMN |
| hive.tez.auto.reducer.parallelism | Option qui active la fonction de parallélisme du réducteur automatique Tez. Hive estime toujours la taille des données et définit des estimations de parallélisme. Tez échantillonne les tailles de sortie des sommets sources et ajuste les estimations au moment de l'exécution si nécessaire. | TRUE |
| hive.tez.container.size | La quantité de mémoire à utiliser par processus de tâche Tez. | 6144 |
| hive.tez.cpu.vcores | Le nombre de cœurs à utiliser pour chaque tâche Tez. | 2 |
| hive.tez.disk.size | Taille du disque pour chaque conteneur de tâches. | 20G |
| hive.tez.input.format | Le format d'entrée pour la génération de splits dans le Tez AM. | org.apache.hadoop.hive.ql.io.HiveInputFormat |
| hive.tez.min.partition.factor | Limite inférieure de réducteurs spécifiée par Tez lorsque vous activez le parallélisme des réducteurs automatiques. | 0.25 |
| hive.vectorized.execution.enabled | Option qui active le mode vectorisé d'exécution des requêtes. | TRUE |
| hive.vectorized.execution.reduce.enabled | Option qui active le mode vectorisé du côté réduction de l'exécution d'une requête. | TRUE |
| javax.jdo.option.ConnectionDriverName | Nom de classe de pilote pour un métastore JDBC. | org.apache.derby.jdbc.EmbeddedDriver |
| javax.jdo.option.ConnectionPassword | Le mot de passe associé à une base de données de métastore. | NULL |
| javax.jdo.option.ConnectionURL | Chaîne de connexion JDBC pour un métastore JDBC. | jdbc:derby:;databaseName=metastore\$1db;create=true |
| javax.jdo.option.ConnectionUserName | Nom d'utilisateur associé à une base de données Metastore. | NULL |
| mapreduce.input.fileinputformat.split.maxsize | La taille maximale d'une division lors du calcul de la division lorsque votre format d'entrée estorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat. La valeur 0 indique l'absence de limite. | 0 |
| tez.am.dag.cleanup.on.completion | Option qui active le nettoyage des données de shuffle lorsque le DAG est terminé. | TRUE |
| tez.am.emr-serverless.launch.env.[KEY] | Option permettant de définir la variable d'KEYenvironnement dans le processus Tez AM. Pour Tez AM, cette valeur remplace la hive.emr-serverless.launch.env.[KEY] valeur. | |
| tez.am.log.level | Le niveau de journalisation root qu'EMR Serverless transmet au serveur principal de l'application Tez. | INFO |
| tez.am.sleep.time.before.exit.millis | EMR Serverless devrait envoyer les événements ATS après cette période après la demande d'arrêt AM. | 0 |
| tez.am.speculation.enabled | Option qui entraîne le lancement spéculatif de tâches plus lentes. Cela peut aider à réduire la latence des tâches lorsque certaines tâches s'exécutent plus lentement en raison de machines défectueuses ou lentes. Compatible uniquement avec Amazon EMR 6.10.x et versions antérieures. | FALSE |
| tez.am.task.max.failed.attempts | Nombre maximal de tentatives susceptibles d'échouer pour une tâche donnée avant que celle-ci n'échoue. Ce nombre ne compte pas les tentatives annulées manuellement. | 3 |
| tez.am.vertex.cleanup.height | Distance à laquelle, si tous les sommets dépendants sont complets, Tez AM supprimera les données de mélange de sommets. Cette fonctionnalité est désactivée lorsque la valeur est 0. Les versions 6.8.0 et ultérieures d'Amazon EMR prennent en charge cette fonctionnalité. | 0 |
| tez.client.asynchronous-stop | Option permettant à EMR Serverless de transmettre les événements ATS avant de mettre fin au pilote Hive. | FALSE |
| tez.grouping.max-size | Limite de taille supérieure (en octets) d'un fractionnement groupé. Cette limite permet d'éviter des divisions trop importantes. | 1073741824 |
| tez.grouping.min-size | Limite de taille inférieure (en octets) d'un fractionnement groupé. Cette limite permet d'éviter un trop grand nombre de petites divisions. | 16777216 |
| tez.runtime.io.sort.mb | La taille de la mémoire tampon souple lorsque Tez trie la sortie est triée. | La valeur optimale est calculée sur la base de la mémoire des tâches Tez |
| tez.runtime.unordered.output.buffer.size-mb | La taille de la mémoire tampon à utiliser si Tez n'écrit pas directement sur le disque. | La valeur optimale est calculée sur la base de la mémoire des tâches Tez |
| tez.shuffle-vertex-manager.max-src-fraction | Fraction des tâches source qui doivent être effectuées avant qu'EMR Serverless ne planifie toutes les tâches pour le sommet actuel (dans le cas d'une connexion). ScatterGather Le nombre de tâches prêtes à être planifiées sur le sommet actuel varie linéairement entre etmin-fraction. max-fraction Cela correspond à la valeur par défaut ou tez.shuffle-vertex-manager.min-src-fraction à la valeur la plus élevée. | 0.75 |
| tez.shuffle-vertex-manager.min-src-fraction | Fraction des tâches source qui doivent être effectuées avant qu'EMR Serverless ne planifie des tâches pour le sommet actuel (dans le cas d'une connexion). ScatterGather | 0.25 |
| tez.task.emr-serverless.launch.env.[KEY] | Option permettant de définir la variable d'KEYenvironnement dans le processus de tâche Tez. Pour les tâches Tez, cette valeur remplace la hive.emr-serverless.launch.env.[KEY] valeur. | |
| tez.task.log.level | Le niveau de journalisation racine qu'EMR Serverless transmet aux tâches Tez. | INFO |
| tez.yarn.ats.event.flush.timeout.millis | Durée maximale pendant laquelle AM doit attendre que les événements soient supprimés avant de s'arrêter. | 300 000 |
## Exemples d'emplois chez Hive
L'exemple de code suivant montre comment exécuter une requête Hive avec l'`StartJobRun`API.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/emr-serverless-hive/query/hive-query.ql",
"parameters": "--hiveconf hive.log.explain.output=false"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.exec.scratchdir": "s3://amzn-s3-demo-bucket/emr-serverless-hive/hive/scratch",
"hive.metastore.warehouse.dir": "s3://amzn-s3-demo-bucket/emr-serverless-hive/hive/warehouse",
"hive.driver.cores": "2",
"hive.driver.memory": "4g",
"hive.tez.container.size": "4096",
"hive.tez.cpu.vcores": "1"
}
}]
}'
```
Vous trouverez d'autres exemples d'exécution de tâches Hive dans le référentiel [EMR Serverless](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/hive) GitHub Samples.
# Résilience des tâches EMR sans serveur
Les versions 7.1.0 et supérieures d'EMR Serverless incluent la prise en charge de la résilience des tâches, de sorte qu'il réessaie automatiquement toutes les tâches ayant échoué sans aucune intervention manuelle de votre part. Un autre avantage de la résilience des tâches est qu'EMR Serverless déplace les exécutions de tâches vers une autre zone de disponibilité (AZ) en cas de problème avec une AZ.
Pour activer la résilience d'une tâche, définissez la politique de nouvelle tentative pour cette tâche. Une politique de nouvelles tentatives garantit qu'EMR Serverless redémarre automatiquement une tâche en cas d'échec. Les politiques de nouvelle tentative sont prises en charge pour les tâches par lots et en streaming. Personnalisez donc la résilience des tâches en fonction de votre cas d'utilisation. Le tableau suivant compare les comportements et les différences de résilience des tâches entre les tâches par lots et les tâches de streaming.
| | Traitements par lots | Offres d'emploi en streaming |
| --- | --- | --- |
| Comportement par défaut | Ne réexécute pas le job. | Réessaie toujours d'exécuter la tâche car l'application crée des points de contrôle pendant l'exécution de la tâche. |
| Point de nouvelle tentative | Les tâches par lots ne comportant pas de points de contrôle, EMR Serverless réexécute toujours la tâche depuis le début. | Les tâches de streaming prennent en charge les points de contrôle. Configurez donc la requête de streaming pour enregistrer l'état d'exécution et progresser vers un point de contrôle dans Amazon S3. EMR Serverless reprend l'exécution du job depuis le point de contrôle. Pour plus d'informations, reportez-vous à la section [Restaurer après un échec avec le point de contrôle dans](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#recovering-from-failures-with-checkpointing) la documentation d'Apache Spark. |
| Nombre maximum de tentatives de nouvelle tentative | Permet un maximum de 10 tentatives. | Les tâches de streaming sont dotées d'un contrôle intégré de prévention des thrash, de sorte que l'application arrête de réessayer les tâches si elles échouent toujours au bout d'une heure. Le nombre de tentatives par défaut dans un délai d'une heure est de cinq tentatives. Vous pouvez configurer ce nombre de tentatives pour qu'il soit compris entre 1 et 10. Vous ne pouvez pas personnaliser le nombre maximum de tentatives. La valeur 1 indique qu'il n'y a pas eu de nouvelle tentative. |
Lorsque EMR Serverless tente de réexécuter une tâche, il indexe également la tâche à l'aide d'un numéro de tentative. Suivez donc le cycle de vie d'une tâche au fil de ses tentatives.
Utilisez les opérations de l'API EMR Serverless ou AWS CLI pour modifier la résilience des tâches ou accéder aux informations relatives à la résilience des tâches. Pour plus d'informations, consultez le guide de l'[API EMR Serverless](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/Welcome.html).
Par défaut, EMR Serverless ne réexécute pas les tâches par lots. Pour activer les nouvelles tentatives pour les tâches par lots, configurez le `maxAttempts` paramètre lorsque vous démarrez l'exécution d'une tâche par lots. Le `maxAttempts` paramètre s'applique uniquement aux tâches par lots. La valeur par défaut est 1, ce qui signifie qu'il ne faut pas réexécuter la tâche. Les valeurs acceptées sont comprises entre 1 et 10 inclus.
L'exemple suivant montre comment spécifier un nombre maximum de 10 tentatives lors du démarrage d'une tâche.
```
aws emr-serverless start-job-run
--application-id \
--execution-role-arn \
--mode 'BATCH' \
--retry-policy '{
"maxAttempts": 10
}' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples-does-not-exist.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi"
}
}'
```
EMR Serverless réessaie indéfiniment les tâches de streaming en cas d'échec. Pour éviter le thrash dû à des échecs irrécupérables répétés, utilisez le `maxFailedAttemptsPerHour` pour configurer le contrôle de prévention du thrash pour les nouvelles tentatives de travail en streaming. Ce paramètre vous permet de spécifier le nombre maximum de tentatives infructueuses autorisées une heure avant qu'EMR Serverless arrête de réessayer. La valeur par défaut est cinq. Les valeurs acceptées sont comprises entre 1 et 10 inclus.
```
aws emr-serverless start-job-run
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--retry-policy '{
"maxFailedAttemptsPerHour": 7
}' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples-does-not-exist.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi"
}
}'
```
Vous pouvez également utiliser les autres opérations d'API d'exécution de tâches pour obtenir des informations sur les tâches. Par exemple, utilisez le `attempt` paramètre avec l'`GetJobRun`opération pour obtenir des informations sur une tentative de travail spécifique. Si vous n'incluez pas le `attempt` paramètre, l'opération renvoie des informations sur la dernière tentative.
```
aws emr-serverless get-job-run \
--job-run-id job-run-id \
--application-id application-id \
--attempt 1
```
L'`ListJobRunAttempts`opération renvoie des informations sur toutes les tentatives liées à l'exécution d'une tâche.
```
aws emr-serverless list-job-run-attempts \
--application-id application-id \
--job-run-id job-run-id
```
L'`GetDashboardForJobRun`opération crée et renvoie une URL qui permet d'accéder à l'application UIs pour l'exécution d'une tâche. Le `attempt` paramètre vous permet d'obtenir l'URL d'une tentative spécifique. Si vous n'incluez pas le `attempt` paramètre, l'opération renvoie des informations sur la dernière tentative.
```
aws emr-serverless get-dashboard-for-job-run \
--application-id application-id \
--job-run-id job-run-id \
--attempt 1
```
## Surveillance d'une tâche à l'aide d'une politique de relance
Le support de résilience des tâches ajoute également le nouvel événement **EMR Serverless** job run retry. EMR Serverless publie cet événement à chaque nouvelle tentative de la tâche. Vous pouvez utiliser cette notification pour suivre les nouvelles tentatives de la tâche. Pour plus d'informations sur les événements, consultez la section [Amazon EventBridge events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html).
## Connexion avec politique de nouvelle tentative
Chaque fois qu'EMR Serverless réessaie une tâche, la tentative génère son propre ensemble de journaux. Pour garantir qu'EMR Serverless puisse transmettre ces journaux à Amazon S3 et Amazon CloudWatch sans en remplacer aucun, EMR Serverless ajoute un préfixe au format du chemin du journal S3 et au nom du flux de journal pour inclure le numéro de CloudWatch tentative de la tâche.
Voici un exemple de ce à quoi ressemble le format.
```
'/applications//jobs//attempts//'.
```
Ce format garantit qu'EMR Serverless publie tous les journaux de chaque tentative de tâche vers son propre emplacement désigné dans Amazon S3 et. CloudWatch Pour plus de détails, reportez-vous à la section [Stockage des journaux](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html).
**Note**
EMR Serverless utilise uniquement ce format de préfixe pour toutes les tâches de streaming et les tâches par lots pour lesquelles la nouvelle tentative est activée.
# Configuration du métastore pour EMR Serverless
Un *métastore Hive* est un emplacement centralisé qui stocke les informations structurelles relatives à vos tables, notamment les schémas, les noms de partitions et les types de données. Avec EMR Serverless, vous pouvez conserver les métadonnées de cette table dans un métastore ayant accès à vos tâches.
Deux options s'offrent à vous pour créer un métastore Hive :
+ Le catalogue AWS de données Glue
+ Un métastore Apache Hive externe
## Utiliser le catalogue AWS de données Glue comme métastore
Vous pouvez configurer vos tâches Spark et Hive pour utiliser le catalogue de données AWS Glue comme métastore. Nous recommandons cette configuration lorsque vous avez besoin d'un métastore persistant ou d'un métastore partagé par différentes applications, services ou. Comptes AWS Pour plus d'informations sur le catalogue de données, reportez-vous à la section [Remplissage du catalogue de données AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html). Pour plus d'informations sur AWS la tarification de Glue, reportez-vous à [AWS la section Tarification de Glue](https://aws.amazon.com/glue/pricing).
Vous pouvez configurer votre tâche EMR Serverless pour utiliser le catalogue de données AWS Glue de la même manière Compte AWS que votre application ou d'une autre manière. Compte AWS
### Configuration du catalogue AWS de données Glue
Pour configurer le catalogue de données, choisissez le type d'application EMR sans serveur que vous souhaitez utiliser.
------
#### [ Spark ]
Lorsque vous utilisez EMR Studio pour exécuter vos tâches avec des applications EMR Serverless Spark, le catalogue de données AWS Glue est le métastore par défaut.
Lorsque vous utilisez SDKs ou AWS CLI, définissez la `spark.hadoop.hive.metastore.client.factory.class` configuration sur `com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory` dans les `sparkSubmit` paramètres de votre tâche d'exécution. L'exemple suivant montre comment configurer le catalogue de données avec AWS CLI.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/code/pyspark/extreme_weather.py",
"sparkSubmitParameters": "--conf spark.hadoop.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory --conf spark.driver.cores=1 --conf spark.driver.memory=3g --conf spark.executor.cores=4 --conf spark.executor.memory=3g"
}
}'
```
Vous pouvez également définir cette configuration lorsque vous créez une nouvelle configuration `SparkSession` dans votre code Spark.
```
from pyspark.sql import SparkSession
spark = (
SparkSession.builder.appName("SparkSQL")
.config(
"spark.hadoop.hive.metastore.client.factory.class",
"com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory",
)
.enableHiveSupport()
.getOrCreate()
)
# we can query tables with SparkSQL
spark.sql("SHOW TABLES").show()
# we can also them with native Spark
print(spark.catalog.listTables())
```
------
#### [ Hive ]
Pour les applications EMR Serverless Hive, le catalogue de données est le métastore par défaut. En d'autres termes, lorsque vous exécutez des tâches sur une application EMR Serverless Hive, Hive enregistre les informations du métastore dans le catalogue de données au même titre que votre application. Compte AWS Vous n'avez pas besoin d'un cloud privé virtuel (VPC) pour utiliser le catalogue de données comme métastore.
Pour accéder aux tables du métastore Hive, ajoutez les politiques AWS Glue requises décrites dans [Configuration des autorisations IAM](https://docs.aws.amazon.com/glue/latest/dg/getting-started-access.html) pour Glue. AWS
------
### Configuration de l'accès entre comptes pour EMR Serverless AWS et Glue Data Catalog
Pour configurer l'accès entre comptes pour EMR Serverless, connectez-vous d'abord à l'adresse suivante : Comptes AWS
+ `AccountA`— Et Compte AWS où vous avez créé une application EMR Serverless.
+ `AccountB`— Et Compte AWS qui contient un catalogue de données AWS Glue auquel vous souhaitez que votre tâche EMR Serverless puisse accéder.
1. Assurez-vous qu'un administrateur ou une autre identité autorisée `AccountB` attache une politique de ressources au catalogue de données dans`AccountB`. Cette politique accorde `AccountA` des autorisations spécifiques entre comptes pour effectuer des opérations sur les ressources du `AccountB` catalogue.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDataBases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"arn:aws:glue:*:123456789012:catalog"
],
"Sid": "AllowGLUEGetdatabase"
}
]
}
```
------
1. Ajoutez une politique IAM au rôle d'exécution des tâches EMR sans serveur afin que ce rôle puisse accéder aux ressources du catalogue de données `AccountA` dans. `AccountB`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDataBases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"arn:aws:glue:*:123456789012:catalog"
],
"Sid": "AllowGLUEGetdatabase"
}
]
}
```
------
1. Commencez à exécuter votre tâche. Cette étape est légèrement différente selon le `AccountA` type d'application EMR Serverless de l'application.
------
#### [ Spark ]
Transmettez la `spark.hadoop.hive.metastore.glue.catalogid` propriété `sparkSubmitParameters` comme indiqué dans l'exemple suivant. Remplacez *`AccountB-catalog-id`* par l'ID du catalogue de données dans`AccountB`.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/scripts/test.py",
"sparkSubmitParameters": "--conf spark.hadoop.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory --conf spark.hadoop.hive.metastore.glue.catalogid=AccountB-catalog-id --conf spark.executor.cores=1 --conf spark.executor.memory=1g --conf spark.driver.cores=1 --conf spark.driver.memory=1g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/logs/"
}
}
}'
```
------
#### [ Hive ]
Définissez la `hive.metastore.glue.catalogid` propriété dans la `hive-site` classification comme indiqué dans l'exemple suivant. Remplacez *`AccountB-catalog-id`* par l'ID du catalogue de données dans`AccountB`.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/hive/scripts/create_table.sql",
"parameters": "--hiveconf hive.exec.scratchdir=s3://amzn-s3-demo-bucket/hive/scratch --hiveconf hive.metastore.warehouse.dir=s3://amzn-s3-demo-bucket/hive/warehouse"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.metastore.glue.catalogid": "AccountB-catalog-id"
}
}]
}'
```
------
### Considérations relatives à l'utilisation du catalogue AWS de données Glue
Vous pouvez ajouter JARs un auxiliaire `ADD JAR` dans vos scripts Hive. Pour plus d'informations, reportez-vous à la section [Considérations relatives à l'utilisation de AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html#emr-hive-glue-considerations-hive).
# Utilisation d'un métastore Hive externe
Vous pouvez configurer vos tâches EMR Serverless Spark et Hive pour vous connecter à un métastore Hive externe, tel qu'Amazon Aurora ou Amazon RDS for MySQL. Cette section explique comment configurer un métastore Amazon RDS Hive, configurer votre VPC et configurer vos tâches EMR Serverless pour utiliser un métastore externe.
## Création d'un métastore Hive externe
1. Créez un Amazon Virtual Private Cloud (Amazon VPC) avec des sous-réseaux privés en suivant les instructions de la section Créer [un](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) VPC.
1. Créez votre application EMR Serverless avec votre nouvel Amazon VPC et vos sous-réseaux privés. Lorsque vous configurez votre application EMR Serverless avec un VPC, elle fournit d'abord une interface Elastic Network pour chaque sous-réseau que vous spécifiez. Il attache ensuite le groupe de sécurité que vous avez spécifié à cette interface réseau. Cela permet à votre application de contrôler l'accès. Pour plus de détails sur la configuration de votre VPC, reportez-vous à. [Configuration de l'accès VPC pour que les applications EMR sans serveur se connectent aux données](vpc-access.md)
1. Créez une base de données MySQL ou Aurora PostgreSQL dans un sous-réseau privé de votre Amazon VPC. Pour plus d'informations sur la création d'une base de données Amazon RDS, reportez-vous à la section [Création d'une instance de base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html).
1. Modifiez le groupe de sécurité de votre base de données MySQL ou Aurora pour autoriser les connexions JDBC depuis votre groupe de sécurité EMR Serverless en suivant les étapes décrites dans Modification d'[une instance de base de données Amazon](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html) RDS. Ajoutez une règle pour le trafic entrant au groupe de sécurité RDS depuis l'un de vos groupes de sécurité EMR Serverless.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/EMR-Serverless-UserGuide/external-metastore.html)
## Configuration des options Spark
**Utilisation de JDBC**
Pour configurer votre application EMR Serverless Spark afin de se connecter à un metastore Hive basé sur une instance Amazon RDS for MySQL ou Amazon Aurora MySQL, utilisez une connexion JDBC. Transmettez le `mariadb-connector-java.jar` with `--jars` dans les `spark-submit` paramètres de votre exécution de tâche.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/scripts/spark-jdbc.py",
"sparkSubmitParameters": "--jars s3://amzn-s3-demo-bucket/mariadb-connector-java.jar
--conf spark.hadoop.javax.jdo.option.ConnectionDriverName=org.mariadb.jdbc.Driver
--conf spark.hadoop.javax.jdo.option.ConnectionUserName=
--conf spark.hadoop.javax.jdo.option.ConnectionPassword=
--conf spark.hadoop.javax.jdo.option.ConnectionURL=
--conf spark.driver.cores=2
--conf spark.executor.memory=10G
--conf spark.driver.memory=6G
--conf spark.executor.cores=4"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/spark/logs/"
}
}
}'
```
L'exemple de code suivant est un script Spark entrypoint qui interagit avec un métastore Hive sur Amazon RDS.
```
from os.path import expanduser, join, abspath
from pyspark.sql import SparkSession
from pyspark.sql import Row
# warehouse_location points to the default location for managed databases and tables
warehouse_location = abspath('spark-warehouse')
spark = SparkSession \
.builder \
.config("spark.sql.warehouse.dir", warehouse_location) \
.enableHiveSupport() \
.getOrCreate()
spark.sql("SHOW DATABASES").show()
spark.sql("CREATE EXTERNAL TABLE `sampledb`.`sparknyctaxi`(`dispatching_base_num` string, `pickup_datetime` string, `dropoff_datetime` string, `pulocationid` bigint, `dolocationid` bigint, `sr_flag` bigint) STORED AS PARQUET LOCATION 's3:///nyctaxi_parquet/'")
spark.sql("SELECT count(*) FROM sampledb.sparknyctaxi").show()
spark.stop()
```
**Utilisation du service d'épargne**
Vous pouvez configurer votre application EMR Serverless Hive pour qu'elle se connecte à un métastore Hive basé sur une instance Amazon RDS for MySQL ou Amazon Aurora MySQL. Pour ce faire, exécutez un serveur d'épargne sur le nœud principal d'un cluster Amazon EMR existant. Cette option est idéale si vous possédez déjà un cluster Amazon EMR avec un serveur d'épargne que vous souhaitez utiliser pour simplifier vos configurations de tâches EMR sans serveur.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/thriftscript.py",
"sparkSubmitParameters": "--jars s3://amzn-s3-demo-bucket/mariadb-connector-java.jar
--conf spark.driver.cores=2
--conf spark.executor.memory=10G
--conf spark.driver.memory=6G
--conf spark.executor.cores=4"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/spark/logs/"
}
}
}'
```
L'exemple de code suivant est un script entrypoint (`thriftscript.py`) qui utilise le protocole Thrift pour se connecter à un métastore Hive. Notez que la `hive.metastore.uris` propriété doit être définie pour être lue depuis un métastore Hive externe.
```
from os.path import expanduser, join, abspath
from pyspark.sql import SparkSession
from pyspark.sql import Row
# warehouse_location points to the default location for managed databases and tables
warehouse_location = abspath('spark-warehouse')
spark = SparkSession \
.builder \
.config("spark.sql.warehouse.dir", warehouse_location) \
.config("hive.metastore.uris","thrift://thrift-server-host:thift-server-port") \
.enableHiveSupport() \
.getOrCreate()
spark.sql("SHOW DATABASES").show()
spark.sql("CREATE EXTERNAL TABLE sampledb.`sparknyctaxi`( `dispatching_base_num` string, `pickup_datetime` string, `dropoff_datetime` string, `pulocationid` bigint, `dolocationid` bigint, `sr_flag` bigint) STORED AS PARQUET LOCATION 's3:///nyctaxi_parquet/'")
spark.sql("SELECT * FROM sampledb.sparknyctaxi").show()
spark.stop()
```
## Configurer les options Hive
**Utilisation de JDBC**
Si vous souhaitez spécifier un emplacement de base de données Hive externe sur une instance Amazon RDS MySQL ou Amazon Aurora, vous pouvez remplacer la configuration de métastore par défaut.
**Note**
Dans Hive, vous pouvez effectuer plusieurs écritures dans des tables de métastore en même temps. Si vous partagez des informations de métastore entre deux jobs, assurez-vous de ne pas écrire simultanément dans la même table de métastore, sauf si vous écrivez sur des partitions différentes de la même table de métastore.
Définissez les configurations suivantes dans la `hive-site` classification pour activer le métastore Hive externe.
```
{
"classification": "hive-site",
"properties": {
"hive.metastore.client.factory.class": "org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClientFactory",
"javax.jdo.option.ConnectionDriverName": "org.mariadb.jdbc.Driver",
"javax.jdo.option.ConnectionURL": "jdbc:mysql://db-host:db-port/db-name",
"javax.jdo.option.ConnectionUserName": "username",
"javax.jdo.option.ConnectionPassword": "password"
}
}
```
**Utilisation d'un serveur d'épargne**
Vous pouvez configurer votre application EMR Serverless Hive pour qu'elle se connecte à un métastore Hive basé sur Amazon RDS for MySQL ou Amazon Aurora My. SQLinstance Pour ce faire, exécutez un serveur d'épargne sur le nœud principal d'un cluster Amazon EMR existant. Cette option est idéale si vous possédez déjà un cluster Amazon EMR qui exécute un serveur d'épargne et que vous souhaitez utiliser vos configurations de tâches EMR sans serveur.
Définissez les configurations suivantes dans la `hive-site` classification afin qu'EMR Serverless puisse accéder à la métastore d'épargne distante. Notez que vous devez définir la `hive.metastore.uris` propriété pour qu'elle puisse être lue depuis un métastore Hive externe.
```
{
"classification": "hive-site",
"properties": {
"hive.metastore.client.factory.class": "org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClientFactory",
"hive.metastore.uris": "thrift://thrift-server-host:thirft-server-port"
}
}
```
# Utilisation de la hiérarchie multi-catalogues AWS Glue sur EMR Serverless
Vous pouvez configurer vos applications EMR Serverless pour qu'elles fonctionnent avec la hiérarchie multi-catalogues AWS Glue. L'exemple suivant montre comment utiliser EMR-S Spark avec la hiérarchie multi-catalogues AWS Glue.
Pour en savoir plus sur la hiérarchie de plusieurs catalogues, reportez-vous à la section [Utilisation d'une hiérarchie de catalogues multiples dans AWS Glue Data Catalog with Spark sur Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html).
## Utilisation du stockage géré Redshift (RMS) avec Iceberg et AWS Glue Data Catalog
Voici comment configurer Spark pour l'intégrer à un catalogue de données AWS Glue avec Iceberg :
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/myscript.py",
"sparkSubmitParameters": "--conf spark.sql.catalog.nfgac_rms = org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.rms.type=glue
--conf spark.sql.catalog.rms.glue.id=Glue RMS catalog ID
--conf spark.sql.defaultCatalog=rms
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"
}
}'
```
Exemple de requête provenant d'une table du catalogue, suite à l'intégration :
```
SELECT * FROM my_rms_schema.my_table
```
## Utilisation du stockage géré Redshift (RMS) avec l'API REST d'Iceberg et le catalogue de données Glue AWS
Voici comment configurer Spark pour qu'il fonctionne avec le catalogue REST d'Iceberg :
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/myscript.py",
"sparkSubmitParameters": "
--conf spark.sql.catalog.rms=org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.rms.type=rest
--conf spark.sql.catalog.rms.warehouse=Glue RMS catalog ID
--conf spark.sql.catalog.rms.uri=Glue endpoint URI/iceberg
--conf spark.sql.catalog.rms.rest.sigv4-enabled=true
--conf spark.sql.catalog.rms.rest.signing-name=glue
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"
}
}'
```
Exemple de requête provenant d'une table du catalogue :
```
SELECT * FROM my_rms_schema.my_table
```
# Considérations relatives à l'utilisation d'un métastore externe
+ Vous pouvez configurer des bases de données compatibles avec MariaDB JDBC en tant que metastore. RDS pour MariaDB, MySQL et Amazon Aurora sont des exemples de ces bases de données.
+ Les métastores ne sont pas initialisés automatiquement. [Si votre métastore n'est pas initialisé avec un schéma pour votre version de Hive, utilisez l'outil Hive Schema.](https://cwiki.apache.org/confluence/display/Hive/Hive+Schema+Tool)
+ EMR Serverless ne prend pas en charge l'authentification Kerberos. Vous ne pouvez pas utiliser un serveur Thrift Metastore avec authentification Kerberos avec des tâches EMR Serverless Spark ou Hive.
+ Vous devez configurer l'accès au VPC pour utiliser la hiérarchie multi-catalogues.
# Accès aux données S3 depuis un autre AWS compte depuis EMR Serverless
Vous pouvez exécuter des tâches Amazon EMR sans serveur à partir d'un AWS compte et les configurer pour accéder aux données des compartiments Amazon S3 appartenant à un autre compte. AWS Cette page décrit comment configurer l'accès entre comptes à S3 depuis EMR Serverless.
Les tâches exécutées sur EMR Serverless peuvent utiliser une politique de compartiment S3 ou un rôle assumé pour accéder aux données dans Amazon S3 à partir d'un autre compte. AWS
## Conditions préalables
Pour configurer l'accès entre comptes pour Amazon EMR Serverless, effectuez les tâches en étant connecté à deux comptes : AWS
+ **`AccountA`**— Il s'agit du AWS compte sur lequel vous avez créé une application Amazon EMR Serverless. Avant de configurer l'accès entre comptes, préparez les éléments suivants dans ce compte :
+ Une application Amazon EMR Serverless dans laquelle vous souhaitez exécuter des tâches.
+ Rôle d'exécution de tâches disposant des autorisations requises pour exécuter des tâches dans l'application. Pour plus d’informations, consultez [Rôles d'exécution des tâches pour Amazon EMR Serverless](security-iam-runtime-role.md).
+ **`AccountB`**— Il s'agit du AWS compte qui contient le compartiment S3 auquel vous souhaitez que vos tâches Amazon EMR Serverless accèdent.
## Utiliser une politique de compartiment S3 pour accéder aux données S3 entre comptes
Pour accéder au compartiment S3 account B depuisaccount A, attachez la politique suivante au compartiment S3 depuisaccount B.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePermissions1",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-bucket-name"
]
},
{
"Sid": "ExamplePermissions2",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::my-bucket-name/*"
]
}
]
}
```
------
Pour plus d'informations sur l'accès entre comptes S3 avec les politiques relatives aux compartiments S3, reportez-vous à l'[exemple 2 : le propriétaire du compartiment accorde des autorisations de compartiment entre comptes](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) dans le guide de l'*utilisateur d'Amazon Simple Storage Service*.
## Utiliser un rôle assumé pour accéder aux données S3 entre comptes
Une autre méthode pour configurer l'accès entre comptes pour Amazon EMR Serverless consiste à utiliser `AssumeRole` l'action du AWS Security Token Service ().AWS STS AWS STS est un service Web mondial qui vous permet de demander des informations d'identification temporaires à privilèges limités pour les utilisateurs. Vous pouvez effectuer des appels d'API vers EMR Serverless et Amazon S3 à l'aide des informations d'identification de sécurité temporaires que vous avez créées avec. `AssumeRole`
Les étapes suivantes illustrent comment utiliser un rôle assumé pour accéder aux données S3 entre comptes depuis EMR Serverless :
1. Créez un compartiment Amazon S3, *cross-account-bucket*, dans `AccountB`. Pour plus d'informations, reportez-vous à la section [Création d'un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) dans le *guide de l'utilisateur d'Amazon Simple Storage Service*. Si vous souhaitez bénéficier d'un accès multicompte à DynamoDB, créez également une table DynamoDB dans. `AccountB` Pour plus d'informations, reportez-vous à la section [Création d'une table DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-1.html) dans le manuel du développeur Amazon *DynamoDB*.
1. Créez un rôle IAM `Cross-Account-Role-B` dans le `AccountB` qui peut accéder au *cross-account-bucket*.
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Choisissez **Rôles** et créez un nouveau rôle : `Cross-Account-Role-B`. Pour plus d'informations sur la création de rôles IAM, reportez-vous à la section [Création de rôles IAM dans le Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) de l'utilisateur IAM.
1. Créez une politique IAM qui spécifie les autorisations du `Cross-Account-Role-B` à accéder au compartiment S3 *cross-account-bucket*, comme le montre la déclaration de politique suivante. Attachez ensuite la politique IAM au `Cross-Account-Role-B`. Pour plus d'informations, reportez-vous à la section [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le Guide de l'*utilisateur IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::cross-account-bucket",
"arn:aws:s3:::cross-account-bucket/*"
],
"Sid": "AllowS3"
}
]
}
```
------
Si vous avez besoin d'un accès DynamoDB, créez une politique IAM qui spécifie les autorisations d'accès à la table DynamoDB entre comptes. Attachez ensuite la politique IAM au `Cross-Account-Role-B`. Pour plus d'informations, consultez [Amazon DynamoDB : autorise l'accès à une table spécifique](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_specific-table.html) dans le guide de *l'*utilisateur IAM.
Voici une politique permettant d'autoriser l'accès à la table DynamoDB`CrossAccountTable`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*"
],
"Resource": [
"arn:aws:dynamodb:*:123456789012:table/CrossAccountTable"
],
"Sid": "AllowDYNAMODB"
}
]
}
```
------
1. Modifiez la relation de confiance du rôle `Cross-Account-Role-B`.
1. Pour configurer la relation de confiance pour le rôle, choisissez l'onglet **Relations de confiance** dans la console IAM pour le rôle `Cross-Account-Role-B` que vous avez créé à l'étape 2.
1. Sélectionnez **Modifier la relation de confiance**.
1. Ajoutez le document de politique suivant. Cela permet `AccountA` à `Job-Execution-Role-A` in d'assumer le `Cross-Account-Role-B` rôle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/Job-Execution-Role-A",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
1. Accordez `Job-Execution-Role-A` `AccountA` l' AWS STS `AssumeRole`autorisation d'assumer`Cross-Account-Role-B`.
1. Dans la console IAM du AWS compte`AccountA`, sélectionnez`Job-Execution-Role-A`.
1. Ajoutez la déclaration de politique générale suivante au rôle `Job-Execution-Role-A` pour autoriser l'action `AssumeRole` sur le rôle `Cross-Account-Role-B`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Cross-Account-Role-B"
],
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
## Exemples de rôles supposés
Utilisez un rôle assumé unique pour accéder à toutes les ressources S3 d'un compte, ou avec Amazon EMR 6.11 et versions ultérieures, configurez plusieurs rôles IAM à assumer lorsque vous accédez à différents compartiments S3 entre comptes.
**Topics**
+ [Accédez aux ressources S3 avec un rôle assumé](#jobs-s3-access-how-to-assumed-role-single)
+ [Accédez aux ressources S3 avec plusieurs rôles assumés](#jobs-s3-access-how-to-assumed-role-multiple)
### Accédez aux ressources S3 avec un rôle assumé
**Note**
Lorsque vous configurez une tâche pour utiliser un seul rôle assumé, toutes les ressources S3 de la tâche utilisent ce rôle, y compris le `entryPoint` script.
Si vous souhaitez utiliser un seul rôle assumé pour accéder à toutes les ressources S3 du compte B, spécifiez les configurations suivantes :
1. Spécifiez la configuration `fs.s3.customAWSCredentialsProvider` EMRFS à. `com.amazonaws.emr.AssumeRoleAWSCredentialsProvider`
1. Pour Spark, utilisez `spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` et `spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` pour spécifier les variables d'environnement sur le pilote et les exécuteurs.
1. Pour Hive, utilisez `hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN``tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN`, et pour spécifier les variables `tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` d'environnement sur le pilote Hive, l'application principale Tez et les conteneurs de tâches Tez.
Les exemples suivants montrent comment utiliser un rôle assumé pour démarrer une tâche EMR sans serveur exécutée avec un accès entre comptes.
------
#### [ Spark ]
L'exemple suivant montre comment utiliser un rôle assumé pour démarrer une tâche EMR Serverless Spark exécutée avec un accès multicompte à S3.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "entrypoint_location",
"entryPointArguments": [":argument_1:", ":argument_2:"],
"sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "spark-defaults",
"properties": {
"spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.AssumeRoleAWSCredentialsProvider",
"spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
}
}]
}'
```
------
#### [ Hive ]
L'exemple suivant montre comment utiliser un rôle assumé pour démarrer une tâche EMR Serverless Hive exécutée avec un accès multicompte à S3.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "query_location",
"parameters": "hive_parameters"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
"hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
}
}]
}'
```
------
### Accédez aux ressources S3 avec plusieurs rôles assumés
Avec les versions 6.11.0 et supérieures d'EMR Serverless, configurez plusieurs rôles IAM à assumer lorsque vous accédez à différents buckets multicomptes. Si vous souhaitez accéder à différentes ressources S3 avec différents rôles assumés dans le compte B, utilisez les configurations suivantes lorsque vous démarrez l'exécution de la tâche :
1. Spécifiez la configuration `fs.s3.customAWSCredentialsProvider` EMRFS à. `com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider`
1. Spécifiez la configuration EMRFS `fs.s3.bucketLevelAssumeRoleMapping` pour définir le mappage entre le nom du compartiment S3 et le rôle IAM à assumer dans le compte B. La valeur doit être au format de`bucket1->role1;bucket2->role2`.
Par exemple, utilisez `arn:aws:iam::AccountB:role/Cross-Account-Role-B-1` pour accéder au bucket `bucket1` et utilisez `arn:aws:iam::AccountB:role/Cross-Account-Role-B-2` pour accéder au bucket`bucket2`. Les exemples suivants montrent comment démarrer une tâche EMR sans serveur exécutée avec un accès entre comptes via plusieurs rôles assumés.
------
#### [ Spark ]
L'exemple suivant montre comment utiliser plusieurs rôles assumés pour créer une tâche EMR Serverless Spark exécutée.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "entrypoint_location",
"entryPointArguments": [":argument_1:", ":argument_2:"],
"sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "spark-defaults",
"properties": {
"spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider",
"spark.hadoop.fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
}
}]
}'
```
------
#### [ Hive ]
Les exemples suivants montrent comment utiliser plusieurs rôles assumés pour créer une tâche EMR Serverless Hive exécutée.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "query_location",
"parameters": "hive_parameters"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
"fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
}
}]
}'
```
------
# Résolution des erreurs dans EMR Serverless
Utilisez les informations suivantes pour diagnostiquer et résoudre les problèmes courants qui se produisent lors de l'utilisation d'Amazon EMR Serverless.
**Topics**
+ [Erreur : Le travail a échoué car le compte a atteint la limite de service du nombre maximal de vCPU qu'il peut utiliser simultanément.](#jobs-troubleshoot-allowed-capacity-vcpu)
+ [Erreur : Le Job a échoué car l'application a dépassé les paramètres de capacité maximale.](#jobs-troubleshoot-maxcapacity)
+ [Erreur : La tâche a échoué car le travailleur n'a pas pu être alloué car l'application a dépassé sa capacité maximale.](#jobs-troubleshoot-worker-allocated)
+ [Erreur : l'accès S3 est refusé. Vérifiez les autorisations d'accès S3 du rôle d'exécution des tâches sur les ressources S3 requises.](#jobs-troubleshoot-s3)
+ [Erreur ModuleNotFoundError : aucun module n'a été nommé. Reportez-vous au guide de l'utilisateur pour savoir comment utiliser les bibliothèques Python avec EMR Serverless.](#jobs-troubleshoot-module)
+ [Erreur : Impossible d'assumer le rôle d'exécution car celui-ci n'existe pas ou n'est pas configuré avec la relation de confiance requise.](#jobs-troubleshoot-runtime-role)
## Erreur : Le travail a échoué car le compte a atteint la limite de service du nombre maximal de vCPU qu'il peut utiliser simultanément.
Cette erreur indique qu'EMR Serverless n'a pas pu soumettre la tâche car le compte a dépassé la capacité maximale. Augmentez la capacité maximale du compte. Vérifiez vos limites de service en fonction des quotas de service [EMR Serverless](https://console.aws.amazon.com/servicequotas/home/services/emr-serverless/quotas).
## Erreur : Le Job a échoué car l'application a dépassé les paramètres de capacité maximale.
Cette erreur indique qu'EMR Serverless n'a pas pu soumettre la tâche car l'application a dépassé la capacité maximale configurée. Augmentez la capacité maximale de l'application.
## Erreur : La tâche a échoué car le travailleur n'a pas pu être alloué car l'application a dépassé sa capacité maximale.
Cette erreur indique que le travail n'a pas pu être terminé. Les travailleurs n'ont pas pu être alloués car l'application a dépassé les paramètres de capacité maximale.
## Erreur : l'accès S3 est refusé. Vérifiez les autorisations d'accès S3 du rôle d'exécution des tâches sur les ressources S3 requises.
Cette erreur indique que votre tâche n'a pas accès à vos ressources S3. Vérifiez que le rôle d'exécution de la tâche est autorisé à accéder aux ressources S3 que la tâche doit utiliser. Pour en savoir plus sur les rôles d'exécution, reportez-vous à[Rôles d'exécution des tâches pour Amazon EMR Serverless](security-iam-runtime-role.md).
## Erreur ModuleNotFoundError : aucun module n'a été nommé. Reportez-vous au guide de l'utilisateur pour savoir comment utiliser les bibliothèques Python avec EMR Serverless.
Cette erreur indique qu'aucun module Python n'était disponible pour le job Spark. Vérifiez que les bibliothèques Python dépendantes sont disponibles pour la tâche. Pour plus d'informations sur la façon d'empaqueter des bibliothèques Python, reportez-vous à[Utilisation de bibliothèques Python avec EMR Serverless](using-python-libraries.md).
## Erreur : Impossible d'assumer le rôle d'exécution car celui-ci n'existe pas ou n'est pas configuré avec la relation de confiance requise.
Cette erreur indique que le rôle d'exécution de la tâche que vous avez spécifié pour la tâche n'existe pas ou qu'il n'a aucune relation de confiance pour les autorisations EMR Serverless. Pour vérifier que le rôle IAM existe et que vous avez correctement configuré la politique de confiance du rôle, consultez les instructions dans[Rôles d'exécution des tâches pour Amazon EMR Serverless](security-iam-runtime-role.md).
# Permettre la répartition des coûts au niveau des tâches
La répartition des coûts au niveau des tâches permet d'attribuer la facturation granulaire pour EMR Serverless au niveau de l'exécution individuelle des tâches, plutôt que d'agréger tous les coûts au niveau de l'application. Lorsque cette option est activée, vous pouvez filtrer et suivre les AWS coûts dans Cost Explorer et Cost and Usage Reports en fonction de l'exécution des tâches spécifiques IDs et des balises associées aux séries de tâches, offrant ainsi une meilleure visibilité des frais liés aux séries de tâches soumises.
## Comportement par défaut
La répartition des coûts au niveau des tâches n'est pas activée par défaut.
## Comment activer ou désactiver la fonctionnalité
Vous pouvez configurer la répartition des coûts au niveau des tâches lors de la création de l'application ou la mettre à jour pour les applications existantes.
Spécifiez le `jobLevelCostAllocation` paramètre lors de la création d'une nouvelle application :
```
# Enable job-level cost allocation:
aws emr-serverless create-application \
--name "my-application" \
--release-label "emr-7.12.0" \
--type "SPARK" \
--job-level-cost-allocation-configuration '{
"enabled": true
}'
# Disable job-level cost allocation:
aws emr-serverless create-application \
--name "my-application" \
--release-label "emr-7.12.0" \
--type "SPARK" \
--job-level-cost-allocation-configuration '{
"enabled": false
}'
```
Mettez à jour le `jobLevelCostAllocationConfiguration` paramètre d'une application existante :
```
# Enable job-level cost allocation:
aws emr-serverless update-application \
--application-id \
--job-level-cost-allocation-configuration '{
"enabled": true
}'
# Disable job-level cost allocation:
aws emr-serverless update-application \
--application-id \
--job-level-cost-allocation-configuration '{
"enabled": false
}'
```
## Considérations et restrictions
+ L'activation de la répartition des coûts au niveau des tâches n'attribue pas rétroactivement les coûts pour les séries de tâches terminées avant l'activation de la fonctionnalité. Les jobs démarrés après l'activation de la fonctionnalité seront soumis à une attribution des coûts granulaire.
+ Le paramètre de répartition des coûts au niveau du travail ne peut être mis à jour que lorsqu'une application est à l'état CREATED ou STOPPED.
+ Lorsque la répartition des coûts au niveau des tâches est activée, les coûts sont attribués à des séries de tâches individuelles plutôt qu'à l'application. Pour afficher les coûts agrégés au niveau de l'application, vous devez appliquer des balises cohérentes (telles que le nom de l'application ou l'identifiant de l'application) à toutes les exécutions de tâches au sein de cette application et filtrer en fonction de ces balises dans Cost Explorer ou Cost and Usage Reports.