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.
# Améliorer les performances de Spark avec Amazon S3
Amazon EMR propose des fonctionnalités pour aider à optimiser la performance lors de l'utilisation de Spark pour demander, lire et écrire des données enregistrées dans Amazon S3.
[S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/) peut améliorer la performance de requête pour les fichiers CSV et JSON dans certaines applications en « poussant vers le bas » le traitement à Amazon S3.
Le committer optimisé pour EMRFS S3 est une alternative à la [OutputCommitter](https://hadoop.apache.org/docs/current/api/org/apache/hadoop/mapreduce/OutputCommitter.html)classe, qui utilise la fonctionnalité de téléchargement en plusieurs parties d'EMRFS pour améliorer les performances lors de l'écriture de fichiers Parquet sur Amazon S3 à l'aide de Spark et de Datasets. DataFrames
**Topics**
+ [Utilisation de S3 Select avec Spark pour améliorer les performances des requêtes](emr-spark-s3select.md)
+ [EMR Spark MagicCommitProtocol](emr-spark-magic-commit-protocol.md)
+ [Utilisation d'un valideur EMRFS optimisé pour S3](emr-spark-s3-optimized-committer.md)
+ [Utiliser le protocole de validation optimisé pour EMRFS S3](emr-spark-s3-optimized-commit-protocol.md)
+ [Réessayer de demander Amazon S3 avec EMRFS](emr-spark-emrfs-retry.md)
# Utilisation de S3 Select avec Spark pour améliorer les performances des requêtes
**Important**
Amazon S3 Select n’est plus disponible pour les nouveaux clients. Les clients existants d’Amazon S3 Select peuvent continuer à utiliser cette fonctionnalité comme d’habitude. [En savoir plus](https://aws.amazon.com/blogs/storage/how-to-optimize-querying-your-data-in-amazon-s3/)
À partir de la version 5.17.0 d'Amazon EMR, vous pouvez utiliser [S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/) avec Spark sur Amazon EMR. *S3 Select* permet aux applications de ne récupérer qu’un sous-ensemble de données d’un objet. Pour Amazon EMR, le travail de calcul qu’implique le filtrage d’importants jeux de données pour le traitement est « poussé » du cluster vers Amazon S3, ce qui peut améliorer les performances de certaines applications et réduire le volume de données transféré entre Amazon EMR et Amazon S3.
S3 Select est pris en charge avec les fichiers CSV et JSON à l'aide des valeurs `s3selectCSV` et `s3selectJSON` pour spécifier le format de données. Pour plus d’informations et d’exemples, consultez [Spécifier S3 Select dans votre code](#emr-spark-s3select-specify).
## S3 Select est-il adapté à mon application ?
Nous vous recommandons de tester vos applications avec et sans S3 Select pour voir si son utilisation peut être adaptée à votre application.
Utilisez les consignes suivantes pour déterminer si votre application peut utiliser S3 Select :
+ Votre requête exclut plus de la moitié de l'ensemble de données d'origine.
+ Votre connexion réseau entre Amazon S3 et le cluster Amazon EMR a une bonne vitesse de transfert et une bande passante disponible. Amazon S3 ne compresse pas les réponses HTTP, de sorte que la taille de la réponse est susceptible d'augmenter pour les fichiers d'entrée compressés.
## Considérations et restrictions
+ Le chiffrement côté serveur d'Amazon S3 avec des clés de chiffrement fournies par le client (SSE-C) et le chiffrement côté client ne sont pas pris en charge.
+ La propriété `AllowQuotedRecordDelimiters` n'est pas prise en charge. Si cette propriété est spécifiée, la requête échoue.
+ Seuls les fichiers CSV et JSON au format UTF-8 sont pris en charge. CSVsLes lignes multiples ne sont pas prises en charge.
+ Seuls les fichiers non compressés ou gzip sont pris en charge.
+ Les options Spark CSV et JSON telles que `nanValue`, `positiveInf`, `negativeInf` et les options liées aux enregistrements corrompus (par exemple, les modes failfast et dropmalformed) ne sont pas prises en charge.
+ L'utilisation de virgules (,) avec des décimales n'est pas prise en charge. Par exemple, `10,000` n'est pas pris en charge, mais `10000` l'est.
+ Les caractères de commentaire ne sont pas pris en charge dans la dernière ligne.
+ Des lignes vides à la fin d'un fichier ne sont pas traitées.
+ Les filtres suivants ne sont pas transmis à Amazon S3 :
+ Fonctions d'agrégation, telles que `COUNT()` et `SUM()`.
+ Filtres qui `CAST()` un attribut. Par exemple, `CAST(stringColumn as INT) = 1`.
+ Filtres avec un attribut d'objet ou complexe. Par exemple, `intArray[1] = 1, objectColumn.objectNumber = 1`.
+ Filtres pour lesquels la valeur n'est pas une valeur littérale. Par exemple, `intColumn1 = intColumn2`
+ Seuls [les types de données S3 Select pris en charge](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-glacier-select-sql-reference-data-types.html) sont pris en charge par les limitations de documentation.
## Spécifier S3 Select dans votre code
Les exemples suivants montrent comment spécifier S3 Select pour CSV à l'aide de Scala, SQL, R et PySpark. Vous pouvez utiliser S3 Select pour JSON de la même manière. Pour une liste d'options, leurs valeurs par défaut et leurs limitations, consultez [Options](#emr-spark-s3select-specify-options).
------
#### [ PySpark ]
```
spark
.read
.format("s3selectCSV") // "s3selectJson" for Json
.schema(...) // optional, but recommended
.options(...) // optional
.load("s3://path/to/my/datafiles")
```
------
#### [ R ]
```
read.df("s3://path/to/my/datafiles", "s3selectCSV", schema, header = "true", delimiter = "\t")
```
------
#### [ Scala ]
```
spark
.read
.format("s3selectCSV") // "s3selectJson" for Json
.schema(...) // optional, but recommended
.options(...) // optional. Examples:
// .options(Map("quote" -> "\'", "header" -> "true")) or
// .option("quote", "\'").option("header", "true")
.load("s3://path/to/my/datafiles")
```
------
#### [ SQL ]
```
CREATE TEMPORARY VIEW MyView (number INT, name STRING) USING s3selectCSV OPTIONS (path "s3://path/to/my/datafiles", header "true", delimiter "\t")
```
------
### Options
Les options suivantes sont disponibles lors de l'utilisation de `s3selectCSV` et `s3selectJSON`. Si rien n'est spécifié, les valeurs par défaut sont utilisées.
#### Options avec S3selectCSV
| Option | Par défaut | Usage |
| --- | --- | --- |
| `compression` | `"none"` | Indique si la compression est utilisée. `"gzip"` est le seul paramètre pris en charge, à part `"none"`. |
| `delimiter` | "," | Spécifie le caractère délimiteur de champ. |
| `quote` | `'\"'` | Spécifie le caractère de citation. La spécification d'une chaîne vide n'est pas prise en charge et mène à une erreur de XML malformé. |
| `escape` | `'\\'` | Spécifie le caractère échappe. |
| `header` | `"false"` | `"false"` spécifie qu'il n'y a pas d'en-tête. `"true"` spécifie qu'une en-tête est dans la première ligne. Les en-têtes ne sont prises en charge que pour la première ligne, et les lignes vides avant une en-tête ne sont pas prises en charge. |
| comment | `"#"` | Spécifie le caractère de commentaire. L'indicateur de commentaire ne peut pas être désactivé. En d'autres termes, la valeur de `\u0000` n'est pas prise en charge. |
| `nullValue` | "" | |
#### Options avec S3selectJSON
| Option | Par défaut | Usage |
| --- | --- | --- |
| `compression` | `"none"` | Indique si la compression est utilisée. `"gzip"` est le seul paramètre pris en charge, à part `"none"`. |
| `multiline` | « false » | `"false"` spécifie que JSON est en format `LINES` S3 Select. Cela implique que chaque ligne des données d'entrée contient un seul objet JSON. `"true"` spécifie que JSON est en format `DOCUMENT` S3 Select, ce qui signifie qu'un objet JSON peut s'étendre sur plusieurs lignes dans les données d'entrée. |
# EMR Spark MagicCommitProtocol
À partir de la version 6.15.0 d'EMR, MagicCommitProtocol devient la valeur par défaut FileCommitProtocol pour Spark lors de l'utilisation du système de fichiers S3A.
## MagicCommitProtocol
MagicCommitProtocol Il s'agit d'une implémentation alternative optimisée pour écrire des fichiers avec EMR Spark sur Amazon S3 lors de l'utilisation du système de fichiers S3A. [FileCommitProtocol](https://dlcdn.apache.org/spark/docs/2.4.2/api/java/org/apache/spark/internal/io/FileCommitProtocol.html) Ce protocole vise à améliorer les performances des applications en évitant d'utiliser des opérations de renommage dans Amazon S3 pendant les phases de validation des tâches et des tâches.
MagicCommitProtocol Il s'agit de l' FileCommitProtocol implémentation par défaut utilisée par Spark s'exécutant sur Amazon Elastic Map Reduce (EMR) lorsque le système de fichiers S3A est utilisé. Il utilise MagicCommitProtocol en interne le [MagicV2Committer pour effectuer les écritures](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/s3a-magicv2-committer.html) de fichiers sur Amazon S3.
Pour les opérations d'insertion statique, les MagicCommitProtocol fichiers sont écrits dans l'emplacement de sortie de la tâche pendant la phase de validation de la tâche. En revanche, pour les opérations d'insertion et de réécriture dynamiques, les fichiers écrits par des tentatives de tâche apparaissent uniquement dans l'emplacement de sortie de la tâche lors de la validation de la tâche. Pour ce faire, les métadonnées de validation sont réexportées vers le pilote Spark lors de l'appel de validation de la tâche.
## Activant MagicCommitProtocol
MagicCommitProtocol Il est activé par défaut pour que Spark s'exécute sur Amazon Elastic Map Reduce (EMR) lors de l'utilisation du système de fichiers S3A.
Pour utiliser le système de fichiers S3A, vous pouvez soit :
1. Utilisez le schéma de fichier comme `s3a://` lors de la définition de la table, de la partition ou du répertoire.
1. Définissez la configuration `fs.s3.impl=org.apache.hadoop.fs.s3a.S3AFileSystem` dans le fichier core-site.xml.
## Désactivation du MagicCommitProtocol
1. Vous pouvez le `spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol.leverageMagicCommitProtocol` définir sur false en le codant en dur dans a`SparkConf`, en le passant en tant que `--conf` paramètre dans le shell Spark ou `spark-submit` les `spark-sql` outils, ou dans`conf/spark-defaults.conf`. Pour plus d'informations, consultez la section [Configuration de Spark](https://spark.apache.org/docs/latest/configuration.html) dans la documentation d'Apache Spark.
L'exemple suivant montre comment le désactiver MagicCommitProtocol lors de l'exécution d'une `spark-sql` commande.
```
spark-sql \
--conf spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol.leverageMagicCommitProtocol=false \
-e "INSERT OVERWRITE TABLE target_table SELECT * FROM source_table;"
```
1. Utilisez la classification `spark-defaults` de configuration pour définir la `spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol.leverageMagicCommitProtocol` propriété sur false. Pour plus d'informations, consultez [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
## MagicCommitProtocol considérations
+ Pour l'insertion d'une partition statique, sur les exécuteurs Spark, chaque fichier écrit par une tentative de tâche MagicCommitProtocol consomme une petite quantité de mémoire jusqu'à ce que la tâche soit validée ou abandonnée. La quantité de mémoire consommée est négligeable dans la plupart des tâches. Aucune mémoire supplémentaire n'est requise sur le pilote Spark
+ Pour l'insertion dynamique d'une partition, sur les pilotes Spark, MagicCommitProtocol il faut de la mémoire pour stocker les informations de métadonnées de chaque fichier validé jusqu'à ce que la tâche soit validée ou abandonnée. Dans la plupart des tâches, le paramètre de mémoire par défaut du pilote Spark est négligeable.
Pour les tâches qui ont des tâches de longue durée qui écrivent un grand nombre de fichiers, la mémoire que le protocole de validation consomme peut être perceptible et nécessiter des ajustements de la mémoire allouée pour Spark, en particulier pour les exécuteurs Spark. Vous pouvez régler la mémoire à l'aide de la propriété `spark.driver.memory` pour les pilotes Spark et de la propriété `spark.executor.memory` pour les exécuteurs Spark. À titre indicatif, une seule tâche d'écriture de 100 000 fichiers nécessite généralement 200 Mo de mémoire supplémentaires. Pour plus d'informations, consultez [Propriétés d'applications](https://spark.apache.org/docs/latest/configuration.html#application-properties) dans la Documentation de configuration Apache Spark.
# Utilisation d'un valideur EMRFS optimisé pour S3
Le committer optimisé pour EMRFS S3 est une [OutputCommitter](https://hadoop.apache.org/docs/current/api/org/apache/hadoop/mapreduce/OutputCommitter.html)implémentation alternative optimisée pour écrire des fichiers sur Amazon S3 lors de l'utilisation d'EMRFS. Le validateur EMRFS optimisé pour S3 améliore les performances de l'application en évitant les opérations de liste et de renommage effectuées dans Amazon S3 pendant les phases de validation des tâches. Le valideur est disponible dans les versions 5.19.0 et ultérieures d'Amazon EMR et est activé par défaut dans les versions 5.20.0 et ultérieures d'Amazon EMR. Le committer est utilisé pour les tâches Spark qui utilisent Spark ou Datasets. DataFrames À partir d'Amazon EMR 6.4.0, ce validateur peut être utilisé pour tous les formats courants, notamment parquet, ORC et les formats basés sur le texte (notamment CSV et JSON). Pour les versions antérieures à Amazon EMR 6.4.0, seul le format Parquet est pris en charge. Dans certaines situations, le valideur n'est pas utilisé. Pour de plus amples informations, veuillez consulter [Exigences du valideur EMRFS optimisé pour S3](emr-spark-committer-reqs.md).
**Topics**
+ [Exigences du valideur EMRFS optimisé pour S3](emr-spark-committer-reqs.md)
+ [Le valideur EMRFS optimisé pour S3 et les chargements partitionnés](emr-spark-committer-multipart.md)
+ [Considérations de réglage de tâche](emr-spark-committer-tuning.md)
+ [Activer le validateur EMRFS S3 pour Amazon EMR 5.19.0](emr-spark-committer-enable.md)
# Exigences du valideur EMRFS optimisé pour S3
Le valideur EMRFS optimisé pour S3 est utilisé lorsque les conditions suivantes sont réunies :
+ Vous exécutez des tâches Spark qui utilisent Spark ou Datasets pour écrire des fichiers sur Amazon S3. DataFrames À partir d'Amazon EMR 6.4.0, ce validateur peut être utilisé pour tous les formats courants, notamment parquet, ORC et les formats basés sur le texte (notamment CSV et JSON). Pour les versions antérieures à Amazon EMR 6.4.0, seul le format Parquet est pris en charge.
+ Les chargements partitionnés sont activés dans Amazon EMR. Il s’agit de l’option par défaut. Pour de plus amples informations, veuillez consulter [Le valideur EMRFS optimisé pour S3 et les chargements partitionnés](emr-spark-committer-multipart.md).
+ Le support de format de fichier intégré à Spark est utilisé. La prise en charge du format de fichier intégré est utilisée dans les circonstances suivantes :
+ Pour les tables de métastore Hive, lorsque `spark.sql.hive.convertMetastoreParquet` est défini sur `true` pour les tables Parquet, ou lorsque `spark.sql.hive.convertMetastoreOrc` est défini sur `true` pour les tables Orc avec Amazon EMR 6.4.0 ou version ultérieure. Il s'agit des paramètres par défaut.
+ Lorsque les tâches écrivent dans des sources de données ou des tables au format de fichier – par exemple, la table cible est créée avec la clause `USING parquet`.
+ Lorsque des tâches écrivent dans des tableaux Parquet de metastore Hive non partitionnées. Le support Parquet intégré à Spark ne prend pas en charge avec les tableaux Hive partitionnés. Il s'agit d'une limitation connue. Pour plus d'informations, consultez la section [Conversion des tables Hive Metastore Parquet](https://spark.apache.org/docs/latest/sql-data-sources-parquet.html#hive-metastore-parquet-table-conversion) dans le guide Apache Spark DataFrames et Datasets.
+ Les opérations de tâche Spark qui écrivent dans un emplacement de partition par défaut (par exemple, `${table_location}/k1=v1/k2=v2/`) utilisent le valideur. Le valideur n'est pas utilisé si une opération de tâche écrit dans un emplacement de partition personnalisé, par exemple, si un emplacement de partition personnalisé est défini à l'aide de la commande `ALTER TABLE SQL`.
+ Les valeurs suivantes pour Spark doivent être utilisées :
+ La propriété `spark.sql.parquet.fs.optimized.committer.optimization-enabled` doit être définie sur `true`. Il s'agit du paramètre par défaut avec Amazon EMR 5.20.0 ou version suivante. Avec Amazon EMR 5.19.0, la valeur par défaut est `false`. Pour plus d'informations sur la configuration de cette valeur, consultez [Activer le validateur EMRFS S3 pour Amazon EMR 5.19.0](emr-spark-committer-enable.md).
+ Si vous écrivez dans des tables de métastore Hive non partitionnées, seuls les formats de fichier Parquet et Orc sont pris en charge. `spark.sql.hive.convertMetastoreParquet`doit être défini sur `true` si vous écrivez sur des tables de métastore Parquet Hive non partitionnées. `spark.sql.hive.convertMetastoreOrc`doit être défini sur `true` si vous écrivez dans des tables de métastore Orc Hive non partitionnées. Il s'agit des paramètres par défaut.
+ `spark.sql.parquet.output.committer.class` doit être défini sur `com.amazon.emr.committer.EmrOptimizedSparkSqlParquetOutputCommitter`. Il s’agit du paramètre par défaut.
+ `spark.sql.sources.commitProtocolClass` doit être défini sur `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol` ou `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol`. `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol` est le paramètre par défaut pour les versions 5.30.0 et ultérieures de la série Amazon EMR 5.x, et pour les versions 6.2.0 et ultérieures de la série Amazon EMR 6.x. `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol` est le paramètre par défaut pour les versions précédentes d’Amazon EMR.
+ Si des tâches Spark remplacent des ensembles de données Parquet partitionnés par des colonnes de partition dynamique, l'option d'écriture `partitionOverwriteMode` et `spark.sql.sources.partitionOverwriteMode` doivent être définis sur `static`. Il s’agit du paramètre par défaut.
**Note**
L'option d'écriture `partitionOverwriteMode` a été introduite dans Spark 2.4.0. Pour Spark version 2.3.2, inclus avec Amazon EMR version 5.19.0, définissez la propriété `spark.sql.sources.partitionOverwriteMode`.
## Cas dans lesquels le valideur EMRFS optimisé pour S3 n’est pas utilisé
En général, le valideur EMRFS S3 optimisé n’est pas utilisé dans les situations suivantes.
****
| Situation | Pourquoi le validateur n'est pas utilisé |
| --- | --- |
| Lorsque vous écrivez dans HDFS | Le validateur prend uniquement en charge l'écriture sur Amazon S3 à l'aide d'EMRFS. |
| Lorsque vous utilisez le système de fichiers S3A | Le validateur ne prend en charge que EMRFS. |
| Lorsque vous utilisez l' MapReduce API RDD de Spark | Le committer prend uniquement en charge l'utilisation de SparkSQL ou DataFrame Dataset. APIs |
Les exemples en Scala suivants illustrent quelques situations supplémentaires qui empêchent d'utiliser le validateur optimisé pour EMRFS S3 en totalité (premier exemple) et en partie (deuxième exemple).
**Example – Mode de remplacement de partition dynamique**
L'exemple Scala suivant indique à Spark d'utiliser un algorithme de validation différent, ce qui empêche complètement l'utilisation du validateur optimisé pour EMRFS S3. Le code définit la propriété `partitionOverwriteMode` sur `dynamic` pour n'écraser que les partitions sur lesquelles vous écrivez des données. Ensuite, les colonnes de partition dynamique sont spécifiées par `partitionBy`, et le mode d'écriture est défini sur `overwrite`.
```
val dataset = spark.range(0, 10)
.withColumn("dt", expr("date_sub(current_date(), id)"))
dataset.write.mode("overwrite")
.option("partitionOverwriteMode", "dynamic")
.partitionBy("dt")
.parquet("s3://amzn-s3-demo-bucket1/output")
```
Vous devez configurer les trois paramètres pour éviter d'utiliser le validateur EMRFS S3. Lorsque vous le faites, Spark exécute un algorithme de validation différent qui est spécifié dans le protocole de validation de Spark. Pour les versions d'Amazon EMR 5.x antérieures à la version 5.30.0 et pour les versions d'Amazon EMR 6.x antérieures à la version 6.2.0, le protocole de validation utilise le répertoire de préparation de Spark, qui est un répertoire temporaire créé sous l'emplacement de sortie commençant par `.spark-staging`. L'algorithme renomme séquentiellement les répertoires de partition, ce qui peut avoir un impact négatif sur les performances. Pour de plus amples informations sur Amazon EMR versions 5.30.0 et versions ultérieures, ainsi que 6.2.0 et versions ultérieures, veuillez consulter [Utiliser le protocole de validation optimisé pour EMRFS S3](emr-spark-s3-optimized-commit-protocol.md).
L'algorithme dans Spark 2.4.0 exécute les étapes suivantes :
1. Les tentatives de tâches écrivent leur résultat dans les répertoires de partition situés dans le répertoire de préparation de Spark, par exemple, `${outputLocation}/spark-staging-${jobID}/k1=v1/k2=v2/`.
1. Pour chaque partition écrite, la tâche tente de suivre les chemins de partition relatifs, par exemple, `k1=v1/k2=v2`.
1. Lorsqu'une tâche se termine avec succès elle fournit le pilote avec tous les chemins de partition relatifs qu'elle a suivis.
1. Une fois toutes les tâches terminées, la phase de validation de tâche collecte tous les répertoires de partition que les tentatives de tâche réussies ont écrit dans le répertoire intermédiaire de Spark. Spark renomme de manière séquentielle chacun de ces répertoires dans son emplacement de sortie final à l'aide d'opérations attribution de nouveau nom de l'arborescence.
1. Le répertoire intermédiaire est supprimé avant que la phase de validation de tâche soit terminée.
**Example – Emplacement de partition personnalisé**
Dans cet exemple, le code Scala s'insère dans deux partitions. Une partition possède un emplacement de partition personnalisé. L'autre partition utilise l'emplacement de partition par défaut. Le valideur EMRFS optimisé pour S3 est utilisé uniquement pour écrire la sortie de tâche dans la partition qui utilise l'emplacement de partition par défaut.
```
val table = "dataset"
val location = "s3://bucket/table"
spark.sql(s"""
CREATE TABLE $table (id bigint, dt date)
USING PARQUET PARTITIONED BY (dt)
LOCATION '$location'
""")
// Add a partition using a custom location
val customPartitionLocation = "s3://bucket/custom"
spark.sql(s"""
ALTER TABLE $table ADD PARTITION (dt='2019-01-28')
LOCATION '$customPartitionLocation'
""")
// Add another partition using default location
spark.sql(s"ALTER TABLE $table ADD PARTITION (dt='2019-01-29')")
def asDate(text: String) = lit(text).cast("date")
spark.range(0, 10)
.withColumn("dt",
when($"id" > 4, asDate("2019-01-28")).otherwise(asDate("2019-01-29")))
.write.insertInto(table)
```
Le code Scala crée les objets Amazon S3 suivants :
```
custom/part-00001-035a2a9c-4a09-4917-8819-e77134342402.c000.snappy.parquet
custom_$folder$
table/_SUCCESS
table/dt=2019-01-29/part-00000-035a2a9c-4a09-4917-8819-e77134342402.c000.snappy.parquet
table/dt=2019-01-29_$folder$
table_$folder$
```
Lorsque vous écrivez des partitions dans des emplacements personnalisés, Spark utilise un algorithme de validation similaire à celui de l'exemple précédent, qui est décrit ci-dessous. Comme dans l'exemple précédent, l'algorithme se traduit par des attributions séquentielles de nouveaux noms, ce qui peut avoir un impact négatif sur les performances.
1. Lors de l'écriture de la sortie d'une partition dans un emplacement personnalisé, les tâches écrivent un fichier dans le répertoire intermédiaire de Spark, qui est créé sous l'emplacement de sortie final. Le nom du fichier comprend un UUID aléatoire pour éviter les conflits de fichier. La tentative de tâche suit chaque fichier, ainsi que le chemin de la sortie souhaité final.
1. Lorsqu'une tâche se termine avec succès, elle fournit au pilote les fichiers et les chemins de sortie souhaités finaux.
1. Une fois toutes les tâches terminées, la phase de validation de tâche renomme de manière séquentielle tous les fichiers qui ont été écrits pour les partitions dans les emplacements personnalisés en leurs chemins de sortie finaux.
1. Le répertoire intermédiaire est supprimé avant que la phase de validation de tâche soit terminée.
# Le valideur EMRFS optimisé pour S3 et les chargements partitionnés
Pour utiliser le valideur EMRFS optimisé pour S3, vous devez activer les chargements partitionnés dans Amazon EMR. Les chargements partitionnés sont activés par défaut. Vous pouvez les réactiver si besoin est. Pour plus d'informations, consultez [Configuration d'un chargement partitionné pour Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#Config_Multipart) dans le *Guide de gestion Amazon EMR*.
Le valideur EMRFS optimisé pour S3 utilise des caractéristiques similaires à des transactions de chargements partitionnés pour assurer que les fichiers écrits par des tentatives de tâches apparaissent uniquement dans l'emplacement de sortie du travail lors de la validation de tâche. En utilisant les téléchargements partitionnés de cette manière, le validateur améliore les performances de validation des tâches par rapport à la version 2 de l' FileOutputCommitter algorithme par défaut. Lors de l'utilisation d'un valideur EMRFS optimisé pour S3, il existe certaines différences importantes à prendre en compte comparé au comportement de chargement partitionné :
+ Les chargements partitionnés sont toujours effectués, peu importe la taille du fichier. Ceci diffère du comportement normal d'EMRFS, où la propriété `fs.s3n.multipart.uploads.split.size` contrôle la taille du fichier à laquelle les chargements partitionnés sont enclenchés.
+ Les chargements partitionnés sont laissés en état non terminé pendant un plus long laps de temps jusqu'à ce que la tâche soit validée ou abandonnée. Ceci diffère du comportement normal d'EMRFS, où un chargement partitionné se termine lorsqu'un tâche termine d'écrire un fichier donné.
En raison de ces différences, si un Spark Executor JVM crache ou qu'il est tué lorsque des tâches sont en cours d'exécution ou écrivent des données à Amazon S3, les chargements partitionnés inachevés ont plus de chances d'être laissés de côté. Pour cette raison, lorsque vous utilisez un valideur EMRFS optimisé pour S3, assurez-vous de suivre les bonnes pratiques de gestion de chargements partitionnés échoués. Pour plus d'informations, consultez [Bonnes pratiques](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) pour travailler avec des compartiments Amazon S3 dans le *Guide de gestion Amazon EMR*.
# Considérations de réglage de tâche
Le valideur EMRFS optimisé pour S3 consomme une petite quantité de mémoire pour chaque fichier écrit par une tentative de tâche, jusqu'à ce que la tâche soit validée ou abandonnée. La quantité de mémoire consommée est négligeable dans la plupart des tâches. Pour les tâches dotées de tâches à longue exécution qui écrivent un grand nombre de fichiers, la mémoire consommée par le valideur peut être significative et nécessitera des ajustements à l'allocation de mémoire aux exécuteurs Spark. Vous pouvez ajuster la mémoire d'exécuteur à l'aide de la propriété `spark.executor.memory`. Une seule tâche écrivant 100 000 fichiers nécessiterait en général environ 100 Mo de mémoire supplémentaire. Pour plus d'informations, consultez [Propriétés d'applications](https://spark.apache.org/docs/latest/configuration.html#application-properties) dans la Documentation de configuration Apache Spark.
# Activer le validateur EMRFS S3 pour Amazon EMR 5.19.0
Si vous utilisez Amazon EMR 5.19.0, vous pouvez définir la propriété `spark.sql.parquet.fs.optimized.committer.optimization-enabled` sur `true` lorsque vous créez un cluster, ou depuis Spark si vous utilisez Amazon EMR.
## Activation d'un valideur EMRFS optimisé pour S3 lors de la création d'un cluster
Utilisez la classification de configuration `spark-defaults` pour définir la propriété `spark.sql.parquet.fs.optimized.committer.optimization-enabled` sur `true`. Pour de plus amples informations, veuillez consulter [Configuration des applications](emr-configure-apps.md).
## Activation d'un valideur EMRFS optimisé pour S3 depuis Spark
Vous pouvez définir `spark.sql.parquet.fs.optimized.committer.optimization-enabled` sur `true` en l'ancrant dans un `SparkConf`, en le passant comme paramètre `--conf` dans le shell Spark ou les outils `spark-submit` et `spark-sql`, ou dans `conf/spark-defaults.conf`. Pour plus d'informations, consultez [Configuration Spark](https://spark.apache.org/docs/latest/configuration.html) dans la documentation Apache Spark.
L'exemple suivant montre comment activer le valideur en exécutant une commande spark-sql.
```
spark-sql \
--conf spark.sql.parquet.fs.optimized.committer.optimization-enabled=true \
-e "INSERT OVERWRITE TABLE target_table SELECT * FROM source_table;"
```
# Utiliser le protocole de validation optimisé pour EMRFS S3
Le protocole de validation optimisé pour EMRFS S3 est une [FileCommitProtocol](https://spark.apache.org/docs/2.2.0//api/java/org/apache/spark/internal/io/FileCommitProtocol.html)implémentation alternative optimisée pour écrire des fichiers avec remplacement dynamique de partition Spark sur Amazon S3 lors de l'utilisation d'EMRFS. Le protocole améliore les performances des applications en évitant les opérations de renommage dans Amazon S3 pendant la phase de validation de la tâche de remplacement de partition dynamique Spark.
Notez que le [validateur optimisé pour EMRFS S3 améliore également les performances en évitant](emr-spark-s3-optimized-committer.html) les opérations de renommage. Cependant, cela ne fonctionne pas pour les cas de remplacement de partition dynamique, tandis que les améliorations du protocole de validation ne ciblent que les cas de remplacement de partition dynamique.
Le protocole de validation est disponible avec les versions 5.30.0 et suivantes d'Amazon EMR et 6.2.0 et suivantes, et il est activé par défaut. Amazon EMR a ajouté une amélioration du parallélisme à partir de la version 5.31.0. Le protocole est utilisé pour les tâches Spark qui utilisent Spark ou Datasets. DataFrames Dans certaines circonstances, le protocole de validation n'est pas utilisé. Pour de plus amples informations, veuillez consulter [Conditions requises pour le protocole de validation EMRFS optimisé pour S3](emr-spark-committer-reqs.md).
**Topics**
+ [Conditions requises pour le protocole de validation EMRFS optimisé pour S3](emr-spark-commit-protocol-reqs.md)
+ [Le protocole de validation EMRFS optimisé pour S3 et les chargements partitionnés](emr-spark-commit-protocol-multipart.md)
+ [Considérations de réglage de tâche](emr-spark-commit-protocol-tuning.md)
# Conditions requises pour le protocole de validation EMRFS optimisé pour S3
Le protocole de validation EMRFS optimisé pour S3 est utilisé lorsque les conditions suivantes sont remplies :
+ Vous exécutez des tâches Spark qui utilisent Spark ou Datasets pour remplacer les tables partitionnées. DataFrames
+ Vous exécutez des tâches Spark dont le mode de remplacement de partition est `dynamic`.
+ Les chargements partitionnés sont activés dans Amazon EMR. Il s’agit de l’option par défaut. Pour de plus amples informations, veuillez consulter [Le protocole de validation EMRFS optimisé pour S3 et les chargements partitionnés](emr-spark-commit-protocol-multipart.md).
+ Le cache du système de fichiers pour EMRFS est activé. Il s’agit de l’option par défaut. Vérifiez que le paramètre `fs.s3.impl.disable.cache` est défini sur `false`.
+ Le support intégré des sources de données de Spark est utilisé. La prise en charge de la source de données intégrée est utilisée dans les circonstances suivantes :
+ Lorsque les tâches écrivent dans des sources de données ou des tables intégrées.
+ Lorsque les tâches écrivent dans la table Parquet du métastore Hive. Cela se produit lorsque `spark.sql.hive.convertInsertingPartitionedTable` et `spark.sql.hive.convertMetastoreParquet` sont tous deux définis sur true. Il s'agit des paramètres par défaut.
+ Lorsque les jobs écrivent dans la table ORC du métastore Hive. Cela se produit lorsque `spark.sql.hive.convertInsertingPartitionedTable` et `spark.sql.hive.convertMetastoreOrc` sont tous deux définis sur `true`. Il s'agit des paramètres par défaut.
+ Les opérations de tâches Spark qui écrivent dans un emplacement de partition par défaut (par exemple, `${table_location}/k1=v1/k2=v2/`) utilisent le protocole de validation. Le protocole n'est pas utilisé si une opération de tâche écrit dans un emplacement de partition personnalisé (par exemple, si un emplacement de partition personnalisé est défini à l'aide de la commande `ALTER TABLE SQL`).
+ Les valeurs suivantes pour Spark doivent être utilisées :
+ `spark.sql.sources.commitProtocolClass` doit être défini sur `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol`. Il s'agit du paramètre par défaut pour les versions 5.30.0 et supérieures d'Amazon EMR, ainsi que pour les versions 6.2.0 et supérieures.
+ L'option d'écriture `partitionOverwriteMode` ou `spark.sql.sources.partitionOverwriteMode` doit être définie sur `dynamic`. Le paramètre par défaut est `static`.
**Note**
L'option d'écriture `partitionOverwriteMode` a été introduite dans Spark 2.4.0. Pour Spark version 2.3.2, inclus avec Amazon EMR version 5.19.0, définissez la propriété `spark.sql.sources.partitionOverwriteMode`.
+ Si les tâches Spark remplacent la table Parquet du métastore Hive, `spark.sql.hive.convertMetastoreParquet`, `spark.sql.hive.convertInsertingPartitionedTable` et `spark.sql.hive.convertMetastore.partitionOverwriteMode` doivent être définis sur `true`. Il s'agit des paramètres par défaut.
+ Si les tâches Spark remplacent la table ORC du métastore Hive, `spark.sql.hive.convertMetastoreOrc`, `spark.sql.hive.convertInsertingPartitionedTable` et `spark.sql.hive.convertMetastore.partitionOverwriteMode` doivent être définis sur `true`. Il s'agit des paramètres par défaut.
**Example – Mode de remplacement de partition dynamique**
Dans cet exemple de Scala, l'optimisation est déclenchée. Tout d'abord, vous définissez la propriété `partitionOverwriteMode` sur `dynamic`. Cela remplace uniquement les partitions sur lesquelles vous écrivez des données. Ensuite, vous spécifiez les colonnes de partition dynamique avec `partitionBy` et définissez le mode d'écriture sur `overwrite`.
```
val dataset = spark.range(0, 10)
.withColumn("dt", expr("date_sub(current_date(), id)"))
dataset.write.mode("overwrite") // "overwrite" instead of "insert"
.option("partitionOverwriteMode", "dynamic") // "dynamic" instead of "static"
.partitionBy("dt") // partitioned data instead of unpartitioned data
.parquet("s3://amzn-s3-demo-bucket1/output") // "s3://" to use Amazon EMR file system, instead of "s3a://" or "hdfs://"
```
## Lorsque le protocole de validation EMRFS optimisé pour S3 n'est pas utilisé
En général, le protocole de validation optimisé pour EMRFS S3 fonctionne de la même manière que le protocole de validation Spark par défaut open source. `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol` L'optimisation ne se produira pas dans les situations suivantes.
****
| Situation | Pourquoi le protocole de validation n'est pas utilisé |
| --- | --- |
| Lorsque vous écrivez dans HDFS | Le protocole de validation prend uniquement en charge l'écriture sur Amazon S3 à l'aide d'EMRFS. |
| Lorsque vous utilisez le système de fichiers S3A | Le protocole de validation ne prend en charge que le protocole EMRFS. |
| Lorsque vous utilisez l' MapReduce API RDD de Spark | Le protocole de validation prend uniquement en charge l'utilisation de SparkSQL ou DataFrame Dataset. APIs |
| Lorsque le remplacement dynamique de la partition n'est pas déclenché | Le protocole de validation optimise uniquement les cas de remplacement dynamique de partitions. Pour les autres cas, consultez [Utilisation d'un valideur EMRFS optimisé pour S3](emr-spark-s3-optimized-committer.md). |
Les exemples Scala suivants démontrent quelques situations supplémentaires que le protocole de validation EMRFS optimisé pour S3 délègue à `SQLHadoopMapReduceCommitProtocol`.
**Example – Mode de remplacement dynamique de partition avec emplacement de partition personnalisé**
Dans cet exemple, les programmes Scala remplacent deux partitions en mode de remplacement dynamique de partition. Une partition possède un emplacement de partition personnalisé. L'autre partition utilise l'emplacement de partition par défaut. Le protocole de validation EMRFS optimisé pour S3 n'améliore que la partition qui utilise l'emplacement de partition par défaut.
```
val table = "dataset"
val inputView = "tempView"
val location = "s3://bucket/table"
spark.sql(s"""
CREATE TABLE $table (id bigint, dt date)
USING PARQUET PARTITIONED BY (dt)
LOCATION '$location'
""")
// Add a partition using a custom location
val customPartitionLocation = "s3://bucket/custom"
spark.sql(s"""
ALTER TABLE $table ADD PARTITION (dt='2019-01-28')
LOCATION '$customPartitionLocation'
""")
// Add another partition using default location
spark.sql(s"ALTER TABLE $table ADD PARTITION (dt='2019-01-29')")
def asDate(text: String) = lit(text).cast("date")
spark.range(0, 10)
.withColumn("dt",
when($"id" > 4, asDate("2019-01-28")).otherwise(asDate("2019-01-29")))
.createTempView(inputView)
// Set partition overwrite mode to 'dynamic'
spark.sql(s"SET spark.sql.sources.partitionOverwriteMode=dynamic")
spark.sql(s"INSERT OVERWRITE TABLE $table SELECT * FROM $inputView")
```
Le code Scala crée les objets Amazon S3 suivants :
```
custom/part-00001-035a2a9c-4a09-4917-8819-e77134342402.c000.snappy.parquet
custom_$folder$
table/_SUCCESS
table/dt=2019-01-29/part-00000-035a2a9c-4a09-4917-8819-e77134342402.c000.snappy.parquet
table/dt=2019-01-29_$folder$
table_$folder$
```
L'écriture sur des emplacements de partition personnalisés dans les versions antérieures de Spark peut entraîner une perte de données. Dans cet exemple, la partition `dt='2019-01-28'` serait perdue. Pour plus de détails, consultez [SPARK-35106](https://issues.apache.org/jira/browse/SPARK-35106). Ce problème est résolu dans les versions 5.33.0 et ultérieures d'Amazon EMR, à l'exception des versions 6.0.x et 6.1.x.
Lorsque vous écrivez des partitions dans des emplacements personnalisés, Spark utilise un algorithme de validation similaire à celui de l'exemple précédent, qui est décrit ci-dessous. Comme dans l'exemple précédent, l'algorithme se traduit par des attributions séquentielles de nouveaux noms, ce qui peut avoir un impact négatif sur les performances.
L'algorithme dans Spark 2.4.0 exécute les étapes suivantes :
1. Lors de l'écriture de la sortie d'une partition dans un emplacement personnalisé, les tâches écrivent un fichier dans le répertoire intermédiaire de Spark, qui est créé sous l'emplacement de sortie final. Le nom du fichier comprend un UUID aléatoire pour éviter les conflits de fichier. La tentative de tâche suit chaque fichier, ainsi que le chemin de la sortie souhaité final.
1. Lorsqu'une tâche se termine avec succès, elle fournit au pilote les fichiers et les chemins de sortie souhaités finaux.
1. Une fois toutes les tâches terminées, la phase de validation de tâche renomme de manière séquentielle tous les fichiers qui ont été écrits pour les partitions dans les emplacements personnalisés en leurs chemins de sortie finaux.
1. Le répertoire intermédiaire est supprimé avant que la phase de validation de tâche soit terminée.
# Le protocole de validation EMRFS optimisé pour S3 et les chargements partitionnés
Pour utiliser l'optimisation pour le remplacement dynamique des partitions dans le protocole de validation optimisé pour EMRFS S3, les chargements partitionnés doivent être activés dans Amazon EMR. Les chargements partitionnés sont activés par défaut. Vous pouvez les réactiver si besoin est. Pour plus d'informations, consultez [Configuration d'un chargement partitionné pour Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#Config_Multipart) dans le *Guide de gestion Amazon EMR*.
Pendant l'écrasement dynamique de partition, le protocole de validation EMRFS optimisé pour S3 utilise les caractéristiques de transaction des chargements partitionnés pour s'assurer que les fichiers écrits par les tentatives de tâches n'apparaissent que dans l'emplacement de sortie de la tâche au moment de la validation de la tâche. En utilisant les chargements partitionnés de cette manière, le protocole de validation améliore les performances de validation des tâches par rapport au protocole par défaut `SQLHadoopMapReduceCommitProtocol`. Lors de l'utilisation du protocole de validation EMRFS optimisé pour S3, il y a quelques différences clés à prendre en compte par rapport au comportement traditionnel des chargements partitionnés :
+ Les chargements partitionnés sont toujours effectués, peu importe la taille du fichier. Ceci diffère du comportement normal d'EMRFS, où la propriété `fs.s3n.multipart.uploads.split.size` contrôle la taille du fichier à laquelle les chargements partitionnés sont enclenchés.
+ Les chargements partitionnés sont laissés en état non terminé pendant un plus long laps de temps jusqu'à ce que la tâche soit validée ou abandonnée. Ceci diffère du comportement normal d'EMRFS, où un chargement partitionné se termine lorsqu'un tâche termine d'écrire un fichier donné.
En raison de ces différences, si une JVM Spark Executor se bloque ou est mise hors service alors que des tâches sont en cours d'exécution et écrivent des données sur Amazon S3, ou si une JVM Spark Driver se bloque ou est mise hors service alors qu'une tâche est en cours d'exécution, les chargements partitionnés incomplets sont plus susceptibles d'être laissés derrière. Pour cette raison, lorsque vous utilisez le protocole de validation EMRFS optimisé pour S3, assurez-vous de suivre les bonnes pratiques de gestion de chargements partitionnés échoués. Pour plus d'informations, consultez [Bonnes pratiques](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) pour travailler avec des compartiments Amazon S3 dans le *Guide de gestion Amazon EMR*.
# Considérations de réglage de tâche
Sur les exécuteurs Spark, le protocole de validation EMRFS optimisé pour S3 consomme une petite quantité de mémoire pour chaque fichier écrit par une tentative de tâche, jusqu'à ce que la tâche soit validée ou abandonnée. La quantité de mémoire consommée est négligeable dans la plupart des tâches.
Sur les pilotes Spark, le protocole de validation optimisé pour EMRFS S3 nécessite de la mémoire pour stocker les informations de métadonnées de chaque fichier validé jusqu'à ce que la tâche soit validée ou abandonnée. Dans la plupart des tâches, le paramètre de mémoire par défaut du pilote Spark est négligeable.
Pour les tâches qui ont des tâches de longue durée qui écrivent un grand nombre de fichiers, la mémoire que le protocole de validation consomme peut être perceptible et nécessiter des ajustements de la mémoire allouée pour Spark, en particulier pour les exécuteurs Spark. Vous pouvez régler la mémoire à l'aide de la propriété `spark.driver.memory` pour les pilotes Spark et de la propriété `spark.executor.memory` pour les exécuteurs Spark. Une seule tâche écrivant 100 000 fichiers nécessiterait en général environ 100 Mo de mémoire supplémentaire. Pour plus d'informations, consultez [Propriétés d'applications](https://spark.apache.org/docs/latest/configuration.html#application-properties) dans la Documentation de configuration Apache Spark.
# Réessayer de demander Amazon S3 avec EMRFS
Cette rubrique fournit des informations sur les stratégies de nouvelle tentative que vous pouvez utiliser lorsque vous envoyez des demandes à Amazon S3 avec EMRFS. Lorsque votre taux de demandes augmente, S3 essaie de s'adapter au nouveau taux. Au cours de ce processus, S3 peut limiter les demandes et renvoyer une erreur `503 Slow Down`. Pour améliorer le taux de réussite de vos demandes S3, vous pouvez ajuster votre stratégie de réessai en configurant les propriétés dans votre configuration `emrfs-site`.
Vous pouvez ajuster votre stratégie de réessai de différentes manières.
+ Augmentez la limite maximale de tentatives pour la stratégie de backoff exponentiel par défaut.
+ Activez et configurez la stratégie de réessai additive-augmentation/diminution multiplicative (AIMD). AIMD est pris en charge pour Amazon EMR versions 6.4.0 et ultérieures.
## Utiliser la stratégie de backoff exponentiel par défaut
Par défaut, EMRFS utilise une stratégie de backoff exponentiel pour réessayer les requêtes Amazon S3. La limite de tentatives EMRFS par défaut est de 15. Pour éviter une erreur S3 `503 Slow Down`, vous pouvez augmenter le nombre limite de tentatives lorsque vous créez un nouveau cluster, sur un cluster en cours d'exécution ou lors de l'exécution de l'application.
Pour augmenter le nombre limite de tentatives, vous devez modifier la valeur de `fs.s3.maxRetries` dans votre configuration `emrfs-site`. L'exemple de configuration suivant définit `fs.s3.maxRetries` sur une valeur personnalisée de 30.
```
[
{
"Classification": "emrfs-site",
"Properties": {
"fs.s3.maxRetries": "30"
}
}
]
```
Pour plus d'informations sur l'utilisation des objets de configuration, consultez [Configuration des applications](emr-configure-apps.md).
## Utiliser la stratégie de nouvelle tentative de l'AIMD
Avec les versions 6.4.0 et ultérieures d'Amazon EMR, EMRFS prend en charge une stratégie de nouvelle tentative alternative basée sur un modèle d'augmentation/diminution multiplicative (AIMD). La stratégie de nouvelle tentative AIMD est particulièrement utile lorsque vous travaillez avec de grands clusters Amazon EMR.
L'AIMD calcule un taux de demandes personnalisé en utilisant les données relatives aux récentes demandes réussies. Cette stratégie réduit le nombre de demandes limitées et le nombre total de tentatives requises par demande.
Pour activer la stratégie de nouvelle tentative AIMD, vous devez définir la propriété `fs.s3.aimd.enabled` sur `true` dans votre configuration `emrfs-site`, comme dans l'exemple suivant.
```
[
{
"Classification": "emrfs-site",
"Properties": {
"fs.s3.aimd.enabled": "true"
}
}
]
```
Pour plus d'informations sur l'utilisation des objets de configuration, consultez [Configuration des applications](emr-configure-apps.md).
## Paramètres de nouvelle tentative AIMD avancés
Vous pouvez configurer les propriétés répertoriées dans le tableau suivant pour affiner le comportement des nouvelles tentatives lorsque vous utilisez la stratégie de nouvelle tentative AIMD. Dans la plupart des cas d'utilisation, nous vous recommandons d'utiliser les valeurs par défaut.
**Propriétés avancées de la stratégie de nouvelle tentative AIMD**
| Propriété | Valeur par défaut | Description |
| --- | --- | --- |
| fs.s3.aimd.increaseIncrement | 0.1 | Contrôle la rapidité avec laquelle le taux de demandes augmente lorsque des demandes consécutives aboutissent. |
| fs.s3.aimd.reductionFactor | 2 | Contrôle la rapidité avec laquelle le taux de demandes diminue lorsqu'Amazon S3 renvoie une réponse 503. Le facteur par défaut de 2 réduit le taux de demandes de moitié. |
| fs.s3.aimd.minRate | 0.1 | Définit la limite inférieure du taux de demandes lorsque les demandes sont soumises à une limitation soutenue par S3. |
| fs.s3.aimd.initialRate | 5500 | Définit le taux de demande initial, qui change ensuite en fonction des valeurs que vous spécifiez pour fs.s3.aimd.increaseIncrement et fs.s3.aimd.reductionFactor.Le taux initial est également utilisé pour les requêtes GET et ajusté proportionnellement (3500/5500) pour les requêtes PUT. |
| fs.s3.aimd.adjustWindow | 2 | Contrôle la fréquence à laquelle le taux de demandes est ajusté, mesuré en nombre de réponses. |
| fs.s3.aimd.maxAttempts | 100 | Définit le nombre maximum de tentatives pour essayer une demande. |