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.
# Configuration de Spark
Vous pouvez configurer [Spark sur Amazon EMR](https://aws.amazon.com/elasticmapreduce/details/spark/) à l’aide de classifications de configuration. Pour plus d'informations sur les classifications de configuration, consultez [Configuration des applications](emr-configure-apps.md).
Les classifications de configuration pour Spark sur Amazon EMR incluent :
+ **`spark`** – Définit la propriété `maximizeResourceAllocation` sur la valeur true ou false. Lorsque la valeur est true, Amazon EMR configure automatiquement les propriétés `spark-defaults` en fonction de la configuration matérielle du cluster. Pour de plus amples informations, veuillez consulter [Utilisation de `maximizeResourceAllocation`](#emr-spark-maximizeresourceallocation).
+ **`spark-defaults`** – Définit les valeurs dans le fichier `spark-defaults.conf`. Pour plus d'informations, consultez [Configuration Spark](https://spark.apache.org/docs/latest/configuration.html) dans la documentation Spark.
+ **`spark-env`** – Définit les valeurs dans le fichier `spark-env.sh`. Pour plus d'informations, consultez [Variables d'environnement](https://spark.apache.org/docs/latest/configuration.html#environment-variables) dans la documentation Spark.
+ **`spark-hive-site`** – Définit les valeurs dans le `hive-site.xml` pour Spark.
+ **`spark-log4j`** : (Amazon EMR versions 6.7.x et antérieures) définit les valeurs dans le fichier `log4j.properties`. Pour plus d'informations, consultez le fichier [log4j.properties.template](https://github.com/apache/spark/blob/branch-3.2/conf/log4j.properties.template) sur Github.
+ **`spark-log4j2`** : (Amazon EMR versions 6.8.0 et supérieures) définit les valeurs du fichier `log4j2.properties`. Pour plus d'informations, consultez le fichier [log4j2.properties.template](https://github.com/apache/spark/blob/v3.3.0/conf/log4j2.properties.template) sur Github.
+ **`spark-metrics`** – Définit les valeurs dans le fichier `metrics.properties`. Pour les paramètres et plus d'informations, consultez le fichier [metrics.properties.template](https://github.com/apache/spark/blob/master/conf/metrics.properties.template) sur Github, et [Métriques](https://spark.apache.org/docs/latest/monitoring.html#metrics) dans la documentation Spark.
**Note**
Si vous migrez des charges de travail Spark vers Amazon EMR depuis une autre plateforme, nous vous recommandons de tester vos charges de travail avec le [Valeurs Spark par défaut définies par Amazon EMR](#spark-defaults) avant d'ajouter des configurations personnalisées. La plupart des clients constatent une amélioration des performances grâce à nos paramètres par défaut.
**Topics**
+ [Valeurs Spark par défaut définies par Amazon EMR](#spark-defaults)
+ [Configuration du récupérateur de mémoire Spark sur Amazon EMR 6.1.0](#spark-gc-config)
+ [Utilisation de `maximizeResourceAllocation`](#emr-spark-maximizeresourceallocation)
+ [Configuration du comportement de mise hors service du nœud](#spark-decommissioning)
+ [Variable d' ThriftServer environnement Spark](#spark-thriftserver)
+ [Modification des paramètres Spark par défaut](#spark-change-defaults)
+ [Migration d'Apache Log4j 1.x vers Log4j 2.x](#spark-migrate-logj42)
## Valeurs Spark par défaut définies par Amazon EMR
La table suivante illustre comment Amazon EMR définit les valeurs par défaut dans `spark-defaults` qui affectent les applications.
**Valeurs Spark par défaut définies par Amazon EMR**
| Paramètre | Description | Valeur par défaut |
| --- | --- | --- |
| spark.executor.memory | Quantité de mémoire à utiliser par processus d'exécution. Par exemple `1g`, `2g`. | Ce paramètre est déterminé par les types d'instance de noyau et de tâche dans le cluster. |
| spark.executor.cores | Le nombre de cœurs à utiliser sur chaque exécuteur. | Ce paramètre est déterminé par les types d'instance de noyau et de tâche dans le cluster. |
| spark.dynamicAllocation.enabled | Lorsque cela est vrai, utilisez l'allocation dynamique des ressources pour augmenter ou réduire le nombre d'exécuteurs enregistrés avec une application en fonction de la charge de travail. | `true` (avec Amazon EMR 4.4.0 et versions ultérieures) Le service Spark réorganisé est automatiquement configuré par Amazon EMR. |
| spark.sql.hive.advancedPartitionPredicatePushdown.enabled | Lorsque c'est vrai, le transfert avancé des prédicats de partition vers le métastore Hive est activé. | true |
| spark.sql.hive.stringLikePartitionPredicatePushdown.enabled | Pousse vers le bas les filtres `startsWith`, `contains` et `endsWith` dans le métastore Hive. Glue ne prend pas en charge le push down des prédicats pour `startsWith`, `contains`, ou `endsWith`. Si vous utilisez le métastore Glue et que vous rencontrez des erreurs en raison de l'activation des prédicats pour ces fonctions, définissez cette configuration sur `false`. | true |
## Configuration du récupérateur de mémoire Spark sur Amazon EMR 6.1.0
La définition de configurations personnalisées de récupérateur de mémoire avec `spark.driver.extraJavaOptions` et `spark.executor.extraJavaOptions` entraîne un échec du lancement du pilote ou de l'exécuteur avec Amazon EMR 6.1 en raison d'une configuration de récupérateur de mémoire conflictuelle avec Amazon EMR 6.1.0. Pour Amazon EMR 6.1.0, la configuration de récupérateur de mémoire par défaut est définie via `spark.driver.defaultJavaOptions` et `spark.executor.defaultJavaOptions`. Cette configuration s'applique uniquement à Amazon EMR 6.1.0. Les options de la JVM non liées au récupérateur de mémoire, telles que celles permettant de configurer le journal (`-verbose:class`), peuvent toujours être définies via `extraJavaOptions`. Pour plus d'informations, consultez [Propriétés de l'application Spark.](https://spark.apache.org/docs/latest/configuration.html#application-properties)
## Utilisation de `maximizeResourceAllocation`
Pour configurer vos exécuteurs afin qu'ils utilisent le maximum de ressources possibles sur chaque nœud d'un cluster, définissez `maximizeResourceAllocation` sur `true` dans votre classification de configuration `spark`. `maximizeResourceAllocation` est spécifique à Amazon EMR. Lorsque vous activez `maximizeResourceAllocation`, Amazon EMR calcule les ressources de calcul et de mémoire maximales disponibles pour un exécuteur sur une instance du groupe d’instances principales. Il définit ensuite les paramètres correspondants `spark-defaults` en fonction des valeurs maximales calculées.
Amazon EMR calcule les ressources de calcul et de mémoire maximales disponibles pour un exécuteur en fonction d'un type d'instance issu du parc d'instances principal. Étant donné que chaque parc d'instances peut avoir des types et des tailles d'instances différents au sein d'un même parc, la configuration d'exécuteur utilisée par Amazon EMR n'est peut-être pas la meilleure pour vos clusters. Nous vous déconseillons donc d'utiliser les paramètres par défaut lors de l'utilisation d'une allocation de ressources maximale. Configurez des paramètres personnalisés pour vos clusters de flotte d'instances.
**Note**
Vous ne devez pas utiliser l'option `maximizeResourceAllocation` sur des clusters avec d'autres applications distribuées telles que HBase. Amazon EMR utilise des configurations YARN personnalisées pour les applications distribuées, qui peuvent entrer en conflit avec `maximizeResourceAllocation` et faire échouer les applications Spark.
Voici un exemple de classification de configuration Spark avec `maximizeResourceAllocation` défini sur `true`.
```
[
{
"Classification": "spark",
"Properties": {
"maximizeResourceAllocation": "true"
}
}
]
```
**Paramètres configurés dans `spark-defaults` lorsque `maximizeResourceAllocation` est activé**
| Paramètre | Description | Value |
| --- | --- | --- |
| spark.default.parallelism | Nombre par défaut de partitions dans les RDD renvoyées par des transformations telles que jointureByKey, réduction et parallélisation lorsqu'elles ne sont pas définies par l'utilisateur. | 2X nombre de cœurs de processeurs disponibles sur des conteneurs YARN. |
| spark.driver.memory | Quantité de mémoire à utiliser pour le processus du pilote, c'est-à-dire où SparkContext est initialisé. (par exemple, 1 g, 2 g). | Le paramétrage est configuré en fonction des types d'instances dans le cluster. Cependant, parce que l'application de pilote Spark peut s'exécuter soit sur le maître, soit sur une des instances principales (par exemple, dans le client YARN et les modes cluster, respectivement), la définition dépend du plus petit des types d'instance dans ces deux groupes d'instances. |
| spark.executor.memory | Volume de mémoire à utiliser par les processus de l'exécuteur. (par exemple, 1g, 2g) | Le paramétrage est configuré en fonction des types d'instances de noyau et de tâches dans le cluster. |
| spark.executor.cores | Le nombre de cœurs à utiliser sur chaque exécuteur. | Le paramétrage est configuré en fonction des types d'instances de noyau et de tâches dans le cluster. |
| spark.executor.instances | Le nombre d'exécuteurs. | Le paramétrage est configuré en fonction des types d'instances de noyau et de tâches dans le cluster. Définissez, sauf si `spark.dynamicAllocation.enabled` définit explicitement sur true en même temps. |
## Configuration du comportement de mise hors service du nœud
Lorsque vous utilisez Amazon EMR 5.9.0 ou une version ultérieure, Spark sur Amazon EMR inclut un ensemble de fonctionnalités qui permettent de s’assurer que Spark gère plus élégamment l’arrêt des nœuds suite à un redimensionnement manuel ou à une demande de politique de mise à l’échelle automatique. Amazon EMR implémente un mécanisme de liste de refus dans Spark par-dessus le mécanisme de mise hors service de YARN. Ce mécanisme aide à garantir qu'aucune nouvelle tâche n'est planifiée sur un nœud qui est mis hors service, tout en autorisant dans le même temps que les tâches déjà en cours d'exécution se terminent. En outre, il existe des fonctionnalités qui permettent de rétablir les tâches Spark plus rapidement en cas de perte de blocs aléatoires lors de la terminaison d'un nœud. Le processus de recalcul est déclenché plus tôt et optimisé pour un recalcul plus rapide avec moins de tentatives d'étape ; en outre, il est possible d'empêcher l'échec des tâches dû aux défaillances d'extraction provoquées par les blocs aléatoires manquants.
**Important**
Le paramètre `spark.decommissioning.timeout.threshold` a été ajouté dans la version 5.11.0 d'Amazon EMR pour améliorer la résilience de Spark lorsque vous utilisez des instances Spot. Dans les versions précédentes, lorsqu'un nœud utilise une instance Spot et que l'instance est terminée en raison du prix de l'offre, Spark peut ne pas gérer correctement la terminaison. Les tâches peuvent échouer et les recalculs aléatoires peuvent nécessiter un temps important. Pour cette raison, nous vous conseillons d'utiliser la version 5.11.0 ou une version ultérieure si vous utilisez des instances Spot.
**Paramètres de mise hors service d'un nœud Spark**
| Paramètre | Description | Valeur par défaut |
| --- | --- | --- |
| `spark.blacklist.decommissioning.enabled` | Lorsqu'il est défini sur `true`, Spark refuse de répertorier les nœuds qui sont dans l'état `decommissioning` dans YARN. Spark ne planifie pas de nouvelles tâches sur les exécuteurs s'exécutant sur ce nœud. Les tâches déjà en cours d'exécution sont autorisées à se terminer. | `true` |
| `spark.blacklist.decommissioning.timeout` | La durée pendant laquelle un nœud dans l'état `decommissioning` est sur la liste de refus. Par défaut, cette valeur est définie sur une heure, qui est aussi l'heure par défaut pour `yarn.resourcemanager.decommissioning.timeout`. Pour s'assurer qu'un nœud est placé sur liste noire pendant toute la période de sa mise hors service, définissez une valeur égale ou supérieure à `yarn.resourcemanager.decommissioning.timeout`. Après l'expiration du délai de mise hors service, le nœud passe à un état `decommissioned` et Amazon EMR peut résilier l'instance EC2 du nœud. Si des tâches continuent à s'exécuter après l'expiration du délai, elles sont perdues ou supprimées, puis replanifiées sur les exécuteurs s'exécutant sur d'autres nœuds. | `1h` |
| `spark.decommissioning.timeout.threshold` | Disponible dans Amazon EMR version 5.11.0 ou ultérieure. Indiqué en secondes. Lorsqu'un nœud passe à l'état de mise hors service, si l'hôte est mis hors service au cours d'une durée inférieure ou égale à cette valeur, Amazon EMR placera le nœud sur la liste noire et nettoiera l'état de l'hôte (comme indiqué par `spark.resourceManager.cleanupExpiredHost`) sans attendre que le nœud passe à l'état de mise hors service. Cela permet à Spark de mieux traiter les arrêts d'instances Spot car les instances Spot sont mises hors services dans un délai de 20 secondes, et ce quelle que soit la valeur de `yarn.resourcemanager.decommissioning.timeout`, qui peut ne pas fournir aux autres nœuds suffisamment de temps pour lire les fichiers de lecture aléatoire. | `20s` |
| `spark.resourceManager.cleanupExpiredHost` | Lorsque la valeur est `true`, Spark annule l'inscription de l'ensemble des données mises en cache et des blocs aléatoires stockés dans les exécuteurs des nœuds qui se trouvent à l'état `decommissioned`. Le processus de récupération s'en trouve accéléré. | `true` |
| `spark.stage.attempt.ignoreOnDecommissionFetchFailure` | Lorsque la valeur est `true`, aide à empêcher que les phases Spark n'échouent et n'entraînent l'échec de la tâche en raison du trop grand nombre d'extractions à partir des nœuds mis hors service ayant elles-mêmes échoué. Les extractions défaillantes de blocs aléatoires d'un nœud ayant l'état `decommissioned` ne sont pas comptabilisées dans le nombre maximal d'extractions défaillantes consécutives. | true |
## Variable d' ThriftServer environnement Spark
Spark définit la variable d'environnement du port de serveur Thrift Hive, `HIVE_SERVER2_THRIFT_PORT`, sur 10001.
## Modification des paramètres Spark par défaut
Vous modifiez les paramètres par défaut dans `spark-defaults.conf` à l'aide de la classification de configuration `spark-defaults` ou du paramètre `maximizeResourceAllocation` dans la classification de configuration `spark`.
Les procédures suivantes montrent comment modifier les paramètres à l'aide de l'interface de ligne ou de la console.
**Pour créer un cluster avec spark.executor.memory défini sur 2g à l'aide de la CLI**
+ Créez un cluster avec Spark installé et la valeur `spark.executor.memory` définie sur 2g, à l'aide de la commande suivante, qui fait référence à un fichier, `myConfig.json` stocké dans Amazon S3.
```
aws emr create-cluster --release-label {{emr-7.13.0}} --applications Name=Spark \
--instance-type m5.xlarge --instance-count 2 --service-role EMR_DefaultRole_V2 --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/amzn-s3-demo-bucket/myfolder/myConfig.json
```
**Note**
Les caractères de continuation de ligne Linux (\\) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
`myConfig.json`:
```
[
{
"Classification": "spark-defaults",
"Properties": {
"spark.executor.memory": "2G"
}
}
]
```
**Pour créer un cluster avec spark.executor.memory défini sur 2g à l'aide de la console**
1. Accédez à la nouvelle console Amazon EMR et sélectionnez **Changer pour l'ancienne console** depuis le menu latéral. Pour plus d'informations sur ce qu'implique le passage à l'ancienne console, consultez la rubrique [Utilisation de l'ancienne console](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in).
1. Choisissez **Créer un cluster** et **Go to advanced options (Aller aux options avancées)**.
1. Choisissez **Spark**.
1. Sous **Edit software settings (Modifier les paramètres logiciels)**, conservez l'option **Enter configuration (Saisir la configuration)** et saisissez la configuration suivante :
```
classification=spark-defaults,properties=[spark.executor.memory=2G]
```
1. Sélectionnez d'autres options, choisissez ****, puis **Create cluster (Créer un cluster)**.
**Pour définir et maximiser ResourceAllocation**
+ Créez un cluster sur lequel Spark est installé et `maximizeResourceAllocation` défini sur true en utilisant le AWS CLI, en faisant référence à un fichier`myConfig.json`, stocké dans Amazon S3.
```
aws emr create-cluster --release-label {{emr-7.13.0}} --applications Name=Spark \
--instance-type m5.xlarge --instance-count 2 --service-role EMR_DefaultRole_V2 --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/amzn-s3-demo-bucket/myfolder/myConfig.json
```
**Note**
Les caractères de continuation de ligne Linux (\\) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
`myConfig.json`:
```
[
{
"Classification": "spark",
"Properties": {
"maximizeResourceAllocation": "true"
}
}
]
```
**Note**
Avec la version 5.21.0 et ultérieures d'Amazon EMR, vous permet de remplacer les configurations de cluster et de spécifier des classifications de configuration supplémentaires pour chaque groupe d'instances dans un cluster en cours d'exécution. Pour ce faire, utilisez la console Amazon EMR, le AWS Command Line Interface (AWS CLI) ou le AWS SDK. Pour plus d'informations, consultez [Fourniture d'une configuration pour un groupe d'instances dans un cluster en cours d'exécution](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).
## Migration d'Apache Log4j 1.x vers Log4j 2.x
Les versions 3.2.x et antérieures d'[Apache Spark](https://aws.amazon.com/emr/features/spark/) utilisent l'ancien Apache Log4j 1.x et le fichier `log4j.properties` pour configurer Log4j dans les processus Spark. Les versions 3.3.0 et ultérieures d'Apache Spark utilisent Apache Log4j 2.x et le fichier `log4j2.properties` pour configurer Log4j dans les processus Spark.
Si vous avez configuré Apache Spark Log4j à l'aide d'une version Amazon EMR inférieure à 6.8.0, vous devez supprimer l'ancienne classification `spark-log4j` de configuration et migrer vers la classification de configuration `spark-log4j2` et le format de clé avant de pouvoir passer à Amazon EMR 6.8.0 ou version ultérieure. L'ancienne classification `spark-log4j` entraîne l'échec de la création de clusters avec une erreur `ValidationException` dans les versions 6.8.0 et ultérieures d'Amazon EMR. Aucun frais ne vous sera facturé en cas de panne liée à l'incompatibilité de Log4j, mais vous devez supprimer la classification de configuration obsolète `spark-log4j` pour continuer.
Pour plus d'informations sur la migration d'Apache Log4j 1.x vers Log4j 2.x, consultez le [Guide de migration d'Apache Log4j](https://logging.apache.org/log4j/2.x/manual/migration.html) et le [Modèle Spark Log4j 2](https://github.com/apache/spark/blob/master/conf/log4j2.properties.template) sur Github.
**Note**
Avec Amazon EMR, Apache Spark utilise un fichier `log4j2.properties` plutôt que le fichier .xml décrit dans le [Guide de migration d’Apache Log4j](https://logging.apache.org/log4j/2.x/manual/migration.html). De plus, nous ne recommandons pas d'utiliser la méthode du pont Log4j 1.x pour convertir en Log4j 2.x.