

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.

# Système de fichiers EMR (EMRFS)
<a name="emr-fs"></a>

**Note**  
À partir de la version 7.10.0 d'EMR, le système de fichiers S3A a remplacé EMRFS en tant que connecteur EMR S3 par défaut.

Le système de fichiers EMR (EMRFS) est une mise en œuvre de HDFS que tous les clusters Amazon EMR utilisent pour la lecture et l'écriture des fichiers réguliers depuis Amazon EMR directement dans Amazon S3. EMRFS permet de stocker des données persistantes dans Amazon S3 en vue de les utiliser avec Hadoop, tout en fournissant des fonctionnalités telles que le chiffrement des données. 

Le chiffrement des données vous permet de chiffrer les objets qu'EMRFS écrit dans Amazon S3 et permet à EMRFS de travailler avec les données chiffrées dans Amazon S3. Si vous utilisez la version 4.8.0 ou ultérieure d'Amazon EMR, vous pouvez utiliser les configurations de sécurité pour configurer le chiffrement des objets EMRFS dans Amazon S3, ainsi que d'autres paramètres de chiffrement. Pour plus d'informations, consultez [Options de chiffrement](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options). Si vous utilisez une version précédente version de Amazon EMR, vous pouvez configurer manuellement les paramètres de chiffrement. Pour de plus amples informations, veuillez consulter [Spécification du chiffrement Amazon S3 en utilisant les propriétés EMRFS](emr-emrfs-encryption.md).

Amazon S3 offre une forte cohérence entre lecture et écriture pour toutes les opérations GET, PUT et LIST dans l'ensemble Régions AWS. Cela signifie que ce que vous écrivez à l'aide d'EMRFS correspond à ce que vous allez lire sur Amazon S3, sans aucun impact sur les performances. Pour plus d’informations, consultez [Modèle de cohérence de données Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel).

Lorsque vous utilisez les versions 5.10.0 ou ultérieures d'Amazon EMR, vous pouvez utiliser différents rôles IAM pour les demandes EMRFS à Amazon S3 en fonction des utilisateurs du cluster, des groupes ou de l'emplacement des données EMRFS dans Amazon S3. Pour plus d'informations, consultez [Configuration de rôles IAM pour les demandes EMRFS à Amazon S3](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-emrfs-iam-roles).

**Avertissement**  
Avant d'activer l'exécution spéculative pour les clusters Amazon EMR exécutant des tâches Apache Spark, veuillez consulter les informations suivantes.  
EMRFS inclut le committer optimisé pour EMRFS S3, une OutputCommitter implémentation optimisée pour écrire des fichiers sur Amazon S3 lors de l'utilisation d'EMRFS. Si vous activez la fonctionnalité d'exécution spéculative d'Apache Spark avec des applications qui écrivent des données sur Amazon S3 et n'utilisent pas le committer optimisé pour EMRFS S3, vous pouvez rencontrer les problèmes d'exactitude des données décrits dans le [SPARK-10063](https://issues.apache.org/jira/browse/SPARK-10063). Cela peut se produire si vous utilisez des versions d'Amazon EMR antérieures à la version 5.19 d'Amazon EMR, ou si vous écrivez des fichiers dans Amazon S3 avec des formats tels que ORC et CSV. Ces formats ne sont pas pris en charge par le validateur optimisé pour EMRFS S3. Pour une liste complète des exigences relatives à l'utilisation du transmetteur optimisé EMRFS S3, consultez [Exigences relatives au transmetteur optimisé EMRFS S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-committer-reqs.html).  
L'écriture directe EMRFS est généralement utilisée lorsque le validateur optimisé pour EMRFS S3 n'est pas pris en charge, par exemple lors de l'écriture de ce qui suit :  
Un format de sortie autre que Parquet, tel que ORC ou texte.
Fichiers Hadoop à l'aide de l'API Spark RDD.
Parquet avec Hive. SerDe Consultez [Conversion de la table Hive Metastore Parquet](https://spark.apache.org/docs/latest/sql-data-sources-parquet.html#hive-metastore-parquet-table-conversion).
L'écriture directe EMRFS n'est pas utilisée dans les scénarios suivants :  
Lorsque le validateur EMRFS optimisé pour S3 est activé. Consultez [Exigences du valideur EMRFS optimisé pour S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-committer-reqs.html).
Lors de l'écriture de partitions dynamiques partitionOverwriteMode définies sur dynamique.
Lorsque vous écrivez sur des emplacements de partition personnalisés, tels que des emplacements non conformes à la convention d'emplacement de partition par défaut de Hive.
Lorsque vous utilisez des systèmes de fichiers autres qu'EMRFS, tels que l'écriture sur HDFS ou l'utilisation du système de fichiers S3A.
Pour déterminer si votre application utilise l'écriture directe dans Amazon EMR 5.14.0 ou version ultérieure, activez la journalisation Spark INFO. Si une ligne de journal contenant le texte « Direct Write : ENABLED » est présente dans les journaux du pilote Spark ou dans les journaux des conteneurs de l'exécuteur Spark, cela signifie que votre application Spark a écrit en écriture directe.  
Par défaut, l'exécution spéculative est activée `OFF` sur Amazon EMRclusters. Nous vous recommandons vivement de ne pas activer l'exécution spéculative si l'une ou l'autre de ces conditions est remplie :  
Vous écrivez des données sur Amazon S3.
Les données sont écrites dans un format autre qu'Apache Parquet ou dans le format Apache Parquet sans utiliser le validateur optimisé pour EMRFS S3.
Si vous activez l'exécution spéculative de Spark et que vous écrivez des données sur Amazon S3 à l'aide de l'écriture directe EMRFS, vous risquez de subir des pertes de données intermittentes. Lorsque vous écrivez des données dans HDFS ou que vous écrivez des données dans Parquet à l'aide du validateur optimisé EMRFS S3, Amazon EMR n'utilise pas l'écriture directe et ce problème ne se produit pas.  
Si vous devez écrire des données dans des formats utilisant l'écriture directe EMRFS depuis Spark vers Amazon S3 et utiliser l'exécution spéculative, nous vous recommandons d'écrire sur HDFS, puis de transférer les fichiers de sortie vers Amazon S3 à l'aide de S3DistCp.

**Topics**
+ [Vue cohérente](emr-plan-consistent-view.md)
+ [Autorisation d'accès aux données EMRFS dans Amazon S3](emr-plan-credentialsprovider.md)
+ [Gestion du point de AWS Security Token Service terminaison par défaut](emr-emrfs-sts-endpoint.md)
+ [Spécification du chiffrement Amazon S3 en utilisant les propriétés EMRFS](emr-emrfs-encryption.md)

# Vue cohérente
<a name="emr-plan-consistent-view"></a>

**Avertissement**  
Le 1er juin 2023, la vue cohérente d'EMRFS atteindra la fin du support standard pour les futures versions d'Amazon EMR. La vue cohérente EMRFS continuera de fonctionner pour les versions existantes.

Avec la sortie d'Amazon S3 Strong read-after-write Cohérence le 1er décembre 2020, vous n'avez plus besoin d'utiliser la vue cohérente EMRFS (EMRFS CV) avec vos clusters Amazon EMR. EMRFS CV est une fonctionnalité optionnelle qui permet aux clusters Amazon EMR de vérifier la liste et la cohérence des objets read-after-write Amazon S3. Lorsque vous créez un cluster et que le CV EMRFS est activé, Amazon EMR crée une base de données Amazon DynamoDB pour stocker les métadonnées des objets qu'il utilise pour suivre la liste et la cohérence des objets S3. read-after-write Vous pouvez désormais désactiver EMRFS CV et supprimer la base de données DynamoDB qu'il utilise afin de ne pas générer de coûts supplémentaires. Les procédures suivantes expliquent comment vérifier la fonctionnalité CV, la désactiver et supprimer la base de données DynamoDB qu'elle utilise.<a name="enable-emr-fs-console"></a>

**Pour vérifier si vous utilisez la fonction EMRFS CV**

1. Accédez à l'onglet **Configuration**. Si votre cluster possède la configuration suivante, il utilise EMRFS CV.

   ```
   Classification=emrfs-site,Property=fs.s3.consistent,Value=true
   ```

1. Vous pouvez également utiliser le AWS CLI pour décrire votre cluster avec l'[`describe-cluster`API](https://docs.aws.amazon.com/cli/latest/reference/emr/describe-cluster.html). Si le résultat en contient `fs.s3.consistent: true`, votre cluster utilise EMRFS CV.

**Pour désactiver le CV EMRFS sur vos clusters Amazon EMR**

Pour désactiver la fonction EMRFS CV, utilisez l'une des trois options suivantes. Vous devez tester ces options dans votre environnement de test avant de les appliquer à vos environnements de production.

1. 

**Pour arrêter votre cluster existant et démarrer un nouveau cluster sans les options EMRFS CV.**

   1. Avant d'arrêter votre cluster, assurez-vous de sauvegarder vos données et d'en informer les utilisateurs.

   1. Pour arrêter votre cluster, suivez les instructions de la section [Résilier un cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/UsingEMR_TerminateJobFlow.html).

   1. Si vous utilisez la console Amazon EMR pour créer un nouveau cluster, accédez aux **Options avancées**. Dans la section **Modifier les paramètres du logiciel**, désélectionnez l'option permettant d'activer EMRFS CV. Si la case à cocher pour une **vue cohérente EMRFS** est disponible, désactivez-la.

   1. Si vous avez l'habitude de AWS CLI créer un nouveau cluster avec l'[`create-cluster`API](https://docs.aws.amazon.com/cli/latest/reference/emr/create-cluster.html), n'utilisez pas l'`--emrfs`option qui active EMRFS CV.

   1. Si vous utilisez un SDK ou CloudFormation pour créer un nouveau cluster, n'utilisez aucune des configurations répertoriées dans [Configurer une vue cohérente](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emrfs-configure-consistent-view.html).

1. 

**Pour cloner un cluster et supprimer le CV EMRFS**

   1. Dans la console Amazon EMR, choisissez le cluster qui utilise EMRFS CV.

   1. En haut de la page **Détails du cluster**, sélectionnez **Cloner**.

   1. Choisissez **Précédent** et passez à l'**Étape 1 : Logiciel et étapes**.

   1. Dans **Modifier les paramètres du logiciel**, supprimez le EMRFS CV. Dans **Modifier la configuration**, supprimez les configurations suivantes dans la classification `emrfs-site`. Si vous chargez du JSON à partir d'un compartiment S3, vous devez modifier votre objet S3.

      ```
      [
      	{"classification":
      		"emrfs-site",
      		"properties": {
      			"fs.s3.consistent.retryPeriodSeconds":"10",
      			"fs.s3.consistent":"true",
      			"fs.s3.consistent.retryCount":"5",
      			"fs.s3.consistent.metadata.tableName":"EmrFSMetadata"
      		}
      	}
      ]
      ```

1. 

**Pour supprimer le CV EMRFS d'un cluster qui utilise des groupes d'instances**

   1. Utilisez la commande suivante pour vérifier si un seul cluster EMR utilise la table DynamoDB associée à EMRFS CV, ou si plusieurs clusters partagent la table. Le nom de la table est spécifié dans `fs.s3.consistent.metadata.tableName`, comme décrit dans [Configuration de la vue cohérente](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emrfs-configure-consistent-view.html). Le nom de table par défaut utilisé par EMRFS CV est `EmrFSMetadata`.

      ```
      aws emr describe-cluster --cluster-id j-XXXXX | grep fs.s3.consistent.metadata.tableName
      ```

   1. Si votre cluster ne partage pas votre base de données DynamoDB avec un autre cluster, utilisez la commande suivante pour reconfigurer le cluster et désactiver EMRFS CV. Pour plus d'informations, consultez [Reconfiguration d'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).

      ```
      aws emr modify-instance-groups --cli-input-json file://disable-emrfs-1.json
      ```

      Cette commande ouvre le fichier que vous souhaitez modifier. Modifiez le fichier avec l'une des configurations suivantes.

      ```
      {
      	"ClusterId": "j-xxxx",
      	"InstanceGroups": [
      		{
      			"InstanceGroupId": "ig-xxxx",
      			"Configurations": [
      				{
      					"Classification": "emrfs-site",
      					"Properties": {
      						"fs.s3.consistent": "false"
      					},
      					"Configurations": []
      				}
      			]
      		}
      	]
      }
      ```

   1. Si votre cluster partage la table DynamoDB avec un autre cluster, désactivez EMRFS CV sur tous les clusters à un moment où aucun cluster ne modifie les objets de l'emplacement S3 partagé.

**Pour supprimer les ressources Amazon DynamoDB associées au CV EMRFS**

Après avoir supprimé le CV EMRFS de vos clusters Amazon EMR, supprimez les ressources DynamoDB associées au CV EMRFS. Jusqu'à ce que vous le fassiez, vous continuez à payer des frais DynamoDB associés à EMRFS CV.

1. Vérifiez les CloudWatch métriques de votre table DynamoDB et confirmez que la table n'est utilisée par aucun cluster.

1. Supprimez la table DynamoDB.

   ```
   aws dynamodb delete-table --table-name <your-table-name>
   ```

**Pour supprimer les ressources Amazon SQS associées au CV EMRFS**

1. Si vous avez configuré votre cluster pour envoyer des notifications d'incohérence à Amazon SQS, vous pouvez supprimer toutes les files d'attente SQS.

1. Recherchez le nom de file d'attente Amazon SQS spécifié dans `fs.s3.consistent.notification.SQS.queueName`, comme décrit dans [Configurer une vue cohérente](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emrfs-configure-consistent-view.html). Le format de nom de file d'attente par défaut est `EMRFS-Inconsistency-<j-cluster ID>`.

   ```
   aws sqs list-queues | grep ‘EMRFS-Inconsistency’
   aws sqs delete-queue –queue-url <your-queue-url>
   ```

**Pour arrêter d'utiliser l'interface de ligne de commande EMRFS**
+ La [CLI EMRFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emrfs-cli-reference.html) gère les métadonnées générées par EMRFS CV. La prise en charge standard d'EMRFS CV arrivant à son terme dans les futures versions d'Amazon EMR, la prise en charge de la CLI EMRFS atteindra également sa fin. 

**Topics**
+ [Activation de la vue cohérente](enable-consistent-view.md)
+ [Comprendre comment la vue cohérente d'EMRFS effectue le suivi des objets dans Amazon S3](emrfs-files-tracked.md)
+ [Logique des nouvelles tentatives](emrfs-retry-logic.md)
+ [Métadonnées de la vue cohérente EMRFS](emrfs-metadata.md)
+ [Configurer les notifications de cohérence pour CloudWatch et Amazon SQS](emrfs-configure-sqs-cw.md)
+ [Configuration de la vue cohérente](emrfs-configure-consistent-view.md)
+ [Référence des commandes CLI EMRFS](emrfs-cli-reference.md)

# Activation de la vue cohérente
<a name="enable-consistent-view"></a>

Vous pouvez activer le chiffrement côté serveur Amazon S3 ou la vue cohérente pour EMRFS en utilisant le AWS Management Console AWS CLI, ou la classification de configuration. `emrfs-site`<a name="enable-emr-fs-console"></a>

**Pour configurer la vue cohérente à 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 des valeurs pour **Step 1: Software and Steps (Étape 1 : Logiciel et étapes)** et **Step 2: Hardware (Étape 2 : Matériel)**. 

1. Pour **Step 3: General Cluster Settings (Étape 3 : Paramètres généraux de cluster)**, sous **Additional Options (Options supplémentaires)**, choisissez **EMRFS consistent view (Vue cohérente EMRFS)**.

1. Pour **EMRFS Metadata store (Boutique de métadonnées EMRFS)**, saisissez le nom de votre magasin de métadonnées. La valeur par défaut est **EmrFSMetadata**. Si la FSMetadata table Emr n'existe pas, elle est créée pour vous dans DynamoDB.
**Note**  
Amazon EMR ne supprime pas automatiquement les métadonnées EMRFS de DynamoDB lorsque le cluster est résilié.

1. Pour **Number of retries (Nombre de nouvelles tentatives)**, tapez une valeur entière. Si une incohérence est détectée, EMRFS essaie d'appeler Amazon S3 ce nombre de fois. La valeur par défaut est **5**. 

1. Pour **Retry period (in seconds) (Période de nouvelle tentative (en secondes))**, tapez une valeur entière. Il s'agit du temps pendant lequel EMRFS attend entre les nouvelles tentatives. La valeur par défaut est **10**.
**Note**  
Les nouvelles tentatives ultérieures utilisent une interruption exponentielle. 

**Pour lancer un cluster avec une vue cohérente activée à l'aide du AWS CLI**

Nous vous recommandons d'installer la version actuelle de AWS CLI. Pour télécharger la dernière version, voir [https://aws.amazon.com/cli/](https://aws.amazon.com/cli/).
+ 
**Note**  
Les caractères de continuation de ligne Linux (\$1) 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 (^).

  ```
  1. aws emr create-cluster --instance-type m5.xlarge --instance-count 3 --emrfs Consistent=true \
  2. --release-label emr-7.12.0 --ec2-attributes KeyName=myKey
  ```

**Pour vérifier si la vue cohérente est activée à l'aide du AWS Management Console**
+ Pour vérifier si la vue cohérente est activée dans la console, accédez à la **Liste de clusters** et sélectionnez le nom de votre cluster pour afficher **Cluster Details (Détails de cluster)**. Le champ « EMRFS consistent view » a la valeur `Enabled` ou `Disabled`.

**Pour vérifier si la vue cohérente est activée en examinant le fichier `emrfs-site.xml`**
+ Vous pouvez vérifier si la cohérence est activée en inspectant le fichier de configuration `emrfs-site.xml` sur le nœud maître du cluster. Si la valeur booléenne pour `fs.s3.consistent` est définie sur `true`, la vue cohérente est activée pour les opérations du système de fichiers impliquant Amazon S3.

# Comprendre comment la vue cohérente d'EMRFS effectue le suivi des objets dans Amazon S3
<a name="emrfs-files-tracked"></a>

EMRFS crée une vue cohérente des objets dans Amazon S3 en ajoutant des informations sur ces objets aux métadonnées EMRFS. EMRFS ajoute ces listes à ses métadonnées lorsque :
+  Objet écrit par EMRFS au cours d'une tâche Amazon EMR.
+  un objet est synchronisé avec les métadonnées EMRFS ou importé dans les métadonnées EMRFS à l'aide de l'interface de ligne de commande d'EMRFS.

Les objets lus par EMRFS ne sont pas automatiquement ajoutés aux métadonnées. Lorsqu'EMRFS supprime un objet, une liste demeure dans les métadonnées avec un état supprimé jusqu'à ce que cette liste soit purgée à l'aide de l'interface de ligne de commande d'EMRFS. Pour plus d'informations sur l'interface de ligne de commande, consultez [Référence des commandes CLI EMRFS](emrfs-cli-reference.md). Pour plus d'informations sur la purge des listes dans les métadonnées EMRFS, consultez [Métadonnées de la vue cohérente EMRFS](emrfs-metadata.md).

Pour chaque opération Amazon S3, EMRFS vérifie les métadonnées pour obtenir des informations sur l'ensemble des objets dans la vue cohérente. Si EMRFS considère que Amazon S3 est incohérent au cours d'une de ces opérations, il réessaie l'opération selon les paramètres définis dans les propriétés de configuration `emrfs-site`. Une fois qu'EMRFS a épuisé les tentatives, il lève une exception `ConsistencyException` ou consigne l'exception et continue le flux de travail. Pour plus d'informations sur la logique des nouvelles tentatives, consultez [Logique des nouvelles tentatives](emrfs-retry-logic.md). Vous pouvez trouver des exceptions `ConsistencyExceptions` dans vos journaux, par exemple :
+  listStatus : aucun objet Amazon S3 pour l'élément de métadonnées `/S3_bucket/dir/object`
+  getFileStatus: la clé `dir/file` est présente dans les métadonnées, mais pas dans Amazon S3

Si vous supprimez un objet qui est suivi dans la vue cohérente d'EMRFS directement à partir d'Amazon S3 , EMRFS traite cet objet comme incohérent, car il reste répertorié dans les métadonnées tel qu'il figure dans Amazon S3. Si vos métadonnées cessent d'être synchronisées avec les objets qu'EMRFS suit dans Amazon S3, vous pouvez utiliser la sous-commande **sync** sur l'interface de ligne de commande d'EMRFS pour réinitialiser les métadonnées afin qu'elles tiennent compte d'Amazon S3. Pour découvrir les différences entre les métadonnées et Amazon S3, utilisez l'outil **diff**. Enfin, EMRFS a uniquement une vue cohérente des objets référencés dans les métadonnées. D'autres objets peuvent figurer dans le même chemin d'accès Amazon S3 et ne pas être suivis. Quand EMRFS répertorie les objets dans un chemin d'accès Amazon S3, il renvoie le sur-ensemble des objets suivis dans les métadonnées et de ceux dans ce chemin d'accès Amazon S3.

# Logique des nouvelles tentatives
<a name="emrfs-retry-logic"></a>

EMRFS essaie de vérifier la cohérence des listes pour les objets suivis dans ses métadonnées pour un certain nombre de tentatives. La valeur par défaut est 5. Au cas où le nombre de nouvelles tentatives est dépassé, la tâche initiale retourne un échec, à moins que `fs.s3.consistent.throwExceptionOnInconsistency` ait la valeur `false`, auquel cas elle consignera uniquement les objets suivis comme incohérents. EMRFS utilise une stratégie de nouvelles tentatives d'interruption exponentielle par défaut, mais vous pouvez également la configurer comme une stratégie fixe. Les utilisateurs peuvent également réessayer pendant un certain temps avant de passer au reste de leur tâche sans lever d'exception. Ils peuvent y parvenir en définissant `fs.s3.consistent.throwExceptionOnInconsistency` sur `false`, `fs.s3.consistent.retryPolicyType` sur `fixed` et `fs.s3.consistent.retryPeriodSeconds` sur la valeur de leur choix. L'exemple suivant crée un cluster avec la cohérence activée, qui consigne les incohérences et définit un intervalle fixe de nouvelle tentative de 10 secondes :

**Example Configuration de la période de nouvelle tentative sur une valeur fixe**  

```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-type m5.xlarge --instance-count 1 \
--emrfs Consistent=true,Args=[fs.s3.consistent.throwExceptionOnInconsistency=false, fs.s3.consistent.retryPolicyType=fixed,fs.s3.consistent.retryPeriodSeconds=10] --ec2-attributes KeyName=myKey
```

**Note**  
Les caractères de continuation de ligne Linux (\$1) 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 (^).

Pour de plus amples informations, veuillez consulter [Vue cohérente](emr-plan-consistent-view.md).

## Les configurations EMRFS pour IMDS reçoivent des appels régionaux
<a name="randomized-exponential-backoff-retry"></a>

EMRFS s'appuie sur l'IMDS (service de métadonnées d'instance) pour obtenir la région de l'instance et Amazon S3, DynamoDB ou les points de terminaison. AWS KMS Cependant, l'IMDS a une limite quant au nombre de demandes qu'il peut traiter, et les demandes qui dépassent cette limite échoueront. Cette limite IMDS peut entraîner l'échec de l'initialisation d'EMRFS et l'échec de la requête ou de la commande. Vous pouvez utiliser le mécanisme de backoff exponentiel aléatoire suivant et les propriétés de configuration d'une région de secours dans le fichier emrfs-site.xml pour résoudre le scénario dans lequel toutes les tentatives échouent.

```
<property>
    <name>fs.s3.region.retryCount</name>
    <value>3</value>
    <description>
    Maximum retries that would be attempted to get AWS region.
    </description>
</property>
<property>
    <name>fs.s3.region.retryPeriodSeconds</name>
    <value>3</value>
    <description>
    Base sleep time in second for each get-region retry.
    </description>
</property>
<property>
    <name>fs.s3.region.fallback</name>
    <value>us-east-1</value>
    <description>
    Fallback to this region after maximum retries for getting AWS region have been reached.
    </description>
</property>
```

# Métadonnées de la vue cohérente EMRFS
<a name="emrfs-metadata"></a>

La vue cohérente d'EMRFS assure la cohérence à l'aide d'une table DynamoDB pour suivre les objets dans Amazon S3 qui ont été synchronisés avec ou créés par le système EMRFS. Les métadonnées sont utilisées pour suivre toutes les opérations (lecture, écriture, mise à jour et copie) et aucun contenu réel n'y est stocké. Ces métadonnées sont utilisées pour vérifier si les objets ou les métadonnées provenant d'Amazon S3 correspondent à ce qui est prévu. Cette confirmation permet à EMRFS de vérifier la cohérence des listes et read-after-write de vérifier la cohérence des nouveaux objets écrits par EMRFS sur Amazon S3 ou des objets synchronisés avec EMRFS. Plusieurs clusters peuvent partager les mêmes métadonnées.

**Comment ajouter des entrées aux métadonnées**  
Vous pouvez utiliser les sous-commandes `sync` ou `import` pour ajouter des entrées aux métadonnées. `sync` reflète l'état des objets Amazon S3 dans un chemin d'accès lorsque la sous-commande `import` est utilisée strictement pour ajouter de nouvelles entrées aux métadonnées. Pour de plus amples informations, veuillez consulter [Référence des commandes CLI EMRFS](emrfs-cli-reference.md).

**Vérification des différences entre les métadonnées et les objets dans Amazon S3**  
Pour vérifier les différences entre les métadonnées et Amazon S3, utilisez la sous-commande `diff` de l'interface de ligne de commande d'EMRFS. Pour de plus amples informations, veuillez consulter [Référence des commandes CLI EMRFS](emrfs-cli-reference.md).

**Comment savoir si les opérations de métadonnées sont limitées**  
EMRFS définit les limites de capacité de débit par défaut sur les métadonnées pour ses opérations de lecture et d'écriture à 500 et 100 unités, respectivement. Un grand nombre d'objets ou de compartiments peut amener les opérations à dépasser cette capacité, auquel cas DynamoDB limitera les opérations. Par exemple, une application peut amener EMRFS à lever une exception `ProvisionedThroughputExceededException` si vous effectuez une opération qui dépasse ces limites de capacité. Lors d'une limitation, l'outil d'interface de ligne de commande d'EMRFS tente de réécrire dans la table DynamoDB à l'aide d'un [backoff exponentiel](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) jusqu'à ce que l'opération s'achève ou qu'il atteigne la valeur maximale de nouvelles tentatives d'écriture d'objets d'Amazon EMR sur Amazon S3. 

Vous pouvez configurer vos propres limites de capacité de débit. Cependant, DynamoDB impose des limites de partition strictes de 3 000 unités de capacité de lecture RCUs () et de 1 000 unités de capacité d'écriture WCUs () par seconde pour les opérations de lecture et d'écriture. Pour éviter les `sync` défaillances causées par la régulation, nous vous recommandons de limiter le débit des opérations de lecture à moins de 3 000 RCUs et celui des opérations d'écriture à moins de 1 000. WCUs Pour obtenir des instructions sur la définition de limites de capacité de débit personnalisées, consultez [Configuration de la vue cohérente](emrfs-configure-consistent-view.md).

Vous pouvez également consulter CloudWatch les métriques Amazon relatives à vos métadonnées EMRFS dans la console DynamoDB, où vous pouvez voir le nombre de demandes de lecture et d'écriture limitées. Si le nombre de demandes limitées n'est pas nul, votre application peut éventuellement bénéficier d'une capacité grandissante de débit allouée pour les opérations de lecture ou d'écriture. Vous pouvez également réaliser une amélioration des performances si vous voyez que vos opérations approchent de la capacité de débit allouée maximale pour les lectures ou les écritures pendant une période de temps prolongée.

**Caractéristiques de débit pour les opérations EMRFS notables**  
La valeur par défaut pour les opérations de lecture et d'écriture est de 400 et de 100 unités de capacité de débit, respectivement. Les caractéristiques de performance suivantes vous donnent une idée du débit requis pour certaines opérations. Ces tests ont été effectués à l'aide d'un cluster `m3.large` à un seul nœud. Toutes les opérations étaient à thread unique. Les performances varient considérablement en fonction des caractéristiques d'application spécifiques et il peut être nécessaire d'expérimenter afin d'optimiser les opérations de système de fichiers.


| Opération  | Moyenne read-per-second  | Moyenne write-per-second  | 
| --- | --- | --- | 
| create (objet) | 26,79 |  6,70 | 
| delete (objet) | 10,79 |  10,79 | 
| delete (répertoire contenant 1 000 objets) | 21,79 | 338,40  | 
|  getFileStatus(objet) | 34,70 | 0  | 
| getFileStatus(annuaire) | 19,96 | 0 | 
| listStatus (répertoire contenant 1 objet) | 43,31 | 0 | 
| listStatus (répertoire contenant 10 objets) | 44,34 | 0 | 
| listStatus (répertoire contenant 100 objets) | 84,44 | 0 | 
| listStatus (répertoire contenant 1 000 objets) | 308,81 | 0 | 
| listStatus (répertoire contenant 10 000 objets) | 416,05 | 0 | 
| listStatus (répertoire contenant 100 000 objets) | 823,56 | 0 | 
| listStatus (répertoire contenant 1 million d'objets) | 882,36 | 0 | 
| mkdir (en continu pendant 120 secondes)  | 24,18 | 4,03 | 
| mkdir | 12,59 | 0 | 
| rename (objet) | 19,53 | 4,88 | 
| rename (répertoire contenant 1 000 objets) | 23,22 | 339,34 | 

**Pour soumettre une étape qui purge les anciennes données à partir de votre magasin de métadonnées**  
Les utilisateurs peuvent supprimer des entrées particulières dans les métadonnées basées sur DynamoDB. Cela peut aider à réduire les coûts de stockage associés à la table. Les utilisateurs ont la possibilité de purger manuellement ou par programmation des entrées particulières à l'aide de la sous-commande `delete` de l'interface de ligne de commande d'EMRFS. Toutefois, si vous supprimez des entrées à partir des métadonnées, EMRFS n'effectue plus aucun contrôle de cohérence.

La purge par programmation à l'issue d'une tâche peut être effectuée en soumettant une étape finale à votre cluster qui exécute une commande sur l'interface de ligne de commande d'EMRFS. Par exemple, tapez la commande suivante pour soumettre une étape à votre cluster afin de supprimer toutes les entrées de plus de deux jours.

```
aws emr add-steps --cluster-id j-2AL4XXXXXX5T9 --steps Name="emrfsCLI",Jar="command-runner.jar",Args=["emrfs","delete","--time","2","--time-unit","days"]
{
    "StepIds": [
        "s-B12345678902"
    ]
}
```

Utilisez la StepId valeur renvoyée pour vérifier le résultat de l'opération dans les journaux.

# Configurer les notifications de cohérence pour CloudWatch et Amazon SQS
<a name="emrfs-configure-sqs-cw"></a>

Vous pouvez activer CloudWatch les métriques et les messages Amazon SQS dans EMRFS pour d'éventuels problèmes de cohérence avec Amazon S3. 

**CloudWatch**  
Lorsque CloudWatch les métriques sont activées, une métrique nommée **Inconsistency est envoyée** chaque fois qu'un appel d'`FileSystem`API échoue en raison de la cohérence éventuelle d'Amazon S3. 

**Pour consulter CloudWatch les statistiques relatives aux éventuels problèmes de cohérence d'Amazon S3**

Pour afficher la métrique **d'incohérence** dans la CloudWatch console, sélectionnez les métriques EMRFS, puis sélectionnez une paire **JobFlowId**/**Metric** Name. Par exemple : `j-162XXXXXXM2CU ListStatus`, `j-162XXXXXXM2CU GetFileStatus`, etc.

1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Dans le **Tableau de bord**, dans la section **Metrics (Métriques)**, choisissez **EMRFS**. 

1. Dans le volet **Job Flow Metrics**, sélectionnez une ou plusieurs paires **JobFlowId**/**Metric Name**. Une représentation graphique des métriques s'affiche dans la fenêtre ci-dessous.

**Amazon SQS**  
Lorsque les notifications Amazon SQS sont activées, une file d'attente Amazon SQS portant le nom `EMRFS-Inconsistency-<jobFlowId>` est créée lors de l'initialisation d'EMRFS. Les messages Amazon SQS sont placés dans la file d'attente lorsqu'un appel d'API `FileSystem` échoue en raison de la cohérence éventuelle d'Amazon S3. Le message contient des informations telles que l'API JobFlowId, une liste de chemins incohérents, une trace de pile, etc. Les messages peuvent être lus à l'aide de la console Amazon SQS ou de la commande `read-sqs` d'EMRFS.

**Pour gérer les messages Amazon SQS en cas de problèmes de cohérence éventuels d'Amazon S3**

Les messages Amazon SQS pour les problèmes de cohérence éventuelle d'Amazon S3 peuvent être lus à l'aide de l'interface de ligne de commande d'EMRFS. Pour lire les messages à partir d'une file d'attente Amazon SQS d'EMRFS, tapez la commande `read-sqs` et spécifiez un emplacement de sortie dans le système de fichiers local du nœud principal pour le fichier de sortie obtenu. 

Vous pouvez également supprimer une file d'attente Amazon SQS d'EMRFS à l'aide de la commande `delete-sqs`.

1. Pour lire les messages à partir d'une file d'attente Amazon SQS, tapez la commande suivante. Remplacez *queuename* par le nom de la file d'attente Amazon SQS que vous avez configurée et remplacez par le chemin */path/filename* d'accès au fichier de sortie :

   ```
   emrfs read-sqs --queue-name queuename --output-file /path/filename
   ```

   Par exemple, pour lire et générer des messages Amazon SQS à partir de la file d'attente par défaut, tapez :

   ```
   emrfs read-sqs --queue-name EMRFS-Inconsistency-j-162XXXXXXM2CU --output-file /path/filename
   ```
**Note**  
Vous pouvez également utiliser les raccourcis `-q` et `-o` à la place de `--queue-name` et `--output-file` respectivement.

1. Pour supprimer une file d'attente Amazon SQS, tapez la commande suivante :

   ```
   emrfs delete-sqs --queue-name queuename
   ```

   Par exemple, pour supprimer la file d'attente par défaut, tapez :

   ```
   emrfs delete-sqs --queue-name EMRFS-Inconsistency-j-162XXXXXXM2CU
   ```
**Note**  
Vous pouvez également utiliser le raccourci `-q` à la place de `--queue-name`.

# Configuration de la vue cohérente
<a name="emrfs-configure-consistent-view"></a>

Vous pouvez configurer d'autres paramètres pour la vue cohérente en les fournissant à l'aide des propriétés de configuration pour les propriétés `emrfs-site`. Par exemple, vous pouvez choisir un autre débit DynamoDB par défaut en fournissant les arguments suivants à l'interface de ligne de commande, à l'aide de l'option `--emrfs`, en utilisant la classification de configuration de site emrfs (versions 4.x et ultérieures d'Amazon EMR uniquement), ou une action d'amorçage pour configurer le fichier emrfs-site.xml sur le nœud principal :

**Example Modification des valeurs de lecture et d'écriture de métadonnées par défaut au lancement du cluster**  

```
aws emr create-cluster --release-label emr-7.12.0 --instance-type m5.xlarge \
--emrfs Consistent=true,Args=[fs.s3.consistent.metadata.read.capacity=600,\
fs.s3.consistent.metadata.write.capacity=300] --ec2-attributes KeyName=myKey
```

Vous pouvez également utiliser le fichier de configuration suivant et l'enregistrer localement ou dans Amazon S3 :

```
[
    {
      "Classification": "emrfs-site",
      "Properties": {
        "fs.s3.consistent.metadata.read.capacity": "600",
        "fs.s3.consistent.metadata.write.capacity": "300"
      }
    }
 ]
```

Utilisez la configuration que vous avez créée avec la syntaxe suivante :

```
aws emr create-cluster --release-label emr-7.12.0 --applications Name=Hive \
--instance-type m5.xlarge --instance-count 2 --configurations file://./myConfig.json
```

**Note**  
Les caractères de continuation de ligne Linux (\$1) 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 (^).

Les options suivantes peuvent être définies à l'aide de configurations ou d' AWS CLI `--emrfs`arguments. Pour plus d'informations sur ces arguments, consultez la [Référence des commandes AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/).


**Propriétés `emrfs-site.xml` pour la vue cohérente**  

| Propriété  | Valeur par défaut | Description  | 
| --- | --- | --- | 
| fs.s3.consistent | false |  Lorsque la valeur est **true**, cette propriété configure EMRFS pour utiliser DynamoDB afin d'assurer la cohérence.  | 
| fs.s3.consistent.retryPolicyType | exponential | Cette propriété identifie la stratégie à utiliser lors d'une nouvelle tentative pour des problèmes de cohérence. Les options comprennent : exponential, fixed et none. | 
| fs.s3.consistent.retryPeriodSeconds | 1 | Cette propriété définit la durée d'attente entre les tentatives de relance de cohérence. | 
| fs.s3.consistent.retryCount | 10 | Cette propriété définit le nombre maximal de nouvelles tentatives lorsqu'une incohérence est détectée. | 
| fs.s3.consistent.throwExceptionOnInconsistency | true | Cette propriété détermine s'il convient de lever ou de consigner une exception de cohérence. Lorsque la valeur est true, une exception ConsistencyException est levée. | 
| fs.s3.consistent.metadata.autoCreate | true | Lorsque la valeur est true, cette propriété permet la création automatique de tables de métadonnées. | 
| fs.s3.consistent.metadata.etag.verification.enabled | true | Avec Amazon EMR 5.29.0, cette propriété est activée par défaut. Lorsque cette option est activée, EMRFS utilise S3 ETags pour vérifier que les objets lus sont de la dernière version disponible. Cette fonctionnalité est utile dans les cas read-after-update d'utilisation dans lesquels des fichiers sur S3 sont remplacés tout en conservant le même nom. Cette fonctionnalité de ETag vérification ne fonctionne pas actuellement avec S3 Select. | 
| fs.s3.consistent.metadata.tableName | EmrFSMetadata | Cette propriété spécifie le nom de la table de métadonnées dans DynamoDB. | 
| fs.s3.consistent.metadata.read.capacity | 500 | Cette propriété spécifie la capacité de lecture DynamoDB à mettre en service lorsque la table de métadonnées est créée. | 
| fs.s3.consistent.metadata.write.capacity | 100 | Cette propriété spécifie la capacité d'écriture DynamoDB à mettre en service lorsque la table de métadonnées est créée. | 
| fs.s3.consistent.fastList | true | Lorsque la valeur est true, cette propriété utilise plusieurs fils pour répertorier un répertoire (si nécessaire). La cohérence doit être activée pour pouvoir utiliser cette propriété. | 
| fs.s3.consistent.fastList.prefetchMetadata | false | Lorsque la valeur est true, cette propriété permet l'extraction préalable de métadonnées pour les répertoires contenant plus de 20 000 éléments. | 
| fs.s3.consistent.notification.CloudWatch | false | Lorsqu'elle est définie surtrue, CloudWatch les métriques sont activées pour les appels d' FileSystem API qui échouent en raison d'éventuels problèmes de cohérence avec Amazon S3. | 
| fs.s3.consistent.notification.SQS | false | Lorsque la valeur est true, les notifications de cohérence éventuelle font l'objet d'un push vers une file d'attente Amazon SQS. | 
| fs.s3.consistent.notification.SQS.queueName | EMRFS-Inconsistency-<jobFlowId> | La modification de cette propriété vous permet de spécifier votre propre nom de file d'attente SQS pour les messages concernant les problèmes de cohérence à terme d'Amazon S3. | 
| fs.s3.consistent.notification.SQS.customMsg | none | Cette propriété vous permet de spécifier des informations personnalisées incluses dans les messages SQS concernant les problèmes de cohérence à terme d'Amazon S3. Si une valeur n'est pas spécifiée pour cette propriété, le champ correspondant dans le message est vide.  | 
| fs.s3.consistent.dynamodb.endpoint | none | Cette propriété vous permet de spécifier un point de terminaison DynamoDB personnalisé pour vos métadonnées de vue cohérente. | 
| fs.s3.useRequesterPaysHeader | false | Lorsqu'elle est définie sur true, cette propriété autorise les requêtes Amazon S3 à être envoyées dans des compartiments avec l'option de payeur de demandes activée.  | 

# Référence des commandes CLI EMRFS
<a name="emrfs-cli-reference"></a>

L'interface de ligne de commande EMRFS est installée par défaut sur tous les nœuds principaux du cluster créé à l'aide de Amazon EMR 3.2.1 ou version supérieure. Vous pouvez utiliser l'interface de ligne de commande EMRFS pour gérer les métadonnées pour la vue cohérente. 

**Note**  
La **emrfs** commande n'est prise en charge qu'avec l'émulation de VT100 terminal. Cependant, elle peut fonctionner avec les autres modes d'émulateur de terminal.

## Commande emrfs de niveau supérieur
<a name="emrfs-top-level"></a>

La commande **emrfs** de niveau supérieur prend en charge la structure suivante.

```
emrfs [describe-metadata | set-metadata-capacity | delete-metadata | create-metadata | \
list-metadata-stores | diff | delete | sync | import ] [options] [arguments]
```

Spécifiez des [options], avec ou sans arguments, comme décrit dans le tableau suivant. Pour les [options] spécifiques à des sous-commandes (`describe-metadata`, `set-metadata-capacity`, etc.), consultez chaque sous-commande ci-dessous.


**[Options] pour emrfs**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-a AWS_ACCESS_KEY_ID \| --access-key AWS_ACCESS_KEY_ID`  |  La clé AWS d'accès que vous utilisez pour écrire des objets sur Amazon S3 et pour créer ou accéder à un magasin de métadonnées dans DynamoDB. Par défaut, *AWS\$1ACCESS\$1KEY\$1ID* est défini sur la clé d'accès utilisée pour créer le cluster.  |  Non  | 
|  `-s AWS_SECRET_ACCESS_KEY \| --secret-key AWS_SECRET_ACCESS_KEY`  |  La clé AWS secrète associée à la clé d'accès que vous utilisez pour écrire des objets sur Amazon S3 et pour créer ou accéder à un magasin de métadonnées dans DynamoDB. Par défaut, *AWS\$1SECRET\$1ACCESS\$1KEY* est défini sur la clé secrète associée à la clé d'accès utilisée pour créer le cluster.  |  Non  | 
|  `-v \| --verbose`  |  Détaillez le résultat.  |  Non  | 
|  `-h \| --help`  |  Affiche le message d'aide pour la commande `emrfs` avec une instruction d'utilisation.  |  Non  | 

## Sous commande describe-metadata emrfs
<a name="emrfs-describe-metadata"></a>


**[Options] pour emrfs describe-metadata**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-m METADATA_NAME \| --metadata-name METADATA_NAME`  |  *METADATA\$1NAME*est le nom de la table de métadonnées DynamoDB. Si l'*METADATA\$1NAME*argument n'est pas fourni, la valeur par défaut est`EmrFSMetadata`.  |  Non  | 

**Example Exemple describe-metadata emrfs**  <a name="emrfs-describe-metadata"></a>
L'exemple suivant décrit la table de métadonnées par défaut.  

```
$ emrfs describe-metadata
EmrFSMetadata
  read-capacity: 400
  write-capacity: 100
  status: ACTIVE
  approximate-item-count (6 hour delay): 12
```

## sous-commande emrfs set-metadata-capacity
<a name="emrfs-set-metadata-capacity"></a>


**[Options] pour emrfs set-metadata-capacity**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-m METADATA_NAME \| --metadata-name METADATA_NAME`  |  *METADATA\$1NAME*est le nom de la table de métadonnées DynamoDB. Si l'*METADATA\$1NAME*argument n'est pas fourni, la valeur par défaut est`EmrFSMetadata`.  |  Non  | 
|  `-r READ_CAPACITY \| --read-capacity READ_CAPACITY`  |  La capacité de débit de lecture demandée pour la table de métadonnées. Si l'*READ\$1CAPACITY*argument n'est pas fourni, la valeur par défaut est`400`.  |  Non  | 
|  `-w WRITE_CAPACITY \| --write-capacity WRITE_CAPACITY`  |  La capacité de débit d'écriture demandée pour la table de métadonnées. Si l'*WRITE\$1CAPACITY*argument n'est pas fourni, la valeur par défaut est`100`.  |  Non  | 

**Example exemple d'emrfs set-metadata-capacity**  
L'exemple suivant définit la capacité de débit de lecture sur `600` et la capacité d'écriture sur `150` pour une table de métadonnées nommée `EmrMetadataAlt`.  

```
$ emrfs set-metadata-capacity --metadata-name EmrMetadataAlt  --read-capacity 600 --write-capacity 150
  read-capacity: 400
  write-capacity: 100
  status: UPDATING
  approximate-item-count (6 hour delay): 0
```

## Sous commande delete-metadata emrfs
<a name="emrfs-delete-metadata"></a>


**[Options] pour emrfs delete-metadata**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-m METADATA_NAME \| --metadata-name METADATA_NAME`  |  *METADATA\$1NAME*est le nom de la table de métadonnées DynamoDB. Si l'*METADATA\$1NAME*argument n'est pas fourni, la valeur par défaut est`EmrFSMetadata`.  |  Non  | 

**Example Exemple delete-metadata emrfs**  
L'exemple suivant supprime la table de métadonnées par défaut.  

```
$ emrfs delete-metadata
```

## Sous commande create-metadata emrfs
<a name="emrfs-create-metadata"></a>


**[Options] pour emrfs create-metadata**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-m METADATA_NAME \| --metadata-name METADATA_NAME`  |  *METADATA\$1NAME*est le nom de la table de métadonnées DynamoDB. Si l'*METADATA\$1NAME*argument n'est pas fourni, la valeur par défaut est`EmrFSMetadata`.  |  Non  | 
|  `-r READ_CAPACITY \| --read-capacity READ_CAPACITY`  |  La capacité de débit de lecture demandée pour la table de métadonnées. Si l'*READ\$1CAPACITY*argument n'est pas fourni, la valeur par défaut est`400`.  |  Non  | 
|  `-w WRITE_CAPACITY \| --write-capacity WRITE_CAPACITY`  |  La capacité de débit d'écriture demandée pour la table de métadonnées. Si l'*WRITE\$1CAPACITY*argument n'est pas fourni, la valeur par défaut est`100`.  |  Non  | 

**Example Exemple create-metadata emrfs**  
L'exemple suivant crée une table de métadonnée nommée `EmrFSMetadataAlt`.  

```
$ emrfs create-metadata -m EmrFSMetadataAlt
Creating metadata: EmrFSMetadataAlt
EmrFSMetadataAlt
  read-capacity: 400
  write-capacity: 100
  status: ACTIVE
  approximate-item-count (6 hour delay): 0
```

## sous-commande emrfs list-metadata-stores
<a name="emrfs-list-metadata-stores"></a>

La sous-commande **emrfs list-metadata-stores** n'a aucune [option]. 

**Example List-metadata-stores exemple**  
L'exemple suivant répertorie vos tables de métadonnées.  

```
$ emrfs list-metadata-stores
  EmrFSMetadata
```

## Sous-commande diff emrfs
<a name="emrfs-diff"></a>


**[Options] pour emrfs diff**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-m METADATA_NAME \| --metadata-name METADATA_NAME`  |  *METADATA\$1NAME*est le nom de la table de métadonnées DynamoDB. Si l'*METADATA\$1NAME*argument n'est pas fourni, la valeur par défaut est`EmrFSMetadata`.  |  Non  | 
|  *s3://s3Path*  |  Le chemin d'accès au compartiment Amazon S3 à comparer à la table des métadonnées. Synchronisation de compartiments de façon récursive.  |  Oui  | 

**Example Exemple diff emrfs**  
L'exemple suivant compare la table de métadonnées par défaut dans un compartiment Amazon S3.  

```
$ emrfs diff s3://elasticmapreduce/samples/cloudfront
BOTH | MANIFEST ONLY | S3 ONLY
DIR elasticmapreduce/samples/cloudfront
DIR elasticmapreduce/samples/cloudfront/code/
DIR elasticmapreduce/samples/cloudfront/input/
DIR elasticmapreduce/samples/cloudfront/logprocessor.jar
DIR elasticmapreduce/samples/cloudfront/input/XABCD12345678.2009-05-05-14.WxYz1234
DIR elasticmapreduce/samples/cloudfront/input/XABCD12345678.2009-05-05-15.WxYz1234
DIR elasticmapreduce/samples/cloudfront/input/XABCD12345678.2009-05-05-16.WxYz1234
DIR elasticmapreduce/samples/cloudfront/input/XABCD12345678.2009-05-05-17.WxYz1234
DIR elasticmapreduce/samples/cloudfront/input/XABCD12345678.2009-05-05-18.WxYz1234
DIR elasticmapreduce/samples/cloudfront/input/XABCD12345678.2009-05-05-19.WxYz1234
DIR elasticmapreduce/samples/cloudfront/input/XABCD12345678.2009-05-05-20.WxYz1234
DIR elasticmapreduce/samples/cloudfront/code/cloudfront-loganalyzer.tgz
```

## Sous commande delete emrfs
<a name="emrfs-delete"></a>


**[Options] pour emrfs delete**  

|  Option  |  Description  |  Obligatoire  | 
| --- | --- | --- | 
|  `-m METADATA_NAME \| --metadata-name METADATA_NAME`  |  *METADATA\$1NAME*est le nom de la table de métadonnées DynamoDB. Si l'*METADATA\$1NAME*argument n'est pas fourni, la valeur par défaut est`EmrFSMetadata`.  |  Non  | 
|  *s3://s3Path*  |  Le chemin d'accès au compartiment Amazon S3 que vous suivez pour une vue cohérente. Synchronisation de compartiments de façon récursive.  |  Oui  | 
| -t TIME \$1 --time TIME |  L'heure d'expiration (interprétée à l'aide de l'argument d'unité de temps). Toutes les entrées de métadonnées antérieures à l'*TIME*argument sont supprimées pour le compartiment spécifié.  |  | 
|  `-u UNIT \| --time-unit UNIT`  |  La mesure utilisée pour interpréter l'argument temps (nanosecondes, microsecondes, millisecondes, secondes, minutes, heures ou jours). Si aucun argument n'est spécifié, la valeur par défaut est `days`.  |  | 
|  `--read-consumption READ_CONSUMPTION`  |  Le montant requis de débit de lecture disponible utilisé pour l'opération **delete**. Si l'*READ\$1CONSUMPTION*argument n'est pas spécifié, la valeur par défaut est`400`.  |  Non   | 
|  `--write-consumption WRITE_CONSUMPTION`  |  Le montant requis de débit d'écriture disponible utilisé pour l'opération **delete**. Si l'*WRITE\$1CONSUMPTION*argument n'est pas spécifié, la valeur par défaut est`100`.  |  Non  | 

**Example Exemple delete emrfs**  
L'exemple suivant supprime tous les objets dans un compartiment Amazon S3 depuis les métadonnées de suivi pour une vue cohérente.  

```
$ emrfs delete s3://elasticmapreduce/samples/cloudfront
entries deleted: 11
```

## Sous commande import emrfs
<a name="emrfs-import"></a>


**[Options] pour emrfs import**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-m METADATA_NAME \| --metadata-name METADATA_NAME`  |  *METADATA\$1NAME*est le nom de la table de métadonnées DynamoDB. Si l'*METADATA\$1NAME*argument n'est pas fourni, la valeur par défaut est`EmrFSMetadata`.  |  Non  | 
|  *s3://s3Path*  |  Le chemin d'accès au compartiment Amazon S3 que vous suivez pour une vue cohérente. Synchronisation de compartiments de façon récursive.  |  Oui  | 
|  `--read-consumption READ_CONSUMPTION`  |  Le montant requis de débit de lecture disponible utilisé pour l'opération **delete**. Si l'*READ\$1CONSUMPTION*argument n'est pas spécifié, la valeur par défaut est`400`.  |  Non  | 
|  `--write-consumption WRITE_CONSUMPTION`  |  Le montant requis de débit d'écriture disponible utilisé pour l'opération **delete**. Si l'*WRITE\$1CONSUMPTION*argument n'est pas spécifié, la valeur par défaut est`100`.  |  Non  | 

**Example Exemple import emrfs**  
L'exemple suivant importe tous les objets dans un compartiment Amazon S3 avec les métadonnées de suivi pour une vue cohérente. Toutes les clés inconnus sont ignorées.  

```
$ emrfs import s3://elasticmapreduce/samples/cloudfront
```

## Sous-commande sync emrfs
<a name="emrfs-sync"></a>


**[Options] pour emrfs sync**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-m METADATA_NAME \| --metadata-name METADATA_NAME`  |  *METADATA\$1NAME*est le nom de la table de métadonnées DynamoDB. Si l'*METADATA\$1NAME*argument n'est pas fourni, la valeur par défaut est`EmrFSMetadata`.  |  Non  | 
|  *s3://s3Path*  |  Le chemin d'accès au compartiment Amazon S3 que vous suivez pour une vue cohérente. Synchronisation de compartiments de façon récursive.  |  Oui  | 
|  `--read-consumption READ_CONSUMPTION`  |  Le montant requis de débit de lecture disponible utilisé pour l'opération **delete**. Si l'*READ\$1CONSUMPTION*argument n'est pas spécifié, la valeur par défaut est`400`.  |  Non  | 
|  `--write-consumption WRITE_CONSUMPTION`  |  Le montant requis de débit d'écriture disponible utilisé pour l'opération **delete**. Si l'*WRITE\$1CONSUMPTION*argument n'est pas spécifié, la valeur par défaut est`100`.  |  Non  | 

**Example Exemple commande sync emrfs**  
L'exemple suivant importe tous les objets dans un compartiment Amazon S3 avec les métadonnées de suivi pour une vue cohérente. Toutes les clés inconnues sont supprimées.   

```
$ emrfs sync s3://elasticmapreduce/samples/cloudfront
Synching samples/cloudfront                                       0 added | 0 updated | 0 removed | 0 unchanged
Synching samples/cloudfront/code/                                 1 added | 0 updated | 0 removed | 0 unchanged
Synching samples/cloudfront/                                      2 added | 0 updated | 0 removed | 0 unchanged
Synching samples/cloudfront/input/                                9 added | 0 updated | 0 removed | 0 unchanged
Done synching s3://elasticmapreduce/samples/cloudfront            9 added | 0 updated | 1 removed | 0 unchanged
creating 3 folder key(s)
folders written: 3
```

## Sous-commande read-sqs emrfs
<a name="emrfs-read-sqs"></a>


**[Options] pour emrfs read-sqs**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-q QUEUE_NAME \| --queue-name QUEUE_NAME`  |  *QUEUE\$1NAME*est le nom de la file d'attente Amazon SQS configurée dans. `emrfs-site.xml` La valeur par défaut est **EMRFS-Inconsistency-<jobFlowId>**.  |  Oui  | 
|  `-o OUTPUT_FILE \| --output-file OUTPUT_FILE`  |  *OUTPUT\$1FILE*est le chemin d'accès au fichier de sortie sur le système de fichiers local du nœud maître. Les messages lus depuis la file d'attente sont écrits dans ce fichier.   |  Oui  | 

## Sous commande delete-sqs emrfs
<a name="emrfs-delete-sqs"></a>


**[Options] pour emrfs delete-sqs**  

| Option  | Description  | Obligatoire  | 
| --- | --- | --- | 
|  `-q QUEUE_NAME \| --queue-name QUEUE_NAME`  |  *QUEUE\$1NAME*est le nom de la file d'attente Amazon SQS configurée dans. `emrfs-site.xml` La valeur par défaut est **EMRFS-Inconsistency-<jobFlowId>**.  |  Oui  | 

## Soumission de commandes CLI EMRFS comme étapes
<a name="emrfs-submit-steps-as-cli"></a>

L'exemple suivant montre comment utiliser l'`emrfs`utilitaire sur le nœud principal en tirant parti de l'API AWS CLI or et en exécutant la `command-runner.jar` `emrfs` commande en tant qu'étape par étape. L'exemple utilise l'étape AWS SDK pour Python (Boto3) pour ajouter une étape à un cluster qui ajoute des objets d'un compartiment Amazon S3 à la table de métadonnées EMRFS par défaut.

```
import boto3
from botocore.exceptions import ClientError


def add_emrfs_step(command, bucket_url, cluster_id, emr_client):
    """
    Add an EMRFS command as a job flow step to an existing cluster.

    :param command: The EMRFS command to run.
    :param bucket_url: The URL of a bucket that contains tracking metadata.
    :param cluster_id: The ID of the cluster to update.
    :param emr_client: The Boto3 Amazon EMR client object.
    :return: The ID of the added job flow step. Status can be tracked by calling
             the emr_client.describe_step() function.
    """
    job_flow_step = {
        "Name": "Example EMRFS Command Step",
        "ActionOnFailure": "CONTINUE",
        "HadoopJarStep": {
            "Jar": "command-runner.jar",
            "Args": ["/usr/bin/emrfs", command, bucket_url],
        },
    }

    try:
        response = emr_client.add_job_flow_steps(
            JobFlowId=cluster_id, Steps=[job_flow_step]
        )
        step_id = response["StepIds"][0]
        print(f"Added step {step_id} to cluster {cluster_id}.")
    except ClientError:
        print(f"Couldn't add a step to cluster {cluster_id}.")
        raise
    else:
        return step_id


def usage_demo():
    emr_client = boto3.client("emr")
    # Assumes the first waiting cluster has EMRFS enabled and has created metadata
    # with the default name of 'EmrFSMetadata'.
    cluster = emr_client.list_clusters(ClusterStates=["WAITING"])["Clusters"][0]
    add_emrfs_step(
        "sync", "s3://elasticmapreduce/samples/cloudfront", cluster["Id"], emr_client
    )


if __name__ == "__main__":
    usage_demo()
```

Vous pouvez utiliser la valeur `step_id` pour vérifier les journaux concernant le résultat de l'opération.

# Autorisation d'accès aux données EMRFS dans Amazon S3
<a name="emr-plan-credentialsprovider"></a>

Par défaut, le rôle EMR pour EC2 détermine les autorisations d'accès aux données EMRFS dans Amazon S3. Les politique IAM qui sont attachées à ce rôle s'appliquent, quel que soit l'utilisateur ou le groupe qui effectuent la demande via le système EMRFS. La valeur par défaut est `EMR_EC2_DefaultRole`. Pour plus d'informations, consultez [Rôle de service pour les instances EC2 de cluster (profil d'instance EC2)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-iam-role-for-ec2.html).

À partir de la version 5.10.0 d'Amazon EMR, vous pouvez utiliser une configuration de sécurité pour spécifier les rôles IAM pour EMRFS. Cela vous permet de personnaliser les autorisations pour les demandes EMRFS à Amazon S3 pour les clusters ayant plusieurs utilisateurs. Vous pouvez spécifier différents rôles IAM pour différents utilisateurs et groupes, et pour différents emplacements de compartiment Amazon S3 en fonction du préfixe dans Amazon S3. Quand EMRFS envoie une demande à Amazon S3 qui correspond à des utilisateurs, des groupes ou des emplacements que vous spécifiez, le cluster utilise le rôle correspondant que vous spécifiez au lieu du rôle EMR pour EC2. Pour plus d'informations, consultez [Configuration de rôles IAM pour les demandes EMRFS à Amazon S3](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-emrfs-iam-roles).

Sinon, si les exigences de votre solution Amazon EMR ne sont pas couvertes par les rôles IAM pour EMRFS, vous pouvez définir une classe de fournisseur d'informations d'identification personnalisées, ce qui vous permet de personnaliser l'accès aux données EMRFS dans Amazon S3.

## Création d'un fournisseur d'informations d'identification personnalisées pour les données EMRFS dans Amazon S3
<a name="emr-create-credentialsprovider"></a>

Pour créer un fournisseur d'informations d'identification personnalisé, vous implémentez les classes [AWSCredentialsProvider](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/AWSCredentialsProvider.html) et Hadoop [Configurable](https://hadoop.apache.org/docs/stable/api/org/apache/hadoop/conf/Configurable.html).

Pour une explication détaillée de cette approche, voir [Analyser en toute sécurité les données d'un autre AWS compte avec EMRFS](https://aws.amazon.com/blogs/big-data/securely-analyze-data-from-another-aws-account-with-emrfs) sur le blog AWS Big Data. Le billet de blog inclut un didacticiel qui explique le processusend-to-end, de la création de rôles IAM au lancement du cluster. Il fournit aussi un exemple de code Java qui implémente la classe fournisseur d'informations d'identification personnalisées.

La procédure de base est la suivante :

**Pour spécifier un fournisseur d'informations d'identification personnalisées**

1. Créez une classe fournisseur d'informations d'identification personnalisées compilée comme fichier JAR.

1. Exécutez un script comme action d'amorçage pour copier le fichier JAR du fournisseur d'informations d'identification personnalisées sur l'emplacement `/usr/share/aws/emr/emrfs/auxlib` du nœud principal du cluster. Pour plus d'informations sur les actions d'amorçage, consultez [(Facultatif) Création d'actions d'amorçage pour installer des logiciels supplémentaires](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html).

1. Personnalisez la classification `emrfs-site` pour spécifier la classe que vous implémentez dans le fichier JAR. Pour plus d'informations sur la spécification d'objets de configuration pour personnaliser les applications, consultez la section [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) dans le *Guide de version Amazon EMR*.

   L'exemple suivant illustre une commande `create-cluster` qui lance un cluster Hive avec les paramètres de configuration courants et qui inclut également :
   + Une action d'amorçage qui exécute le script, `copy_jar_file.sh`, enregistré sur `amzn-s3-demo-bucket` dans Amazon S3.
   + Une classification `emrfs-site` qui spécifie un fournisseur d'informations d'identification personnalisées défini dans le fichier JAR comme `MyCustomCredentialsProvider`
**Note**  
Les caractères de continuation de ligne Linux (\$1) 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 (^).

   ```
   aws emr create-cluster --applications Name=Hive \
   --bootstrap-actions '[{"Path":"s3://amzn-s3-demo-bucket/copy_jar_file.sh","Name":"Custom action"}]' \
   --ec2-attributes '{"KeyName":"MyKeyPair","InstanceProfile":"EMR_EC2_DefaultRole",\
   "SubnetId":"subnet-xxxxxxxx","EmrManagedSlaveSecurityGroup":"sg-xxxxxxxx",\
   "EmrManagedMasterSecurityGroup":"sg-xxxxxxxx"}' \
   --service-role EMR_DefaultRole_V2 --enable-debugging --release-label emr-7.12.0 \
   --log-uri 's3n://amzn-s3-demo-bucket/' --name 'test-awscredentialsprovider-emrfs' \
   --instance-type=m5.xlarge --instance-count 3  \
   --configurations '[{"Classification":"emrfs-site",\
   "Properties":{"fs.s3.customAWSCredentialsProvider":"MyAWSCredentialsProviderWithUri"},\
   "Configurations":[]}]'
   ```

# Gestion du point de AWS Security Token Service terminaison par défaut
<a name="emr-emrfs-sts-endpoint"></a>

EMRFS utilise le AWS Security Token Service (STS) pour récupérer des informations d'identification de sécurité temporaires afin d'accéder à vos AWS ressources. Les versions antérieures d'Amazon EMR envoient toutes les AWS STS demandes à un seul point de terminaison mondial à l'adresse. `https://sts.amazonaws.com` Amazon EMR publie les versions 5.31.0 et 6.1.0 et ultérieures pour envoyer des demandes aux points de terminaison régionaux. AWS STS Cela réduit la latence et améliore la validité des jetons de session. Pour plus d'informations sur les AWS STS points de terminaison, consultez [la section Gestion AWS STS dans une AWS région](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) dans le *Guide de l'Gestion des identités et des accès AWS utilisateur*.

Lorsque vous utilisez les versions 5.31.0 et 6.1.0 et ultérieures d'Amazon EMR, vous pouvez remplacer le point de terminaison par défaut AWS STS . Pour ce faire, vous devez modifier la propriété `fs.s3.sts.endpoint` dans votre configuration `emrfs-site`.

L' AWS CLI exemple suivant définit le point de AWS STS terminaison par défaut utilisé par EMRFS comme point de terminaison global.

```
aws emr create-cluster --release-label <emr-5.33.0> --instance-type m5.xlarge \
--emrfs Args=[fs.s3.sts.endpoint=https://sts.amazonaws.com]
```

**Note**  
Les caractères de continuation de ligne Linux (\$1) 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 (^).

Vous pouvez également créer un fichier de configuration JSON à l'aide de l'exemple suivant et le spécifier à l'aide de l'argument `--configurations` de `emr create-cluster`. Pour plus d'informations sur l'utilisation de `--configurations,`, consultez la [*Référence des commandes AWS CLI *.](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/emr/create-cluster.html)

```
[
  {
    "classification": "emrfs-site",
    "properties": {
      "fs.s3.sts.endpoint": "https://sts.amazonaws.com"
    }
  }
]
```

# Spécification du chiffrement Amazon S3 en utilisant les propriétés EMRFS
<a name="emr-emrfs-encryption"></a>

**Important**  
À partir de la version 4.8.0 d'Amazon EMR, vous pouvez utiliser les configurations de sécurité pour appliquer les paramètres de chiffrement plus facilement et avec plus d'options. Nous vous recommandons d'utiliser les configurations de sécurité. Pour plus d'informations, consultez [Configuration du chiffrement des données](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-create-security-configuration.html#emr-security-configuration-encryption). Les instructions de console décrites dans cette section sont disponibles pour les versions antérieures à la version 4.8.0. Si vous utilisez le AWS CLI pour configurer le chiffrement Amazon S3 à la fois dans la configuration du cluster et dans une configuration de sécurité dans les versions suivantes, la configuration de sécurité remplace la configuration du cluster.

Lorsque vous créez un cluster, vous pouvez spécifier le chiffrement côté serveur (SSE) ou le chiffrement côté client (CSE) pour les données EMRFS dans Amazon S3 à l'aide de la console `emrfs-site` ou à l'aide des propriétés de classification via le SDK ou EMR. AWS CLI Le chiffrement SSE et le chiffrement CSE pour Amazon S3 s'excluent mutuellement. Vous pouvez choisir l'un ou l'autre, mais pas les deux.

Pour AWS CLI obtenir des instructions, consultez la section correspondant à votre type de chiffrement ci-dessous.

**Pour spécifier les options de chiffrement EMRFS à l'aide du AWS Management 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 une **Release (Version)** 4.7.2 ou antérieure.

1. Choisissez d'autres options pour **Software and Steps (Logiciel et étapes)** selon les besoins de votre application, puis cliquez sur **Next (Suivant)**.

1. Choisissez les paramètres dans les volets **Hardware (Matériel)** et **General Cluster Settings (Paramètres de cluster généraux)** selon les besoins de votre application.

1. Dans le volet **Security (Sécurité)**, sous **Authentication and encryption (Authentification et chiffrement)**, sélectionnez l'option **S3 Encryption (with EMRFS) (Chiffrement S3 (avec EMRFS))** à utiliser.
**Note**  
**S3 server-side encryption with KMS Key Management** (Chiffrement côté serveur S3 avec gestion de clé KMS) (SSE-KMS) n'est pas disponible lorsque vous utilisez Amazon EMR version 4.4 ou antérieure.
   + Si vous choisissez une option qui utilise **AWS Key Management**, choisissez un **AWS KMS Key ID**. Pour de plus amples informations, veuillez consulter [Utilisation AWS KMS keys pour le chiffrement EMRFS](#emr-emrfs-awskms).
   + Si vous choisissez le **S3 client-side encryption with custom materials provider (Chiffrement côté client S3 avec fournisseur de matériaux personnalisé)**, spécifiez le **Class name (Nom de classe)** et l'**JAR location (emplacement du JAR)**. Pour de plus amples informations, veuillez consulter [Chiffrement côté client sur Amazon S3](emr-emrfs-encryption-cse.md).

1. Choisissez d'autres options selon les besoins de votre application, puis choisissez **Create Cluster (Créer un cluster)**.

## Utilisation AWS KMS keys pour le chiffrement EMRFS
<a name="emr-emrfs-awskms"></a>

La clé de AWS KMS chiffrement doit être créée dans la même région que votre instance de cluster Amazon EMR et les compartiments Amazon S3 utilisés avec EMRFS. Si la clé que vous spécifiez se trouve dans un compte différent de celui que vous utilisez pour configurer un cluster, vous devez spécifier la clé à l'aide de son ARN.

Le rôle du profil d'instance Amazon EC2 doit être autorisé à utiliser la clé KMS que vous spécifiez. Le rôle par défaut du profil d'instance dans Amazon EMR est `EMR_EC2_DefaultRole`. Si vous utilisez un rôle différent pour le profil d'instance, ou si vous utilisez des rôles IAM pour les demandes EMRFS adressées à Amazon S3, assurez-vous que chaque rôle est ajouté en tant qu'utilisateur clé, le cas échéant. Cela donne au rôle des autorisations pour utiliser la clé KMS. Pour plus d'informations, consultez les sections [Utilisation des stratégies de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) dans le *Guide du développeur AWS Key Management Service * et [Configuration des rôles IAM pour les demandes EMRFS adressées à Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html).

Vous pouvez utiliser le AWS Management Console pour ajouter votre profil d'instance ou votre profil d'instance EC2 à la liste des utilisateurs clés pour la clé KMS spécifiée, ou vous pouvez utiliser le AWS CLI ou un AWS SDK pour associer une politique de clé appropriée.

Notez qu'Amazon EMR prend uniquement en charge les [clés KMS symétriques](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks). Vous ne pouvez pas utiliser une [clé KMS asymétrique](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html#asymmetric-cmks) pour chiffrer les données au repos dans un cluster Amazon EMR. Pour savoir si une clés KMS est symétrique ou asymétrique, consultez [Identification de clés KMS symétriques et asymétriques](https://docs.aws.amazon.com/kms/latest/developerguide/find-symm-asymm.html).

La procédure ci-dessous décrit comment ajouter le profil d'instance Amazon EMR par défaut, `EMR_EC2_DefaultRole`, en tant qu'*utilisateur de clé* à l'aide de la AWS Management Console. Elle suppose que vous avez déjà créé une clé KMS. Pour créer une nouvelle clé KMS, consultez [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide du développeur AWS Key Management Service *.

**Pour ajouter le profil d'instance EC2 pour Amazon EMR à la liste des utilisateurs de clés de chiffrement**

1. Connectez-vous à la console AWS Key Management Service (AWS KMS) AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/kms.](https://console.aws.amazon.com/kms)

1. Pour modifier le Région AWS, utilisez le sélecteur de région dans le coin supérieur droit de la page.

1. Sélectionnez l'alias de la clé KMS à modifier.

1. Sur la page de détails de la clé, sous **Key Users (Utilisateurs de clés)**, choisissez **Add (Ajouter)**.

1. Dans la boîte de dialogue **Ajouter des utilisateurs clés** sélectionnez le rôle approprié. Le nom du rôle par défaut est `EMR_EC2_DefaultRole`.

1. Choisissez **Ajouter**.

## Chiffrement côté serveur sur Amazon S3
<a name="emr-emrfs-encryption-sse"></a>

Le chiffrement est configuré par défaut pour tous les compartiments Amazon S3, et tous les nouveaux objets chargés dans un compartiment S3 sont automatiquement chiffrés au repos. Amazon S3 chiffre les données au niveau de l'objet lorsqu'il écrit les données sur le disque et les déchiffre lors de l'accès. Pour plus d'informations sur SSE, consultez [Protection des données à l'aide du chiffrement côté serveur](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.

Lorsque vous indiquez le chiffrement SSE sur Amazon EMR, vous pouvez choisir entre deux systèmes de gestion de clés différents : 
+ **SSE-S3** – Amazon S3 gère les clés pour vous.
+ **SSE-KMS** — Vous utilisez un AWS KMS key pour configurer des politiques adaptées à Amazon EMR. Pour plus d'informations sur les exigences clés relatives à Amazon EMR, consultez la section [Utilisation à des AWS KMS keys fins](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys) de chiffrement.

Le chiffrement SSE avec des clés fournies par le client (SSE-C) n'est pas disponible pour une utilisation avec Amazon EMR.

**Pour créer un cluster avec SSE-S3 activé à l'aide du AWS CLI**
+ Saisissez la commande suivante :

  ```
  aws emr create-cluster --release-label emr-4.7.2 or earlier \
  --instance-count 3 --instance-type m5.xlarge --emrfs Encryption=ServerSide
  ```

Vous pouvez également activer SSE-S3 en définissant le fs.s3. enableServerSideLa propriété de chiffrement prend la valeur true dans les `emrfs-site` propriétés. Voir l'exemple pour SSE-KMS ci-dessous et omettez la propriété pour l'ID de clé.

**Pour créer un cluster avec SSE-KMS activé à l'aide du AWS CLI**
**Note**  
SSE-KMS est uniquement disponible dans Amazon EMR version 4.5.0 et versions ultérieures.
+ Tapez la AWS CLI commande suivante pour créer un cluster avec SSE-KMS, où se *keyID* trouve, par exemple AWS KMS key, un : *a4567b8-9900-12ab-1234-123a45678901*

  ```
  aws emr create-cluster --release-label emr-4.7.2 or earlier --instance-count 3 \
  --instance-type m5.xlarge --use-default-roles \
  --emrfs Encryption=ServerSide,Args=[fs.s3.serverSideEncryption.kms.keyId=keyId]
  ```

  **--OR--**

  Tapez la AWS CLI commande suivante à l'aide de la `emrfs-site` classification et fournissez un fichier de configuration JSON dont le contenu est similaire `myConfig.json` à celui de l'exemple ci-dessous :

  ```
  aws emr create-cluster --release-label emr-4.7.2 or earlier --instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop --configurations file://myConfig.json --use-default-roles
  ```

  Exemple de contenu de **myConfig.json** :

  ```
  [
    {
      "Classification":"emrfs-site",
      "Properties": {
         "fs.s3.enableServerSideEncryption": "true",
         "fs.s3.serverSideEncryption.kms.keyId":"a4567b8-9900-12ab-1234-123a45678901"
      }
    }
  ]
  ```

### Propriétés de configuration pour SSE-S3 et SSE-KMS
<a name="emr-emrfs-encryption-site-sse-properties"></a>

Ces propriétés peuvent être configurées à l'aide de la classification de configuration `emrfs-site`. SSE-KMS est uniquement disponible dans Amazon EMR version 4.5.0 et versions ultérieures.


| Propriété  | Valeur par défaut | Description  | 
| --- | --- | --- | 
| fs.s3.enableServerSideEncryption | false |  Lorsque la valeur est **true**, les objets stockés dans Amazon S3 sont chiffrés à l'aide du chiffrement côté serveur. Si aucune clé n'est spécifiée, SSE-S3 est utilisé.  | 
| fs.s3.serverSideEncryption.kms.keyId | n/a |  Spécifie un ID de AWS KMS clé ou un ARN. Si une clé est spécifiée, SSE-KMS est utilisé.  | 

# Chiffrement côté client sur Amazon S3
<a name="emr-emrfs-encryption-cse"></a>

Avec le chiffrement côté client sur Amazon S3, le chiffrement et le déchiffrement par Amazon S3 se déroulent dans le client EMRFS de votre cluster. Les objets sont chiffrés avant d'être chargés sur Amazon S3 et déchiffrés après leur chargement. Le fournisseur que vous indiquez fournit la clé de chiffrement utilisée par le client. Le client peut utiliser les clés fournies par AWS KMS (CSE-KMS) ou une classe Java personnalisée qui fournit la clé racine côté client (CSE-C). Les spécificités du chiffrement sont légèrement différentes entre CSE-KMS et CSE-C, en fonction du fournisseur indiqué et des métadonnées de l'objet à déchiffrer ou à chiffrer. Pour plus d'informations sur ces différences, consultez [Protection des données à l'aide du chiffrement côté client](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.

**Note**  
Le chiffrement CSE sur Amazon S3 garantit uniquement que les données  EMRFS échangées avec Amazon S3 sont chiffrées ; cela ne signifie pas que toutes les données sur les volumes des instances du cluster sont chiffrées. De plus, étant donné que Hue n'utilise pas EMRFS, les objets que le navigateur de fichiers S3 de Hue écrit sur Amazon S3 ne sont pas chiffrés.

**Pour spécifier le CSE-KMS pour les données EMRFS dans Amazon S3 à l'aide du AWS CLI**
+ Tapez la commande suivante et remplacez-la *MyKMSKeyID* par l'ID de clé ou l'ARN de la clé KMS à utiliser :

  ```
  aws emr create-cluster --release-label emr-4.7.2 or earlier
  --emrfs Encryption=ClientSide,ProviderType=KMS,KMSKeyId=MyKMSKeyId
  ```

## Création d'un fournisseur de clés personnalisé
<a name="emr-emrfs-create-cse-key"></a>

Selon le type de chiffrement que vous utilisez lors de la création d'un fournisseur de clés personnalisé, l'application doit également implémenter différentes EncryptionMaterialsProvider interfaces. Les deux interfaces sont disponibles dans le AWS SDK pour Java version 1.11.0 et versions ultérieures.
+ Pour implémenter le chiffrement Amazon S3, utilisez le fichier [com.amazonaws.services.s3.model. EncryptionMaterialsProvider ](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/EncryptionMaterialsProvider.html)interface.
+ Pour implémenter le chiffrement du disque local, utilisez le fichier [com.amazonaws.services.elasticmapreduce.spi.security. EncryptionMaterialsProvider ](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/spi/security/EncryptionMaterialsProvider.html)interface.

Vous pouvez utiliser n'importe quelle stratégie pour fournir du matériel de chiffrement pour la mise en œuvre. Par exemple, vous pouvez choisir de fournir du matériel de chiffrement statique ou de l'intégrer à un système de gestion de clés plus complexe.

Si vous utilisez le chiffrement Amazon S3, vous devez utiliser les algorithmes de chiffrement **AES/GCM/NoPadding**pour le matériel de chiffrement personnalisé.

Si vous utilisez le chiffrement de disque local, l'algorithme de chiffrement à utiliser pour le matériel de chiffrement personnalisé varie selon la version de l'EMR. Pour Amazon EMR 7.0.0 et versions antérieures, vous devez utiliser. **AES/GCM/NoPadding** **Pour Amazon EMR 7.1.0 et versions ultérieures, vous devez utiliser AES.**

La EncryptionMaterialsProvider classe obtient le matériel de chiffrement par contexte de chiffrement. Amazon EMR renseigne les informations contextuelles de chiffrement au moment de l'exécution pour aider l'appelant à déterminer les matériaux de chiffrement à renvoyer.

**Example Exemple : utilisation d'un fournisseur de clés personnalisé pour le chiffrement Amazon S3 avec EMRFS**  
Lorsqu'Amazon EMR extrait les matériaux de chiffrement de la EncryptionMaterialsProvider classe pour effectuer le chiffrement, EMRFS remplit éventuellement l'argument MaterialsDescription avec deux champs : l'URI Amazon S3 de l'objet et JobFlowId l'URI du cluster, qui peuvent être utilisés par la classe pour renvoyer du matériel de chiffrement de manière sélective. EncryptionMaterialsProvider   
Par exemple, le fournisseur peut renvoyer des clés différentes pour différents préfixes d'URI Amazon S3. C'est la description des matériaux de chiffrement renvoyés qui est finalement stockée avec l'objet Amazon S3 plutôt que la valeur materialsDescription qui est générée par EMRFS et transmise au fournisseur. Lors du déchiffrement d'un objet Amazon S3, la description du matériel de chiffrement est transmise à la EncryptionMaterialsProvider classe, afin qu'elle puisse, à nouveau, renvoyer de manière sélective la clé correspondante pour déchiffrer l'objet.  
Une implémentation EncryptionMaterialsProvider de référence est fournie ci-dessous. Un autre fournisseur personnalisé est disponible auprès de GitHub. [EMRFSRSAEncryptionMaterialsProvider](https://github.com/awslabs/emr-sample-apps/tree/master/emrfs-plugins/EMRFSRSAEncryptionMaterialsProvider)   

```
import com.amazonaws.services.s3.model.EncryptionMaterials;
import com.amazonaws.services.s3.model.EncryptionMaterialsProvider;
import com.amazonaws.services.s3.model.KMSEncryptionMaterials;
import org.apache.hadoop.conf.Configurable;
import org.apache.hadoop.conf.Configuration;

import java.util.Map;

/**
 * Provides KMSEncryptionMaterials according to Configuration
 */
public class MyEncryptionMaterialsProviders implements EncryptionMaterialsProvider, Configurable{
  private Configuration conf;
  private String kmsKeyId;
  private EncryptionMaterials encryptionMaterials;

  private void init() {
    this.kmsKeyId = conf.get("my.kms.key.id");
    this.encryptionMaterials = new KMSEncryptionMaterials(kmsKeyId);
  }

  @Override
  public void setConf(Configuration conf) {
    this.conf = conf;
    init();
  }

  @Override
  public Configuration getConf() {
    return this.conf;
  }

  @Override
  public void refresh() {

  }

  @Override
  public EncryptionMaterials getEncryptionMaterials(Map<String, String> materialsDescription) {
    return this.encryptionMaterials;
  }

  @Override
  public EncryptionMaterials getEncryptionMaterials() {
    return this.encryptionMaterials;
  }
}
```

## Spécifier un fournisseur de matériaux personnalisés à l'aide du AWS CLI
<a name="emr-emrfs-encryption-cse-custom-cli"></a>

Pour utiliser l' AWS CLI, transmettez les arguments `Encryption`, `ProviderType`, `CustomProviderClass` et `CustomProviderLocation` à l'option `emrfs`.

```
aws emr create-cluster --instance-type m5.xlarge --release-label emr-4.7.2 or earlier --emrfs Encryption=ClientSide,ProviderType=Custom,CustomProviderLocation=s3://amzn-s3-demo-bucket/myfolder/provider.jar,CustomProviderClass=classname
```

L'affectation à `ClientSide` de la valeur `Encryption` rend possible le chiffrement côté client. `CustomProviderClass` est le nom de votre objet `EncryptionMaterialsProvider` et `CustomProviderLocation` est l'emplacement local ou Amazon S3 à partir duquel Amazon EMR copie `CustomProviderClass` sur chaque nœud du cluster et le place dans le chemin de classe.

## Spécification d'un fournisseur de matériaux personnalisés à l'aide d'un kit SDK
<a name="emr-emrfs-encryption-cse-custom-sdk"></a>

Pour utiliser un kit SDK, vous pouvez définir la propriété `fs.s3.cse.encryptionMaterialsProvider.uri` pour télécharger la classe `EncryptionMaterialsProvider` personnalisée que vous stockez dans Amazon S3 vers chaque nœud de votre cluster. Vous configurez cela dans le fichier `emrfs-site.xml` avec CSE activé et l'emplacement correct du fournisseur personnalisé.

Par exemple, lors de l' AWS SDK pour Java utilisation RunJobFlowRequest, votre code peut ressembler à ce qui suit :

```
<snip>
		Map<String,String> emrfsProperties = new HashMap<String,String>();
	    	emrfsProperties.put("fs.s3.cse.encryptionMaterialsProvider.uri","s3://amzn-s3-demo-bucket/MyCustomEncryptionMaterialsProvider.jar");
	    	emrfsProperties.put("fs.s3.cse.enabled","true");
	    	emrfsProperties.put("fs.s3.consistent","true");
		    emrfsProperties.put("fs.s3.cse.encryptionMaterialsProvider","full.class.name.of.EncryptionMaterialsProvider");

		Configuration myEmrfsConfig = new Configuration()
	    	.withClassification("emrfs-site")
	    	.withProperties(emrfsProperties);

		RunJobFlowRequest request = new RunJobFlowRequest()
			.withName("Custom EncryptionMaterialsProvider")
			.withReleaseLabel("emr-7.12.0")
			.withApplications(myApp)
			.withConfigurations(myEmrfsConfig)
			.withServiceRole("EMR_DefaultRole_V2")
			.withJobFlowRole("EMR_EC2_DefaultRole")
			.withLogUri("s3://myLogUri/")
			.withInstances(new JobFlowInstancesConfig()
				.withEc2KeyName("myEc2Key")
				.withInstanceCount(2)
				.withKeepJobFlowAliveWhenNoSteps(true)
				.withMasterInstanceType("m5.xlarge")
				.withSlaveInstanceType("m5.xlarge")
			);						
					
		RunJobFlowResult result = emr.runJobFlow(request);
</snip>
```

## Personnalisé EncryptionMaterialsProvider avec arguments
<a name="emr-emrfs-encryption-custommaterials"></a>

Vous devrez peut-être transmettre des arguments directement au fournisseur. Pour ce faire, vous pouvez utiliser la classification de configuration `emrfs-site` avec les propriétés définies comme arguments personnalisés. Un exemple de configuration est indiqué ci-dessous, qui est enregistré dans un fichier, `myConfig.json` :

```
[
    {
      "Classification": "emrfs-site",
      "Properties": {
        "myProvider.arg1":"value1",
	    "myProvider.arg2":"value2"
      }
    }
 ]
```

À l'aide de la `create-cluster` commande du AWS CLI, vous pouvez utiliser l'`--configurations`option pour spécifier le fichier comme indiqué ci-dessous :

```
aws emr create-cluster --release-label emr-7.12.0 --instance-type m5.xlarge --instance-count 2 --configurations file://myConfig.json --emrfs Encryption=ClientSide,CustomProviderLocation=s3://amzn-s3-demo-bucket/myfolder/myprovider.jar,CustomProviderClass=classname
```

## Configuration de la prise en charge d'EMRFS S3EC V2
<a name="emr-emrfs-encryption-cse-s3v2"></a>

Les versions du SDK Java S3 (1.11.837 et versions ultérieures) prennent en charge la version 2 du client de chiffrement (S3EC V2) avec diverses améliorations de sécurité. Pour plus d'informations, consultez l'article de blog S3 [Updates to the Amazon S3 encryption client](https://aws.amazon.com/blogs/developer/updates-to-the-amazon-s3-encryption-client/). Reportez-vous également à la [migration du client de chiffrement Amazon S3](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/s3-encryption-migration.html) dans le manuel du AWS SDK pour Java développeur. 

Le client de chiffrement V1 est toujours disponible dans le SDK pour des raisons de rétrocompatibilité. Par défaut, EMRFS utilise S3EC V1 pour chiffrer et déchiffrer les objets S3 si le CSE est activé.

Les objets S3 chiffrés avec S3EC V2 ne peuvent pas être déchiffrés par EMRFS sur un cluster EMR dont la version de publication est antérieure à emr-5.31.0 (emr-5.30.1 et versions antérieures, emr-6.1.0 et versions antérieures).

**Example Configurer EMRFS pour utiliser S3EC V2**  
Pour configurer EMRFS afin d'utiliser S3EC V2, ajoutez la configuration suivante :  

```
{
  "Classification": "emrfs-site",
  "Properties": {
    "fs.s3.cse.encryptionV2.enabled": "true"
  }
}
```

## Propriétés `emrfs-site.xml` pour le chiffrement côté client Amazon S3
<a name="emr-emrfs-cse-config"></a>


| Propriété  | Valeur par défaut | Description  | 
| --- | --- | --- | 
| fs.s3.cse.enabled | false |  Lorsque la valeur est **true**, les objets EMRFS stockés dans Amazon S3 sont chiffrés à l'aide du chiffrement côté client.  | 
| fs.s3.cse.encryptionV2.enabled | false |  Lorsqu'il est défini sur `true`, EMRFS utilise le client de chiffrement S3 version 2 pour chiffrer et déchiffrer les objets sur S3. Disponible à partir de la version 5.31.0 d'EMR.  | 
| fs.s3.cse.encryptionMaterialsProvider.uri | N/A | S'applique lors de l'utilisation de supports de chiffrement personnalisés. L'URI Amazon S3 où se trouve le fichier JAR contenant le EncryptionMaterialsProvider. Lorsque vous fournissez cet URI, Amazon EMR télécharge automatiquement le fichier JAR sur tous les nœuds du cluster. | 
| fs.s3.cse.encryptionMaterialsProvider | N/A |  Le chemin de classe `EncryptionMaterialsProvider` utilisé avec le chiffrement côté client. Lorsque vous utilisez CSE-KMS, spécifiez `com.amazon.ws.emr.hadoop.fs.cse.KMSEncryptionMaterialsProvider`.  | 
| fs.s3.cse.materialsDescription.enabled | false |  Lorsqu'il est défini sur`true`, remplit le MaterialsDescription des objets chiffrés avec l'URI Amazon S3 de l'objet et le. JobFlowId Définissez sur `true` lors de l'utilisation de supports de chiffrement personnalisés.  | 
| fs.s3.cse.kms.keyId | N/A |  S'applique lors de l'utilisation de CSE-KMS. La valeur de l' KeyIdARN ou de l'alias de la clé KMS utilisée pour le chiffrement.  | 
| fs.s3.cse.cryptoStorageMode | ObjectMetadata  |  Le mode de stockage Amazon S3. Par défaut, la description des informations de chiffrement est stockée dans les métadonnées de l'objet. Vous pouvez également stocker la description dans un fichier d'instructions. Les valeurs valides sont ObjectMetadata etInstructionFile. Pour plus d'informations, consultez la section [Chiffrement des données côté client avec Amazon S3 AWS SDK pour Java et Amazon S3](https://aws.amazon.com/articles/client-side-data-encryption-with-the-aws-sdk-for-java-and-amazon-s3/).  | 