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.
# Nouveautés
Cette page décrit les modifications et les fonctionnalités disponibles dans les dernières versions d’Amazon EMR 7.x, 6.x et 5.x.
Ces notes de mise à jour sont également disponibles sur les pages [Amazon EMR 7.12.0](emr-7120-release.md), [Amazon EMR 6.15.0 [et Amazon](emr-5362-release.md) EMR](emr-6150-release.md) 5.36.2, ainsi que les versions de l'application, les versions des composants et les classifications de configuration disponibles pour chaque version.
+ Pour les notes de publication des versions précédentes, consultez [Archive des notes de publication Amazon EMR](emr-whatsnew-history.md).
+ Abonnez-vous au [flux RSS des notes de mise à jour d’Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/amazon-emr-release-notes.rss) pour recevoir des mises à jour lorsqu’une nouvelle version d’Amazon EMR est disponible.
**Note**
Les versions ultérieures d'Amazon EMR utilisent AWS Signature Version 4 (SigV4) pour authentifier les demandes adressées à Amazon S3. Nous vous recommandons d’utiliser une version Amazon EMR compatible avec SigV4 afin de pouvoir accéder aux nouveaux compartiments S3 et d’éviter toute interruption de vos charges de travail. Pour plus d’informations et accéder à la liste des versions d’Amazon EMR compatibles avec SigV4, voir la rubrique [Amazon EMR et AWS Signature, version 4](#emr-sigv4).
## Agents de mise à niveau et de dépannage Apache Spark
**Agent de mise à niveau Apache Spark**
L'agent de mise à niveau Apache Spark pour Amazon EMR est une fonctionnalité d'intelligence artificielle conversationnelle qui accélère les mises à niveau des versions d'Apache Spark pour vos applications EMR. Les mises à niveau traditionnelles de Spark nécessitent des mois d'efforts d'ingénierie pour analyser les modifications des API, résoudre les conflits de dépendance et valider l'exactitude fonctionnelle. L'agent simplifie le processus de mise à niveau grâce à des instructions en langage naturel, à la transformation automatique du code et à la validation de la qualité des données.
Vous pouvez utiliser l'agent pour mettre à niveau PySpark les applications Scala s'exécutant sur Amazon EMR sur EC2 et Amazon EMR Serverless. L'agent analyse votre code, identifie les modifications requises et effectue des transformations automatisées tout en gardant le contrôle de l'approbation de toutes les modifications. Pour plus de détails, reportez-vous à[Qu'est-ce que l'agent de mise à niveau Apache Spark pour Amazon EMR](spark-upgrades.md).
**Agent de résolution des problèmes Apache Spark**
L'agent de résolution des problèmes Apache Spark pour Amazon EMR est une fonctionnalité d'intelligence artificielle conversationnelle qui simplifie le dépannage des applications Apache Spark sur Amazon EMR, Glue AWS et Amazon Notebooks. SageMaker Le dépannage traditionnel de Spark nécessite une analyse manuelle approfondie des journaux, des indicateurs de performance et des modèles d'erreur afin d'identifier les causes profondes et de corriger le code. L'agent simplifie ce processus grâce à des instructions en langage naturel, à une analyse automatisée de la charge de travail et à des recommandations de code intelligentes.
Vous pouvez utiliser l'agent pour résoudre les problèmes PySpark et les défaillances des applications Scala. L'agent analyse vos tâches qui ont échoué, identifie les goulots d'étranglement liés aux performances et fournit des recommandations pratiques et des corrections de code tout en vous donnant un contrôle total sur les décisions de mise en œuvre. Pour plus de détails, reportez-vous à[Qu'est-ce que l'agent de résolution des problèmes Apache Spark pour Amazon EMR](spark-troubleshoot.md).
## Amazon EMR 7.12.0 (dernière version de la série 7.x)
Les nouvelles versions d'Amazon EMR sont mises à disposition dans différentes régions sur une période de plusieurs jours, en commençant par la première région à la date de sortie initiale. Il est possible que la dernière version ne soit pas disponible dans votre région pendant cette période.
Les notes de mise à jour suivantes incluent des informations relatives à la version 7.11.0 d'Amazon EMR.
+ **Nouvelles fonctionnalités**
+ Mises à niveau des **applications — Les mises à niveau** des applications Amazon EMR 7.11.0 incluent Delta 3.3.2-amzn-0, Flink 1.20.0-amzn-5, HBase 2.6.2-amzn-2, 3.1.3-amzn-20, Hadoop 3.4.1-amzn-3, Hive HCatalog 3.1.3-amzn-20, Hudi 1.0.2-amzn-0, Iceberg 1.9.1-amzn-0, Presto 0.287-0 amzn-5, Spark 3.5.6-amzn-0, 2.19.0, Tez 0.10.2-amzn-18, Trino 475-amzn-0 et 3.9.3-amzn-3. TensorFlow ZooKeeper
+ Amazon EMR sur EC2 prend désormais en charge les sessions d'arrière-plan des utilisateurs d'IAM Identity Center
+ **Sessions d'arrière-plan utilisateur** : permet aux charges de travail Spark de longue durée de continuer à s'exécuter même après que les utilisateurs se soient déconnectés d' SageMaker Unified Studio, ce qui permet de prendre en charge des sessions allant jusqu'à 90 jours
+ Configuration **flexible des sessions en arrière-plan : configuration** à deux niveaux (instance IAM Identity Center et cluster Amazon EMR-EC2) avec une durée de session d'arrière-plan personnalisable de 15 minutes à 90 jours (par défaut : 7 jours)
+ **Propagation d'identité fiable** : maintient un contexte d'identité sécurisé tout au long du cycle de vie des sessions en arrière-plan grâce à la fonction de propagation d'identité fiable d'Amazon EMR
+ **SageMaker Intégration à Unified Studio** : sessions d'arrière-plan initiées via des sessions interactives Livy dans SageMaker Unified Studio
+ **Sessions de longue durée avec des identités d'entreprise** : Amazon SageMaker Unified Studio prend désormais en charge les sessions de longue durée avec des identités d'entreprise par le biais de la technologie Trusted Identity Propagation (TIP) d'IAM Identity Center. Les utilisateurs peuvent lancer des blocs-notes interactifs et des sessions de traitement de données sur Amazon EMR et AWS Glue qui persistent en utilisant les informations d'identification de l'entreprise, même lorsqu'ils sont déconnectés ou que les sessions expirent. Les sessions durent jusqu'à 90 jours (7 jours par défaut) tout en maintenant les autorisations d'identité et les contrôles de sécurité cohérents.
## Amazon EMR 6.15.0 (dernière version de la série 6.x)
Les nouvelles versions d'Amazon EMR sont mises à disposition dans différentes régions sur une période de plusieurs jours, en commençant par la première région à la date de sortie initiale. Il est possible que la dernière version ne soit pas disponible dans votre région pendant cette période.
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.15.0. Les modifications ont été apportées à la version 6.14.0. Pour plus d'informations sur le calendrier de publication, consultez le [Journal des modifications 6.15.0](emr-6150-release.md#6150-changelog).
**Nouvelles fonctionnalités**
+ **Mises à niveau des applications** –Amazon EMR 6.15.0 application upgrades include Apache Hadoop 3.3.6, Apache Hudi 0.14.0-amzn-0, Iceberg 1.4.0-amzn-0, and Trino 426..
+ **[Lancement plus rapide pour les clusters EMR qui s’exécutent sur EC2](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-emr-ec2-clusters-5-minutes-less/)** – Le lancement d’un cluster Amazon EMR sur EC2 est désormais jusqu’à 35 % plus rapide. Grâce à cette amélioration, la plupart des clients peuvent lancer leurs clusters en moins de 5 minutes.
+ **[CodeWhisperer pour EMR Studio](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-codewhisperer.html)** — Vous pouvez désormais utiliser Amazon avec CodeWhisperer Amazon EMR Studio pour obtenir des recommandations en temps réel lorsque vous écrivez du code. JupyterLab CodeWhisperer peut compléter vos commentaires, terminer des lignes de code individuelles, faire line-by-line des recommandations et générer des fonctions entièrement formées.
+ **[Redémarrage accéléré des tâches avec Flink](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-restart.html)** – Avec Amazon EMR 6.15.0 et versions ultérieures, plusieurs nouveaux mécanismes sont disponibles pour Apache Flink afin d’améliorer le temps de redémarrage des tâches lors des opérations de récupération ou de mise à l’échelle des tâches. Cela permet d’optimiser la vitesse de récupération et de redémarrage des graphes d’exécution afin d’améliorer la stabilité des tâches.
+ **[Contrôle d'accès détaillé et au niveau des tables pour les formats de tables ouvertes : avec Amazon EMR 6.15.0 et versions ultérieures, lorsque vous exécutez des tâches Spark sur Amazon EMR sur des clusters EC2 qui accèdent aux données du catalogue de données AWS Glue, vous pouvez AWS Lake Formation appliquer des autorisations au niveau des tables, des lignes, des colonnes et des cellules aux tables basées](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lf-enable.html)** sur Hudi, Iceberg ou Delta Lake.
+ **Mise à niveau de Hadoop** – Amazon EMR 6.15.0 inclut une mise à niveau d’Apache Hadoop vers la version 3.3.6. Hadoop 3.3.6 était la dernière version au moment du déploiement d’Amazon EMR 6.15, publiée par Apache en juin 2023. Les versions précédentes d’Amazon EMR (6.9.0 à 6.14.x) utilisaient Hadoop 3.3.3.
La mise à niveau inclut des centaines d’améliorations et de correctifs, ainsi que des fonctionnalités telles que des paramètres de nœud de données reconfigurables, l’option `DFSAdmin` qui permet de lancer des opérations de reconfiguration en bloc sur tous les nœuds de données actifs et une API vectorielle qui permet aux lecteurs à forte densité de recherche de spécifier plusieurs plages à lire. Hadoop 3.3.6 ajoute également la prise en charge du HDFS APIs et de la sémantique à son journal d'écriture anticipée (WAL), afin qu' HBase il puisse fonctionner sur d'autres implémentations de systèmes de stockage. *Pour plus d’informations, consultez les journaux des modifications pour les versions [3.3.4](https://hadoop.apache.org/docs/r3.3.4/hadoop-project-dist/hadoop-common/release/3.3.4/CHANGELOG.3.3.4.html), [3.3.5](https://hadoop.apache.org/docs/r3.3.5/hadoop-project-dist/hadoop-common/release/3.3.5/CHANGELOG.3.3.5.html) et [3.3.6](https://hadoop.apache.org/docs/r3.3.6/hadoop-project-dist/hadoop-common/release/3.3.6/CHANGELOG.3.3.6.html) dans la documentation Apache Hadoop*.
+ **Support du AWS SDK pour Java, version** [2 - Les applications Amazon EMR 6.15.0 peuvent utiliser les [versions 1.12.569 ou 2.20.160 du SDK pour AWS Java si l'application prend en charge la version v2](https://github.com/aws/aws-sdk-java/tree/1.12.569).](https://github.com/aws/aws-sdk-java-v2/tree/2.20.160) Le AWS SDK pour Java 2.x est une réécriture majeure de la base de code de la version 1.x. Il repose sur Java 8\$1 et ajoute plusieurs fonctionnalités fréquemment demandées. Cela inclut la prise en charge d’E/S non bloquantes et la possibilité de brancher une implémentation HTTP différente au moment de l’exécution. Pour plus d’informations, notamment un **Guide de migration du kit SDK pour la version 1 de Java version la version 2**, voir le guide du [Kit AWS SDK pour Java, version 2](https://docs.aws.amazon.com/sdk-for-java).
**Problèmes connus**
+ Un script d'état d'instance sur le cluster qui surveille l'état de santé de l'instance peut consommer des ressources de processeur et de mémoire excessives lorsqu'un grand nombre de threads sont and/or ouverts, de descripteurs de fichiers sur le nœud.
**Modifications, améliorations et problèmes résolus**
+ *À partir de Spark 3.3.1 (pris en charge dans les versions EMR 6.10 et supérieures), tous les exécuteurs d'un hôte en cours de mise hors service sont définis sur un nouvel état, appelé DECOMMISSIONING. `ExecutorState`* Les exécuteurs mis hors service ne peuvent pas être utilisés par Yarn pour allouer des tâches et il demandera donc de nouveaux exécuteurs, si nécessaire, pour les tâches en cours d'exécution. Ainsi, si vous désactivez Spark DRA lorsque vous utilisez EMR Managed Scaling, EMR Auto Scaling ou tout autre mécanisme de dimensionnement personnalisé sur les clusters EMR-EC2, Yarn peut demander le maximum d'exécuteurs autorisés pour chaque tâche. Pour éviter ce problème, laissez la `spark.dynamicAllocation.enabled` propriété définie sur `TRUE` (valeur par défaut) lorsque vous utilisez la combinaison de fonctionnalités ci-dessus. En outre, vous pouvez également définir des contraintes d'exécuteur minimales et maximales en définissant des valeurs `spark.dynamicAllocation.maxExecutors` et des `spark.dynamicAllocation.minExecutors` propriétés pour vos tâches Spark, afin de limiter le nombre d'exécuteurs alloués lors de l'exécution de la tâche.
+ Pour améliorer vos clusters EMR haute disponibilité, cette version assure la connectivité aux démons Amazon EMR sur un hôte local utilisant des points de terminaison IPv6.
+ Cette version permet au protocole TLS 1.2 de communiquer avec les nœuds ZooKeeper provisionnés sur tous les nœuds principaux de votre cluster à haute disponibilité.
+ Cette version améliore la gestion des fichiers journaux de ZooKeeper transactions conservés sur les nœuds principaux afin de minimiser les scénarios dans lesquels les fichiers journaux dépassent les limites et interrompent les opérations du cluster.
+ Cette version accentue la résilience de la communication intra-nœud pour les clusters EMR haute disponibilité. Cette amélioration réduit le risque d’échec des actions d’amorçage ou de démarrage du cluster.
+ Tez dans Amazon EMR 6.15.0 introduit des configurations que vous pouvez spécifier pour ouvrir de manière asynchrone les divisions d’entrée dans une division groupée Tez. Cela permet d’accélérer les performances des requêtes de lecture lorsqu’il existe un grand nombre de divisions d’entrée dans une seule division groupée Tez. Pour plus d’informations, consultez la rubrique [Ouverture fractionnée asynchrone Tez](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/tez-configure.html#tez-configure-async).
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew.html)
## Amazon EMR 5.36.2 (dernière version de la série 5.x)
Les nouvelles versions d'Amazon EMR sont mises à disposition dans différentes régions sur une période de plusieurs jours, en commençant par la première région à la date de sortie initiale. Il est possible que la dernière version ne soit pas disponible dans votre région pendant cette période.
Les notes de mise à jour suivantes incluent des informations relatives à la version 5.36.2 d'Amazon EMR. Les modifications sont relatives à la version 5.36.1. Pour plus d'informations sur le calendrier de publication, consultez le [journal des modifications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-5362-release.html#5362-changelog).
**Modifications, améliorations et problèmes résolus**
+ Cette version améliore la logique de réduction du cluster afin qu'Amazon EMR ne réduise pas les nœuds principaux en dessous du paramètre de facteur de réplication HDFS pour le cluster. Cette amélioration répond aux exigences de redondance des données et réduit le risque de blocage d'une opération de dimensionnement.
+ Cette version ajoute un nouveau mécanisme de nouvelle tentative au flux de travail de dimensionnement des clusters pour les clusters EMR qui exécutent Presto ou Trino. Cette amélioration réduit le risque que le redimensionnement du cluster s'exécute indéfiniment en raison de l'échec d'une seule opération de redimensionnement. Cela améliore également l'utilisation du cluster, car celui-ci augmente et diminue la capacité plus rapidement.
+ Résout un problème selon lequel les opérations de réduction du cluster pouvaient être bloquées alors qu'Amazon EMR mettait hors service gracieusement un nœud principal et que celui-ci devenait inutilisable avant sa mise hors service complète.
+ Améliore la stabilité d'un nœud dans un cluster à haute disponibilité comportant plusieurs nœuds principaux lorsqu'Amazon EMR redémarre un seul nœud.
+ Optimise la gestion des journaux avec Amazon EMR exécuté sur Amazon EC2. C'est pourquoi vous constaterez peut-être une légère réduction des coûts de stockage pour les journaux de votre cluster.
+ Améliore la gestion des fichiers journaux de ZooKeeper transactions conservés sur les nœuds principaux afin de minimiser les scénarios dans lesquels les fichiers journaux dépassent les limites et interrompent les opérations du cluster.
+ Corrige un bogue rare qui peut provoquer l'échec d'un cluster à haute disponibilité comportant plusieurs nœuds principaux en raison de l'impossibilité de communiquer avec le Yarn ResourceManager.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew.html)
## Amazon EMR et AWS Signature, version 4
Les versions Amazon EMR utilisent AWS Signature Version 4 (SigV4) pour authentifier les demandes adressées à Amazon S3. Les compartiments créés dans Amazon S3 après le 24 juin 2020 ne prennent pas en charge les demandes signées par Signature Version 2 (SigV2). Les buckets créés le 24 juin 2020 ou avant cette date continueront de prendre en charge le protocole SIGv2. Nous vous recommandons de migrer vers une version Amazon EMR qui prend en charge SigV4 afin de pouvoir accéder aux nouveaux compartiments S3 et d’éviter toute interruption de vos charges de travail.
Si vous utilisez des applications incluses dans Amazon EMR, telles qu’Apache Spark, Apache Hive et Presto, vous n’avez pas besoin de modifier le code de votre application pour utiliser SigV4. Si vous utilisez des applications personnalisées qui ne sont pas incluses dans Amazon EMR, vous devrez peut-être mettre à jour votre code pour utiliser SigV4. Pour plus d'informations, consultez la section [Passage de Signature Version 2 à Signature Version 4](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingAWSSDK.html#UsingAWSSDK-move-to-Sig4) dans le Guide de l'utilisateur Amazon S3.
SigV4 est pris en charge par les versions suivantes d’Amazon EMR : emr-4.7.4, emr-4.8.5, emr-4.9.6, emr-4.10.1, emr-5.1.1, emr-5.2.3, emr-5.3.2, emr-5.4.1, emr-5.5.4, emr-5.6.1, emr-5.7.1, emr-5.8.3, emr-5.9.1, emr-5.10.1, emr-5.11.4, emr-5.12.3, emr-5.13.1, emr-5.14.2, emr-5.15.1, emr-5.16.1, emr-5.17.2, emr-5.18.1, emr-5.19.1, emr-5.20.1, emr-5.21.2, and emr-5.22.0 and higher. Toutes les versions 6.x et 7.x prennent en charge SigV4.
# Approche visant à atténuer le CVE-2021-44228
**Note**
Pour Amazon EMR version 6.9.0 et versions ultérieures, tous les composants installés par Amazon EMR qui utilisent les bibliothèques Log4j utilisent Log4j version 2.17.1 ou ultérieure.
**Amazon EMR exécuté sur EC2**
Le problème abordé dans [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) concerne les versions principales d'Apache Log4j comprises entre 2.0.0 et 2.14.1 lors du traitement d'entrées provenant de sources non fiables. Les clusters Amazon EMR lancés avec les versions 5.x d'Amazon EMR 5.x jusqu'à 5.34.0 et les versions d'EMR 6.x antérieures à Amazon EMR 6.5.0 incluent des frameworks open source tels qu'Apache Hive, Flink, HUDI, Presto et Trino, qui utilisent ces versions d'Apache Log4j. Cependant, de nombreux clients utilisent les frameworks open source installés sur leurs clusters Amazon EMR pour traiter et enregistrer les entrées provenant de sources non fiables.
Nous vous recommandons d'appliquer la « solution d'action Amazon EMR Bootstrap pour Log4j CVE-2021-44228 » comme décrit dans la section suivante. Cette solution prend également en charge le CVE-2021-45046.
**Note**
Les scripts d'action d'amorçage pour Amazon EMR ont été mis à jour le 7 septembre 2022 pour inclure des corrections de bogues progressives et des améliorations pour Oozie. Si vous utilisez Oozie, vous devez appliquer la solution d'action d'amorçage Amazon EMR mise à jour décrite dans la section suivante.
**Amazon EMR on EKS**
Si vous utilisez [Amazon EMR sur EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks.html) avec une configuration par défaut, vous n'êtes pas concerné par le problème décrit dans le CVE-2021-44228 et vous n'êtes pas obligé d'appliquer la solution décrite dans la section [Solution d'action d'amorçage Amazon EMR pour Log4j CVE-2021-44228 et CVE-2021-45046](#emr-log4j-vulnerability-patch-instructions). Pour Amazon EMR sur EKS, le moteur d'exécution Amazon EMR pour Spark utilise Apache Log4j version 1.2.17. Lorsque vous utilisez Amazon EMR sur EKS, vous ne devez pas modifier le paramètre par défaut du composant `log4j.appender` sur `log`.
## Solution d'action d'amorçage Amazon EMR pour Log4j CVE-2021-44228 et CVE-2021-45046
Cette solution fournit une action d'amorçage Amazon EMR qui doit être appliquée à vos clusters Amazon EMR. Pour chaque version d'Amazon EMR, vous trouverez ci-dessous un lien vers un script d'action d'amorçage. Pour appliquer cette action d'amorçage, vous devez suivre les étapes suivantes :
1. Copiez le script correspondant à votre version d'Amazon EMR dans un compartiment S3 local de votre Compte AWS. Assurez-vous que vous utilisez un script d'amorçage spécifique à votre version d'Amazon EMR.
1. Configurez une action d'amorçage pour vos clusters EMR afin d'exécuter le script copié dans votre compartiment S3 conformément aux instructions décrites dans [Documentation EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html). Si d'autres actions d'amorçage sont configurées pour vos clusters EMR, assurez-vous que ce script est configuré comme le premier script d'action d'amorçage à exécuter.
1. Mettez fin aux clusters EMR existants et lancez de nouveaux clusters à l'aide du script d'action bootstrap. AWS recommande de tester les scripts bootstrap dans votre environnement de test et de valider vos applications avant de les appliquer à votre environnement de production. Si vous n'utilisez pas la dernière version d'une version mineure d'EMR (par exemple, 6.3.0), vous devez utiliser la dernière révision (par exemple, 6.3.1), puis appliquer la solution décrite ci-dessus.
**CVE-2021-44228 et CVE-2021-45046 – Scripts d’amorçage pour les versions d’Amazon EMR**
| Numéro de version d’Amazon EMR | Emplacement du script | Date de sortie du script |
| --- | --- | --- |
| 6.5.0 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.5.0-v2.sh
| 24 mars 2022 |
| 6.4.0 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.4.0-v2.sh
| 24 mars 2022 |
| 6.3.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.3.1-v2.sh
| 24 mars 2022 |
| 6.2.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.2.1-v2.sh
| 24 mars 2022 |
| 6.1.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.1.1-v2.sh
| 14 décembre 2021 |
| 6.0.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-6.0.1-v2.sh
| 14 décembre 2021 |
| 5,34,0 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.34.0-v2.sh
| 12 décembre 2021 |
| 5,33.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.33.1-v2.sh
| 12 décembre 2021 |
| 5,32.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.32.1-v2.sh
| 13 décembre 2021 |
| 5,31.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.31.1-v2.sh
| 13 décembre 2021 |
| 5,30,2 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.30.2-v2.sh
| 14 décembre 2021 |
| 5,29,0 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.29.0-v2.sh
| 14 décembre 2021 |
| 5,28.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.28.1-v2.sh
| 15 décembre 2021 |
| 5,27.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.27.1-v2.sh
| 15 décembre 2021 |
| 5,26,0 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.26.0-v2.sh
| 15 décembre 2021 |
| 5,25,0 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.25.0-v2.sh
| 15 décembre 2021 |
| 5.24.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.24.1-v2.sh
| 15 décembre 2021 |
| 5.23.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.23.1-v2.sh
| 15 décembre 2021 |
| 5,22,0 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.22.0-v2.sh
| 15 décembre 2021 |
| 5.21.2 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.21.2-v2.sh
| 15 décembre 2021 |
| 5.20.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.20.1-v2.sh
| 15 décembre 2021 |
| 5.19.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.19.1-v2.sh
| 15 décembre 2021 |
| 5.18.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.18.1-v2.sh
| 15 décembre 2021 |
| 5,17.2 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.17.2-v2.sh
| 15 décembre 2021 |
| 5.16.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.16.1-v2.sh
| 15 décembre 2021 |
| 5.15.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.15.1-v2.sh
| 15 décembre 2021 |
| 5.14.2 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.14.2-v2.sh
| 15 décembre 2021 |
| 5.13.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.13.1-v2.sh
| 15 décembre 2021 |
| 5.12.3 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.12.3-v2.sh
| 15 décembre 2021 |
| 5.11.4 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.11.4-v2.sh
| 15 décembre 2021 |
| 5.10.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.10.1-v2.sh
| 15 décembre 2021 |
| 5.9.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.9.1-v2.sh
| 15 décembre 2021 |
| 5.8.3 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.8.3-v2.sh
| 15 décembre 2021 |
| 5.7.1 | s3://elasticmapreduce/bootstrap-actions/log4j/patch-log4j-emr-5.7.1-v2.sh
| 15 décembre 2021 |
****
| Version EMR | Dernière révision en date de décembre 2021 |
| --- | --- |
| 6.3.0 | 6.3.1 |
| 6.2.0 | 6.2.1 |
| 6,10 | 6.1.1 |
| 6.0.0 | 6.0.1 |
| 5,33,0 | 5,33.1 |
| 5,32,0 | 5,32.1 |
| 5,31,0 | 5,31.1 |
| 5.30.0 ou 5.30.1 | 5,30,2 |
| 5,28,0 | 5,28.1 |
| 5,27,0 | 5,27.1 |
| 5,24,0 | 5.24.1 |
| 5.23.0 | 5.23.1 |
| 5.21.0 ou 5.21.1 | 5.21.2 |
| 5,20,0 | 5.20.1 |
| 5,19,0 | 5.19.1 |
| 5,18,0 | 5.18.1 |
| 5.17.0 ou 5.17.1 | 5,17.2 |
| 5.16.0 | 5.16.1 |
| 5.15.0 | 5.15.1 |
| 5.14.0 ou 5.14.1 | 5.14.2 |
| 5.13.0 | 5.13.1 |
| 5.12.0, 5.12.1, 5.12.2 | 5.12.3 |
| 5.11.0, 5.11.1, 5.11.2, 5.11.3 | 5.11.4 |
| 5.9.0 | 5.9.1 |
| 5,8.0, 5,8.1, 5,8.2 | 5.8.3 |
| 5.7.0 | 5.7.1 |
## Questions fréquentes (FAQ)
+ **Les versions d'EMR antérieures à EMR 5 sont-elles affectées par le CVE-2021-44228** ?
Non Les versions EMR antérieures à la version 5 d'EMR utilisent des versions de Log4j antérieures à 2.0.
+ **Cette solution répond-elle au CVE-2021-45046 ?**
Oui, cette solution prend également en charge le **CVE-2021-45046**.
+ **La solution gère-t-elle les applications personnalisées que j'installe sur mes clusters EMR ?**
Le script d'amorçage met uniquement à jour les fichiers JAR installés par EMR. Si vous installez et exécutez des applications personnalisées et des fichiers JAR sur vos clusters EMR par le biais d'actions d'amorçage, d'étapes soumises à vos clusters, en utilisant une AMI Amazon Linux personnalisée ou via tout autre mécanisme, contactez votre fournisseur d'applications pour déterminer si vos applications personnalisées sont affectées par le CVE-2021-44228 et pour déterminer une solution appropriée.
+ **Comment gérer les [images docker personnalisées](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images.html) avec EMR sur EKS ?**
Si vous ajoutez des applications personnalisées à Amazon EMR on EKS à l'aide d'[images docker](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images.html) personnalisées ou si vous soumettez des tâches à Amazon EMR sur des fichiers d'application EKSwith personnalisés, contactez le fournisseur de l'application pour déterminer si vos applications personnalisées sont concernées par le CVE-2021-44228 et pour déterminer une solution appropriée.
+ **Comment fonctionne le script bootstrap pour atténuer le problème décrit dans CVE-2021-44228 et CVE-2021-45046 ?**
Le script d'amorçage met à jour les instructions de démarrage d'EMR en ajoutant un nouveau jeu d'instructions. Ces nouvelles instructions suppriment les fichiers JndiLookup de classe utilisés via Log4j par tous les frameworks open source installés par EMR. Cela fait suite à la [recommandation publiée par Apache](https://nvd.nist.gov/vuln/detail/CVE-2021-45046#vulnCurrentDescriptionTitle) pour résoudre les problèmes liés à Log4j.
+ **Existe-t-il une mise à jour d'EMR qui utilise les versions 2.17.1 ou supérieures de Log4j ?**
Les versions EMR 5 jusqu'à la version 5.34 et les versions EMR 6 jusqu'à la version 6.5 utilisent d'anciennes versions de frameworks open source incompatibles avec les dernières versions de Log4j. Si vous continuez à utiliser ces versions, nous vous recommandons d'appliquer l'action bootstrap pour atténuer les problèmes décrits dans le CVEs. Après EMR 5 version 5.34 et EMR 6 version 6.5, les applications qui utilisent Log4j 1.x et Log4j 2.x seront mises à niveau pour utiliser Log4j 1.2.17 (ou supérieur) et Log4j 2.17.1 (ou supérieur) respectivement, et ne nécessiteront pas l'utilisation des actions d'amorçage fournies ci-dessus pour atténuer les problèmes CVE.
+ **Les versions d'EMR sont-elles affectées par le CVE-2021-45105 ?**
Les applications installées par Amazon EMR avec les configurations par défaut d'EMR ne sont pas affectées par CVE-2021-45105. Parmi les applications installées par Amazon EMR, seul Apache Hive utilise Apache Log4j avec des [recherches contextuelles](https://logging.apache.org/log4j/2.x/index.html), et il n'utilise pas de disposition de modèle autre que celle par défaut de manière à permettre le traitement de données d'entrée inappropriées.
+ **Amazon EMR est-il concerné par l'une des divulgations CVE suivantes ?**
Le tableau suivant contient une liste de ceux CVEs qui sont liés à Log4j et indique si chaque CVE a un impact sur Amazon EMR. Les informations de ce tableau ne s'appliquent que lorsque les applications sont installées par Amazon EMR à l'aide des configurations par défaut.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-log4j-vulnerability.html)
# Archive des notes de publication Amazon EMR
Les notes de mise à jour de toutes les versions d'Amazon EMR sont disponibles ci-dessous. Pour obtenir des informations complètes sur chaque version, consultez [Versions Amazon EMR 6.x](emr-release-6x.md), [Versions Amazon EMR 5.x](emr-release-5x.md) et [Versions Amazon EMR 4.x](emr-release-4x.md).
Abonnez-vous au [flux RSS des notes de mise à jour d’Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/amazon-emr-release-notes.rss) pour recevoir des mises à jour lorsqu’une nouvelle version d’Amazon EMR est disponible.
## Version 6.14.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.14.0. Les modifications ont été apportées à la version 6.13.0. Pour plus d'informations sur le calendrier de publication, consultez le [Journal des modifications 6.14.0](emr-6140-release.md#6140-changelog).
**Nouvelles fonctionnalités**
+ Amazon EMR 6.14.0 supports Apache Spark 3.4.1, Apache Spark RAPIDS 23.06.0-amzn-2, Flink 1.17.1, Iceberg 1.3.1, and Trino 422.
+ La [mise à l'échelle gérée par Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) est désormais disponible dans la région `ap-southeast-3` Asie-Pacifique (Jakarta) pour les clusters que vous créez avec Amazon EMR 6.14.0 ou version ultérieure.
**Problèmes connus**
+ Un script d'état d'instance sur le cluster qui surveille l'état de santé de l'instance peut consommer des ressources de processeur et de mémoire excessives lorsqu'un grand nombre de threads sont and/or ouverts, de descripteurs de fichiers sur le nœud.
**Modifications, améliorations et problèmes résolus**
+ *À partir de Spark 3.3.1 (pris en charge dans les versions EMR 6.10 et supérieures), tous les exécuteurs d'un hôte en cours de mise hors service sont définis sur un nouvel état, appelé DECOMMISSIONING. `ExecutorState`* Les exécuteurs mis hors service ne peuvent pas être utilisés par Yarn pour allouer des tâches et il demandera donc de nouveaux exécuteurs, si nécessaire, pour les tâches en cours d'exécution. Ainsi, si vous désactivez Spark DRA lorsque vous utilisez EMR Managed Scaling, EMR Auto Scaling ou tout autre mécanisme de dimensionnement personnalisé sur les clusters EMR-EC2, Yarn peut demander le maximum d'exécuteurs autorisés pour chaque tâche. Pour éviter ce problème, laissez la `spark.dynamicAllocation.enabled` propriété définie sur `TRUE` (valeur par défaut) lorsque vous utilisez la combinaison de fonctionnalités ci-dessus. En outre, vous pouvez également définir des contraintes d'exécuteur minimales et maximales en définissant des valeurs `spark.dynamicAllocation.maxExecutors` et des `spark.dynamicAllocation.minExecutors` propriétés pour vos tâches Spark, afin de limiter le nombre d'exécuteurs alloués lors de l'exécution de la tâche.
+ La version 6.14.0 optimise la gestion des journaux avec Amazon EMR exécuté sur Amazon EC2. C'est pourquoi vous constaterez peut-être une légère réduction des coûts de stockage pour les journaux de votre cluster.
+ La version 6.14.0 améliore le flux de travail de mise à l'échelle afin de prendre en compte les différentes instances principales dont la taille varie considérablement pour leurs volumes Amazon EBS. Cette amélioration s'applique uniquement aux nœuds principaux ; les opérations de réduction des nœuds de tâches ne sont pas affectées.
+ La version 6.14.0 améliore la façon dont Amazon EMR interagit avec les applications open source telles que Apache Hadoop YARN ResourceManager and HDFS NameNode. Cette amélioration réduit le risque de retards opérationnels liés à la mise à l'échelle du cluster et atténue les échecs de démarrage dus à des problèmes de connectivité avec les applications open source.
+ La version 6.14.0 optimise l'installation des applications au lancement du cluster. Cela améliore les temps de démarrage du cluster pour certaines combinaisons d'applications Amazon EMR.
+ La version 6.14.0 corrige un problème où les opérations de réduction de cluster pouvaient se bloquer lorsqu'un cluster exécuté dans un VPC avec un domaine personnalisé rencontrait un redémarrage de nœud principal ou de nœud de tâche.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
## Version 6.13.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.13.0. Les modifications ont été apportées à la version 6.12.0. Pour plus d'informations sur le calendrier de publication, consultez le [Journal des modifications 6.13.0](emr-6130-release.md#6130-changelog).
**Nouvelles fonctionnalités**
+ Amazon EMR 6.13.0 supports Apache Spark 3.4.1, Apache Spark RAPIDS 23.06.0-amzn-1, CUDA Toolkit 11.8.0, and JupyterHub 1.5.0.
**Problèmes connus**
+ Un script d'état d'instance sur le cluster qui surveille l'état de santé de l'instance peut consommer des ressources de processeur et de mémoire excessives lorsqu'un grand nombre de threads sont and/or ouverts, de descripteurs de fichiers sur le nœud.
**Modifications, améliorations et problèmes résolus**
+ *À partir de Spark 3.3.1 (pris en charge dans les versions EMR 6.10 et supérieures), tous les exécuteurs d'un hôte en cours de mise hors service sont définis sur un nouvel état, appelé DECOMMISSIONING. `ExecutorState`* Les exécuteurs mis hors service ne peuvent pas être utilisés par Yarn pour allouer des tâches et il demandera donc de nouveaux exécuteurs, si nécessaire, pour les tâches en cours d'exécution. Ainsi, si vous désactivez Spark DRA lorsque vous utilisez EMR Managed Scaling, EMR Auto Scaling ou tout autre mécanisme de dimensionnement personnalisé sur les clusters EMR-EC2, Yarn peut demander le maximum d'exécuteurs autorisés pour chaque tâche. Pour éviter ce problème, laissez la `spark.dynamicAllocation.enabled` propriété définie sur `TRUE` (valeur par défaut) lorsque vous utilisez la combinaison de fonctionnalités ci-dessus. En outre, vous pouvez également définir des contraintes d'exécuteur minimales et maximales en définissant des valeurs `spark.dynamicAllocation.maxExecutors` et des `spark.dynamicAllocation.minExecutors` propriétés pour vos tâches Spark, afin de limiter le nombre d'exécuteurs alloués lors de l'exécution de la tâche.
+ La version 6.13.0 améliore le démon de gestion des journaux Amazon EMR afin de garantir que tous les journaux sont chargés à une cadence régulière sur Amazon S3 lorsqu'une commande de résiliation de cluster est émise. Cela permet de résilier plus rapidement les clusters.
+ La version 6.13.0 améliore les capacités de gestion des journaux Amazon EMR afin de garantir un chargement cohérent et en temps voulu de tous les fichiers journaux sur Amazon S3. Cela est particulièrement avantageux pour les clusters EMR de longue durée.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
## Version 6.12.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.12.0. Les modifications ont été apportées à la version 6.11.0. Pour plus d'informations sur le calendrier de publication, consultez le [Journal des modifications 6.12.0](emr-6120-release.md#6120-changelog).
**Nouvelles fonctionnalités**
+ Amazon EMR 6.12.0 supports Apache Spark 3.4.0, Apache Spark RAPIDS 23.06.0-amzn-0, CUDA 11.8.0, Apache Hudi 0.13.1-amzn-0, Apache Iceberg 1.3.0-amzn-0, Trino 414, and PrestoDB 0.281.
+ Les versions 6.12.0 et supérieures d'Amazon EMR prennent en charge l'intégration LDAP avec Apache Livy, Apache Hive via HiveServer 2 (HS2), Trino, Presto et Hue. Vous pouvez également installer Apache Spark et Apache Hadoop sur un cluster EMR utilisant la version 6.12.0 ou supérieure et les configurer pour utiliser LDAP. Pour plus d'informations, consultez [Utilisation de serveurs Active Directory ou LDAP pour l'authentification avec Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/ldap.html).
**Problèmes connus**
+ Un script d'état d'instance sur le cluster qui surveille l'état de santé de l'instance peut consommer des ressources de processeur et de mémoire excessives lorsqu'un grand nombre de threads sont and/or ouverts, de descripteurs de fichiers sur le nœud.
**Modifications, améliorations et problèmes résolus**
+ *À partir de Spark 3.3.1 (pris en charge dans les versions EMR 6.10 et supérieures), tous les exécuteurs d'un hôte en cours de mise hors service sont définis sur un nouvel état, appelé DECOMMISSIONING. `ExecutorState`* Les exécuteurs mis hors service ne peuvent pas être utilisés par Yarn pour allouer des tâches et il demandera donc de nouveaux exécuteurs, si nécessaire, pour les tâches en cours d'exécution. Ainsi, si vous désactivez Spark DRA lorsque vous utilisez EMR Managed Scaling, EMR Auto Scaling ou tout autre mécanisme de dimensionnement personnalisé sur les clusters EMR-EC2, Yarn peut demander le maximum d'exécuteurs autorisés pour chaque tâche. Pour éviter ce problème, laissez la `spark.dynamicAllocation.enabled` propriété définie sur `TRUE` (valeur par défaut) lorsque vous utilisez la combinaison de fonctionnalités ci-dessus. En outre, vous pouvez également définir des contraintes d'exécuteur minimales et maximales en définissant des valeurs `spark.dynamicAllocation.maxExecutors` et des `spark.dynamicAllocation.minExecutors` propriétés pour vos tâches Spark, afin de limiter le nombre d'exécuteurs alloués lors de l'exécution de la tâche.
+ Les versions 6.12.0 et supérieures d'Amazon EMR fournissent la prise en charge de l'exécution Java 11 pour Flink. Pour de plus amples informations, veuillez consulter [Configurer Flink pour qu'il fonctionne avec Java 11](flink-configure.md#flink-configure-java11).
+ La version 6.12.0 ajoute un nouveau mécanisme de nouvelle tentative au flux de travail de dimensionnement des clusters pour les clusters EMR qui exécutent Presto ou Trino. Cette amélioration réduit le risque que le redimensionnement du cluster soit bloqué indéfiniment en raison de l'échec d'une seule opération de redimensionnement. Cela améliore également l'utilisation du cluster, car celui-ci augmente et diminue la capacité plus rapidement.
+ La version 6.12.0 corrige un problème à cause duquel les opérations de réduction de la taille du cluster peuvent se bloquer lorsqu'un nœud principal en cours de mise hors service appropriée tombe en panne pour une raison quelconque avant d'être complètement mis hors service.
+ La version 6.12.0 améliore la logique de réduction de la taille des clusters afin que votre cluster ne tente pas une réduction d'échelle des nœuds principaux en dessous du paramètre de facteur de réplication HDFS défini pour le cluster. Cela répond à vos exigences en matière de redondance des données et réduit le risque de blocage d'une opération de dimensionnement.
+ La version 6.12.0 améliore les performances et l'efficacité du service de surveillance de l'état d'Amazon EMR en augmentant la vitesse à laquelle il enregistre les changements d'état des instances. Cette amélioration réduit le risque de dégradation des performances des nœuds de cluster qui exécutent plusieurs outils clients personnalisés ou des applications tierces.
+ La version 6.12.0 améliore les performances du démon de gestion des journaux sur le cluster pour Amazon EMR. Par conséquent, les risques de dégradation des performances sont moindres avec les clusters EMR qui exécutent des étapes avec une simultanéité élevée.
+ Avec la version 6.12.0 d'Amazon EMR, le démon de gestion des journaux a été mis à niveau pour identifier tous les journaux en cours d'utilisation avec des descripteurs de fichiers ouverts sur le stockage d'instance local, ainsi que les processus associés. Cette mise à niveau garantit qu'Amazon EMR supprime correctement les fichiers et récupère de l'espace de stockage une fois les journaux archivés dans Amazon S3.
+ La version 6.12.0 inclut une amélioration du démon de gestion des journaux qui supprime les répertoires d'étapes vides et inutilisés dans le système de fichiers du cluster local. Un trop grand nombre de répertoires vides peut dégrader les performances des démons Amazon EMR et entraîner une surutilisation du disque.
+ La version 6.12.0 permet la rotation des journaux pour les journaux YARN Timeline Server. Cela permet de minimiser les scénarios de surutilisation des disques, en particulier pour les clusters de longue durée.
+ La taille du volume racine par défaut est passée à 15 Go dans Amazon EMR 6.10.0 et versions ultérieures. Les versions antérieures ont une taille de volume racine par défaut de 10 Go.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
## Version 6.11.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.11.1. Les modifications ont été apportées à la version 6.11.0. Pour plus d'informations sur le calendrier de publication, consultez le [Journal des modifications 6.11.1](emr-6111-release.md#6111-changelog).
**Modifications, améliorations et problèmes résolus**
+ *À partir de Spark 3.3.1 (pris en charge dans les versions EMR 6.10 et supérieures), tous les exécuteurs d'un hôte en cours de mise hors service sont définis sur un nouvel état, appelé DECOMMISSIONING. `ExecutorState`* Les exécuteurs mis hors service ne peuvent pas être utilisés par Yarn pour allouer des tâches et il demandera donc de nouveaux exécuteurs, si nécessaire, pour les tâches en cours d'exécution. Ainsi, si vous désactivez Spark DRA lorsque vous utilisez EMR Managed Scaling, EMR Auto Scaling ou tout autre mécanisme de dimensionnement personnalisé sur les clusters EMR-EC2, Yarn peut demander le maximum d'exécuteurs autorisés pour chaque tâche. Pour éviter ce problème, laissez la `spark.dynamicAllocation.enabled` propriété définie sur `TRUE` (valeur par défaut) lorsque vous utilisez la combinaison de fonctionnalités ci-dessus. En outre, vous pouvez également définir des contraintes d'exécuteur minimales et maximales en définissant des valeurs `spark.dynamicAllocation.maxExecutors` et des `spark.dynamicAllocation.minExecutors` propriétés pour vos tâches Spark, afin de limiter le nombre d'exécuteurs alloués lors de l'exécution de la tâche.
+ En raison d'un conflit de verrouillage, un nœud peut se retrouver bloqué s'il est ajouté ou supprimé en même temps qu'il est mis hors service. Par conséquent, le gestionnaire de ressources Hadoop (YARN) ne répond plus et affecte tous les conteneurs entrants et en cours d'exécution.
+ Cette version inclut une modification qui permet aux clusters à haute disponibilité de se remettre d'un état défaillant après le redémarrage.
+ Cette version inclut des correctifs de sécurité pour Hue et HBase.
+ Cette version résout un problème selon lequel les clusters exécutant des charges de travail sur Spark avec Amazon EMR peuvent recevoir silencieusement des résultats incorrects avec `contains`, `startsWith`, `endsWith` et `like`. Ce problème se produit lorsque vous utilisez les expressions sur des champs partitionnés contenant des métadonnées dans Amazon EMR Hive3 Metastore Server (HMS).
+ Cette version corrige un problème de limitation du côté de Glue en l'absence de fonctions définies par l'utilisateur (UDF).
+ Cette version corrige un problème qui supprime les journaux des conteneurs par le service d'agrégation des journaux des nœuds avant que le transmetteur de journaux ne puisse les envoyer vers S3 en cas de mise hors service de YARN.
+ Cette version corrige un problème lié aux métriques du FairShare planificateur lorsque Node Label est activé pour Hadoop.
+ Cette version corrige un problème qui affectait les performances de Spark lorsque vous définissez une valeur `true` par défaut pour la configuration `spark.yarn.heterogeneousExecutors.enabled` dans `spark-defaults.conf`.
+ Cette version corrige un problème lié à l'échec de la lecture des données de shuffle par Reduce Task. Ce problème provoquait des échecs de requêtes Hive avec une erreur de mémoire corrompue.
+ Cette version ajoute un nouveau mécanisme de nouvelle tentative au flux de travail de dimensionnement des clusters pour les clusters EMR qui exécutent Presto ou Trino. Cette amélioration réduit le risque que le redimensionnement du cluster soit bloqué indéfiniment en raison de l'échec d'une seule opération de redimensionnement. Cela améliore également l'utilisation du cluster, car celui-ci augmente et diminue la capacité plus rapidement.
+ Cette version améliore la logique de réduction de la taille des clusters afin que votre cluster ne tente pas une réduction d'échelle des nœuds principaux en dessous du paramètre de facteur de réplication HDFS défini pour le cluster. Cela répond à vos exigences en matière de redondance des données et réduit le risque de blocage d'une opération de dimensionnement.
+ Le démon de gestion des journaux a été mis à niveau pour identifier tous les journaux en cours d'utilisation avec des descripteurs de fichiers ouverts sur le stockage d'instance local, ainsi que les processus associés. Cette mise à niveau garantit qu'Amazon EMR supprime correctement les fichiers et récupère de l'espace de stockage une fois les journaux archivés dans Amazon S3.
+ Cette version inclut une amélioration du démon de gestion des journaux qui supprime les répertoires d'étapes vides et inutilisés dans le système de fichiers du cluster local. Un trop grand nombre de répertoires vides peut dégrader les performances des démons Amazon EMR et entraîner une surutilisation du disque.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
## Version 6.11.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.11.0. Les modifications ont été apportées à la version 6.10.0. Pour plus d'informations sur le calendrier de publication, consultez le [journal des modifications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-6110-release.html#6110-changelog).
**Nouvelles fonctionnalités**
+ Amazon EMR 6.11.0 prend en charge Apache Spark 3.3.2-amzn-0, Apache Spark RAPIDS 23.02.0-amzn-0, CUDA 11.8.0, Apache Hudi 0.13.0-amzn-0, Apache Iceberg 1.2.0-amzn-0, Trino 410-amzn-0 et PrestoDB 0.279-amzn-0.
**Modifications, améliorations et problèmes résolus**
+ *À partir de Spark 3.3.1 (pris en charge dans les versions EMR 6.10 et supérieures), tous les exécuteurs d'un hôte en cours de mise hors service sont définis sur un nouvel état, appelé DECOMMISSIONING. `ExecutorState`* Les exécuteurs mis hors service ne peuvent pas être utilisés par Yarn pour allouer des tâches et il demandera donc de nouveaux exécuteurs, si nécessaire, pour les tâches en cours d'exécution. Ainsi, si vous désactivez Spark DRA lorsque vous utilisez EMR Managed Scaling, EMR Auto Scaling ou tout autre mécanisme de dimensionnement personnalisé sur les clusters EMR-EC2, Yarn peut demander le maximum d'exécuteurs autorisés pour chaque tâche. Pour éviter ce problème, laissez la `spark.dynamicAllocation.enabled` propriété définie sur `TRUE` (valeur par défaut) lorsque vous utilisez la combinaison de fonctionnalités ci-dessus. En outre, vous pouvez également définir des contraintes d'exécuteur minimales et maximales en définissant des valeurs `spark.dynamicAllocation.maxExecutors` et des `spark.dynamicAllocation.minExecutors` propriétés pour vos tâches Spark, afin de limiter le nombre d'exécuteurs alloués lors de l'exécution de la tâche.
+ Avec Amazon EMR 6.11.0, le connecteur DynamoDB a été mis à niveau vers la version 5.0.0. La version 5.0.0 utilise AWS SDK for Java 2.x. Les versions précédentes utilisaient la version AWS SDK pour Java 1.x. À la suite de cette mise à niveau, nous vous conseillons vivement de tester votre code avant d'utiliser le connecteur DynamoDB avec Amazon EMR 6.11.
+ Lorsque le connecteur DynamoDB pour Amazon EMR 6.11.0 appelle le service DynamoDB, il utilise la valeur de région que vous fournissez pour la propriété `dynamodb.endpoint`. Nous vous recommandons de configurer également `dynamodb.region` lorsque vous utilisez `dynamodb.endpoint`, et que les deux propriétés ciblent la même Région AWS. Si vous l'utilisez `dynamodb.endpoint` et que vous ne le configurez pas`dynamodb.region`, le connecteur DynamoDB pour Amazon EMR 6.11.0 renverra une exception de région non valide et tentera de réconcilier vos informations à Région AWS partir du service de métadonnées d'instance Amazon EC2 (IMDS). Si le connecteur ne parvient pas à récupérer la région depuis IMDS, la valeur par défaut est USA Est (Virginie du Nord) (`us-east-1`). L'erreur suivante illustre l'exception de région non valide que vous pourriez obtenir si vous ne configurez pas correctement la `dynamodb.region` propriété : `error software.amazon.awssdk.services.dynamodb.model.DynamoDbException: Credential should be scoped to a valid region.` pour plus d'informations sur les classes concernées par la AWS SDK pour Java mise à niveau vers la version 2.x, consultez le commit [Upgrade AWS SDK pour Java from 1.x to 2.x (\$1175)](https://github.com/awslabs/emr-dynamodb-connector/commit/1dec9d1972d3673c3fae6c6ea51f19f295147ccf) dans le GitHub dépôt du connecteur Amazon EMR - DynamoDB.
+ Cette version corrige un problème où les données des colonnes deviennent `NULL` lorsque vous utilisez Delta Lake pour stocker les données de la table Delta dans Amazon S3 après l'opération de changement de nom de colonne. Pour plus d'informations sur cette fonctionnalité expérimentale dans Delta Lake, consultez [Opération de changement de nom de colonne](https://docs.delta.io/latest/delta-batch.html#rename-columns) dans le guide de l'utilisateur Delta Lake.
+ La version 6.11.0 résout un problème qui peut survenir lorsque vous créez un nœud périphérique en répliquant l'un des nœuds primaires à partir d'un cluster comportant plusieurs nœuds primaires. Le nœud périphérique répliqué peut retarder les opérations de réduction d'échelle ou entraîner une utilisation élevée de la mémoire sur les nœuds primaires. Pour plus d'informations sur la création d'un nœud périphérique pour communiquer avec votre cluster EMR, consultez la section [Edge Node Creator](https://github.com/aws-samples/aws-emr-utilities/tree/main/utilities/emr-edge-node-creator) dans le `aws-samples` référentiel sur. GitHub
+ La version 6.11.0 améliore le processus d'automatisation utilisé par Amazon EMR pour remonter les volumes Amazon EBS sur une instance après un redémarrage.
+ La version 6.11.0 corrige un problème qui entraînait des écarts intermittents dans les métriques Hadoop publiées par Amazon EMR sur Amazon. CloudWatch
+ La version 6.11.0 résout un problème lié aux clusters EMR où une mise à jour du fichier de configuration YARN contenant la liste d'exclusion des nœuds du cluster est interrompue en raison d'une surutilisation du disque. La mise à jour incomplète entrave les futures opérations de réduction de la taille du cluster. Cette version garantit que votre cluster reste sain et que les opérations de dimensionnement fonctionnent comme prévu.
+ La taille du volume racine par défaut est passée à 15 Go dans Amazon EMR 6.10.0 et versions ultérieures. Les versions antérieures ont une taille de volume racine par défaut de 10 Go.
+ Hadoop 3.3.3 a introduit une modification dans YARN ([YARN-9608](https://issues.apache.org/jira/browse/YARN-9608)) qui maintient les nœuds sur lesquels les conteneurs s'exécutaient dans un état de mise hors service jusqu'à ce que l'application soit terminée. Cette modification permet de s'assurer que les données locales telles que les données réorganisées ne sont pas perdues et que vous n'avez pas besoin de réexécuter la tâche. Cette approche peut également entraîner une sous-utilisation des ressources sur les clusters avec ou sans activation de la mise à l'échelle gérée.
Dans les versions 6.11.0 et supérieures d'Amazon EMR ainsi que dans les versions 6.8.1, 6.9.1 et 6.10.1, la valeur de `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications` est définie sur `false` dans `yarn-site.xml` pour résoudre ce problème.
Bien que ce correctif règle les problèmes introduits par YARN-9608, il peut entraîner l'échec des tâches Hive en raison de la perte de données de réorganisation sur les clusters pour lesquels la mise à l'échelle gérée est activée. Nous avons atténué ce risque dans cette version en définissant également `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` pour les charges de travail Hive. Cette configuration n'est disponible qu'à partir de la version 6.11.0 d'Amazon EMR.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
**Note**
Cette version ne bénéficie plus de mises à jour automatiques de l'AMI puisqu'elle a été suivie d'une version supplémentaire de correctifs. La version du correctif est indiquée par le numéro qui suit la deuxième décimale (`6.8.1`). Pour savoir si vous utilisez la dernière version du correctif, consultez les versions disponibles dans le [https://docs.aws.amazon.com/emr/latest/ReleaseGuide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide), ou consultez le menu déroulant des **versions d'Amazon EMR** lorsque vous créez un cluster dans la console, ou utilisez l'action d'API [https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html) ou de CLI [https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html](https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html). Pour être tenu au courant des nouvelles versions, abonnez-vous au flux RSS sur la page [Quoi de neuf ?](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-whatsnew.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
## Version 6.10.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.10.0. Les modifications ont été apportées à la version 6.9.0. Pour plus d'informations sur le calendrier de publication, consultez le [journal des modifications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-6100-release.html#6100-changelog).
**Nouvelles fonctionnalités**
+ Amazon EMR 6.10.0 prend en charge Apache Spark 3.3.1, Apache Spark RAPIDS 22.12.0, CUDA 11.8.0, Apache Hudi 0.12.2-amzn-0, Apache Iceberg 1.1.0-amzn-0, Trino 403 et PrestoDB 0.278.1.
+ Amazon EMR 6.10.0 inclut un connecteur Trino-Hudi natif qui fournit un accès en lecture aux données des tables Hudi. Vous pouvez activer le connecteur avec `trino-cli --catalog hudi` et le configurer en fonction de vos besoins avec `trino-connector-hudi`. L'intégration native avec Amazon EMR signifie que vous n'avez plus besoin d'utiliser `trino-connector-hive` pour interroger les tables Hudi. Pour obtenir la liste des configurations prises en charge avec le nouveau connecteur, consultez la page [Connecteur Hudi](https://trino.io/docs/current/connector/hudi.html) dans la documentation de Trino.
+ Les versions 6.10.0 et supérieures d'Amazon EMR prennent en charge l'intégration d'Apache Zeppelin avec Apache Flink. Pour plus d’informations, consultez [Travailler avec les jobs Flink de Zeppelin dans Amazon EMR](flink-zeppelin.md).
**Problèmes connus**
+ Hadoop 3.3.3 a introduit une modification dans YARN ([YARN-9608](https://issues.apache.org/jira/browse/YARN-9608)) qui maintient les nœuds sur lesquels les conteneurs s'exécutaient dans un état de mise hors service jusqu'à ce que l'application soit terminée. Cette modification permet de s'assurer que les données locales telles que les données réorganisées ne sont pas perdues et que vous n'avez pas besoin de réexécuter la tâche. Cette approche peut également entraîner une sous-utilisation des ressources sur les clusters avec ou sans activation de la mise à l'échelle gérée.
Pour contourner ce problème dans Amazon EMR 6.10.0, vous pouvez définir la valeur de `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications` sur `false` dans `yarn-site.xml`. Dans les versions 6.11.0 et supérieures d'Amazon EMR, ainsi que 6.8.1, 6.9.1 et 6.10.1, la configuration est définie sur `false` par défaut pour résoudre ce problème.
+ *À partir de Spark 3.3.1 (pris en charge dans les versions EMR 6.10 et supérieures), tous les exécuteurs d'un hôte en cours de mise hors service sont définis sur un nouvel état, appelé DECOMMISSIONING. `ExecutorState`* Les exécuteurs mis hors service ne peuvent pas être utilisés par Yarn pour allouer des tâches et il demandera donc de nouveaux exécuteurs, si nécessaire, pour les tâches en cours d'exécution. Ainsi, si vous désactivez Spark DRA lorsque vous utilisez EMR Managed Scaling, EMR Auto Scaling ou tout autre mécanisme de dimensionnement personnalisé sur les clusters EMR-EC2, Yarn peut demander le maximum d'exécuteurs autorisés pour chaque tâche. Pour éviter ce problème, laissez la `spark.dynamicAllocation.enabled` propriété définie sur `TRUE` (valeur par défaut) lorsque vous utilisez la combinaison de fonctionnalités ci-dessus. En outre, vous pouvez également définir des contraintes d'exécuteur minimales et maximales en définissant des valeurs `spark.dynamicAllocation.maxExecutors` et des `spark.dynamicAllocation.minExecutors` propriétés pour vos tâches Spark, afin de limiter le nombre d'exécuteurs alloués lors de l'exécution de la tâche.
**Modifications, améliorations et problèmes résolus**
+ Amazon EMR 6.10.0 supprime la dépendance sur `minimal-json.jar` pour l'[intégration Amazon Redshift pour Apache Spark](emr-spark-redshift-launch.md) et ajoute automatiquement les fichiers JAR liés à Spark-Redshift requis au chemin de classe de l'exécuteur pour Spark : `spark-redshift.jar`, `spark-avro.jar` et `RedshiftJDBC.jar`.
+ La version 6.10.0 améliore le démon de gestion des journaux sur le cluster afin de surveiller des dossiers de journaux supplémentaires dans votre cluster EMR. Cette amélioration permet de minimiser les scénarios de surutilisation des disques.
+ La version 6.10.0 redémarre automatiquement le démon de gestion des journaux du cluster lorsqu'il s'arrête. Cette amélioration réduit le risque que les nœuds apparaissent défectueux en raison d'une surutilisation du disque.
+ Amazon EMR 6.10.0 prend en charge les points de terminaison régionaux pour le mappage des utilisateurs EMRFS.
+ La taille du volume racine par défaut est passée à 15 Go dans Amazon EMR 6.10.0 et versions ultérieures. Les versions antérieures ont une taille de volume racine par défaut de 10 Go.
+ La version 6.10.0 corrige un problème qui provoquait le blocage des tâches Spark lorsque tous les exécuteurs Spark restants se trouvaient sur un hôte en cours de mise hors service avec le gestionnaire de ressources YARN.
+ Avec Amazon EMR 6.6.0 à 6.9.x, les requêtes INSERT avec partition dynamique et clause ORDER BY ou SORT BY auront toujours deux réducteurs. Ce problème est dû à la modification d'OSS [HIVE-20703](https://issues.apache.org/jira/browse/HIVE-20703), qui place l'optimisation des partitions dynamiques de tri dans le cadre d'une décision basée sur les coûts. Si votre charge de travail ne nécessite pas le tri des partitions dynamiques, nous vous recommandons de définir la propriété `hive.optimize.sort.dynamic.partition.threshold` sur `-1` pour désactiver la nouvelle fonctionnalité et obtenir le nombre de réducteurs correctement calculé. Ce problème est résolu dans OSS Hive dans le cadre de [HIVE-22269](https://issues.apache.org/jira/browse/HIVE-22269) et dans Amazon EMR 6.10.0.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
**Note**
Cette version ne bénéficie plus de mises à jour automatiques de l'AMI puisqu'elle a été suivie d'une version supplémentaire de correctifs. La version du correctif est indiquée par le numéro qui suit la deuxième décimale (`6.8.1`). Pour savoir si vous utilisez la dernière version du correctif, consultez les versions disponibles dans le [https://docs.aws.amazon.com/emr/latest/ReleaseGuide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide), ou consultez le menu déroulant des **versions d'Amazon EMR** lorsque vous créez un cluster dans la console, ou utilisez l'action d'API [https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html) ou de CLI [https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html](https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html). Pour être tenu au courant des nouvelles versions, abonnez-vous au flux RSS sur la page [Quoi de neuf ?](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-whatsnew.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
## Version 6.9.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.9.0. Il s'agit des modifications apportées à la version Amazon EMR 6.8.0. Pour plus d'informations sur le calendrier de publication, consultez le [journal des modifications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-690-release.html#690-changelog).
**Nouvelles fonctionnalités**
+ La version 6.9.0 d'Amazon EMR prend en charge Apache Spark RAPIDS 22.08.0, Apache Hudi 0.12.1, Apache Iceberg 0.14.1, Trino 398 et Tez 0.10.2.
+ La version 6.9.0 d'Amazon EMR inclut une nouvelle application open source, [Delta Lake](emr-delta.md) 2.1.0.
+ L'intégration d'Amazon Redshift à Apache Spark est incluse dans les versions 6.9.0 et ultérieures d'Amazon EMR. Auparavant un outil open-source, l'intégration native est un connecteur Spark que vous pouvez utiliser pour créer des applications Apache Spark capables de lire et d'écrire des données sur Amazon Redshift et Amazon Redshift sans serveur. Pour de plus amples informations, veuillez consulter [Utilisation de l'intégration d'Amazon Redshift pour Apache Spark avec Amazon EMR](emr-spark-redshift.md).
+ La version 6.9.0 d'Amazon EMR ajoute la prise en charge de l'archivage des journaux dans Amazon S3 lors de la réduction de la taille du cluster. Auparavant, vous pouviez uniquement archiver les fichiers journaux sur Amazon S3 lors de la résiliation du cluster. Cette nouvelle fonctionnalité garantit que les fichiers journaux générés sur le cluster sont conservés sur Amazon S3 même après la résiliation du nœud. Pour plus d'informations, consultez [Configuration de la journalisation et du débogage de cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-debugging.html).
+ Pour prendre en charge les requêtes de longue durée, Trino inclut désormais un mécanisme d'exécution tolérant aux pannes. L'exécution tolérante aux pannes atténue les échecs des requêtes en réessayant les requêtes qui ont échoué ou les tâches correspondantes.
+ Vous pouvez utiliser Apache Flink sur Amazon EMR pour le traitement `BATCH` et `STREAM` unifié des tables Apache Hive ou des métadonnées de n'importe quelle source de tables Flink telle que Iceberg, Kinesis ou Kafka. Vous pouvez spécifier le catalogue de données AWS Glue comme métastore pour Flink à l'aide de l'API AWS Management Console, AWS CLI ou Amazon EMR. Pour de plus amples informations, veuillez consulter [Configuration de Flink dans Amazon EMR](flink-configure.md).
+ Vous pouvez désormais spécifier des rôles d'exécution Gestion des identités et des accès AWS (IAM) et un contrôle d'accès AWS Lake Formation basé pour les requêtes Apache Spark, Apache Hive et Presto sur Amazon EMR sur des clusters EC2 avec Amazon AI Studio. SageMaker Pour obtenir des informations supplémentaires, consultez [Configuration des rôles d'exécution pour les étapes d'Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-steps-runtime-roles.html).
**Problèmes connus**
+ Pour Amazon EMR version 6.9.0, Trino ne fonctionne pas sur les clusters activés pour Apache Ranger. Si vous devez utiliser Trino avec Ranger, contactez [Support](https://console.aws.amazon.com/support/home#/).
+ Si vous utilisez l'intégration Amazon Redshift pour Apache Spark et que vous disposez d'une heure, d'un timestamp, d'un timestamp ou d'un timestamptz au format Parquet avec une précision de la microseconde, le connecteur arrondit les valeurs temporelles à la milliseconde la plus proche. Pour contourner le problème, utilisez le paramètre `unload_s3_format` de format de déchargement du texte.
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
+ Les connexions aux clusters Amazon EMR depuis Amazon SageMaker AI Studio peuvent échouer par intermittence avec un code de réponse **403** Forbidden. Cette erreur se produit lorsque la configuration du rôle IAM sur le cluster prend plus de 60 secondes. Pour contourner le problème, vous pouvez installer un correctif Amazon EMR pour activer les nouvelles tentatives et augmenter le délai d'expiration à un minimum de 300 secondes. Suivez les étapes ci-dessous pour appliquer l'action d'amorçage lorsque vous lancez votre cluster.
1. Téléchargez le script bootstrap et les fichiers RPM depuis l'Amazon S3 URIs suivant.
```
s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/gcsc/replace-rpms.sh
s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/gcsc/emr-secret-agent-1.18.0-SNAPSHOT20221121212949.noarch.rpm
```
1. Chargez les fichiers de l'étape précédente sur un compartiment Amazon S3 dont vous êtes propriétaire. Le compartiment doit se trouver à l' Région AWS endroit où vous prévoyez de lancer le cluster.
1. Incluez l'action d'amorçage suivante lorsque vous lancez votre cluster EMR. Remplacez *bootstrap\$1URI* et *RPM\$1URI* par le correspondant URIs provenant d'Amazon S3.
```
--bootstrap-actions "Path=bootstrap_URI,Args=[RPM_URI]"
```
+ Avec les versions 5.36.0 et 6.6.0 à 6.9.0 d'Amazon EMR, les composants de service `SecretAgent` et `RecordServer` peuvent subir une perte de données de journal en raison d'une configuration incorrecte du modèle de nom de fichier dans les propriétés de Log4j2. En cas de configuration incorrecte, les composants ne génèrent qu'un seul fichier journal par jour. Lorsque la stratégie de rotation est appliquée, elle remplace le fichier existant au lieu de générer un nouveau fichier journal comme prévu. Pour contourner le problème, utilisez une action d'amorçage pour générer des journaux toutes les heures et ajoutez un nombre entier auto-incrémenté dans le nom du fichier pour gérer la rotation.
Pour les versions 6.6.0 à 6.9.0 d'Amazon EMR, utilisez l'action de démarrage suivante lorsque vous lancez un cluster.
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
```
Pour Amazon EMR 5.36.0, utilisez l'action de démarrage suivante lorsque vous lancez un cluster.
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
```
+ Apache Flink fournit des FileSystem connecteurs natifs S3 FileSystem et Hadoop, qui permettent aux applications de créer FileSink et d'écrire les données dans Amazon S3. Cela FileSink échoue avec l'une des deux exceptions suivantes.
```
java.lang.UnsupportedOperationException: Recoverable writers on Hadoop are only supported for HDFS
```
```
Caused by: java.lang.NoSuchMethodError: org.apache.hadoop.io.retry.RetryPolicies.retryOtherThanRemoteAndSaslException(Lorg/apache/hadoop/io/retry/RetryPolicy;Ljava/util/Map;)Lorg/apache/hadoop/io/retry/RetryPolicy;
at org.apache.hadoop.yarn.client.RMProxy.createRetryPolicy(RMProxy.java:302) ~[hadoop-yarn-common-3.3.3-amzn-0.jar:?]
```
Pour contourner le problème, vous pouvez installer un correctif Amazon EMR, qui corrige le problème ci-dessus dans Flink. Suivez les étapes suivantes pour appliquer l'action d'amorçage lors du lancement de votre cluster.
1. Téléchargez le fichier flink-rpm dans votre compartiment Amazon S3. Votre chemin RPM est `s3://DOC-EXAMPLE-BUCKET/rpms/flink/`.
1. Téléchargez le script d'amorçage et les fichiers RPM depuis Amazon S3 en utilisant l'URI suivant. Remplacez `regionName` par l' Région AWS endroit où vous prévoyez de lancer le cluster.
```
s3://emr-data-access-control-regionName/customer-bootstrap-actions/gcsc/replace-rpms.sh
```
1. Hadoop 3.3.3 a introduit une modification dans YARN ([YARN-9608](https://issues.apache.org/jira/browse/YARN-9608)) qui maintient les nœuds sur lesquels les conteneurs s'exécutaient dans un état de mise hors service jusqu'à ce que l'application soit terminée. Cette modification permet de s'assurer que les données locales telles que les données réorganisées ne sont pas perdues et que vous n'avez pas besoin de réexécuter la tâche. Dans Amazon EMR 6.8.0 et 6.9.0, cette approche peut également entraîner une sous-utilisation des ressources sur les clusters avec ou sans activation de la mise à l'échelle gérée.
Avec [Amazon EMR 6.10.0](emr-6100-release.md#emr-6100-relnotes), il existe une solution à ce problème qui consiste à définir la valeur de `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications` sur `false` dans `yarn-site.xml`. Dans les versions 6.11.0 et supérieures d'Amazon EMR, ainsi que 6.8.1, 6.9.1 et 6.10.1, la configuration est définie sur `false` par défaut pour résoudre ce problème.
**Modifications, améliorations et problèmes résolus**
+ Pour Amazon EMR version 6.9.0 et versions ultérieures, tous les composants installés par Amazon EMR qui utilisent les bibliothèques Log4j utilisent Log4j version 2.17.1 ou ultérieure.
+ Lorsque vous utilisez le connecteur DynamoDB avec Spark sur les versions 6.6.0, 6.7.0 et 6.8.0 d'Amazon EMR, toutes les lectures de votre table renvoient un résultat vide, même si la division d'entrée fait référence à des données non vides. La version 6.9.0 d'Amazon EMR résout ce problème.
+ Amazon EMR 6.9.0 ajoute une prise en charge limitée du contrôle d'accès basé sur Lake Formation avec Apache Hudi lors de la lecture de données à l'aide de Spark SQL. La prise en charge concerne les requêtes SELECT utilisant Spark SQL et se limite au contrôle d'accès au niveau des colonnes. Pour plus d'informations, consultez [Hudi et Lake Formation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/hudi-with-lake-formation.html).
+ Lorsque vous utilisez Amazon EMR 6.9.0 pour créer un cluster Hadoop avec les [étiquettes de nœuds](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/NodeLabel.html) activées, l'[API de métriques YARN](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerRest.html#Cluster_Metrics_API) renvoie des informations agrégées sur toutes les partitions, au lieu de la partition par défaut. Pour plus d'informations, consultez [YARN-11414](https://issues.apache.org/jira/browse/YARN-11414).
+ Avec la version 6.9.0 d'Amazon EMR, nous avons mis à jour Trino vers la version 398, qui utilise Java 17. La version précédemment prise en charge de Trino pour Amazon EMR 6.8.0 était Trino 388 fonctionnant sous Java 11. Pour plus d'informations sur cette modification, consultez [Mises à jour de Trino vers Java 17](https://trino.io/blog/2022/07/14/trino-updates-to-java-17.html) sur le blog de Trino.
+ Cette version corrige un problème d'inadéquation des séquences temporelles entre Apache BigTop et Amazon EMR sur la séquence de démarrage du cluster EC2. Ce décalage se produit lorsqu'un système tente d'effectuer deux ou plusieurs opérations en même temps au lieu de les effectuer dans le bon ordre. Par conséquent, certaines configurations de cluster ont connu des délais de démarrage des instances et des temps de démarrage des clusters plus lents.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
**Note**
Cette version ne bénéficie plus de mises à jour automatiques de l'AMI puisqu'elle a été suivie d'une version supplémentaire de correctifs. La version du correctif est indiquée par le numéro qui suit la deuxième décimale (`6.8.1`). Pour savoir si vous utilisez la dernière version du correctif, consultez les versions disponibles dans le [https://docs.aws.amazon.com/emr/latest/ReleaseGuide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide), ou consultez le menu déroulant des **versions d'Amazon EMR** lorsque vous créez un cluster dans la console, ou utilisez l'action d'API [https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html) ou de CLI [https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html](https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html). Pour être tenu au courant des nouvelles versions, abonnez-vous au flux RSS sur la page [Quoi de neuf ?](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-whatsnew.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
## Version 6.8.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.8.0. Les modifications ont été apportées à la version 6.7.0.
**Nouvelles fonctionnalités**
+ La fonctionnalité Amazon EMR Steps prend désormais en charge le point de terminaison et les clients Apache Livy. JDBC/ODBC Pour obtenir des informations supplémentaires, consultez [Configuration des rôles d'exécution pour les étapes d'Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-steps-runtime-roles.html).
+ La version 6.8.0 d'Amazon EMR est fournie avec la version 2.4.12 d'Apache HBase . Avec cette HBase version, vous pouvez à la fois archiver et supprimer vos HBase tables. Le processus d'archivage Amazon S3 renomme tous les fichiers de table dans le répertoire d'archive. Ce processus peut être long et coûteux. Vous pouvez désormais ignorer le processus d'archivage et supprimer rapidement des tables volumineuses. Pour de plus amples informations, veuillez consulter [Utilisation de la HBase coque](emr-hbase-connect.md).
**Problèmes connus**
+ Hadoop 3.3.3 a introduit une modification dans YARN ([YARN-9608](https://issues.apache.org/jira/browse/YARN-9608)) qui maintient les nœuds sur lesquels les conteneurs s'exécutaient dans un état de mise hors service jusqu'à ce que l'application soit terminée. Cette modification permet de s'assurer que les données locales telles que les données réorganisées ne sont pas perdues et que vous n'avez pas besoin de réexécuter la tâche. Dans Amazon EMR 6.8.0 et 6.9.0, cette approche peut également entraîner une sous-utilisation des ressources sur les clusters avec ou sans activation de la mise à l'échelle gérée.
Avec [Amazon EMR 6.10.0](emr-6100-release.md#emr-6100-relnotes), il existe une solution à ce problème qui consiste à définir la valeur de `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-applications` sur `false` dans `yarn-site.xml`. Dans les versions 6.11.0 et supérieures d'Amazon EMR, ainsi que 6.8.1, 6.9.1 et 6.10.1, la configuration est définie sur `false` par défaut pour résoudre ce problème.
**Modifications, améliorations et problèmes résolus**
+ Lorsqu'Amazon EMR version 6.5.0, 6.6.0 ou 6.7.0 lisait les tables Apache Phoenix via le shell Apache Spark, Amazon EMR a produit une erreur `NoSuchMethodError`. La version 6.8.0 d'Amazon EMR résout ce problème.
+ La version 6.8.0 d'Amazon EMR est fournie avec [Apache Hudi](https://hudi.apache.org/) 0.11.1 ; toutefois, les clusters Amazon EMR 6.8.0 sont également compatibles avec le `hudi-spark3.3-bundle_2.12` open source de Hudi 0.12.0.
+ La version 6.8.0 d'Amazon EMR est fournie avec la version 3.3.0 d'Apache Spark. Cette version de Spark utilise Apache Log4j 2 et le fichier `log4j2.properties` pour configurer Log4j dans les processus Spark. Si vous utilisez Spark dans le cluster ou si vous créez des clusters EMR avec des paramètres de configuration personnalisés, et que vous voulez passer à la version 6.8.0 d'Amazon EMR, vous devez migrer vers la nouvelle classification de configuration `spark-log4j2` et le nouveau format de clé pour Apache Log4j 2. Pour de plus amples informations, veuillez consulter [Migration d'Apache Log4j 1.x vers Log4j 2.x](emr-spark-configure.md#spark-migrate-logj42).
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
**Note**
Cette version ne bénéficie plus de mises à jour automatiques de l'AMI puisqu'elle a été suivie d'une version supplémentaire de correctifs. La version du correctif est indiquée par le numéro qui suit la deuxième décimale (`6.8.1`). Pour savoir si vous utilisez la dernière version du correctif, consultez les versions disponibles dans le [https://docs.aws.amazon.com/emr/latest/ReleaseGuide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide), ou consultez le menu déroulant des **versions d'Amazon EMR** lorsque vous créez un cluster dans la console, ou utilisez l'action d'API [https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ListReleaseLabels.html) ou de CLI [https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html](https://docs.aws.amazon.com/cli/latest/reference/emr/list-release-labels.html). Pour être tenu au courant des nouvelles versions, abonnez-vous au flux RSS sur la page [Quoi de neuf ?](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-whatsnew.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
**Problèmes connus**
+ Lorsque vous utilisez le connecteur DynamoDB avec Spark sur les versions 6.6.0, 6.7.0 et 6.8.0 d'Amazon EMR, toutes les lectures de votre table renvoient un résultat vide, même si la division d'entrée fait référence à des données non vides. Cela est dû au fait que Spark 3.2.0 définit `spark.hadoopRDD.ignoreEmptySplits` sur `true` par défaut. Pour contourner le problème, définissez explicitement `spark.hadoopRDD.ignoreEmptySplits` sur `false`. La version 6.9.0 d'Amazon EMR résout ce problème.
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
+ Avec les versions 5.36.0 et 6.6.0 à 6.9.0 d'Amazon EMR, les composants de service `SecretAgent` et `RecordServer` peuvent subir une perte de données de journal en raison d'une configuration incorrecte du modèle de nom de fichier dans les propriétés de Log4j2. En cas de configuration incorrecte, les composants ne génèrent qu'un seul fichier journal par jour. Lorsque la stratégie de rotation est appliquée, elle remplace le fichier existant au lieu de générer un nouveau fichier journal comme prévu. Pour contourner le problème, utilisez une action d'amorçage pour générer des journaux toutes les heures et ajoutez un nombre entier auto-incrémenté dans le nom du fichier pour gérer la rotation.
Pour les versions 6.6.0 à 6.9.0 d'Amazon EMR, utilisez l'action de démarrage suivante lorsque vous lancez un cluster.
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
```
Pour Amazon EMR 5.36.0, utilisez l'action de démarrage suivante lorsque vous lancez un cluster.
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
```
Pour plus d'informations sur le calendrier de publication, consultez le [journal des modifications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-680-release.html#680-changelog).
## Version 6.7.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.7.0. Les modifications ont été apportées à la version 6.6.0.
Date de parution initiale : 15 juillet 2022
**Nouvelles fonctionnalités**
+ Amazon EMR prend désormais en charge Apache Spark 3.2.1, Apache Hive 3.1.3, HUDI 0.11, PrestoDB 0.272 et Trino 0.378.
+ Prend en charge les contrôles d'accès basés sur les rôles IAM et Lake Formation avec des étapes EMR (Spark, Hive) pour Amazon EMR sur des clusters EC2.
+ Prend en charge les instructions de définition de données Apache Spark sur les clusters compatibles avec Apache Ranger. Cela inclut désormais la prise en charge des applications Trino lisant et écrivant des métadonnées Apache Hive sur des clusters compatibles avec Apache Ranger. Pour plus d'informations, consultez [Mise en place d'une gouvernance fédérée à l'aide de Trino et d'Apache Ranger sur Amazon EMR](https://aws.amazon.com/blogs/big-data/enable-federated-governance-using-trino-and-apache-ranger-on-amazon-emr/).
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
**Problèmes connus**
+ Lorsque les versions 6.5.0, 6.6.0 ou 6.7.0 d'Amazon EMR lisent les tables Apache Phoenix via le shell Apache Spark, une erreur `NoSuchMethodError` se produit car Amazon EMR utilise une `Hbase.compat.version` incorrecte. La version 6.8.0 d'Amazon EMR résout ce problème.
+ Lorsque vous utilisez le connecteur DynamoDB avec Spark sur les versions 6.6.0, 6.7.0 et 6.8.0 d'Amazon EMR, toutes les lectures de votre table renvoient un résultat vide, même si la division d'entrée fait référence à des données non vides. Cela est dû au fait que Spark 3.2.0 définit `spark.hadoopRDD.ignoreEmptySplits` sur `true` par défaut. Pour contourner le problème, définissez explicitement `spark.hadoopRDD.ignoreEmptySplits` sur `false`. La version 6.9.0 d'Amazon EMR résout ce problème.
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
+ Avec les versions 5.36.0 et 6.6.0 à 6.9.0 d'Amazon EMR, les composants de service `SecretAgent` et `RecordServer` peuvent subir une perte de données de journal en raison d'une configuration incorrecte du modèle de nom de fichier dans les propriétés de Log4j2. En cas de configuration incorrecte, les composants ne génèrent qu'un seul fichier journal par jour. Lorsque la stratégie de rotation est appliquée, elle remplace le fichier existant au lieu de générer un nouveau fichier journal comme prévu. Pour contourner le problème, utilisez une action d'amorçage pour générer des journaux toutes les heures et ajoutez un nombre entier auto-incrémenté dans le nom du fichier pour gérer la rotation.
Pour les versions 6.6.0 à 6.9.0 d'Amazon EMR, utilisez l'action de démarrage suivante lorsque vous lancez un cluster.
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
```
Pour Amazon EMR 5.36.0, utilisez l'action de démarrage suivante lorsque vous lancez un cluster.
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
```
+ L’API `GetClusterSessionCredentials` n’est pas prise en charge avec les clusters qui s’exécutent sur Amazon EMR 6.7 ou version antérieure.
+ Les commits Hadoop suivants ont été rétroportés.
- [[HADOOP-16080]](https://issues.apache.org/jira/browse/HADOOP-16080) Corrigez un problème qui ne fonctionnait pas avec. `hadoop-aws` `hadoop-client-api`
- [[HADOOP-18237]](https://issues.apache.org/jira/browse/HADOOP-18237) Mettez à jour Apache Xerces Java vers la version 2.12.2.
- [[YARN-11092]](https://issues.apache.org/jira/browse/YARN-11092) Mettez à jour jquery vers ui vers la version 1.13.1.
- [[YARN-10720]](https://issues.apache.org/jira/browse/YARN-10720) YARN WebAppProxyServlet devrait prendre en charge le délai d'expiration de la connexion pour empêcher le serveur proxy de se bloquer.
## Version 6.6.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.6.0. Les modifications ont été apportées à la version 6.5.0.
Date de parution initiale : 9 mai 2022
Date de mise à jour de la documentation : 15 juin 2022
**Nouvelles fonctionnalités**
+ Amazon EMR 6.6 prend désormais en charge Apache Spark 3.2, Apache Spark RAPIDS 22.02, CUDA 11, Apache Hudi 0.10.1, Apache Iceberg 0.13, Trino 0.367 et PrestoDB 0.267.
+ Lorsque vous lancez un cluster avec *le dernier correctif* d'Amazon EMR 5.36 ou supérieur, 6.6 ou supérieur, ou 7.0 ou supérieur, Amazon EMR utilise la dernière version d'Amazon Linux 2023 ou Amazon Linux 2 pour l'AMI Amazon EMR par défaut. Pour plus d'informations, consultez [Utilisation de l'AMI Amazon Linux par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
+ Avec Amazon EMR 6.6 et les versions ultérieures, les applications qui utilisent Log4j 1.x et Log4j 2.x sont mises à niveau pour utiliser respectivement Log4j 1.2.17 (ou supérieur) et Log4j 2.17.1 (ou supérieur), et n'ont pas besoin d'utiliser les [actions d'amorçage](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-log4j-vulnerability.html) fournies pour atténuer les problèmes liés aux CVE.
+ **[Mise à l'échelle gérée] Optimisation de la mise à l'échelle gérée des données de réorganisation Spark** – Pour Amazon EMR versions 5.34.0 et ultérieures, et EMR versions 6.4.0 et ultérieures, la mise à l'échelle gérée prend désormais en compte les données de réorganisation Spark (données que Spark redistribue entre les partitions pour effectuer des opérations spécifiques). Pour plus d'informations sur les opérations de réorganisation, consultez [Utilisation de la mise à l'échelle gérée par EMR dans Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) dans le *Guide de gestion Amazon EMR* et le [Guide de programmation Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations).
+ À partir d'Amazon EMR 5.32.0 et 6.5.0, le dimensionnement dynamique de l'exécuteur pour Apache Spark est activé par défaut. Pour activer ou désactiver cette fonctionnalité, vous pouvez utiliser le paramètre de configuration `spark.yarn.heterogeneousExecutors.enabled`.
**Modifications, améliorations et problèmes résolus**
+ Amazon EMR réduit le temps de démarrage des clusters de 80 secondes en moyenne pour les clusters qui utilisent l'option AMI par défaut d'EMR et n'installent que des applications courantes, telles qu'Apache Hadoop, Apache Spark et Apache Hive.
**Problèmes connus**
+ Lorsque les versions 6.5.0, 6.6.0 ou 6.7.0 d'Amazon EMR lisent les tables Apache Phoenix via le shell Apache Spark, une erreur `NoSuchMethodError` se produit car Amazon EMR utilise une `Hbase.compat.version` incorrecte. La version 6.8.0 d'Amazon EMR résout ce problème.
+ Lorsque vous utilisez le connecteur DynamoDB avec Spark sur les versions 6.6.0, 6.7.0 et 6.8.0 d'Amazon EMR, toutes les lectures de votre table renvoient un résultat vide, même si la division d'entrée fait référence à des données non vides. Cela est dû au fait que Spark 3.2.0 définit `spark.hadoopRDD.ignoreEmptySplits` sur `true` par défaut. Pour contourner le problème, définissez explicitement `spark.hadoopRDD.ignoreEmptySplits` sur `false`. La version 6.9.0 d'Amazon EMR résout ce problème.
+ Sur les clusters de longue durée de Trino, Amazon EMR 6.6.0 active les paramètres de journalisation du récupérateur de mémoire dans le fichier jvm.config de Trino afin d'obtenir de meilleures informations à partir des journaux du récupérateur de mémoire. Cette modification ajoute de nombreux journaux de collecte des déchets au fichier launcher.log (/var/log/trino/launcher.log). Si vous utilisez des clusters Trino dans Amazon EMR 6.6.0, vous pouvez rencontrer des nœuds à court d'espace disque après quelques jours d'exécution du cluster en raison des journaux ajoutés.
La solution à ce problème consiste à exécuter le script ci-dessous en tant qu'action d'amorçage afin de désactiver les paramètres de journalisation du récupérateur de mémoire dans jvm.config lors de la création ou du clonage du cluster pour Amazon EMR 6.6.0.
```
#!/bin/bash
set -ex
PRESTO_PUPPET_DIR='/var/aws/emr/bigtop-deploy/puppet/modules/trino'
sudo bash -c "sed -i '/-Xlog/d' ${PRESTO_PUPPET_DIR}/templates/jvm.config"
```
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
+ Avec les versions 5.36.0 et 6.6.0 à 6.9.0 d'Amazon EMR, les composants de service `SecretAgent` et `RecordServer` peuvent subir une perte de données de journal en raison d'une configuration incorrecte du modèle de nom de fichier dans les propriétés de Log4j2. En cas de configuration incorrecte, les composants ne génèrent qu'un seul fichier journal par jour. Lorsque la stratégie de rotation est appliquée, elle remplace le fichier existant au lieu de générer un nouveau fichier journal comme prévu. Pour contourner le problème, utilisez une action d'amorçage pour générer des journaux toutes les heures et ajoutez un nombre entier auto-incrémenté dans le nom du fichier pour gérer la rotation.
Pour les versions 6.6.0 à 6.9.0 d'Amazon EMR, utilisez l'action de démarrage suivante lorsque vous lancez un cluster.
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-6x/replace-puppet.sh,Args=[]"
```
Pour Amazon EMR 5.36.0, utilisez l'action de démarrage suivante lorsque vous lancez un cluster.
```
‑‑bootstrap‑actions "Path=s3://emr-data-access-control-us-east-1/customer-bootstrap-actions/log-rotation-emr-5x/replace-puppet.sh,Args=[]"
```
## Version 5.35.0
Ceci est la note de mise à jour de la version 5.35.0 d'Amazon EMR.
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.35.0. Les modifications ont été apportées à la version 5.34.0.
Date de parution initiale : 30 mars 2022
**Nouvelles fonctionnalités**
+ Les applications Amazon EMR version 5.35 qui utilisent Log4j 1.x et Log4j 2.x sont mises à niveau pour utiliser Log4j 1.2.17 (ou version ultérieure) et Log4j 2.17.1 (ou version ultérieure) respectivement, et ne nécessitent pas d'actions d'amorçage pour atténuer les problèmes CVE dans les versions précédentes. Consultez [Approche visant à atténuer le CVE-2021-44228](emr-log4j-vulnerability.md).
**Modifications, améliorations et problèmes résolus**
**Modifications apportées à Flink**
| Type de modification | Description |
| --- | --- |
| Mises à niveau | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
**Modifications apportées à Hadoop**
| Type de modification | Description |
| --- | --- |
| Rétroportages de Hadoop open source depuis EMR 5.34.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
| Modifications et corrections apportées à Hadoop | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
**Modifications apportées à Hive**
| Type de modification | Description |
| --- | --- |
| Hive est passé à la [version open source 2.3.9](https://www.mail-archive.com/user@hive.apache.org/msg22311.html), y compris ces correctifs JIRA | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
| Rétroportages de Hive open source depuis EMR 5.34.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
| Mises à niveau et correctifs apportés à Hive | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
| Nouvelles fonctionnalités | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
**Modifications apportées à Oozie**
| Type de modification | Description |
| --- | --- |
| Rétroportages d'Oozie open source depuis EMR 5.34.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
**Modifications apportées à Pig**
| Type de modification | Description |
| --- | --- |
| Mises à niveau | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html) |
**Problèmes connus**
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 5.34.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.34.0. Les modifications ont été apportées à la version 5.33.1.
Date de parution initiale : 20 janvier 2022
Date de mise à niveau : 21 mars 2022
**Nouvelles fonctionnalités**
+ **[Mise à l'échelle gérée] Optimisation de la mise à l'échelle gérée des données de réorganisation Spark** – Pour Amazon EMR versions 5.34.0 et ultérieures, et EMR versions 6.4.0 et ultérieures, la mise à l'échelle gérée prend désormais en compte les données de réorganisation Spark (données que Spark redistribue entre les partitions pour effectuer des opérations spécifiques). Pour plus d'informations sur les opérations de réorganisation, consultez [Utilisation de la mise à l'échelle gérée par EMR dans Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) dans le *Guide de gestion Amazon EMR* et le [Guide de programmation Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations).
+ [Hudi] Améliorations visant à simplifier la configuration de Hudi. Le contrôle de simultanéité optimiste a été désactivé par défaut.
**Modifications, améliorations et problèmes résolus**
+ Cette version vise à résoudre les problèmes liés à Amazon EMR Scaling lorsqu'elle ne parvient pas à up/scale réduire correctement un cluster ou entraîne des défaillances d'applications.
+ Auparavant, le redémarrage manuel du gestionnaire de ressources sur un cluster multimaître provoquait le rechargement par les démons Amazon EMR on-cluster, comme Zookeeper, de tous les nœuds précédemment mis hors service ou perdus dans le fichier znode de Zookeeper. Cela a entraîné le dépassement des limites par défaut dans certaines situations. Amazon EMR supprime désormais les enregistrements de nœuds mis hors service ou perdus datant de plus d'une heure du fichier Zookeeper et les limites internes ont été augmentées.
+ Correction d'un problème où les demandes de mise à l'échelle échouaient pour un grand cluster très utilisé lorsque les démons Amazon EMR sur le cluster exécutaient des activités de surveillance de l'état, telles que la collecte de l'état des nœuds YARN et de l'état des nœuds HDFS. Cela était dû au fait que les démons du cluster n'étaient pas en mesure de communiquer les données d'état d'un nœud aux composants internes d'Amazon EMR.
+ Démons EMR intégrés au cluster améliorés pour suivre correctement l'état des nœuds lorsque les adresses IP sont réutilisées afin d'améliorer la fiabilité lors des opérations de mise à l'échelle.
+ [SPARK-29683](https://issues.apache.org/jira/browse/SPARK-29683). Correction d'un problème où les tâches échouaient lors de la réduction de la taille du cluster, car Spark supposait que tous les nœuds disponibles étaient sur la liste de refus.
+ [YARN-9011](https://issues.apache.org/jira/browse/YARN-9011). Correction d'un problème où des échecs de tâches se produisaient en raison d'une condition de course dans la mise hors service de YARN lorsque le cluster essayait d'augmenter ou de réduire sa capacité.
+ Correction du problème des échecs d'étapes ou de tâches lors de la mise à l'échelle du cluster en veillant à ce que les états des nœuds soient toujours cohérents entre les démons Amazon EMR sur le cluster et YARN/HDFS.
+ Correction d'un problème où les opérations de cluster telles que la réduction d'échelle et la soumission d'étapes échouaient pour les clusters Amazon EMR activés avec l'authentification Kerberos. Cela s'explique par le fait que le démon Amazon EMR intégré au cluster n'a pas renouvelé le ticket Kerberos, qui est nécessaire pour communiquer en toute sécurité avec HDFS/YARN l'exécution sur le nœud principal.
+ Mise à niveau de Zeppelin vers la version 0.10.0.
+ Livy Fix – mise à niveau vers la version 0.7.1
+ Amélioration des performances de Spark – les exécuteurs hétérogènes sont désactivés lorsque certaines valeurs de configuration de Spark sont remplacées dans EMR 5.34.0.
+ WebHDFS et le serveur HttpFS sont désactivés par défaut. Vous pouvez réactiver WebHDFS en utilisant la configuration Hadoop, `dfs.webhdfs.enabled`. Le serveur HttpFS peut être démarré en utilisant `sudo systemctl start hadoop-httpfs`.
**Problèmes connus**
+ La fonctionnalité Blocs-notes Amazon EMR utilisée avec l'emprunt d'identité de l'utilisateur Livy ne fonctionne pas car HttpFS est désactivé par défaut. Dans ce cas, le bloc-notes EMR ne peut pas se connecter au cluster dont l'emprunt d'identité Livy est activé. La solution consiste à démarrer le serveur HttpFS avant de connecter le bloc-notes EMR au cluster à l'aide de `sudo systemctl start hadoop-httpfs`.
+ Les requêtes Hue ne fonctionnent pas dans Amazon EMR 6.4.0 car le serveur Apache Hadoop HTTPFS est désactivé par défaut. Pour utiliser Hue sur Amazon EMR 6.4.0, démarrez manuellement le serveur HttpFS sur le nœud primaire d'Amazon EMR à l'aide de `sudo systemctl start hadoop-httpfs`, ou [utilisez une étape d'Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/add-step-cli.html).
+ La fonctionnalité Blocs-notes Amazon EMR utilisée avec l'emprunt d'identité de l'utilisateur Livy ne fonctionne pas car HttpFS est désactivé par défaut. Dans ce cas, le bloc-notes EMR ne peut pas se connecter au cluster dont l'emprunt d'identité Livy est activé. La solution consiste à démarrer le serveur HttpFS avant de connecter le bloc-notes EMR au cluster à l'aide de `sudo systemctl start hadoop-httpfs`.
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 6.5.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.5.0. Les modifications ont été apportées à la version 6.4.0.
Date de parution initiale : 20 janvier 2022
Date de mise à niveau : 21 mars 2022
**Nouvelles fonctionnalités**
+ **[Mise à l'échelle gérée] Optimisation de la mise à l'échelle gérée des données de réorganisation Spark** – Pour Amazon EMR versions 5.34.0 et ultérieures, et EMR versions 6.4.0 et ultérieures, la mise à l'échelle gérée prend désormais en compte les données de réorganisation Spark (données que Spark redistribue entre les partitions pour effectuer des opérations spécifiques). Pour plus d'informations sur les opérations de réorganisation, consultez [Utilisation de la mise à l'échelle gérée par EMR dans Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) dans le *Guide de gestion Amazon EMR* et le [Guide de programmation Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations).
+ À partir d'Amazon EMR 5.32.0 et 6.5.0, le dimensionnement dynamique de l'exécuteur pour Apache Spark est activé par défaut. Pour activer ou désactiver cette fonctionnalité, vous pouvez utiliser le paramètre de configuration `spark.yarn.heterogeneousExecutors.enabled`.
+ Prise en charge du format de table ouvert Apache Iceberg pour les jeux de données analytiques volumineux.
+ Support pour ranger-trino-plugin 2.0.1-amzn-1
+ Prise en charge de toree 0.5.0
**Modifications, améliorations et problèmes résolus**
+ La version 6.5 d'Amazon EMR prend désormais en charge Apache Iceberg 0.12.0 et apporte des améliorations d'exécution avec l'environnement d'exécution Amazon EMR pour Apache Spark, l'environnement d'exécution Amazon EMR pour Presto et l'environnement d'exécution Amazon EMR pour Apache Hive.
+ [Apache Iceberg](https://iceberg.apache.org/) est un format de table ouvert pour les grands jeux de données dans Amazon S3. Il fournit des performances de requête rapides sur de grandes tables, des validations atomiques, des écritures simultanées et une évolution de table compatible avec SQL. Avec EMR 6.5, vous pouvez utiliser Apache Spark 3.1.2 avec le format de table Iceberg.
+ Apache Hudi 0.9 ajoute la prise en charge de DDL et DML de Spark SQL. Cela vous permet de créer et de modifier des tables Hudi en utilisant uniquement des instructions SQL. Apache Hudi 0.9 inclut également des améliorations des performances côté requête et côté écriture.
+ L'environnement d'exécution Amazon EMR pour Apache Hive améliore les performances d'Apache Hive sur Amazon S3 en supprimant les opérations de changement de nom pendant les opérations intermédiaires et en améliorant les performances des commandes de vérification du métastore (MSCK) utilisées pour la réparation des tables.
**Problèmes connus**
+ Lorsque les versions 6.5.0, 6.6.0 ou 6.7.0 d'Amazon EMR lisent les tables Apache Phoenix via le shell Apache Spark, une erreur `NoSuchMethodError` se produit car Amazon EMR utilise une `Hbase.compat.version` incorrecte. La version 6.8.0 d'Amazon EMR résout ce problème.
+ Les clusters de la solution groupée Hbase en haute disponibilité (HA) ne parviennent pas à se provisionner avec la taille de volume et le type d'instance par défaut. La solution à ce problème consiste à augmenter la taille du volume racine.
+ Pour utiliser les actions Spark avec Apache Oozie, vous devez ajouter la configuration suivante à votre fichier Oozie `workflow.xml`. Sinon, plusieurs bibliothèques critiques telles que Hadoop et EMRFS seront absentes du classpath des exécuteurs Spark lancés par Oozie.
```
--conf spark.yarn.populateHadoopClasspath=true
```
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 6.4.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.4.0. Les modifications ont été apportées à la version 6.3.0.
Date de parution initiale : 20 septembre 2021
Date de mise à niveau : 21 mars 2022
**Applications prises en charge**
+ AWS SDK pour Java version 1.12.31
+ CloudWatch Version 2.2.0 de l'évier
+ Connecteur DynamoDB version 4.16.0
+ EMRFS version 2.47.0
+ Amazon EMR Goodies version 3.2.0
+ Amazon EMR Kinesis Connector version 3.5.0
+ Amazon EMR Record Server version 2.1.0
+ Amazon EMR Scripts version 2.5.0
+ Flink version 1.13.1
+ Ganglia version 3.7.2
+ AWS Client Glue Hive Metastore version 3.3.0
+ Hadoop version 3.2.1-amzn-4
+ HBase version 2.4.4-amzn-0
+ HBase-operator-tools 1.1.0
+ HCatalog version 3.1.2-amzn-5
+ Hive version 3.1.2-amzn-5
+ Hudi version 0.8.0-amzn-0
+ Hue version 4.9.0
+ Java JDK version Corretto-8.302.08.1 (build 1.8.0\$1302-b08)
+ JupyterHub version 1.4.1
+ Livy version 0.7.1-incubating
+ MXNet version 1.8.0
+ Oozie version 5.2.1
+ Phoenix version 5.1.2
+ Pig version 0.17.0
+ Presto version 0.254.1-amzn-0
+ Trino version 359
+ Apache Ranger KMS (chiffrement transparent à plusieurs maîtres) version 2.0.0
+ ranger-plugins 2.0.1-amzn-0
+ ranger-s3-plugin 1.2.0
+ SageMaker Version 1.4.1 du SDK Spark
+ Scala version 2.12.10 (machine virtuelle du serveur OpenJDK 64 bits, Java 1.8.0\$1282)
+ Spark version 3.1.2-amzn-0
+ spark-rapids 0.4.1
+ Sqoop version 1.4.7
+ TensorFlow version 2.4.1
+ tez version 0.9.2
+ Zeppelin version 0.9.0
+ Zookeeper version 3.5.7
+ Connecteurs et pilotes : Connecteur DynamoDB 4.16.0
**Nouvelles fonctionnalités**
+ **[Mise à l'échelle gérée] Optimisation de la mise à l'échelle gérée des données de réorganisation Spark** – Pour Amazon EMR versions 5.34.0 et ultérieures, et EMR versions 6.4.0 et ultérieures, la mise à l'échelle gérée prend désormais en compte les données de réorganisation Spark (données que Spark redistribue entre les partitions pour effectuer des opérations spécifiques). Pour plus d'informations sur les opérations de réorganisation, consultez [Utilisation de la mise à l'échelle gérée par EMR dans Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) dans le *Guide de gestion Amazon EMR* et le [Guide de programmation Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations).
+ Sur les clusters Amazon EMR compatibles avec Apache Ranger, vous pouvez utiliser Apache Spark SQL pour insérer des données dans les tables de métastore Apache Hive ou les mettre à jour à l'aide de `INSERT INTO`, `INSERT OVERWRITE` et `ALTER TABLE`. Lorsque vous utilisez ALTER TABLE avec Spark SQL, l'emplacement d'une partition doit être le répertoire enfant d'un emplacement de table. Amazon EMR ne prend actuellement pas en charge l'insertion de données dans une partition où l'emplacement de la partition est différent de celui de la table.
+ PrestoSQL a été [renommé Trino.](https://trino.io/blog/2020/12/27/announcing-trino.html)
+ Hive : l'exécution de requêtes SELECT simples avec la clause LIMIT est accélérée en arrêtant l'exécution de la requête dès que le nombre d'enregistrements mentionné dans la clause LIMIT est récupéré. Les requêtes SELECT simples sont des requêtes qui ne contiennent pas de clause GROUP BY/ORDER BY ou des requêtes qui n'ont pas d'étape de réduction. Par exemple, `SELECT * from WHERE LIMIT `.
**Contrôles de simultanéité Hudi**
+ Hudi prend désormais en charge le contrôle de simultanéité optimiste (OCC), qui peut être exploité avec des opérations d'écriture telles que UPSERT et INSERT pour permettre les modifications de plusieurs enregistreurs sur la même table Hudi. Il s'agit d'un OCC au niveau du fichier, de sorte que deux validations (ou enregistreurs) peuvent écrire dans la même table, si leurs modifications n'entrent pas en conflit. Pour plus d'informations, consultez le [contrôle de simultanéité de Hudi](https://hudi.apache.org/docs/concurrency_control/).
+ Zookeeper est installé sur les clusters Amazon EMR, qui peut être utilisé comme fournisseur de verrous pour OCC. Pour faciliter l'utilisation de cette fonctionnalité, les propriétés préconfigurées des clusters Amazon EMR sont les suivantes :
```
hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.ZookeeperBasedLockProvider
hoodie.write.lock.zookeeper.url=
hoodie.write.lock.zookeeper.port=
hoodie.write.lock.zookeeper.base_path=/hudi
```
Pour activer l'OCC, vous devez configurer les propriétés suivantes soit avec leurs options de tâche Hudi, soit au niveau du cluster à l'aide de l'API de configuration Amazon EMR :
```
hoodie.write.concurrency.mode=optimistic_concurrency_control
hoodie.cleaner.policy.failed.writes=LAZY (Performs cleaning of failed writes lazily instead of inline with every write)
hoodie.write.lock.zookeeper.lock_key= (Table Name is a good option)
```
**Hudi Monitoring : CloudWatch intégration d'Amazon pour générer des rapports sur Hudi Metrics**
+ Amazon EMR prend en charge la publication de Hudi Metrics sur Amazon. CloudWatch Elle est activée en définissant les configurations requises suivantes :
```
hoodie.metrics.on=true
hoodie.metrics.reporter.type=CLOUDWATCH
```
+ Les configurations Hudi facultatives que vous pouvez modifier sont les suivantes :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
**Prise en charge et amélioration des configurations Hudi d'Amazon EMR**
+ Les clients peuvent désormais tirer parti de l'API de configuration EMR et de la fonctionnalité de reconfiguration pour configurer les configurations Hudi au niveau du cluster. Un nouveau support de configuration basé sur des fichiers a été introduit via/etc/hudi/conf/hudi-defaults.conf, à l'instar d'autres applications telles que Spark, Hive, etc. EMR configure quelques paramètres par défaut pour améliorer l'expérience utilisateur :
— `hoodie.datasource.hive_sync.jdbcurl ` est configuré selon l'URL du serveur Hive du cluster et n'a plus besoin d'être spécifié. Cela est particulièrement utile lorsque vous exécutez une tâche en mode cluster Spark, où vous deviez auparavant spécifier l'adresse IP principale Amazon EMR.
— HBase des configurations spécifiques, utiles pour utiliser l' HBase index avec Hudi.
— Configuration spécifique au fournisseur de verrous Zookeeper, comme indiqué dans la section Contrôle de simultanéité, qui facilite l'utilisation du contrôle de simultanéité optimiste (OCC).
+ Des modifications supplémentaires ont été introduites pour réduire le nombre de configurations à transmettre et pour en déduire automatiquement dans la mesure du possible :
— Le mot clé `partitionBy ` peut être utilisé pour spécifier la colonne de partition.
— Lorsque vous activez Hive Sync, il n'est plus obligatoire de spécifier `HIVE_TABLE_OPT_KEY, HIVE_PARTITION_FIELDS_OPT_KEY, HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY`. Ces valeurs peuvent être déduites du nom de la table Hudi et du champ de partition.
— `KEYGENERATOR_CLASS_OPT_KEY` n'est pas obligatoire et peut être déduite de cas plus simples de `SimpleKeyGenerator` et`ComplexKeyGenerator`.
**Mises en garde de Hudi**
+ Hudi ne prend pas en charge l'exécution vectorisée dans les tables Hive for Merge on Read (MoR) et Bootstrap. Par exemple, `count(*)` échoue avec la table en temps réel de Hudi lorsque `hive.vectorized.execution.enabled` est défini sur true. Comme solution de contournement, vous pouvez désactiver la lecture vectorisée en définissant `hive.vectorized.execution.enabled` sur `false`.
+ La prise en charge des enregistreurs multiples n'est pas compatible avec la fonction d'amorçage de Hudi.
+ Flink Streamer et Flink SQL sont des fonctionnalités expérimentales dans cette version. Ces fonctionnalités ne sont pas recommandées pour les déploiements de production.
**Modifications, améliorations et problèmes résolus**
Cette version vise à résoudre les problèmes liés à Amazon EMR Scaling lorsqu'elle ne parvient pas à up/scale réduire correctement un cluster ou entraîne des défaillances d'applications.
+ Auparavant, le redémarrage manuel du gestionnaire de ressources sur un cluster multimaître provoquait le rechargement par les démons Amazon EMR on-cluster, comme Zookeeper, de tous les nœuds précédemment mis hors service ou perdus dans le fichier znode de Zookeeper. Cela a entraîné le dépassement des limites par défaut dans certaines situations. Amazon EMR supprime désormais les enregistrements de nœuds mis hors service ou perdus datant de plus d'une heure du fichier Zookeeper et les limites internes ont été augmentées.
+ Correction d'un problème où les demandes de mise à l'échelle échouaient pour un grand cluster très utilisé lorsque les démons Amazon EMR sur le cluster exécutaient des activités de surveillance de l'état, telles que la collecte de l'état des nœuds YARN et de l'état des nœuds HDFS. Cela était dû au fait que les démons du cluster n'étaient pas en mesure de communiquer les données d'état d'un nœud aux composants internes d'Amazon EMR.
+ Démons EMR intégrés au cluster améliorés pour suivre correctement l'état des nœuds lorsque les adresses IP sont réutilisées afin d'améliorer la fiabilité lors des opérations de mise à l'échelle.
+ [SPARK-29683](https://issues.apache.org/jira/browse/SPARK-29683). Correction d'un problème où les tâches échouaient lors de la réduction de la taille du cluster, car Spark supposait que tous les nœuds disponibles étaient sur la liste de refus.
+ [YARN-9011](https://issues.apache.org/jira/browse/YARN-9011). Correction d'un problème où des échecs de tâches se produisaient en raison d'une condition de course dans la mise hors service de YARN lorsque le cluster essayait d'augmenter ou de réduire sa capacité.
+ Correction du problème des échecs d'étapes ou de tâches lors de la mise à l'échelle du cluster en veillant à ce que les états des nœuds soient toujours cohérents entre les démons Amazon EMR sur le cluster et YARN/HDFS.
+ Correction d'un problème où les opérations de cluster telles que la réduction d'échelle et la soumission d'étapes échouaient pour les clusters Amazon EMR activés avec l'authentification Kerberos. Cela s'explique par le fait que le démon Amazon EMR intégré au cluster n'a pas renouvelé le ticket Kerberos, qui est nécessaire pour communiquer en toute sécurité avec HDFS/YARN l'exécution sur le nœud principal.
+ **Configuration d'un cluster pour résoudre les problèmes de performances d'Apache YARN Timeline Server versions 1 et 1.5**
Les versions 1 et 1.5 d'Apache YARN Timeline Server peuvent entraîner des problèmes de performances avec de grands clusters EMR très actifs, en particulier avec `yarn.resourcemanager.system-metrics-publisher.enabled=true`, le paramètre par défaut d'Amazon EMR. YARN Timeline Server v2 open source résout le problème de performance lié à la capacité de mise à l'échelle de YARN Timeline Server.
Les autres solutions à ce problème incluent :
+ Configuration de yarn.resourcemanager. system-metrics-publisher.enabled=false dans le fichier yarn-site.xml.
+ Activation du correctif pour ce problème lors de la création d'un cluster, comme décrit ci-dessous.
Les versions Amazon EMR suivantes contiennent un correctif pour ce problème de performance de YARN Timeline Server.
EMR 5.30.2, 5.31.1, 5.32.1, 5.33.1, 5.34.x, 6.0.1, 6.1.1, 6.2.1, 6.3.1, 6.4.x
Pour activer le correctif sur l'une des versions Amazon EMR spécifiées ci-dessus, définissez ces propriétés sur `true` dans un fichier JSON de configuration transmis à l'aide du [paramètre de commande `aws emr create-cluster`](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-create-cluster.html) : `--configurations file://./configurations.json`. Vous pouvez également activer le correctif à l'aide de l'[interface utilisateur de la console de reconfiguration](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).
Exemple du contenu du fichier configurations.json :
```
[
{
"Classification": "yarn-site",
"Properties": {
"yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.enable-batch": "true",
"yarn.resourcemanager.system-metrics-publisher.enabled": "true"
},
"Configurations": []
}
]
```
+ WebHDFS et le serveur HttpFS sont désactivés par défaut. Vous pouvez réactiver WebHDFS en utilisant la configuration Hadoop, `dfs.webhdfs.enabled`. Le serveur HttpFS peut être démarré en utilisant `sudo systemctl start hadoop-httpfs`.
+ Le protocole HTTPS est désormais activé par défaut pour les référentiels Amazon Linux. Si vous utilisez une politique VPCE Amazon S3 pour restreindre l'accès à des compartiments spécifiques, vous devez ajouter le nouvel ARN du compartiment Amazon Linux `arn:aws:s3:::amazonlinux-2-repos-$region/*` à votre politique (remplacez `$region` par la région où se trouve le point de terminaison). Pour plus d'informations, consultez cette rubrique dans les forums de AWS discussion. [Annonce : Amazon Linux 2 permet désormais d'utiliser le protocole HTTPS lors de la connexion aux référentiels de packages](https://forums.aws.amazon.com/ann.jspa?annID=8528).
+ Hive : les performances des requêtes d'écriture sont améliorées en permettant l'utilisation d'un répertoire temporaire sur HDFS pour la dernière tâche. Les données temporaires pour la tâche finale sont écrites sur HDFS au lieu d'Amazon S3 et les performances sont améliorées car les données sont déplacées de HDFS vers l'emplacement de la table finale (Amazon S3) au lieu d'être déplacées entre les appareils Amazon S3.
+ Hive : amélioration du temps de compilation des requêtes jusqu'à 2,5 fois avec l'élimination des partitions du métastore Glue.
+ Par défaut, lorsque les éléments intégrés UDFs sont transmis par Hive au serveur Hive Metastore, seul un sous-ensemble de ces éléments intégrés UDFs est transmis au Glue Metastore, car Glue ne prend en charge que des opérateurs d'expression limités. Si vous définissez `hive.glue.partition.pruning.client=true`, tout l'élimination des partitions se fait du côté client. Si vous définissez `hive.glue.partition.pruning.server=true`, tout l'élimination des partitions se fait du côté serveur.
**Problèmes connus**
+ Les requêtes Hue ne fonctionnent pas dans Amazon EMR 6.4.0 car le serveur Apache Hadoop HTTPFS est désactivé par défaut. Pour utiliser Hue sur Amazon EMR 6.4.0, démarrez manuellement le serveur HttpFS sur le nœud primaire d'Amazon EMR à l'aide de `sudo systemctl start hadoop-httpfs`, ou [utilisez une étape d'Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/add-step-cli.html).
+ La fonctionnalité Blocs-notes Amazon EMR utilisée avec l'emprunt d'identité de l'utilisateur Livy ne fonctionne pas car HttpFS est désactivé par défaut. Dans ce cas, le bloc-notes EMR ne peut pas se connecter au cluster dont l'emprunt d'identité Livy est activé. La solution consiste à démarrer le serveur HttpFS avant de connecter le bloc-notes EMR au cluster à l'aide de `sudo systemctl start hadoop-httpfs`.
+ Dans la version 6.4.0 d'Amazon EMR, Phoenix ne prend pas en charge le composant des connecteurs Phoenix.
+ Pour utiliser les actions Spark avec Apache Oozie, vous devez ajouter la configuration suivante à votre fichier Oozie `workflow.xml`. Sinon, plusieurs bibliothèques critiques telles que Hadoop et EMRFS seront absentes du classpath des exécuteurs Spark lancés par Oozie.
```
--conf spark.yarn.populateHadoopClasspath=true
```
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 5.32.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.32.0. Les modifications ont été apportées à la version 5.31.0.
Date de parution initiale : 8 janvier 2021
**Mises à niveau**
+ Mise à niveau du connecteur Amazon Glue vers la version 1.14.0
+ Mise à niveau du SDK Amazon SageMaker Spark vers la version 1.4.1
+ Mise à niveau AWS SDK pour Java vers la version 1.11.890
+ Mise à niveau de la version 4.16.0 du connecteur DynamoDB d'EMR
+ Mise à niveau d'EMRFS vers la version 2.45.0
+ Mise à niveau des métriques d'analyse des journaux d'EMR vers la version 1.18.0
+ MetricsAndEventsApiGateway Client EMR mis à niveau vers la version 1.5.0
+ Mise à niveau du serveur d'enregistrement EMR vers la version 1.8.0
+ Mise à niveau d'EMR S3 Dist CP vers la version 2.17.0
+ Mise à niveau d'EMR Secret Agent vers la version 1.7.0
+ Mise à niveau de Flink vers la version 1.11.2
+ Mise à niveau de Hadoop vers la version 2.10.1-amzn-0
+ Mise à niveau de Hive vers la version 2.3.7-amzn-3
+ Mise à niveau de Hue vers la version 4.8.0
+ Mise à niveau de Mxnet vers la version 1.7.0
+ Mise à niveau d'OpenCV vers la version 4.4.0
+ Mise à niveau de Presto vers la version 0.240.1-amzn-0
+ Mise à niveau de Spark vers la version 2.4.7-amzn-0
+ Mise à niveau TensorFlow vers la version 2.3.1
**Modifications, améliorations et problèmes résolus**
+ Cette version vise à résoudre les problèmes liés à Amazon EMR Scaling lorsqu'elle ne parvient pas à up/scale réduire correctement un cluster ou entraîne des défaillances d'applications.
+ Correction d'un problème où les demandes de mise à l'échelle échouaient pour un grand cluster très utilisé lorsque les démons Amazon EMR sur le cluster exécutaient des activités de surveillance de l'état, telles que la collecte de l'état des nœuds YARN et de l'état des nœuds HDFS. Cela était dû au fait que les démons du cluster n'étaient pas en mesure de communiquer les données d'état d'un nœud aux composants internes d'Amazon EMR.
+ Démons EMR intégrés au cluster améliorés pour suivre correctement l'état des nœuds lorsque les adresses IP sont réutilisées afin d'améliorer la fiabilité lors des opérations de mise à l'échelle.
+ [SPARK-29683](https://issues.apache.org/jira/browse/SPARK-29683). Correction d'un problème où les tâches échouaient lors de la réduction de la taille du cluster, car Spark supposait que tous les nœuds disponibles étaient sur la liste de refus.
+ [YARN-9011](https://issues.apache.org/jira/browse/YARN-9011). Correction d'un problème où des échecs de tâches se produisaient en raison d'une condition de course dans la mise hors service de YARN lorsque le cluster essayait d'augmenter ou de réduire sa capacité.
+ Correction du problème des échecs d'étapes ou de tâches lors de la mise à l'échelle du cluster en veillant à ce que les états des nœuds soient toujours cohérents entre les démons Amazon EMR sur le cluster et YARN/HDFS.
+ Correction d'un problème où les opérations de cluster telles que la réduction d'échelle et la soumission d'étapes échouaient pour les clusters Amazon EMR activés avec l'authentification Kerberos. Cela s'explique par le fait que le démon Amazon EMR intégré au cluster n'a pas renouvelé le ticket Kerberos, qui est nécessaire pour communiquer en toute sécurité avec HDFS/YARN l'exécution sur le nœud principal.
+ Les nouvelles versions d'Amazon EMR corrigent le problème en abaissant la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions d' AL2 Amazon EMR. Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent désormais un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé.
+ Versions de composants mises à niveau.
+ Pour obtenir la liste des versions des composants, consultez la section [À propos des versions d'Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html) dans ce guide.
**Nouvelles fonctionnalités**
+ À partir d'Amazon EMR 5.32.0 et 6.5.0, le dimensionnement dynamique de l'exécuteur pour Apache Spark est activé par défaut. Pour activer ou désactiver cette fonctionnalité, vous pouvez utiliser le paramètre de configuration `spark.yarn.heterogeneousExecutors.enabled`.
+ État de prise en charge du service de métadonnées d'instance (IMDS) V2 : les composants Amazon EMR 5.23.1, 5.27.1 et 5.32 ou versions ultérieures sont utilisés pour tous les appels IMDS. IMDSv2 Pour les appels IMDS dans le code de votre application, vous pouvez utiliser les deux IMDSv1 ou configurer l'IMDS pour qu'il ne soit utilisé que IMDSv2 pour renforcer la sécurité. IMDSv2 Pour les autres versions 5.x EMR, la IMDSv1 désactivation entraîne l'échec du démarrage du cluster.
+ À partir d'Amazon EMR 5.32.0, vous pouvez lancer un cluster qui s'intègre nativement à Apache Ranger. Apache Ranger est un cadre open source permettant d'activer, de surveiller et de gérer la sécurité globale des données sur la plateforme Hadoop. Pour plus d'informations, consultez [Apache Ranger](https://ranger.apache.org/). Grâce à l'intégration native, vous pouvez utiliser votre propre Apache Ranger pour appliquer un contrôle précis de l'accès aux données sur Amazon EMR. Consultez [Intégration d'Amazon EMR à Apache Ranger](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger.html) dans le *Guide de version Amazon EMR.*
+ La version 5.32.0 d'Amazon EMR prend en charge Amazon EMR sur EKS. Pour en savoir plus sur la prise en main d'EMR sur EKS, consultez [Qu'est-ce qu'Amazon EMR sur EKS ?](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks.html).
+ La version 5.32.0 d'Amazon EMR prend en charge Amazon EMR Studio (version préliminaire). Pour plus d'informations sur la prise en main d'EMR Studio, consultez [Amazon EMR Studio (version préliminaire)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio.html).
+ Politiques gérées délimitées : pour s'aligner sur les AWS meilleures pratiques, Amazon EMR a introduit des politiques gérées par défaut définies dans la version 2 EMR en remplacement des politiques qui seront déconseillées. Consultez [Politiques gérées par Amazon EMR.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-iam-policies.html)
**Problèmes connus**
+ Pour les clusters de sous-réseaux privés Amazon EMR 6.3.0 et 6.2.0, vous ne pouvez pas accéder à l'interface utilisateur Web de Ganglia. Vous recevrez un message d'erreur « accès refusé (403) ». D'autres sites Web UIs, tels que Spark, Hue JupyterHub, Zeppelin, Livy et Tez, fonctionnent normalement. L'accès à l'interface utilisateur Web de Ganglia sur les clusters de sous-réseaux publics fonctionne également normalement. Pour résoudre ce problème, redémarrez le service httpd sur le nœud primaire avec `sudo systemctl restart httpd`. Ce problème est résolu dans Amazon EMR 6.4.0.
+ **Réduction de la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions AL2 [corrigée dans les nouvelles versions].** Versions Amazon EMR : emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 et emr-6.2.0 sont basées sur les anciennes versions d'Amazon Linux 2 (), qui ont un paramètre ulimit inférieur pour le « Nombre maximum de fichiers ouverts » lorsque les clusters Amazon EMR sont créés avec l'AMI par défaut. AL2 Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé. Les versions dont la limite de fichiers ouverts est inférieure provoquent l'erreur « Trop de fichiers ouverts » lors de la soumission d'une tâche Spark. Dans les versions concernées, l'AMI par défaut Amazon EMR possède un paramètre ulimit par défaut de 4096 pour le « Nombre maximum de fichiers ouverts », ce qui est inférieur à la limite de fichiers de 65536 de la dernière AMI Amazon Linux 2. Le paramètre ulimit inférieur pour « Nombre maximum de fichiers ouverts » entraîne l'échec de la tâche Spark lorsque le pilote et l'exécuteur Spark tentent d'ouvrir plus de 4 096 fichiers. Pour résoudre ce problème, Amazon EMR dispose d'un script d'action d'amorçage (BA, bootstrap action) qui ajuste le paramètre ulimit lors de la création du cluster.
Si vous utilisez une ancienne version d'Amazon EMR qui ne contient pas de solution permanente à ce problème, la solution suivante vous permet de définir explicitement le paramètre ulimit du contrôleur d'instance sur un maximum de 65536 fichiers.
**Définir explicitement un ulimit à partir de la ligne de commande**
1. Modifiez `/etc/systemd/system/instance-controller.service` pour ajouter les paramètres suivants à la section Service.
`LimitNOFILE=65536`
`LimitNPROC=65536`
1. Redémarrer InstanceController
`$ sudo systemctl daemon-reload`
`$ sudo systemctl restart instance-controller`
**Définissez un ulimit à l'aide de l'action d'amorçage (BA)**
Vous pouvez également utiliser un script d'action d'amorçage (BA) pour configurer ulimit du contrôleur d'instance à 65536 fichiers lors de la création du cluster.
```
#!/bin/bash
for user in hadoop spark hive; do
sudo tee /etc/security/limits.d/$user.conf << EOF
$user - nofile 65536
$user - nproc 65536
EOF
done
for proc in instancecontroller logpusher; do
sudo mkdir -p /etc/systemd/system/$proc.service.d/
sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
[Service]
LimitNOFILE=65536
LimitNPROC=65536
EOF
pid=$(pgrep -f aws157.$proc.Main)
sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
done
sudo systemctl daemon-reload
```
+
**Important**
Les clusters EMR qui exécutent des AMI (Amazon Linux Machine Images) Amazon Linux ou Amazon Linux 2 utilisent le comportement par défaut d’Amazon Linux et ne téléchargent pas et n’installent pas automatiquement les mises à jour importantes et critiques du noyau nécessitant un redémarrage. Ce comportement est identique à celui des autres instances Amazon EC2 qui exécutent l’AMI Amazon Linux par défaut. Si de nouvelles mises à jour logicielles Amazon Linux nécessitant un redémarrage (telles que les mises à jour du noyau, de NVIDIA et de CUDA) sont disponibles après la publication d’une version d’Amazon EMR, les instances de cluster EMR qui exécutent l’AMI par défaut ne téléchargent pas et n’installent pas automatiquement ces mises à jour. Pour obtenir les mises à jour du noyau, vous pouvez [personnaliser votre AMI Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html) afin d'[utiliser la dernière AMI Amazon Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html).
+ La prise en charge par console pour créer une configuration de sécurité spécifiant l'option d'intégration de AWS Ranger n'est actuellement pas prise en charge dans la GovCloud région. La configuration de la sécurité peut être effectuée à l'aide de la CLI. Consultez [Création de la configuration de sécurité EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-security-config.html) dans le *Guide de gestion Amazon EMR*.
+ Lorsque AtRestEncryption le chiffrement HDFS est activé sur un cluster qui utilise Amazon EMR 5.31.0 ou 5.32.0, les requêtes Hive génèrent l'exception d'exécution suivante.
```
TaskAttempt 3 failed, info=[Error: Error while running task ( failure ) : attempt_1604112648850_0001_1_01_000000_3:java.lang.RuntimeException: java.lang.RuntimeException: Hive Runtime Error while closing operators: java.io.IOException: java.util.ServiceConfigurationError: org.apache.hadoop.security.token.TokenIdentifier: Provider org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier not found
```
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 6.2.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.2.0. Les modifications ont été apportées à la version 6.1.0.
Date de parution initiale : 9 décembre 2020
Dernière mise à jour : 4 octobre 2021
**Applications prises en charge**
+ AWS SDK pour Java version 1.11.828
+ emr-record-server version 1.7.0
+ Flink version 1.11.2
+ Ganglia version 3.7.2
+ Hadoop version 3.2.1-amzn-1
+ HBase version 2.2.6-amzn-0
+ HBase-operator-tools 1.0.0
+ HCatalog version 3.1.2-amzn-0
+ Hive version 3.1.2-amzn-3
+ Hudi version 0.6.0-amzn-1
+ Hue version 4.8.0
+ JupyterHub version 1.1.0
+ Livy version 0.7.0
+ MXNet version 1.7.0
+ Oozie version 5.2.0
+ Phoenix version 5.0.0
+ Pig version 0.17.0
+ Presto version 0.238.3-amzn-1
+ PrestoSQL version 343
+ Spark version 3.0.1-amzn-0
+ spark-rapids 0.2.0
+ TensorFlow version 2.3.1
+ Zeppelin version 0.9.0-preview1
+ Zookeeper version 3.4.14
+ Connecteurs et pilotes : Connecteur DynamoDB 4.16.0
**Nouvelles fonctionnalités**
+ HBase: Suppression du changement de nom lors de la phase de validation et ajout d'un HFile suivi persistant. Consultez la section [ HFile Suivi permanent](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-s3.html#emr-hbase-s3-hfile-tracking) dans le guide de *mise à jour d'Amazon EMR.*
+ HBase: Rétroporté [Créez une configuration qui oblige à mettre en cache les blocs lors du compactage](https://issues.apache.org/jira/browse/HBASE-23066).
+ PrestoDB : améliorations apportées à l'élimination dynamique des partitions. Join Reorder basée sur des règles fonctionne sur des données non partitionnées.
+ Politiques gérées délimitées : pour s'aligner sur les AWS meilleures pratiques, Amazon EMR a introduit des politiques gérées par défaut définies dans la version 2 EMR en remplacement des politiques qui seront déconseillées. Consultez [Politiques gérées par Amazon EMR.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-iam-policies.html)
+ État de prise en charge du service de métadonnées d'instance (IMDS) V2 : pour Amazon EMR 6.2 ou version ultérieure, les composants Amazon EMR sont IMDSv2 utilisés pour tous les appels IMDS. Pour les appels IMDS dans le code de votre application, vous pouvez utiliser les deux IMDSv1 ou configurer l'IMDS pour qu'il ne soit utilisé que IMDSv2 pour renforcer la sécurité. IMDSv2 Si vous la désactivez IMDSv1 dans les versions antérieures d'Amazon EMR 6.x, cela entraîne un échec du démarrage du cluster.
**Modifications, améliorations et problèmes résolus**
+ Cette version vise à résoudre les problèmes liés à Amazon EMR Scaling lorsqu'elle ne parvient pas à up/scale réduire correctement un cluster ou entraîne des défaillances d'applications.
+ Correction d'un problème où les demandes de mise à l'échelle échouaient pour un grand cluster très utilisé lorsque les démons Amazon EMR sur le cluster exécutaient des activités de surveillance de l'état, telles que la collecte de l'état des nœuds YARN et de l'état des nœuds HDFS. Cela était dû au fait que les démons du cluster n'étaient pas en mesure de communiquer les données d'état d'un nœud aux composants internes d'Amazon EMR.
+ Démons EMR intégrés au cluster améliorés pour suivre correctement l'état des nœuds lorsque les adresses IP sont réutilisées afin d'améliorer la fiabilité lors des opérations de mise à l'échelle.
+ [SPARK-29683](https://issues.apache.org/jira/browse/SPARK-29683). Correction d'un problème où les tâches échouaient lors de la réduction de la taille du cluster, car Spark supposait que tous les nœuds disponibles étaient sur la liste de refus.
+ [YARN-9011](https://issues.apache.org/jira/browse/YARN-9011). Correction d'un problème où des échecs de tâches se produisaient en raison d'une condition de course dans la mise hors service de YARN lorsque le cluster essayait d'augmenter ou de réduire sa capacité.
+ Correction du problème des échecs d'étapes ou de tâches lors de la mise à l'échelle du cluster en veillant à ce que les états des nœuds soient toujours cohérents entre les démons Amazon EMR sur le cluster et YARN/HDFS.
+ Correction d'un problème où les opérations de cluster telles que la réduction d'échelle et la soumission d'étapes échouaient pour les clusters Amazon EMR activés avec l'authentification Kerberos. Cela s'explique par le fait que le démon Amazon EMR intégré au cluster n'a pas renouvelé le ticket Kerberos, qui est nécessaire pour communiquer en toute sécurité avec HDFS/YARN l'exécution sur le nœud principal.
+ Les nouvelles versions d'Amazon EMR corrigent le problème en abaissant la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions d' AL2 Amazon EMR. Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent désormais un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé.
+ Spark : amélioration des performances dans l'environnement d'exécution de Spark.
**Problèmes connus**
+ Les autorisations définies sur Amazon EMR 6.2 sont incorrectes. Le répertoire/etc/cron.d/libinstance-controller-java file in EMR 6.2.0. Permissions on the file are 645 (-rw-r--r-x), when they should be 644 (-rw-r--r--). As a result, Amazon EMR version 6.2 does not log instance-state logs, and the /emr/instance-logs est vide. Ce problème est corrigé dans Amazon EMR 6.3.0 et les versions ultérieures.
Pour contourner ce problème, exécutez le script suivant en tant qu'action d'amorçage lors du lancement du cluster.
```
#!/bin/bash
sudo chmod 644 /etc/cron.d/libinstance-controller-java
```
+ Pour les clusters de sous-réseaux privés Amazon EMR 6.2.0 et 6.3.0, vous ne pouvez pas accéder à l'interface utilisateur Web de Ganglia. Vous recevrez un message d'erreur « accès refusé (403) ». D'autres sites Web UIs, tels que Spark, Hue JupyterHub, Zeppelin, Livy et Tez, fonctionnent normalement. L'accès à l'interface utilisateur Web de Ganglia sur les clusters de sous-réseaux publics fonctionne également normalement. Pour résoudre ce problème, redémarrez le service httpd sur le nœud primaire avec `sudo systemctl restart httpd`. Ce problème est résolu dans Amazon EMR 6.4.0.
+ Amazon EMR 6.2.0 présente un problème selon lequel httpd échoue continuellement, ce qui rend Ganglia indisponible. Le message d'erreur « Impossible de se connecter au serveur » s'affiche. Pour réparer un cluster déjà en cours d'exécution présentant ce problème, connectez-vous en SSH au nœud primaire du cluster et ajoutez la ligne `Listen 80` au fichier `httpd.conf` situé dans `/etc/httpd/conf/httpd.conf`. Ce problème est résolu dans Amazon EMR 6.3.0.
+ HTTTD échoue sur les clusters EMR 6.2.0 lorsque vous utilisez une configuration de sécurité. Cela rend l'interface utilisateur de l'application web Ganglia indisponible. Pour accéder à l'interface utilisateur de l'application web Ganglia, ajoutez `Listen 80` au fichier `/etc/httpd/conf/httpd.conf` sur le nœud primaire de votre cluster. Pour plus d'informations sur la connexion à votre cluster, consultez [Connexion au nœud primaire à l'aide de SSH](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html).
Blocs-notes EMR ne parvient pas non plus à établir une connexion avec les clusters EMR 6.2.0 lorsque vous utilisez une configuration de sécurité. Le bloc-notes ne parviendra pas à répertorier les noyaux et à soumettre les tâches Spark. Nous vous recommandons d'utiliser Blocs-notes EMR avec une autre version d'Amazon EMR à la place.
+ **Réduction de la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions AL2 [corrigée dans les nouvelles versions].** Versions Amazon EMR : emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 et emr-6.2.0 sont basées sur les anciennes versions d'Amazon Linux 2 (), qui ont un paramètre ulimit inférieur pour le « Nombre maximum de fichiers ouverts » lorsque les clusters Amazon EMR sont créés avec l'AMI par défaut. AL2 Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé. Les versions dont la limite de fichiers ouverts est inférieure provoquent l'erreur « Trop de fichiers ouverts » lors de la soumission d'une tâche Spark. Dans les versions concernées, l'AMI par défaut Amazon EMR possède un paramètre ulimit par défaut de 4096 pour le « Nombre maximum de fichiers ouverts », ce qui est inférieur à la limite de fichiers de 65536 de la dernière AMI Amazon Linux 2. Le paramètre ulimit inférieur pour « Nombre maximum de fichiers ouverts » entraîne l'échec de la tâche Spark lorsque le pilote et l'exécuteur Spark tentent d'ouvrir plus de 4 096 fichiers. Pour résoudre ce problème, Amazon EMR dispose d'un script d'action d'amorçage (BA, bootstrap action) qui ajuste le paramètre ulimit lors de la création du cluster.
Si vous utilisez une ancienne version d'Amazon EMR qui ne contient pas de solution permanente à ce problème, la solution suivante vous permet de définir explicitement le paramètre ulimit du contrôleur d'instance sur un maximum de 65536 fichiers.
**Définir explicitement un ulimit à partir de la ligne de commande**
1. Modifiez `/etc/systemd/system/instance-controller.service` pour ajouter les paramètres suivants à la section Service.
`LimitNOFILE=65536`
`LimitNPROC=65536`
1. Redémarrer InstanceController
`$ sudo systemctl daemon-reload`
`$ sudo systemctl restart instance-controller`
**Définissez un ulimit à l'aide de l'action d'amorçage (BA)**
Vous pouvez également utiliser un script d'action d'amorçage (BA) pour configurer ulimit du contrôleur d'instance à 65536 fichiers lors de la création du cluster.
```
#!/bin/bash
for user in hadoop spark hive; do
sudo tee /etc/security/limits.d/$user.conf << EOF
$user - nofile 65536
$user - nproc 65536
EOF
done
for proc in instancecontroller logpusher; do
sudo mkdir -p /etc/systemd/system/$proc.service.d/
sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
[Service]
LimitNOFILE=65536
LimitNPROC=65536
EOF
pid=$(pgrep -f aws157.$proc.Main)
sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
done
sudo systemctl daemon-reload
```
+
**Important**
Amazon EMR 6.1.0 et 6.2.0 présentent un problème de performance qui peut affecter de manière critique toutes les opérations insert, upsert et delete de Hudi. Si vous envisagez d'utiliser Hudi avec Amazon EMR 6.1.0 ou 6.2.0, AWS contactez le support pour obtenir un RPM Hudi corrigé.
+
**Important**
Les clusters EMR qui exécutent des AMI (Amazon Linux Machine Images) Amazon Linux ou Amazon Linux 2 utilisent le comportement par défaut d’Amazon Linux et ne téléchargent pas et n’installent pas automatiquement les mises à jour importantes et critiques du noyau nécessitant un redémarrage. Ce comportement est identique à celui des autres instances Amazon EC2 qui exécutent l’AMI Amazon Linux par défaut. Si de nouvelles mises à jour logicielles Amazon Linux nécessitant un redémarrage (telles que les mises à jour du noyau, de NVIDIA et de CUDA) sont disponibles après la publication d’une version d’Amazon EMR, les instances de cluster EMR qui exécutent l’AMI par défaut ne téléchargent pas et n’installent pas automatiquement ces mises à jour. Pour obtenir les mises à jour du noyau, vous pouvez [personnaliser votre AMI Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html) afin d'[utiliser la dernière AMI Amazon Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html).
+ Les artefacts Maven d'Amazon EMR 6.2.0 ne sont pas publiés. Ils seront publiés avec une future version d'Amazon EMR.
+ Le HFile suivi permanent à l'aide de la table système HBase Storefile ne prend pas en charge la fonctionnalité de réplication des HBase régions. Pour plus d'informations sur HBase la réplication régionale, consultez la section Nombre [élevé de lectures disponibles cohérentes avec la chronologie](http://hbase.apache.org/book.html#arch.timelineconsistent.reads).
+ Différences de version entre Amazon EMR 6.x et EMR 5.x pour la compartimentation Hive
EMR 5.x utilise OOS Apache Hive 2, tandis que EMR 6.x utilise OOS Apache Hive 3. La version open source Hive2 utilise la version 1 de Bucketing, tandis que la version open source Hive3 utilise la version 2. Cette différence de version de compartimentation entre Hive 2 (EMR 5.x) et Hive 3 (EMR 6.x) signifie que le hachage de compartimentation de Hive fonctionne différemment. Consultez l'exemple ci-dessous.
Le tableau suivant est un exemple créé dans EMR 6.x et EMR 5.x, respectivement.
```
-- Using following LOCATION in EMR 6.x
CREATE TABLE test_bucketing (id INT, desc STRING)
PARTITIONED BY (day STRING)
CLUSTERED BY(id) INTO 128 BUCKETS
LOCATION 's3://your-own-s3-bucket/emr-6-bucketing/';
-- Using following LOCATION in EMR 5.x
LOCATION 's3://your-own-s3-bucket/emr-5-bucketing/';
```
Insertion des mêmes données dans EMR 6.x et EMR 5.x.
```
INSERT INTO test_bucketing PARTITION (day='01') VALUES(66, 'some_data');
INSERT INTO test_bucketing PARTITION (day='01') VALUES(200, 'some_data');
```
La vérification de l'emplacement S3 montre que le nom du fichier de compartimentation est différent, car la fonction de hachage est différente entre EMR 6.x (Hive 3) et EMR 5.x (Hive 2).
```
[hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-6-bucketing/day=01/
2020-10-21 20:35:16 13 000025_0
2020-10-21 20:35:22 14 000121_0
[hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-5-bucketing/day=01/
2020-10-21 20:32:07 13 000066_0
2020-10-21 20:32:51 14 000072_0
```
Vous pouvez également constater la différence de version en exécutant la commande suivante dans la CLI Hive dans EMR 6.x. Notez qu'il renvoie la version 2 de compartimentation.
```
hive> DESCRIBE FORMATTED test_bucketing;
...
Table Parameters:
bucketing_version 2
...
```
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 5.31.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.31.0. Les modifications ont été apportées à la version 5.30.1.
Date de parution initiale : 9 octobre 2020
Dernière mise à jour : 15 octobre 2020
**Mises à niveau**
+ Mise à niveau du connecteur Amazon Glue vers la version 1.13.0
+ Mise à niveau du SDK Amazon SageMaker Spark vers la version 1.4.0
+ Mise à niveau du connecteur Amazon Kinesis vers la version 3.5.9
+ Mise à niveau AWS SDK pour Java vers la version 1.11.852
+ Mise à niveau de Bigtop-tomcat vers la version 8.5.56
+ Mise à niveau d'EMRFS vers la version 2.43.0
+ MetricsAndEventsApiGateway Client EMR mis à niveau vers la version 1.4.0
+ Mise à niveau d'EMR S3 Dist CP vers la version 2.15.0
+ Mise à niveau d'EMR S3 Select vers la version 1.6.0
+ Mise à niveau de Flink vers la version 1.11.0
+ Mise à niveau de Hadoop vers la version 2.10.0
+ Mise à niveau de Hive vers la version 2.3.7
+ Mise à niveau de Hudi vers la version 0.6.0
+ Mise à niveau de Hue vers la version 4.7.1
+ Mise à niveau JupyterHub vers la version 1.1.0
+ Mise à niveau de Mxnet vers la version 1.6.0
+ Mise à niveau d'OpenCV vers la version 4.3.0
+ Mise à niveau de Presto vers la version 0.238.3
+ Mise à niveau TensorFlow vers la version 2.1.0
**Modifications, améliorations et problèmes résolus**
+ Cette version vise à résoudre les problèmes liés à Amazon EMR Scaling lorsqu'elle ne parvient pas à up/scale réduire correctement un cluster ou entraîne des défaillances d'applications.
+ Correction d'un problème où les demandes de mise à l'échelle échouaient pour un grand cluster très utilisé lorsque les démons Amazon EMR sur le cluster exécutaient des activités de surveillance de l'état, telles que la collecte de l'état des nœuds YARN et de l'état des nœuds HDFS. Cela était dû au fait que les démons du cluster n'étaient pas en mesure de communiquer les données d'état d'un nœud aux composants internes d'Amazon EMR.
+ Démons EMR intégrés au cluster améliorés pour suivre correctement l'état des nœuds lorsque les adresses IP sont réutilisées afin d'améliorer la fiabilité lors des opérations de mise à l'échelle.
+ [SPARK-29683](https://issues.apache.org/jira/browse/SPARK-29683). Correction d'un problème où les tâches échouaient lors de la réduction de la taille du cluster, car Spark supposait que tous les nœuds disponibles étaient sur la liste de refus.
+ [YARN-9011](https://issues.apache.org/jira/browse/YARN-9011). Correction d'un problème où des échecs de tâches se produisaient en raison d'une condition de course dans la mise hors service de YARN lorsque le cluster essayait d'augmenter ou de réduire sa capacité.
+ Correction du problème des échecs d'étapes ou de tâches lors de la mise à l'échelle du cluster en veillant à ce que les états des nœuds soient toujours cohérents entre les démons Amazon EMR sur le cluster et YARN/HDFS.
+ Correction d'un problème où les opérations de cluster telles que la réduction d'échelle et la soumission d'étapes échouaient pour les clusters Amazon EMR activés avec l'authentification Kerberos. Cela s'explique par le fait que le démon Amazon EMR intégré au cluster n'a pas renouvelé le ticket Kerberos, qui est nécessaire pour communiquer en toute sécurité avec HDFS/YARN l'exécution sur le nœud principal.
+ Les nouvelles versions d'Amazon EMR corrigent le problème en abaissant la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions d' AL2 Amazon EMR. Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent désormais un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé.
+ Les [statistiques des colonnes Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ColumnStatistics) sont prises en charge pour les versions 5.31.0 et ultérieures d'Amazon EMR.
+ Versions de composants mises à niveau.
+ Prise en charge d'EMRFS S3EC V2 dans Amazon EMR 5.31.0. Dans les versions 1.11.837 et ultérieures du kit SDK Java S3, le client de chiffrement version 2 (S3EC V2) a été introduit avec diverses améliorations de sécurité. Pour plus d’informations, consultez les ressources suivantes :
+ Article de blog S3 : [Updates to the Amazon S3 encryption client](https://aws.amazon.com/blogs/developer/updates-to-the-amazon-s3-encryption-client/).
+ AWS SDK pour Java Guide du développeur : [Migrez les clients de chiffrement et de déchiffrement vers la version V2](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/s3-encryption-migration.html#s3-cse-update-code).
+ Guide de gestion EMR : [Chiffrement côté client Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-emrfs-encryption-cse.html).
Le client de chiffrement V1 est toujours disponible dans le kit SDK pour des raisons de rétrocompatibilité.
**Nouvelles fonctionnalités**
+ **Réduction de la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions AL2 [corrigée dans les nouvelles versions].** Versions Amazon EMR : emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 et emr-6.2.0 sont basées sur les anciennes versions d'Amazon Linux 2 (), qui ont un paramètre ulimit inférieur pour le « Nombre maximum de fichiers ouverts » lorsque les clusters Amazon EMR sont créés avec l'AMI par défaut. AL2 Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé. Les versions dont la limite de fichiers ouverts est inférieure provoquent l'erreur « Trop de fichiers ouverts » lors de la soumission d'une tâche Spark. Dans les versions concernées, l'AMI par défaut Amazon EMR possède un paramètre ulimit par défaut de 4096 pour le « Nombre maximum de fichiers ouverts », ce qui est inférieur à la limite de fichiers de 65536 de la dernière AMI Amazon Linux 2. Le paramètre ulimit inférieur pour « Nombre maximum de fichiers ouverts » entraîne l'échec de la tâche Spark lorsque le pilote et l'exécuteur Spark tentent d'ouvrir plus de 4 096 fichiers. Pour résoudre ce problème, Amazon EMR dispose d'un script d'action d'amorçage (BA, bootstrap action) qui ajuste le paramètre ulimit lors de la création du cluster.
Si vous utilisez une ancienne version d'Amazon EMR qui ne contient pas de solution permanente à ce problème, la solution suivante vous permet de définir explicitement le paramètre ulimit du contrôleur d'instance sur un maximum de 65536 fichiers.
**Définir explicitement un ulimit à partir de la ligne de commande**
1. Modifiez `/etc/systemd/system/instance-controller.service` pour ajouter les paramètres suivants à la section Service.
`LimitNOFILE=65536`
`LimitNPROC=65536`
1. Redémarrer InstanceController
`$ sudo systemctl daemon-reload`
`$ sudo systemctl restart instance-controller`
**Définissez un ulimit à l'aide de l'action d'amorçage (BA)**
Vous pouvez également utiliser un script d'action d'amorçage (BA) pour configurer ulimit du contrôleur d'instance à 65536 fichiers lors de la création du cluster.
```
#!/bin/bash
for user in hadoop spark hive; do
sudo tee /etc/security/limits.d/$user.conf << EOF
$user - nofile 65536
$user - nproc 65536
EOF
done
for proc in instancecontroller logpusher; do
sudo mkdir -p /etc/systemd/system/$proc.service.d/
sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
[Service]
LimitNOFILE=65536
LimitNPROC=65536
EOF
pid=$(pgrep -f aws157.$proc.Main)
sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
done
sudo systemctl daemon-reload
```
+ Avec Amazon EMR 5.31.0, vous pouvez lancer un cluster qui s'intègre à Lake Formation. Cette intégration fournit un filtrage des données précis au niveau des colonnes pour les bases de données et les tables du Glue AWS Data Catalog. Il permet également une authentification unique fédérée à Blocs-notes EMR ou Apache Zeppelin à partir d'un système d'identité d'entreprise. Pour plus d'informations, consultez [Intégration d'Amazon EMR avec AWS Lake Formation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lake-formation.html) dans le *Guide de gestion Amazon EMR*.
Amazon EMR with Lake Formation est actuellement disponible dans 16 AWS régions : USA Est (Ohio et Virginie du Nord), USA Ouest (Californie du Nord et Oregon), Asie-Pacifique (Mumbai, Séoul, Singapour, Sydney et Tokyo), Canada (Centre), Europe (Francfort, Irlande, Londres, Paris et Stockholm), Amérique du Sud (São Paulo).
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
+ Lorsque AtRestEncryption le chiffrement HDFS est activé sur un cluster qui utilise Amazon EMR 5.31.0 ou 5.32.0, les requêtes Hive génèrent l'exception d'exécution suivante.
```
TaskAttempt 3 failed, info=[Error: Error while running task ( failure ) : attempt_1604112648850_0001_1_01_000000_3:java.lang.RuntimeException: java.lang.RuntimeException: Hive Runtime Error while closing operators: java.io.IOException: java.util.ServiceConfigurationError: org.apache.hadoop.security.token.TokenIdentifier: Provider org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier not found
```
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 6.1.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.1.0. Les modifications ont été apportées à la version 6.0.0.
Date de parution initiale : 4 septembre 2020
Dernière mise à jour : 15 octobre 2020
**Applications prises en charge**
+ AWS SDK pour Java version 1.11.828
+ Flink version 1.11.0
+ Ganglia version 3.7.2
+ Hadoop version 3.2.1-amzn-1
+ HBase version 2.2.5
+ HBase-operator-tools 1.0.0
+ HCatalog version 3.1.2-amzn-0
+ Hive version 3.1.2-amzn-1
+ Hudi version 0.5.2-incubation
+ Hue version 4.7.1
+ JupyterHub version 1.1.0
+ Livy version 0.7.0
+ MXNet version 1.6.0
+ Oozie version 5.2.0
+ Phoenix version 5.0.0
+ Presto version 0.232
+ PrestoSQL version 338
+ Spark version 3.0.0-amzn-0
+ TensorFlow version 2.1.0
+ Zeppelin version 0.9.0-preview1
+ Zookeeper version 3.4.14
+ Connecteurs et pilotes : Connecteur DynamoDB 4.14.0
**Nouvelles fonctionnalités**
+ Les types d'instance ARM sont pris en charge à partir des versions 5.30.0 et 6.1.0 d'Amazon EMR.
+ Les types d'instances à usage général M6g sont pris en charge à partir des versions 6.1.0 et 5.30.0 d'Amazon EMR. Pour plus d'informations, consultez [Types d'instance pris en charge](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-supported-instance-types.html) dans le *Guide de gestion Amazon EMR*.
+ La fonctionnalité de groupe de placement EC2 est prise en charge à partir de la version 5.23.0 d'Amazon EMR en tant qu'option pour plusieurs clusters de nœuds primaires. Actuellement, seuls les types de nœuds primaires sont pris en charge par la fonctionnalité de groupe de placement. La stratégie `SPREAD` est appliquée à ces nœuds primaires. La stratégie `SPREAD` place un petit groupe d'instances sur un matériel sous-jacent distinct afin de se prémunir contre la perte de plusieurs nœuds primaires en cas de panne matérielle. Pour plus d'informations, consultez [Intégration d'EMR au groupe de placement EC2](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-placementgroup.html) dans le *Guide de gestion Amazon EMR*.
+ Mise à l'échelle gérée – Avec la version 6.1.0 d'Amazon EMR, vous pouvez activer la mise à l'échelle gérée par Amazon EMR pour augmenter ou diminuer automatiquement le nombre d'instances ou d'unités dans votre cluster en fonction de la charge de travail. Amazon EMR évalue en permanence les métriques de cluster pour prendre des décisions de dimensionnement qui optimisent vos clusters en termes de coût et de vitesse. Managed Scaling est également disponible sur Amazon EMR version 5.30.0 et suivantes, à l'exception de 6.0.0. Pour plus d'informations, consultez [Mise à l'échelle des ressources de cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-scale-on-demand.html) dans le *Guide de gestion Amazon EMR*.
+ La version 338 de PrestoSQL est prise en charge avec EMR 6.1.0. Pour plus d'informations, consultez [Presto](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto.html).
+ PrestoSQL est uniquement pris en charge sur EMR 6.1.0 et versions ultérieures, pas sur EMR 6.0.0 ou EMR 5.x.
+ Le nom de l'application, `Presto` continue d'être utilisé pour installer PrestoDB sur des clusters. Pour installer PrestoSQL sur des clusters, utilisez le nom de l'application `PrestoSQL`.
+ Vous pouvez installer PrestoDB ou PrestoSQL, mais vous ne pouvez pas installer les deux sur un seul cluster. Si PrestoDB et PrestoSQL sont spécifiés lors de la tentative de création d'un cluster, une erreur de validation se produit et la demande de création de cluster échoue.
+ PrestoSQL est pris en charge sur les clusters mono-maître et muti-maître. Sur les clusters multi-maîtres, un métastore Hive externe est requis pour exécuter PrestoSQL ou Prestodb. Consultez [Applications prises en charge dans un cluster EMR avec plusieurs nœuds primaires](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html#emr-plan-ha-applications-list).
+ Prise en charge de l'authentification automatique ECR sur Apache Hadoop et Apache Spark avec Docker : les utilisateurs de Spark peuvent utiliser des images Docker provenant de Docker Hub et d'Amazon Elastic Container Registry (Amazon ECR) pour définir les dépendances de l'environnement et des bibliothèques.
[Configurez Docker](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-docker.html) et [exécutez des applications Spark avec Docker à l'aide d'Amazon EMR 6.x](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-docker.html).
+ EMR prend en charge les transactions ACID d'Apache Hive : Amazon EMR 6.1.0 prend en charge les transactions ACID de Hive afin qu'elles soient conformes aux propriétés ACID d'une base de données. Grâce à cette fonctionnalité, vous pouvez exécuter les opérations `INSERT, UPDATE, DELETE,` et `MERGE` dans des tables gérées par Hive avec des données stockées dans Amazon Simple Storage Service (Amazon S3). Il s'agit d'une fonctionnalité essentielle pour les cas d'utilisation tels que l'ingestion en continu, le retraitement des données, les mises à jour en masse à l'aide de MERGE et les dimensions qui changent lentement. Pour plus d'informations, notamment des exemples de configuration et des cas supports, consultez [Amazon EMR prend en charge les transactions ACID d'Apache Hive](https://aws.amazon.com/blogs/big-data/amazon-emr-supports-apache-hive-acid-transactions).
**Modifications, améliorations et problèmes résolus**
+ Cette version vise à résoudre les problèmes liés à Amazon EMR Scaling lorsqu'elle ne parvient pas à up/scale réduire correctement un cluster ou entraîne des défaillances d'applications.
+ Correction d'un problème où les demandes de mise à l'échelle échouaient pour un grand cluster très utilisé lorsque les démons Amazon EMR sur le cluster exécutaient des activités de surveillance de l'état, telles que la collecte de l'état des nœuds YARN et de l'état des nœuds HDFS. Cela était dû au fait que les démons du cluster n'étaient pas en mesure de communiquer les données d'état d'un nœud aux composants internes d'Amazon EMR.
+ Démons EMR intégrés au cluster améliorés pour suivre correctement l'état des nœuds lorsque les adresses IP sont réutilisées afin d'améliorer la fiabilité lors des opérations de mise à l'échelle.
+ [SPARK-29683](https://issues.apache.org/jira/browse/SPARK-29683). Correction d'un problème où les tâches échouaient lors de la réduction de la taille du cluster, car Spark supposait que tous les nœuds disponibles étaient sur la liste de refus.
+ [YARN-9011](https://issues.apache.org/jira/browse/YARN-9011). Correction d'un problème où des échecs de tâches se produisaient en raison d'une condition de course dans la mise hors service de YARN lorsque le cluster essayait d'augmenter ou de réduire sa capacité.
+ Correction du problème des échecs d'étapes ou de tâches lors de la mise à l'échelle du cluster en veillant à ce que les états des nœuds soient toujours cohérents entre les démons Amazon EMR sur le cluster et YARN/HDFS.
+ Correction d'un problème où les opérations de cluster telles que la réduction d'échelle et la soumission d'étapes échouaient pour les clusters Amazon EMR activés avec l'authentification Kerberos. Cela s'explique par le fait que le démon Amazon EMR intégré au cluster n'a pas renouvelé le ticket Kerberos, qui est nécessaire pour communiquer en toute sécurité avec HDFS/YARN l'exécution sur le nœud principal.
+ Les nouvelles versions d'Amazon EMR corrigent le problème en abaissant la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions d' AL2 Amazon EMR. Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent désormais un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé.
+ Apache Flink n'est pas pris en charge sur EMR 6.0.0, mais il l'est sur EMR 6.1.0 avec Flink 1.11.0. Il s'agit de la première version de Flink officiellement compatible avec Hadoop 3. Consultez [Annonce de sortie d'Apache Flink 1.11.0](https://flink.apache.org/news/2020/07/06/release-1.11.0.html).
+ Ganglia a été supprimé des packages EMR 6.1.0 par défaut.
**Problèmes connus**
+ **Réduction de la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions AL2 [corrigée dans les nouvelles versions].** Versions Amazon EMR : emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 et emr-6.2.0 sont basées sur les anciennes versions d'Amazon Linux 2 (), qui ont un paramètre ulimit inférieur pour le « Nombre maximum de fichiers ouverts » lorsque les clusters Amazon EMR sont créés avec l'AMI par défaut. AL2 Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé. Les versions dont la limite de fichiers ouverts est inférieure provoquent l'erreur « Trop de fichiers ouverts » lors de la soumission d'une tâche Spark. Dans les versions concernées, l'AMI par défaut Amazon EMR possède un paramètre ulimit par défaut de 4096 pour le « Nombre maximum de fichiers ouverts », ce qui est inférieur à la limite de fichiers de 65536 de la dernière AMI Amazon Linux 2. Le paramètre ulimit inférieur pour « Nombre maximum de fichiers ouverts » entraîne l'échec de la tâche Spark lorsque le pilote et l'exécuteur Spark tentent d'ouvrir plus de 4 096 fichiers. Pour résoudre ce problème, Amazon EMR dispose d'un script d'action d'amorçage (BA, bootstrap action) qui ajuste le paramètre ulimit lors de la création du cluster.
Si vous utilisez une ancienne version d'Amazon EMR qui ne contient pas de solution permanente à ce problème, la solution suivante vous permet de définir explicitement le paramètre ulimit du contrôleur d'instance sur un maximum de 65536 fichiers.
**Définir explicitement un ulimit à partir de la ligne de commande**
1. Modifiez `/etc/systemd/system/instance-controller.service` pour ajouter les paramètres suivants à la section Service.
`LimitNOFILE=65536`
`LimitNPROC=65536`
1. Redémarrer InstanceController
`$ sudo systemctl daemon-reload`
`$ sudo systemctl restart instance-controller`
**Définissez un ulimit à l'aide de l'action d'amorçage (BA)**
Vous pouvez également utiliser un script d'action d'amorçage (BA) pour configurer ulimit du contrôleur d'instance à 65536 fichiers lors de la création du cluster.
```
#!/bin/bash
for user in hadoop spark hive; do
sudo tee /etc/security/limits.d/$user.conf << EOF
$user - nofile 65536
$user - nproc 65536
EOF
done
for proc in instancecontroller logpusher; do
sudo mkdir -p /etc/systemd/system/$proc.service.d/
sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
[Service]
LimitNOFILE=65536
LimitNPROC=65536
EOF
pid=$(pgrep -f aws157.$proc.Main)
sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
done
sudo systemctl daemon-reload
```
+
**Important**
Amazon EMR 6.1.0 et 6.2.0 présentent un problème de performance qui peut affecter de manière critique toutes les opérations insert, upsert et delete de Hudi. Si vous envisagez d'utiliser Hudi avec Amazon EMR 6.1.0 ou 6.2.0, AWS contactez le support pour obtenir un RPM Hudi corrigé.
+ Si vous définissez une configuration de collecte des déchets personnalisée avec `spark.driver.extraJavaOptions` et`spark.executor.extraJavaOptions`, cela entraînera un échec du driver/executor lancement d'EMR 6.1 en raison d'une configuration de collecte des déchets conflictuelle. Avec la version 6.1.0 d'EMR, vous devez spécifier la configuration personnalisée du récupérateur de mémoire Spark pour les pilotes et les exécuteurs avec les propriétés `spark.driver.defaultJavaOptions` et `spark.executor.defaultJavaOptions` à la place. Pour en savoir plus, consultez [Environnement d'exécution Apache Spark](https://spark.apache.org/docs/latest/configuration.html#runtime-environment) et [Configuration du récupérateur de mémoire Spark sur Amazon EMR 6.1.0](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-gc-config).
+ L'utilisation de Pig avec Oozie (et au sein de Hue, puisque Hue utilise les actions Oozie pour exécuter les scripts Pig), génère une erreur indiquant qu'une bibliothèque native-lzo ne peut pas être chargée. Ce message d'erreur est informatif et n'empêche pas Pig de fonctionner.
+ Prise en charge de la simultanéité dans Hudi : Actuellement, Hudi ne prend pas en charge les écritures simultanées dans une seule table Hudi. De plus, Hudi annule toutes les modifications effectuées par les enregistreurs en cours avant de permettre à un nouvel enregistreur de démarrer. Les écritures simultanées peuvent interférer avec ce mécanisme et introduire des conditions de concurrence, ce qui peut entraîner une corruption des données. Vous devez vous assurer que, dans le cadre de votre flux de traitement des données, il n'y a qu'un seul enregistreur Hudi opérant sur une table Hudi à tout moment. Hudi prend en charge plusieurs lecteurs simultanés opérant sur la même table Hudi.
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
+ Il y a un problème dans Amazon EMR 6.1.0 qui affecte les clusters exécutant Presto. Après une période prolongée (plusieurs jours), le cluster peut générer des erreurs telles que "su : failed to execute /bin/bash : Resource temporarily unavailable" ou "shell request failed on channel 0". Ce problème est dû à un processus interne Amazon EMR (InstanceController) qui génère trop de processus légers (LWP), ce qui finit par amener l'utilisateur Hadoop à dépasser sa limite nproc. Cela empêche l'utilisateur d'ouvrir des processus supplémentaires. La solution à ce problème est de mettre à niveau vers EMR 6.2.0.
## Version 6.0.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 6.0.0.
Date de parution initiale : 10 mars 2020
**Applications prises en charge**
+ AWS SDK pour Java version 1.11.711
+ Ganglia version 3.7.2
+ Hadoop version 3.2.1
+ HBase version 2.2.3
+ HCatalog version 3.1.2
+ Hive version 3.1.2
+ Hudi version 0.5.0-incubation
+ Hue version 4.4.0
+ JupyterHub version 1.0.0
+ Livy version 0.6.0
+ MXNet version 1.5.1
+ Oozie version 5.1.0
+ Phoenix version 5.0.0
+ Presto version 0.230
+ Spark version 2.4.4
+ TensorFlow version 1.14.0
+ Zeppelin version 0.9.0-SNAPSHOT
+ Zookeeper version 3.4.14
+ Connecteurs et pilotes : Connecteur DynamoDB 4.14.0
**Note**
Flink, Sqoop, Pig et Mahout ne sont pas disponibles dans Amazon EMR version 6.0.0.
**Nouvelles fonctionnalités**
+ Prise en charge de l'exécution de Docker pour YARN - Les applications YARN, telles que les tâches Spark, peuvent désormais s'exécuter dans le contexte d'un conteneur Docker. Vous pouvez ainsi définir facilement des dépendances dans une image Docker sans avoir besoin d'installer des bibliothèques personnalisées sur votre cluster Amazon EMR. Pour plus d'informations, consultez [Configuration de l'intégration Docker](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-docker.html) et [Exécution des applications Spark avec Docker à l'aide d'Amazon EMR version 6.0.0](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-docker.html).
+ Prise en charge de LLAP pour Hive - Hive prend désormais en charge le mode d'exécution LLAP pour améliorer les performances des requêtes. Pour de plus amples informations, veuillez consulter [Utilisation de LLAP pour Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-llap.html).
**Modifications, améliorations et problèmes résolus**
+ Cette version vise à résoudre les problèmes liés à Amazon EMR Scaling lorsqu'elle ne parvient pas à up/scale réduire correctement un cluster ou entraîne des défaillances d'applications.
+ Correction d'un problème où les demandes de mise à l'échelle échouaient pour un grand cluster très utilisé lorsque les démons Amazon EMR sur le cluster exécutaient des activités de surveillance de l'état, telles que la collecte de l'état des nœuds YARN et de l'état des nœuds HDFS. Cela était dû au fait que les démons du cluster n'étaient pas en mesure de communiquer les données d'état d'un nœud aux composants internes d'Amazon EMR.
+ Démons EMR intégrés au cluster améliorés pour suivre correctement l'état des nœuds lorsque les adresses IP sont réutilisées afin d'améliorer la fiabilité lors des opérations de mise à l'échelle.
+ [SPARK-29683](https://issues.apache.org/jira/browse/SPARK-29683). Correction d'un problème où les tâches échouaient lors de la réduction de la taille du cluster, car Spark supposait que tous les nœuds disponibles étaient sur la liste de refus.
+ [YARN-9011](https://issues.apache.org/jira/browse/YARN-9011). Correction d'un problème où des échecs de tâches se produisaient en raison d'une condition de course dans la mise hors service de YARN lorsque le cluster essayait d'augmenter ou de réduire sa capacité.
+ Correction du problème des échecs d'étapes ou de tâches lors de la mise à l'échelle du cluster en veillant à ce que les états des nœuds soient toujours cohérents entre les démons Amazon EMR sur le cluster et YARN/HDFS.
+ Correction d'un problème où les opérations de cluster telles que la réduction d'échelle et la soumission d'étapes échouaient pour les clusters Amazon EMR activés avec l'authentification Kerberos. Cela s'explique par le fait que le démon Amazon EMR intégré au cluster n'a pas renouvelé le ticket Kerberos, qui est nécessaire pour communiquer en toute sécurité avec HDFS/YARN l'exécution sur le nœud principal.
+ Les nouvelles versions d'Amazon EMR corrigent le problème en abaissant la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions d' AL2 Amazon EMR. Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent désormais un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé.
+ Amazon Linux
+ Amazon Linux 2 est le système d'exploitation de la série EMR version 6.x.
+ `systemd` est utilisé pour la gestion des services au lieu d'`upstart`, utilisé dans Amazon Linux 1.
+ Kit de développement Java (JDK)
+ Corretto JDK 8 est le JDK par défaut pour la série EMR version 6.x.
+ Scala
+ Scala 2.12 est utilisé avec Apache Spark et Apache Livy.
+ Python 3
+ Python 3 est maintenant la version par défaut de Python dans EMR.
+ Étiquettes de nœud YARN
+ À partir de la série Amazon EMR version 6.x, la fonction des étiquettes de nœud YARN est désactivée par défaut. Les processus principaux des applications peuvent s'exécuter à la fois sur les nœuds de noyau et sur les nœuds de tâche par défaut. Vous pouvez activer la fonction des étiquettes de nœud YARN en configurant les propriétés suivantes : `yarn.node-labels.enabled` et `yarn.node-labels.am.default-node-label-expression`. Pour plus d'informations, consultez [Comprendre les nœuds primaires, les nœuds principaux et les nœuds de tâches](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html).
**Problèmes connus**
+ **Réduction de la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions AL2 [corrigée dans les nouvelles versions].** Versions Amazon EMR : emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 et emr-6.2.0 sont basées sur les anciennes versions d'Amazon Linux 2 (), qui ont un paramètre ulimit inférieur pour le « Nombre maximum de fichiers ouverts » lorsque les clusters Amazon EMR sont créés avec l'AMI par défaut. AL2 Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé. Les versions dont la limite de fichiers ouverts est inférieure provoquent l'erreur « Trop de fichiers ouverts » lors de la soumission d'une tâche Spark. Dans les versions concernées, l'AMI par défaut Amazon EMR possède un paramètre ulimit par défaut de 4096 pour le « Nombre maximum de fichiers ouverts », ce qui est inférieur à la limite de fichiers de 65536 de la dernière AMI Amazon Linux 2. Le paramètre ulimit inférieur pour « Nombre maximum de fichiers ouverts » entraîne l'échec de la tâche Spark lorsque le pilote et l'exécuteur Spark tentent d'ouvrir plus de 4 096 fichiers. Pour résoudre ce problème, Amazon EMR dispose d'un script d'action d'amorçage (BA, bootstrap action) qui ajuste le paramètre ulimit lors de la création du cluster.
Si vous utilisez une ancienne version d'Amazon EMR qui ne contient pas de solution permanente à ce problème, la solution suivante vous permet de définir explicitement le paramètre ulimit du contrôleur d'instance sur un maximum de 65536 fichiers.
**Définir explicitement un ulimit à partir de la ligne de commande**
1. Modifiez `/etc/systemd/system/instance-controller.service` pour ajouter les paramètres suivants à la section Service.
`LimitNOFILE=65536`
`LimitNPROC=65536`
1. Redémarrer InstanceController
`$ sudo systemctl daemon-reload`
`$ sudo systemctl restart instance-controller`
**Définissez un ulimit à l'aide de l'action d'amorçage (BA)**
Vous pouvez également utiliser un script d'action d'amorçage (BA) pour configurer ulimit du contrôleur d'instance à 65536 fichiers lors de la création du cluster.
```
#!/bin/bash
for user in hadoop spark hive; do
sudo tee /etc/security/limits.d/$user.conf << EOF
$user - nofile 65536
$user - nproc 65536
EOF
done
for proc in instancecontroller logpusher; do
sudo mkdir -p /etc/systemd/system/$proc.service.d/
sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
[Service]
LimitNOFILE=65536
LimitNPROC=65536
EOF
pid=$(pgrep -f aws157.$proc.Main)
sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
done
sudo systemctl daemon-reload
```
+ Le shell interactif Spark PySpark, y compris SparkR et spark-shell, ne prend pas en charge l'utilisation de Docker avec des bibliothèques supplémentaires.
+ Pour utiliser Python 3 avec Amazon EMR version 6.0.0, vous devez ajouter `PATH` à `yarn.nodemanager.env-whitelist`.
+ La fonctionnalité Live Long and Process (LLAP) n'est pas prise en charge lorsque vous utilisez le catalogue de données AWS Glue comme métastore pour Hive.
+ Lorsque vous utilisez Amazon EMR 6.0.0 avec l'intégration Spark et Docker, vous devez configurer les instances de votre cluster avec le même type d'instance et la même quantité de volumes EBS pour éviter les échecs lors de la soumission d'une tâche Spark avec l'exécution Docker.
+ Dans Amazon EMR 6.0.0, le mode de stockage Amazon HBase S3 est impacté par le problème [HBASE-24286](https://issues.apache.org/jira/browse/HBASE-24286). HBase master ne peut pas s'initialiser lorsque le cluster est créé à l'aide de données S3 existantes.
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.30.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.30.1. Les modifications ont été apportées à la version 5.30.0.
Date de parution initiale : 30 juin 2020
Dernière mise à jour : 24 août 2020
**Modifications, améliorations et problèmes résolus**
+ Les nouvelles versions d'Amazon EMR corrigent le problème en abaissant la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions d' AL2 Amazon EMR. Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent désormais un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé.
+ Correction d'un problème à cause duquel le processus du contrôleur d'instance générait un nombre infini de processus.
+ Correction d'un problème où Hue ne parvenait pas à exécuter une requête Hive, affichant un message « la base de données est verrouillée » et empêchant l'exécution des requêtes.
+ Correction d'un problème lié à Spark qui permettait à un plus grand nombre de tâches de s'exécuter simultanément sur le cluster EMR.
+ Correction d'un problème de bloc-notes Jupyter provoquant une erreur « trop de fichiers ouverts » dans le serveur Jupyter.
+ Correction d'un problème lié aux temps de démarrage des clusters.
**Nouvelles fonctionnalités**
+ Les interfaces d'application persistantes Tez UI et YARN timeline server sont disponibles avec les versions 6.x d'Amazon EMR et les versions 5.30.1 et ultérieures d'EMR. L'accès par lien en un clic à l'historique des applications persistantes vous permet d'accéder rapidement à l'historique des tâches sans avoir à configurer un proxy web par le biais d'une connexion SSH. Les journaux des clusters actifs et résiliés sont disponibles pendant 30 jours après la fin de l'application. Pour plus d'informations, consultez [Affichage des interfaces utilisateur des applications persistantes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html) dans le *Guide de gestion Amazon EMR*.
+ L'exécution de blocs-notes EMR est disponible pour exécuter APIs des blocs-notes EMR via un script ou une ligne de commande. La possibilité de démarrer, d'arrêter, de répertorier et de décrire les exécutions d'un bloc-notes EMR sans la AWS console vous permet de contrôler un bloc-notes EMR par programme. À l'aide d'une cellule de bloc-notes paramétrée, vous pouvez transmettre différentes valeurs de paramètres à un bloc-notes sans avoir à créer une copie du bloc-notes pour chaque nouvel ensemble de valeurs de paramètres. Consultez [Actions d'API EMR.](https://docs.aws.amazon.com/emr/latest/APIReference/API_Operations.html) Pour un exemple de code, consultez [Exemples de commandes pour l'exécution de blocs-notes EMR par programmation.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-headless.html)
**Problèmes connus**
+ **Réduction de la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions AL2 [corrigée dans les nouvelles versions].** Versions Amazon EMR : emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 et emr-6.2.0 sont basées sur les anciennes versions d'Amazon Linux 2 (), qui ont un paramètre ulimit inférieur pour le « Nombre maximum de fichiers ouverts » lorsque les clusters Amazon EMR sont créés avec l'AMI par défaut. AL2 Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé. Les versions dont la limite de fichiers ouverts est inférieure provoquent l'erreur « Trop de fichiers ouverts » lors de la soumission d'une tâche Spark. Dans les versions concernées, l'AMI par défaut Amazon EMR possède un paramètre ulimit par défaut de 4096 pour le « Nombre maximum de fichiers ouverts », ce qui est inférieur à la limite de fichiers de 65536 de la dernière AMI Amazon Linux 2. Le paramètre ulimit inférieur pour « Nombre maximum de fichiers ouverts » entraîne l'échec de la tâche Spark lorsque le pilote et l'exécuteur Spark tentent d'ouvrir plus de 4 096 fichiers. Pour résoudre ce problème, Amazon EMR dispose d'un script d'action d'amorçage (BA, bootstrap action) qui ajuste le paramètre ulimit lors de la création du cluster.
Si vous utilisez une ancienne version d'Amazon EMR qui ne contient pas de solution permanente à ce problème, la solution suivante vous permet de définir explicitement le paramètre ulimit du contrôleur d'instance sur un maximum de 65536 fichiers.
**Définir explicitement un ulimit à partir de la ligne de commande**
1. Modifiez `/etc/systemd/system/instance-controller.service` pour ajouter les paramètres suivants à la section Service.
`LimitNOFILE=65536`
`LimitNPROC=65536`
1. Redémarrer InstanceController
`$ sudo systemctl daemon-reload`
`$ sudo systemctl restart instance-controller`
**Définissez un ulimit à l'aide de l'action d'amorçage (BA)**
Vous pouvez également utiliser un script d'action d'amorçage (BA) pour configurer ulimit du contrôleur d'instance à 65536 fichiers lors de la création du cluster.
```
#!/bin/bash
for user in hadoop spark hive; do
sudo tee /etc/security/limits.d/$user.conf << EOF
$user - nofile 65536
$user - nproc 65536
EOF
done
for proc in instancecontroller logpusher; do
sudo mkdir -p /etc/systemd/system/$proc.service.d/
sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
[Service]
LimitNOFILE=65536
LimitNPROC=65536
EOF
pid=$(pgrep -f aws157.$proc.Main)
sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
done
sudo systemctl daemon-reload
```
+ **Blocs-notes EMR**
La fonctionnalité qui permet d'installer des noyaux et des bibliothèques Python supplémentaires sur le nœud primaire du cluster est désactivée par défaut dans la version EMR 5.30.1. Pour plus d'informations sur cette fonctionnalité, consultez [Installation de noyaux et de bibliothèques Python sur un nœud primaire de cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-installing-libraries-and-kernels.html).
Pour activer cette fonctionnalité, procédez comme suit :
1. Assurez-vous que la politique d'autorisations attachée à la fonction du service pour les blocs-notes EMR autorise l'action suivante :
`elasticmapreduce:ListSteps`
Pour plus d'informations, consultez [Rôle de service pour les bloc-notes EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-service-role.html).
1. Utilisez le AWS CLI pour exécuter une étape sur le cluster qui configure les Notebooks EMR, comme indiqué dans l'exemple suivant. Remplacez *us-east-1* par la région dans laquelle réside votre cluster. Pour plus d'informations sur l'ajout d'étapes, consultez la rubrique [Ajout d'étapes à un cluster à l'aide de la AWS CLI](https://docs.aws.amazon.com/emr/latest/ManagementGuide/add-step-cli.html).
```
aws emr add-steps --cluster-id MyClusterID --steps Type=CUSTOM_JAR,Name=EMRNotebooksSetup,ActionOnFailure=CONTINUE,Jar=s3://us-east-1.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://awssupportdatasvcs.com/bootstrap-actions/EMRNotebooksSetup/emr-notebooks-setup.sh"]
```
+ **Mise à l'échelle gérée**
Les opérations de mise à l'échelle gérées sur des clusters 5.30.0 et 5.30.1 sans Presto installé peuvent provoquer des défaillances d'applications ou empêcher le maintien d'un groupe d'instances ou d'une flotte d'instances uniforme dans l'état `ARRESTED`, en particulier lorsqu'une opération de réduction est rapidement suivie d'une opération d'augementation.
Pour contourner le problème, choisissez Presto comme application à installer lorsque vous créez un cluster avec les versions 5.30.0 et 5.30.1 d'Amazon EMR, même si votre travail ne nécessite pas Presto.
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 5.30.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.30.0. Les modifications ont été apportées à la version 5.29.0.
Date de parution initiale : 13 mai 2020
Date de la dernière mise à jour : 25 juin 2020
**Mises à niveau**
+ Mise à niveau AWS SDK pour Java vers la version 1.11.759
+ Mise à niveau du SDK Amazon SageMaker Spark vers la version 1.3.0
+ Mise à niveau du serveur d'enregistrement EMR vers la version 1.6.0
+ Mise à niveau de Flink vers la version 1.10.0
+ Mise à niveau de Ganglia vers la version 3.7.2
+ Mise à niveau HBase vers la version 1.4.13
+ Mise à niveau de Hudi vers la version 0.5.2 incubating
+ Mise à niveau de Hue vers la version 4.6.0
+ Mise à niveau JupyterHub vers la version 1.1.0
+ Mise à niveau de Livy vers la version 0.7.0-incubating
+ Mise à niveau d'Oozie vers la version 5.2.0
+ Mise à niveau de Presto vers la version 0.232
+ Mise à niveau de Spark vers la version 2.4.5
+ Connecteurs et pilotes mis à niveau : Amazon Glue Connector 1.12.0 ; Amazon Kinesis Connector 3.5.0 ; EMR DynamoDB Connector 4.14.0
**Nouvelles fonctionnalités**
+ **Blocs-notes EMR** – Lorsqu'ils sont utilisés avec des clusters EMR créés à l'aide de la version 5.30.0, les noyaux du bloc-notes EMR s'exécutent sur un cluster. Cela améliore les performances des blocs-notes et vous permet d'installer et de personnaliser les noyaux. Vous pouvez également installer des bibliothèques Python sur le nœud primaire du cluster. Pour plus d'informations, consultez [Installation et utilisation des noyaux et des bibliothèques](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-managed-notebooks-installing-libraries-and-kernels.html) dans le *Manuel de gestion EMR *.
+ **Dimensionnement géré** – Avec les versions 5.30.0 et ultérieures d'Amazon EMR, vous pouvez activer le dimensionnement géré par EMR pour augmenter ou diminuer automatiquement le nombre d'instances ou d'unités dans votre cluster en fonction de la charge de travail. Amazon EMR évalue en permanence les métriques de cluster pour prendre des décisions de dimensionnement qui optimisent vos clusters en termes de coût et de vitesse. Pour plus d'informations, consultez [Mise à l'échelle des ressources de cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-scale-on-demand.html) dans le *Guide de gestion Amazon EMR*.
+ **Chiffrer les fichiers journaux stockés dans Amazon S3** : avec Amazon EMR version 5.30.0 et versions ultérieures, vous pouvez chiffrer les fichiers journaux stockés dans Amazon S3 à l'aide d'une clé gérée par le client. AWS KMS Pour plus d'informations, consultez [Chiffrer les fichiers journaux stockés dans Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-debugging.html#emr-log-encryption) dans le *Guide de gestion Amazon EMR*.
+ **Prise en charge d'Amazon Linux 2** – Les versions 5.30.0 et ultérieures d'EMR utilisent le système d'exploitation Amazon Linux 2. La nouvelle personnalisation AMIs (Amazon Machine Image) doit être basée sur l'AMI Amazon Linux 2. Pour en savoir plus, consultez [Utilisation d'une image AMI personnalisée](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html).
+ **Dimensionnement automatique gracieux Presto** – Les clusters EMR utilisant la version 5.30.0 peuvent inclure un délai d'attente de dimensionnement automatique qui donne aux tâches Presto le temps s'exécuter complètement avant que leur nœud ne soit hors-service. Pour de plus amples informations, veuillez consulter [Utilisation du dimensionnement automatique de Presto avec désaffectation gracieuse](presto-graceful-autoscale.md).
+ **Création d'une instance de flotte avec une nouvelle option de stratégie d'allocation** – Une nouvelle option de stratégie d'allocation est disponible dans les versions 5.12.1 et ultérieures d'EMR. Cela permet un approvisionnement plus rapide des clusters, une allocation plus précise et moins d'interruptions d'instances Spot. Des mises à jour des rôles de service EMR autres que ceux par défaut sont requises. Consultez [Configuration de parcs d'instances](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html).
+ **Commandes sudo systemctl stop et sudo systemctl start** – Dans les versions 5.30.0 et ultérieures d'EMR, qui utilisent le système d'exploitation Amazon Linux 2, EMR utilise les commandes `sudo systemctl stop` et `sudo systemctl start` pour redémarrer les services. Pour plus d'informations, consultez [Comment redémarrer un service dans Amazon EMR ?](https://aws.amazon.com/premiumsupport/knowledge-center/restart-service-emr/).
**Modifications, améliorations et problèmes résolus**
+ EMR version 5.30.0 n'installe pas Ganglia par défaut. Lorsque vous créez un cluster, vous pouvez sélectionner expressément l’installation de Ganglia.
+ Optimisation des performances Spark.
+ Optimisation des performances Presto.
+ Python 3 est la version par défaut pour Amazon EMR version 5.30.0 et versions ultérieures.
+ Le groupe de sécurité géré par défaut pour l'accès au service dans les sous-réseaux privés a été mis à jour avec de nouvelles règles. Si vous utilisez un groupe de sécurité personnalisé pour accéder au service, vous devez inclure les mêmes règles que le groupe de sécurité géré par défaut. Pour plus d'informations, consultez [Groupe de sécurité géré par Amazon EMR pour l'accès au service (sous-réseaux privés)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-sa-private). Si vous utilisez un rôle de service personnalisé pour Amazon EMR, vous devez accorder l'autorisation aux `ec2:describeSecurityGroups` pour permettre à EMR de confirmer que les groupes de sécurité sont correctement créés. Si vous utilisez le `EMR_DefaultRole`, cette autorisation est déjà incluse dans la stratégie gérée par défaut.
**Problèmes connus**
+ **Réduction de la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions AL2 [corrigée dans les nouvelles versions].** Versions Amazon EMR : emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 et emr-6.2.0 sont basées sur les anciennes versions d'Amazon Linux 2 (), qui ont un paramètre ulimit inférieur pour le « Nombre maximum de fichiers ouverts » lorsque les clusters Amazon EMR sont créés avec l'AMI par défaut. AL2 Les versions 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 et versions ultérieures d'Amazon EMR incluent un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé. Les versions dont la limite de fichiers ouverts est inférieure provoquent l'erreur « Trop de fichiers ouverts » lors de la soumission d'une tâche Spark. Dans les versions concernées, l'AMI par défaut Amazon EMR possède un paramètre ulimit par défaut de 4096 pour le « Nombre maximum de fichiers ouverts », ce qui est inférieur à la limite de fichiers de 65536 de la dernière AMI Amazon Linux 2. Le paramètre ulimit inférieur pour « Nombre maximum de fichiers ouverts » entraîne l'échec de la tâche Spark lorsque le pilote et l'exécuteur Spark tentent d'ouvrir plus de 4 096 fichiers. Pour résoudre ce problème, Amazon EMR dispose d'un script d'action d'amorçage (BA, bootstrap action) qui ajuste le paramètre ulimit lors de la création du cluster.
Si vous utilisez une ancienne version d'Amazon EMR qui ne contient pas de solution permanente à ce problème, la solution suivante vous permet de définir explicitement le paramètre ulimit du contrôleur d'instance sur un maximum de 65536 fichiers.
**Définir explicitement un ulimit à partir de la ligne de commande**
1. Modifiez `/etc/systemd/system/instance-controller.service` pour ajouter les paramètres suivants à la section Service.
`LimitNOFILE=65536`
`LimitNPROC=65536`
1. Redémarrer InstanceController
`$ sudo systemctl daemon-reload`
`$ sudo systemctl restart instance-controller`
**Définissez un ulimit à l'aide de l'action d'amorçage (BA)**
Vous pouvez également utiliser un script d'action d'amorçage (BA) pour configurer ulimit du contrôleur d'instance à 65536 fichiers lors de la création du cluster.
```
#!/bin/bash
for user in hadoop spark hive; do
sudo tee /etc/security/limits.d/$user.conf << EOF
$user - nofile 65536
$user - nproc 65536
EOF
done
for proc in instancecontroller logpusher; do
sudo mkdir -p /etc/systemd/system/$proc.service.d/
sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
[Service]
LimitNOFILE=65536
LimitNPROC=65536
EOF
pid=$(pgrep -f aws157.$proc.Main)
sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
done
sudo systemctl daemon-reload
```
+ **Mise à l'échelle gérée**
Les opérations de mise à l'échelle gérées sur des clusters 5.30.0 et 5.30.1 sans Presto installé peuvent provoquer des défaillances d'applications ou empêcher le maintien d'un groupe d'instances ou d'une flotte d'instances uniforme dans l'état `ARRESTED`, en particulier lorsqu'une opération de réduction est rapidement suivie d'une opération d'augementation.
Pour contourner le problème, choisissez Presto comme application à installer lorsque vous créez un cluster avec les versions 5.30.0 et 5.30.1 d'Amazon EMR, même si votre travail ne nécessite pas Presto.
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
+ Le moteur de base de données par défaut pour Hue 4.6.0 est SQLite, ce qui pose des problèmes lorsque vous essayez d'utiliser Hue avec une base de données externe. Pour résoudre ce problème, définissez `engine` de votre configuration de classification `hue-ini` sur `mysql`. Ce problème a été résolu dans la version 5.30.1 d'Amazon EMR.
+ Lorsque vous utilisez Spark avec le formatage de l'emplacement de partition Hive pour lire des données dans Amazon S3, et que vous exécutez Spark sur les versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0 d'Amazon EMR, vous pouvez rencontrer un problème qui empêche votre cluster de lire correctement les données. Cela peut se produire si vos partitions présentent toutes les caractéristiques suivantes :
+ Deux partitions ou plus sont analysées à partir de la même table.
+ Au moins un chemin de répertoire de partition est un préfixe d'au moins un autre chemin de répertoire de partition, par exemple, `s3://bucket/table/p=a` est un préfixe de `s3://bucket/table/p=a b`.
+ Le premier caractère qui suit le préfixe dans le répertoire de l'autre partition a une valeur UTF-8 inférieure au caractère `/` (U\$1002F). Par exemple, le caractère d'espace (U\$10020) qui apparaît entre a et b dans `s3://bucket/table/p=a b` entre dans cette catégorie. Notez qu'il existe 14 autres caractères de non-contrôle : `!"#$%&‘()*+,-`. Pour plus d'informations, consultez [Table de codage UTF-8 et les caractères Unicode](https://www.utf8-chartable.de/).
Pour contourner ce problème, définissez la configuration `spark.sql.sources.fastS3PartitionDiscovery.enabled` sur `false` dans la classification `spark-defaults`.
## Version 5.29.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.29.0. Les modifications ont été apportées à la version 5.28.1.
Date de parution initiale : 17 janvier 2020
**Mises à niveau**
+ Mise à niveau AWS SDK pour Java vers la version 1.11.682
+ Mise à niveau de Hive vers la version 2.3.6
+ Mise à niveau de Flink vers la version 1.9.1
+ Mise à niveau d'EmrFS vers la version 2.38.0
+ Mise à niveau du connecteur DynamoDB d'EMR vers la version 4.13.0
**Modifications, améliorations et problèmes résolus**
+ Spark
+ Optimisation des performances Spark.
+ EMRFS
+ Mise à jour du guide de gestion avec les paramètres par défaut du fichier emrfs-site.xml pour un affichage cohérent.
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.28.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.28.1. Les modifications ont été apportées à la version 5.28.0.
Date de parution initiale : 10 janvier 2020
**Modifications, améliorations et problèmes résolus**
+ Spark
+ Correction des problèmes de compatibilité Spark.
+ CloudWatch Métriques
+ Correction de la publication d'Amazon CloudWatch Metrics sur un cluster EMR comportant plusieurs nœuds principaux.
+ Message de journal désactivé
+ Message de faux journal désactivé, « ...en utilisant l'ancienne version (<4.5.8) du client HTTP Apache ».
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.28.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.28.0. Les modifications ont été apportées à la version 5.27.0.
Date de parution initiale : 12 novembre 2019
**Mises à niveau**
+ Mise à niveau de Flink vers la version 1.9.0
+ Mise à niveau de Hive vers la version 2.3.6
+ Mise à niveau MXNet vers la version 1.5.1
+ Mise à niveau de Phoenix vers la version 4.14.3
+ Mise à niveau de Presto vers la version 0.227
+ Mise à niveau de Zeppelin vers la version 0.8.2
**Nouvelles fonctionnalités**
+ [Apache Hudi](https://hudi.apache.org/) est désormais disponible pour une installation via Amazon EMR lorsque vous créez un cluster. Pour de plus amples informations, veuillez consulter [Hudi](emr-hudi.md).
+ (25 novembre 2019) Vous pouvez maintenant choisir d'exécuter plusieurs étapes en parallèle pour améliorer l'utilisation du cluster et faire des économies. Vous pouvez également annuler à la fois les étapes en attente et celles en cours d'exécution. Pour plus d'informations, voir [Travailler avec des étapes à l'aide de la console AWS CLI AND](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-work-with-steps.html).
+ (3 décembre 2019) Vous pouvez désormais créer et exécuter des clusters EMR sur. AWS Outposts AWS Outposts permet AWS des services, une infrastructure et des modèles d'exploitation natifs dans les installations sur site. Dans AWS Outposts les environnements, vous pouvez utiliser les mêmes AWS APIs outils et infrastructures que ceux que vous utilisez dans le AWS cloud. Pour plus d'informations, consultez la section [Clusters EMR sur. AWS Outposts](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-outposts.html)
+ (11 mars 2020) À partir de la version 5.28.0 d'Amazon EMR, vous pouvez créer et exécuter des clusters Amazon EMR sur un sous-réseau de zones AWS locales en tant qu'extension logique d'une région prenant en charge les zones locales. AWS Une zone locale permet aux fonctionnalités d'Amazon EMR et à un sous-ensemble de AWS services, tels que les services de calcul et de stockage, d'être situés plus près des utilisateurs, offrant ainsi un accès à très faible latence aux applications exécutées localement. Pour obtenir la liste des zones locales disponibles, consultez [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Pour plus d'informations sur l'accès aux zones AWS locales disponibles, voir [Régions, zones de disponibilité et zones locales](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
Les zones Locales ne sont actuellement pas compatibles avec Blocs-notes Amazon EMR et ne prennent pas en charge les connexions directes à Amazon EMR via le point de terminaison d'un VPC d'interface (AWS PrivateLink).
**Modifications, améliorations et problèmes résolus**
+ Prise en charge d'applications étendues pour des clusters à haute disponibilité
+ Pour plus d'informations, consultez [Applications prises en charge dans un cluster EMR avec plusieurs nœuds primaires](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html#emr-plan-ha-applications-list) dans le *Guide de gestion Amazon EMR*.
+ Spark
+ Optimisation des performances
+ Hive
+ Optimisation des performances
+ Presto
+ Optimisation des performances
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.27.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.27.0. Les modifications ont été apportées à la version 5.26.0.
Date de parution initiale : 23 septembre 2019
**Mises à niveau**
+ AWS SDK pour Java 1,1,615
+ Flink 1.8.1
+ JupyterHub 1.0.0
+ Spark 2.4.4
+ TensorFlow 1.14.0
+ Connecteurs et pilotes :
+ Connecteur DynamoDB 4.12.0
**Nouvelles fonctionnalités**
+ (24 octobre 2019) Les nouvelles fonctionnalités suivantes des blocs-notes EMR sont disponibles avec toutes les versions d'Amazon EMR.
+ Vous pouvez désormais associer des référentiels Git aux blocs-notes EMR pour stocker vos blocs-notes dans un environnement à version contrôlée. Vous pouvez partager du code avec vos pairs et réutiliser les blocs-notes Jupyter existants via des référentiels Git distants. Pour plus d'informations, consultez [Associer des référentiels Git à Blocs-notes EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-git-repo.html) dans le *Guide de gestion Amazon EMR*.
+ L'[utilitaire nbdime](https://github.com/jupyter/nbdime) est désormais disponible dans les blocs-notes EMR afin de simplifier la comparaison et la fusion des blocs-notes.
+ Les ordinateurs portables EMR sont désormais compatibles. JupyterLab JupyterLab est un environnement de développement interactif basé sur le Web entièrement compatible avec les ordinateurs portables Jupyter. Vous pouvez désormais choisir d'ouvrir votre bloc-notes dans l'éditeur de bloc-notes Jupyter JupyterLab ou dans l'éditeur de bloc-notes Jupyter.
+ (30 octobre 2019) Avec Amazon EMR versions 5.25.0 et ultérieures, vous pouvez vous connecter à l'interface utilisateur du serveur d'historique Spark à partir de la page **Récapitulatif** du cluster ou de l'onglet **Historique de l'application** dans la console. Au lieu de configurer un proxy Web par le biais d'une connexion SSH, vous pouvez accéder rapidement à l'interface utilisateur du serveur d'historique Spark pour consulter les métriques de l'application et accéder aux fichiers journaux pertinents pour les clusters actifs et résiliés. Pour plus d'informations, consultez [Accès hors cluster aux interfaces utilisateur d'application persistante](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html) dans le *Guide de gestion Amazon EMR*.
**Modifications, améliorations et problèmes résolus**
+ Cluster Amazon EMR avec plusieurs nœuds primaires
+ Vous pouvez installer et exécuter Flink sur un cluster Amazon EMR comportant plusieurs nœuds primaires. Pour plus d'informations, consultez [Applications et fonctionnalités prises en charge](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html).
+ Vous pouvez configurer le chiffrement transparent HDFS sur un cluster Amazon EMR comportant plusieurs nœuds primaires. Pour plus d'informations, consultez [Chiffrement transparent HDFS sur les clusters EMR comportant plusieurs nœuds primaires](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html#emr-hadoop-kms-multi-master).
+ Vous pouvez désormais modifier la configuration des applications exécutées sur un cluster Amazon EMR comportant plusieurs nœuds primaires. Pour plus d'informations, consultez [Fourniture d'une configuration pour un groupe d'instances dans un cluster en cours d'exécution](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).
+ Connecteur Amazon EMR-DynamoDB
+ Le connecteur Amazon EMR-DynamoDB prend désormais en charge les types de données DynamoDB suivants : boolean, list, map, item, null. Pour plus d'informations, consultez [Configuration d'une table Hive pour l'exécution de commandes Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/EMR_Interactive_Hive.html).
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.26.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.26.0. Les modifications ont été apportées à la version 5.25.0.
Date de parution initiale : 8 août 2019
Dernière mise à jour : 19 août 2019
**Mises à niveau**
+ AWS SDK pour Java 1,1595
+ HBase 1.4.10
+ Phoenix 4.14.2
+ Connecteurs et pilotes :
+ Connecteur DynamoDB 4.11.0
+ Connecteur MariaDB 2.4.2
+ Pilote JDBC Amazon Redshift version 1.2.32.1056
**Nouvelles fonctionnalités**
+ (Bêta) Avec Amazon EMR 5.26.0, vous pouvez lancer un cluster qui s'intègre à Lake Formation. Cette intégration fournit un accès détaillé au niveau des colonnes aux bases de données et aux tables du Glue AWS Data Catalog. Il permet également une authentification unique fédérée à Blocs-notes EMR ou Apache Zeppelin à partir d'un système d'identité d'entreprise. Pour plus d'informations, consultez [Intégrer Amazon EMR à AWS Lake Formation (version bêta)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lake-formation.html).
+ (19 août 2019) Bloquer l'accès public d'Amazon EMR est désormais disponible avec toutes les versions d'Amazon EMR qui prennent en charge les groupes de sécurité. Bloquer l'accès public est un paramètre applicable à l'ensemble du compte et appliqué à chaque AWS région. Bloquer l'accès public empêche le lancement d'un cluster lorsqu'un groupe de sécurité associé au cluster possède une règle autorisant le trafic entrant depuis IPv4 0.0.0.0/0 ou IPv6 : :/0 (accès public) sur un port, sauf si un port est spécifié comme exception. Le port 22 est une exception par défaut. Pour plus d'informations, consultez [Utilisation d'Amazon EMR Block Public Access](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-block-public-access.html) dans le *Guide de gestion Amazon EMR*.
**Modifications, améliorations et problèmes résolus**
+ Blocs-notes EMR
+ Avec EMR 5.26.0 et versions ultérieures, Blocs-notes EMR prend en charge les bibliothèques Python limitées aux blocs-notes en plus des bibliothèques Python par défaut. Vous pouvez installer des bibliothèques limitées au bloc-notes depuis l'éditeur de bloc-notes sans avoir à recréer un cluster ou à rattacher un bloc-notes à un cluster. Les bibliothèques limitées aux blocs-notes sont créées dans un environnement virtuel Python, de sorte qu'elles ne s'appliquent qu'à la session de bloc-notes en cours. Cela vous permet d'isoler les dépendances du bloc-notes. Pour plus d'informations, consultez [Utilisation de bibliothèques limitées aux blocs-notes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-custom-libraries-limitations.html) dans le *Guide de gestion Amazon EMR*.
+ EMRFS
+ Vous pouvez activer une fonctionnalité ETag de vérification (version bêta) en réglant `fs.s3.consistent.metadata.etag.verification.enabled` sur`true`. Grâce à cette fonctionnalité, EMRFS utilise Amazon 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 Amazon S3 sont remplacés tout en conservant le même nom. Cette fonctionnalité de ETag vérification ne fonctionne pas actuellement avec S3 Select. Pour plus d'informations, consultez [Configuration de la vue cohérente](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emrfs-configure-consistent-view.html).
+ Spark
+ Les optimisations suivantes sont désormais activées par défaut : élimination dynamique des partitions, DISTINCT avant INTERSECT, amélioration de l'inférence des statistiques de plan SQL pour les requêtes JOIN suivies de DISTINCT, aplatissement des sous-requêtes scalaires, réorganisation optimisée des jointures et jointure par filtre bloom. Pour plus d'informations, consultez [Optimisation des performances de Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-performance.html).
+ Génération de code améliorée pour l'ensemble de l'étape pour Sort Merge Join.
+ Amélioration de la réutilisation des fragments de requête et des sous-requêtes.
+ Améliorations apportées à la préallocation des exécuteurs au démarrage de Spark.
+ Les jointures par filtre bloom ne sont plus appliquées lorsque le côté le plus petit de la jointure inclut un indice de diffusion.
+ Tez
+ Un problème avec Tez a été résolu. L'interface utilisateur de Tez fonctionne désormais sur un cluster Amazon EMR avec plusieurs nœuds primaires.
**Problèmes connus**
+ Les fonctionnalités améliorées de génération de code pour l'ensemble de l'étape pour Sort Merge Join peuvent augmenter la sollicitation de la mémoire lorsqu'elles sont activées. Cette optimisation améliore les performances, mais peut entraîner de nouvelles tentatives de tâches ou des échecs si `spark.yarn.executor.memoryOverheadFactor` n'est pas réglé pour fournir suffisamment de mémoire. Pour désactiver cette fonctionnalité, définissez `spark.sql.sortMergeJoinExec.extendedCodegen.enabled` sur false.
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.25.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.25.0. Les modifications ont été apportées à la version 5.24.1.
Date de parution initiale : 17 juillet 2019
Dernière mise à jour : 30 octobre 2019
**Amazon EMR 5.25.0**
**Mises à niveau**
+ AWS SDK pour Java 1,1,566
+ Hive 2.3.5
+ Presto 0.220
+ Spark 2.4.3
+ TensorFlow 1.13.1
+ Tez 0.9.2
+ Zookeeper 3.4.14
**Nouvelles fonctionnalités**
+ (30 octobre 2019) À partir de la version 5.25.0 d'Amazon EMR, vous pouvez vous connecter à l'interface utilisateur du serveur d'historique Spark à partir de la page **Récapitulatif** du cluster ou de l'onglet **Historique de l'application** dans la console. Au lieu de configurer un proxy Web par le biais d'une connexion SSH, vous pouvez accéder rapidement à l'interface utilisateur du serveur d'historique Spark pour consulter les métriques de l'application et accéder aux fichiers journaux pertinents pour les clusters actifs et résiliés. Pour plus d'informations, consultez [Accès hors cluster aux interfaces utilisateur d'application persistante](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html) dans le *Guide de gestion Amazon EMR*.
**Modifications, améliorations et problèmes résolus**
+ Spark
+ Amélioration des performances de certaines jointures en utilisant des filtres Bloom pour préfiltrer les entrées. L'optimisation est désactivée par défaut et peut être activée en définissant le paramètre de configuration Spark `spark.sql.bloomFilterJoin.enabled` sur `true`.
+ Amélioration des performances du regroupement par colonnes de type chaîne.
+ Amélioration de la mémoire par défaut de l'exécuteur Spark et de la configuration des cœurs des types d'instances R4 pour les clusters non HBase installés.
+ Résolution d'un problème antérieur lié à la fonctionnalité d'élimination dynamique des partitions, où la table éliminée devait se trouver du côté gauche de la jointure.
+ Amélioration de l'optimisation DISTINCT avant INTERSECT pour l'appliquer à des cas supplémentaires impliquant des alias.
+ Amélioration de l'inférence des statistiques de plan SQL pour les requêtes JOIN suivies de DISTINCT. Cette amélioration est désactivée par défaut et peut être activée en définissant le paramètre de configuration Spark `spark.sql.statsImprovements.enabled` sur `true`. Cette optimisation est requise par la fonctionnalité Distinct avant Intersect et sera automatiquement activée lorsque `spark.sql.optimizer.distinctBeforeIntersect.enabled` est définie sur `true`.
+ Ordre de jointure optimisé en fonction de la taille de la table et des filtres. Cette optimisation est désactivée par défaut et peut être activée en définissant le paramètre de configuration Spark `spark.sql.optimizer.sizeBasedJoinReorder.enabled` sur `true`.
Pour plus d'informations, consultez [Optimisation des performances de Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-performance.html).
+ EMRFS
+ Le paramètre EMRFS, `fs.s3.buckets.create.enabled`, est désormais désactivé par défaut. Lors des tests, nous avons constaté que la désactivation de ce paramètre améliore les performances et empêche la création involontaire de compartiments S3. Si votre application repose sur cette fonctionnalité, vous pouvez l'activer en définissant la propriété `fs.s3.buckets.create.enabled` sur `true` dans la classification de configuration `emrfs-site`. Pour plus d'informations, consultez [Fourniture d'une configuration lors de la création d'un cluster](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-create-cluster.html).
+ Améliorations du chiffrement du disque local et du chiffrement S3 dans les configurations de sécurité (5 août 2019)
+ Les paramètres de chiffrement Amazon S3 ont été séparés des paramètres de chiffrement du disque local dans la configuration de la sécurité.
+ Ajout d'une option permettant d'activer le chiffrement EBS avec les versions 5.24.0 et ultérieures. La sélection de cette option chiffre le volume du périphérique racine en plus des volumes de stockage. Les versions précédentes nécessitaient l'utilisation d'une AMI personnalisée pour chiffrer le volume du périphérique racine.
+ Pour plus d'informations, consultez [Options de chiffrement](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html) dans le *Guide de gestion Amazon EMR*.
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.24.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.24.1. Les modifications ont été apportées à la version 5.24.0.
Date de parution initiale : 26 juin 2019
**Modifications, améliorations et problèmes résolus**
+ Mise à jour de l'AMI Amazon Linux par défaut pour Amazon EMR afin d'inclure d'importantes mises à jour de sécurité du noyau Linux, notamment le problème de déni de service TCP SACK ([AWS-2019-005](https://aws.amazon.com/security/security-bulletins/AWS-2019-005/)).
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.24.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.24.0. Les modifications ont été apportées à la version 5.23.0.
Date de parution initiale : 11 juin 2019
Dernière mise à jour : 5 août 2019
**Mises à niveau**
+ Flink 1.8.0
+ Hue 4.4.0
+ JupyterHub 0,9,6
+ Livy 0.6.0
+ MxNet 1.4.0
+ Presto 0.219
+ Spark 2.4.2
+ AWS SDK pour Java 1,1,546
+ Connecteurs et pilotes :
+ Connecteur DynamoDB 4.9.0
+ Connecteur MariaDB 2.4.1
+ Pilote JDBC Amazon Redshift version 1.2.27.1051
**Modifications, améliorations et problèmes résolus**
+ Spark
+ Ajout d'une optimisation pour éliminer dynamiquement les partitions. L'optimisation est désactivée par défaut. Pour l'activer, définissez le paramètre de configuration Spark `spark.sql.dynamicPartitionPruning.enabled` sur `true`.
+ Amélioration des performances des requêtes `INTERSECT`. L'optimisation est désactivée par défaut. Pour l'activer, définissez le paramètre de configuration Spark `spark.sql.optimizer.distinctBeforeIntersect.enabled` sur `true`.
+ Ajout d'une optimisation pour aplatir les sous-requêtes scalaires avec des agrégats qui utilisent la même relation. L'optimisation est désactivée par défaut. Pour l'activer, définissez le paramètre de configuration Spark `spark.sql.optimizer.flattenScalarSubqueriesWithAggregates.enabled` sur `true`.
+ Génération de code améliorée pour l'ensemble de l'étape.
Pour plus d'informations, consultez [Optimisation des performances de Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-performance.html).
+ Améliorations du chiffrement du disque local et du chiffrement S3 dans les configurations de sécurité (5 août 2019)
+ Les paramètres de chiffrement Amazon S3 ont été séparés des paramètres de chiffrement du disque local dans la configuration de la sécurité.
+ Ajout d'une option pour activer le chiffrement EBS. La sélection de cette option chiffre le volume du périphérique racine en plus des volumes de stockage. Les versions précédentes nécessitaient l'utilisation d'une AMI personnalisée pour chiffrer le volume du périphérique racine.
+ Pour plus d'informations, consultez [Options de chiffrement](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html) dans le *Guide de gestion Amazon EMR*.
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.23.0. Les modifications ont été apportées à la version 5.22.0.
Date de parution initiale : 1 avril 2019
Dernière mise à jour : 30 avril 2019
**Mises à niveau**
+ AWS SDK pour Java 1,1,519
**Nouvelles fonctionnalités**
+ (30 avril 2019) Avec Amazon EMR 5.23.0 et versions ultérieures, vous pouvez lancer un cluster avec trois nœuds principaux pour prendre en charge la haute disponibilité d'applications telles que YARN Resource Manager, HDFS, Spark NameNode, Hive et Ganglia. Le nœud primaire n'est plus un point de défaillance potentiel grâce à cette fonctionnalité. Si l'un des nœuds primaires tombe en panne, Amazon EMR passe automatiquement sur un nœud primaire de secours et remplace le nœud primaire défaillant par un nouveau nœud ayant la même configuration et les mêmes actions de démarrage. Pour plus d'informations, consultez [Planification et configuration des nœuds primaires](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha.html).
**Problèmes connus**
+ Interface utilisateur Tez (corrigée dans la version 5.26.0 d'Amazon EMR)
L'interface utilisateur de Tez ne fonctionne pas sur un cluster EMR comportant plusieurs nœuds primaires.
+ Hue (corrigée dans la version 5.24.0 d'Amazon EMR)
+ Hue exécuté sur Amazon EMR ne prend pas en charge Solr. À compter de la version 5.20.0 d'Amazon EMR, un problème de configuration incorrect entraîne l'activation de Solr et un message d'erreur inoffensif semblable au suivant s'affiche :
`Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))`
**Pour empêcher l'affichage du message d'erreur de Solr, procédez comme suit :**
1. Connectez-vous à la ligne de commande du nœud primaire à l'aide de SSH.
1. Utilisez un éditeur de texte pour ouvrir le fichier `hue.ini`. Par exemple :
`sudo vim /etc/hue/conf/hue.ini`
1. Recherchez le terme `appblacklist` et modifiez la ligne comme suit :
```
appblacklist = search
```
1. Enregistrez vos modifications et redémarrez Hue comme indiqué dans l'exemple suivant :
```
sudo stop hue; sudo start hue
```
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.22.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.22.0. Les modifications ont été apportées à la version 5.21.0.
**Important**
Depuis la version 5.22.0 d'Amazon EMR, Amazon EMR AWS utilise Signature version 4 exclusivement pour authentifier les demandes adressées à Amazon S3. Les versions antérieures d'Amazon EMR utilisent la version 2 de AWS Signature dans certains cas, sauf si les notes de publication indiquent que la version 4 de Signature est utilisée exclusivement. Pour plus d'informations, consultez les [sections Authentification des demandes (AWS Signature version 4)](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html) et [Authentification des demandes (AWS Signature version 2)](https://docs.aws.amazon.com/AmazonS3/latest/API/auth-request-sig-v2.html) dans le manuel *Amazon Simple Storage Service Developer Guide*.
Date de parution initiale : 20 mars 2019
**Mises à niveau**
+ Flink 1.7.1
+ HBase 1.4.9
+ Oozie 5.1.0
+ Phoenix 4.14.1
+ Zeppelin 0.8.1
+ Connecteurs et pilotes :
+ Connecteur DynamoDB 4.8.0
+ Connecteur MariaDB 2.2.6
+ Pilote JDBC Amazon Redshift version 1.2.20.1043
**Nouvelles fonctionnalités**
+ Modification de la configuration EBS par défaut pour les types d'instances EC2 avec stockage EBS uniquement. Lorsque vous créez un cluster à l'aide d'Amazon EMR version 5.22.0 et versions ultérieures, la quantité de stockage EBS par défaut augmente en fonction de la taille de l'instance. En outre, nous avons fractionné une plus grande quantité de stockage sur plusieurs volumes, afin d'offrir de meilleures performances en termes d'IOPS. Si vous voulez utiliser une autre configuration de stockage d'instance EBS, vous pouvez la spécifier lorsque vous créez un cluster EMR ou ajoutez des nœuds à un cluster existant. Pour plus d'informations sur la quantité de stockage et le nombre de volumes alloués par défaut pour chaque type d'instance, consultez [Stockage EBS par défaut pour les instances](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-storage.html#emr-plan-storage-ebs-storage-default) dans le *Guide de gestion Amazon EMR*.
**Modifications, améliorations et problèmes résolus**
+ Spark
+ Introduction d'une nouvelle propriété de configuration pour Spark sur YARN, `spark.yarn.executor.memoryOverheadFactor`. La valeur de cette propriété est un facteur d'échelle qui définit la valeur de la surcharge mémoire à un pourcentage de la mémoire de l'exécuteur, avec un minimum de 384 Mo. Si la surcharge mémoire est définie explicitement à l'aide `spark.yarn.executor.memoryOverhead`, cette propriété n'a aucun effet. La valeur par défaut est `0.1875`, ce qui représente 18,75 %. Cette valeur par défaut pour Amazon EMR laisse plus d'espace dans les conteneurs YARN pour la surcharge de mémoire de l'exécuteur que la valeur par défaut de 10 % définie en interne par Spark. La valeur par défaut d'Amazon EMR de 18,75 % a montré de façon empirique moins de défaillances liées à la mémoire dans les évaluations comparatives TPC-DS.
+ Rétroportage de [SPARK-26316](https://issues.apache.org/jira/browse/SPARK-26316) pour améliorer les performances.
+ Dans les versions 5.19.0, 5.20.0 et 5.21.0 d'Amazon EMR, les étiquettes des nœuds YARN sont stockées dans un répertoire HDFS. Dans certaines situations, cela entraîne des retards dans le démarrage des nœuds principaux, ce qui provoque le dépassement du délai du cluster et l'échec du lancement. À partir d'Amazon EMR 5.22.0, ce problème est résolu. Les étiquettes des nœuds YARN sont stockées sur le disque local de chaque nœud du cluster, évitant ainsi toute dépendance vis-à-vis du HDFS.
**Problèmes connus**
+ Hue (corrigée dans la version 5.24.0 d'Amazon EMR)
+ Hue exécuté sur Amazon EMR ne prend pas en charge Solr. À compter de la version 5.20.0 d'Amazon EMR, un problème de configuration incorrect entraîne l'activation de Solr et un message d'erreur inoffensif semblable au suivant s'affiche :
`Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))`
**Pour empêcher l'affichage du message d'erreur de Solr, procédez comme suit :**
1. Connectez-vous à la ligne de commande du nœud primaire à l'aide de SSH.
1. Utilisez un éditeur de texte pour ouvrir le fichier `hue.ini`. Par exemple :
`sudo vim /etc/hue/conf/hue.ini`
1. Recherchez le terme `appblacklist` et modifiez la ligne comme suit :
```
appblacklist = search
```
1. Enregistrez vos modifications et redémarrez Hue comme indiqué dans l'exemple suivant :
```
sudo stop hue; sudo start hue
```
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.21.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.21.1. Les modifications ont été apportées à la version 5.21.0.
Date de parution initiale : 18 juillet 2019
**Modifications, améliorations et problèmes résolus**
+ Mise à jour de l'AMI Amazon Linux par défaut pour Amazon EMR afin d'inclure d'importantes mises à jour de sécurité du noyau Linux, notamment le problème de déni de service TCP SACK ([AWS-2019-005](https://aws.amazon.com/security/security-bulletins/AWS-2019-005/)).
**Problèmes connus**
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.21.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.21.0. Les modifications ont été apportées à la version 5.20.0.
Date de parution initiale : 18 février 2019
Dernière mise à jour : 3 avril 2019
**Mises à niveau**
+ Flink 1.7.0
+ Presto 0.215
+ AWS SDK pour Java 1,11,479
**Nouvelles fonctionnalités**
+ (3 avril 2019) Avec la version 5.21.0 et ultérieures d'Amazon EMR, vous permet de remplacer les configurations de cluster et de spécifier des classifications de configuration supplémentaires pour chaque groupe d'instances dans un cluster en cours d'exécution. Pour ce faire, utilisez la console Amazon EMR, le AWS Command Line Interface (AWS CLI) ou le AWS SDK. Pour plus d'informations, consultez [Fourniture d'une configuration pour un groupe d'instances dans un cluster en cours d'exécution](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).
**Modifications, améliorations et problèmes résolus**
+ Zeppelin
+ Rétroportage de [ZEPPELIN-3878](https://issues.apache.org/jira/browse/ZEPPELIN-3878).
**Problèmes connus**
+ Hue (corrigée dans la version 5.24.0 d'Amazon EMR)
+ Hue exécuté sur Amazon EMR ne prend pas en charge Solr. À compter de la version 5.20.0 d'Amazon EMR, un problème de configuration incorrect entraîne l'activation de Solr et un message d'erreur inoffensif semblable au suivant s'affiche :
`Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))`
**Pour empêcher l'affichage du message d'erreur de Solr, procédez comme suit :**
1. Connectez-vous à la ligne de commande du nœud primaire à l'aide de SSH.
1. Utilisez un éditeur de texte pour ouvrir le fichier `hue.ini`. Par exemple :
`sudo vim /etc/hue/conf/hue.ini`
1. Recherchez le terme `appblacklist` et modifiez la ligne comme suit :
```
appblacklist = search
```
1. Enregistrez vos modifications et redémarrez Hue comme indiqué dans l'exemple suivant :
```
sudo stop hue; sudo start hue
```
+ Tez
+ Ce problème a été corrigé dans Amazon EMR 5.22.0.
Lorsque vous vous connectez à l'interface utilisateur de Tez à l'adresse http : //:8080/tez-ui *MasterDNS* via une connexion SSH au nœud principal du cluster, le message d'erreur « L'opération de l'adaptateur a échoué - Le serveur Timeline (ATS) est hors de portée. Soit il est en panne, soit CORS n'est pas activé » apparaît, ou les tâches affichent de manière inattendue « N/A ».
Cela est dû au fait que l'interface utilisateur de Tez envoie des demandes à YARN Timeline Server en utilisant `localhost` plutôt que le nom d'hôte du nœud primaire. Pour contourner le problème, un script est disponible pour être exécuté en tant qu'action ou étape d'amorçage. Le script met à jour le nom d'hôte dans le fichier Tez `configs.env`. Pour plus d'informations et pour connaître l'emplacement du script, consultez les [Instructions sur l'amorçage](http://awssupportdatasvcs.com/bootstrap-actions/fix_tez_ui_0-9-1/).
+ Dans les versions 5.19.0, 5.20.0 et 5.21.0 d'Amazon EMR, les étiquettes des nœuds YARN sont stockées dans un répertoire HDFS. Dans certaines situations, cela entraîne des retards dans le démarrage des nœuds principaux, ce qui provoque le dépassement du délai du cluster et l'échec du lancement. À partir d'Amazon EMR 5.22.0, ce problème est résolu. Les étiquettes des nœuds YARN sont stockées sur le disque local de chaque nœud du cluster, évitant ainsi toute dépendance vis-à-vis du HDFS.
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.20.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.20.0. Les modifications ont été apportées à la version 5.19.0.
Date de parution initiale : 18 décembre 2018
Dernière mise à jour : 22 janvier 2019
**Mises à niveau**
+ Flink 1.6.2
+ HBase 1.4.8
+ Hive 2.3.4
+ Hue 4.3.0
+ MXNet 1.3.1
+ Presto 0.214
+ Spark 2.4.0
+ TensorFlow 1,12,0
+ Tez 0.9.1
+ AWS SDK pour Java 1,11,461
**Nouvelles fonctionnalités**
+ (22 janvier 2019) Kerberos dans Amazon EMR a été amélioré pour prendre en charge l'authentification des principaux à partir d'un KDC externe. Cela permet de centraliser la gestion des principaux, car plusieurs clusters peuvent partager un seul KDC externe. De plus, le KDC externe peut avoir une relation d'approbation inter-domaines avec un domaine Active Directory. Cela permet à tous les clusters d'authentifier les mandataires à partir d'Active Directory. Pour plus d'informations, consultez [Utilisation de l'authentification Kerberos](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-kerberos.html) dans le *Guide de gestion Amazon EMR*.
**Modifications, améliorations et problèmes résolus**
+ AMI Amazon Linux par défaut pour Amazon EMR
+ Le package Python3 a été mis à jour de python 3.4 à 3.6.
+ Le valideur EMRFS optimisé pour S3
+ Le validateur EMRFS optimisé pour S3 est désormais activé par défaut, ce qui améliore les performances d'écriture. Pour de plus amples informations, veuillez consulter [Utilisation d'un valideur EMRFS optimisé pour S3](emr-spark-s3-optimized-committer.md).
+ Hive
+ Rétroportage de [HIVE-16686](https://issues.apache.org/jira/browse/HIVE-16686).
+ Glue avec Spark et Hive
+ Dans EMR 5.20.0 ou version ultérieure, l'élagage parallèle des partitions est activé automatiquement pour Spark et Hive lorsque AWS Glue Data Catalog est utilisé comme métastore. Cette modification réduit considérablement le temps de planification des requêtes en exécutant plusieurs requêtes en parallèle pour récupérer des partitions. Le nombre total de segments pouvant être exécutés simultanément est compris entre 1 et 10. La valeur par défaut est 5, ce qui est recommandé. Vous pouvez le modifier en spécifiant la propriété `aws.glue.partition.num.segments` dans la classification de configuration `hive-site`. En cas de limitation, vous pouvez désactiver la fonctionnalité en remplaçant la valeur par 1. Pour en savoir plus, consultez [Structure d'un segment AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-partitions.html#aws-glue-api-catalog-partitions-Segment).
**Problèmes connus**
+ Hue (corrigée dans la version 5.24.0 d'Amazon EMR)
+ Hue exécuté sur Amazon EMR ne prend pas en charge Solr. À compter de la version 5.20.0 d'Amazon EMR, un problème de configuration incorrect entraîne l'activation de Solr et un message d'erreur inoffensif semblable au suivant s'affiche :
`Solr server could not be contacted properly: HTTPConnectionPool('host=ip-xx-xx-xx-xx.ec2.internal', port=1978): Max retries exceeded with url: /solr/admin/info/system?user.name=hue&doAs=administrator&wt=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused',))`
**Pour empêcher l'affichage du message d'erreur de Solr, procédez comme suit :**
1. Connectez-vous à la ligne de commande du nœud primaire à l'aide de SSH.
1. Utilisez un éditeur de texte pour ouvrir le fichier `hue.ini`. Par exemple :
`sudo vim /etc/hue/conf/hue.ini`
1. Recherchez le terme `appblacklist` et modifiez la ligne comme suit :
```
appblacklist = search
```
1. Enregistrez vos modifications et redémarrez Hue comme indiqué dans l'exemple suivant :
```
sudo stop hue; sudo start hue
```
+ Tez
+ Ce problème a été corrigé dans Amazon EMR 5.22.0.
Lorsque vous vous connectez à l'interface utilisateur de Tez à l'adresse http : //:8080/tez-ui *MasterDNS* via une connexion SSH au nœud principal du cluster, le message d'erreur « L'opération de l'adaptateur a échoué - Le serveur Timeline (ATS) est hors de portée. Soit il est en panne, soit CORS n'est pas activé » apparaît, ou les tâches affichent de manière inattendue « N/A ».
Cela est dû au fait que l'interface utilisateur de Tez envoie des demandes à YARN Timeline Server en utilisant `localhost` plutôt que le nom d'hôte du nœud primaire. Pour contourner le problème, un script est disponible pour être exécuté en tant qu'action ou étape d'amorçage. Le script met à jour le nom d'hôte dans le fichier Tez `configs.env`. Pour plus d'informations et pour connaître l'emplacement du script, consultez les [Instructions sur l'amorçage](http://awssupportdatasvcs.com/bootstrap-actions/fix_tez_ui_0-9-1/).
+ Dans les versions 5.19.0, 5.20.0 et 5.21.0 d'Amazon EMR, les étiquettes des nœuds YARN sont stockées dans un répertoire HDFS. Dans certaines situations, cela entraîne des retards dans le démarrage des nœuds principaux, ce qui provoque le dépassement du délai du cluster et l'échec du lancement. À partir d'Amazon EMR 5.22.0, ce problème est résolu. Les étiquettes des nœuds YARN sont stockées sur le disque local de chaque nœud du cluster, évitant ainsi toute dépendance vis-à-vis du HDFS.
+ Problème connu dans les clusters dotés de plusieurs nœuds primaires et d'une authentification Kerberos
Si vous exécutez des clusters avec plusieurs nœuds primaires et une authentification Kerberos dans les versions 5.20.0 et ultérieures d'Amazon EMR, vous pouvez rencontrer des problèmes avec des opérations de cluster telles que la réduction d'échelle ou la soumission d'étapes, après que le cluster ait fonctionné pendant un certain temps. La durée dépend de la période de validité du ticket Kerberos que vous avez définie. Le problème de réduction d'échelle a un impact à la fois sur la réduction d'échelle automatique et sur les demandes de réduction d'échelle explicites que vous avez soumises. D'autres opérations de cluster peuvent également être affectées.
Solution :
+ SSH en tant qu'utilisateur `hadoop` au nœud primaire du cluster EMR avec plusieurs nœuds primaires.
+ Exécutez la commande suivante pour renouveler le ticket Kerberos pour l'utilisateur `hadoop`.
```
kinit -kt
```
Généralement, le fichier keytab se trouve dans `/etc/hadoop.keytab` et le principal se présente sous la forme de `hadoop/@`.
**Note**
Cette solution de contournement sera effective pendant toute la durée de validité du ticket Kerberos. Cette durée est de 10 heures par défaut, mais peut être configurée par vos paramètres Kerberos. Vous devez exécuter à nouveau la commande ci-dessus une fois le ticket Kerberos expiré.
## Version 5.19.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.19.0. Les modifications ont été apportées à la version 5.18.0.
Date de parution initiale : 7 novembre 2018
Date de la dernière mise à jour : 19 novembre 2018
**Mises à niveau**
+ Hadoop 2.8.5
+ Flink 1.6.1
+ JupyterHub 0,9.4
+ MXNet 1.3.0
+ Presto 0.212
+ TensorFlow 1,11,0
+ Zookeeper 3.4.13
+ AWS SDK pour Java 1,1,433
**Nouvelles fonctionnalités**
+ (19 novembre 2018) Blocs-notes EMR est un environnement géré basé sur le bloc-notes Jupyter. Il prend en charge les noyaux magiques Spark pour PySpark Spark SQL, Spark R et Scala. Blocs-notes EMR peut être utilisé avec des clusters créés à l'aide de la version 5.18.0 d'Amazon EMR ou d'une version ultérieure. Pour plus d'informations, consultez [Utilisation de Blocs-notes EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks.html) dans le *Guide de gestion d'Amazon EMR*.
+ Le validateur EMRFS optimisé pour S3 est disponible lors de l'écriture de fichiers Parquet avec Spark et EMRFS. Ce validateur améliore les performances d'écriture. Pour de plus amples informations, veuillez consulter [Utilisation d'un valideur EMRFS optimisé pour S3](emr-spark-s3-optimized-committer.md).
**Modifications, améliorations et problèmes résolus**
+ YARN
+ Modification de la logique qui limite le processus principal de l'application à l'exécution sur les nœuds principaux. Cette fonctionnalité utilise désormais la fonctionnalité et les propriétés des étiquettes de nœuds YARN dans les classifications de configuration `yarn-site` et `capacity-scheduler`. Pour plus d’informations, consultez [https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html#emr-plan-spot-YARN.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html#emr-plan-spot-YARN.)
+ AMI Amazon Linux par défaut pour Amazon EMR
+ `ruby18`, `php56` et `gcc48` ne sont plus installés par défaut. Ils peuvent être installés si vous le souhaitez à l'aide de `yum`.
+ Le gem ruby aws-sdk n'est plus installé par défaut. Il peut être installé en utilisant `gem install aws-sdk`, si vous le souhaitez. Des composants spécifiques peuvent également être installés. Par exemple, `gem install aws-sdk-s3`.
**Problèmes connus**
+ **Blocs-notes EMR** – Dans certains cas, lorsque plusieurs éditeurs de blocs-notes sont ouverts, l'éditeur de bloc-notes peut sembler incapable de se connecter au cluster. Dans ce cas, effacez les cookies du navigateur, puis rouvrez les éditeurs de bloc-notes.
+ **CloudWatch ContainerPending Mise à l'échelle métrique et automatique** — (Corrigé dans la version 5.20.0) Amazon EMR peut émettre une valeur négative pour. `ContainerPending` Si `ContainerPending` est utilisée dans une règle de mise à l'échelle automatique, la mise à l'échelle automatique ne se comporte pas comme prévu. Évitez d'utiliser `ContainerPending` avec la mise à l'échelle automatique.
+ Dans les versions 5.19.0, 5.20.0 et 5.21.0 d'Amazon EMR, les étiquettes des nœuds YARN sont stockées dans un répertoire HDFS. Dans certaines situations, cela entraîne des retards dans le démarrage des nœuds principaux, ce qui provoque le dépassement du délai du cluster et l'échec du lancement. À partir d'Amazon EMR 5.22.0, ce problème est résolu. Les étiquettes des nœuds YARN sont stockées sur le disque local de chaque nœud du cluster, évitant ainsi toute dépendance vis-à-vis du HDFS.
## Version 5.18.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.18.0. Les modifications ont été apportées à la version 5.17.0.
Date de parution initiale : 24 octobre 2018
**Mises à niveau**
+ Flink 1.6.0
+ HBase 1.4.7
+ Presto 0.210
+ Spark 2.3.2
+ Zeppelin 0.8.0
**Nouvelles fonctionnalités**
+ À partir d'Amazon EMR 5.18.0, vous pouvez utiliser le référentiel d'artefacts d'Amazon EMR pour générer le code de votre tâche en fonction des versions exactes des bibliothèques et des dépendances qui sont disponibles avec des versions spécifiques d'Amazon EMR. Pour de plus amples informations, veuillez consulter [Vérification des dépendances à l'aide du référentiel d'artefacts d'Amazon EMR](emr-artifact-repository.md).
**Modifications, améliorations et problèmes résolus**
+ Hive
+ Ajout de la prise en charge de S3 Select. Pour de plus amples informations, veuillez consulter [Utilisation de S3 Select avec Hive pour améliorer les performances](emr-hive-s3select.md).
+ Presto
+ Ajout de la prise en charge de [S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/) Pushdown. Pour de plus amples informations, veuillez consulter [Utilisation de S3 Select Pushdown avec Presto pour améliorer les performances](emr-presto-s3select.md).
+ Spark
+ La configuration par défaut de log4j pour Spark a été modifiée pour enregistrer les journaux des conteneurs toutes les heures pour les tâches de streaming Spark. Cela permet d'éviter la suppression des journaux pour les tâches de streaming Spark de longue durée.
## Version 5.17.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.17.1. Les modifications ont été apportées à la version 5.17.0.
Date de parution initiale : 18 juillet 2019
**Modifications, améliorations et problèmes résolus**
+ Mise à jour de l'AMI Amazon Linux par défaut pour Amazon EMR afin d'inclure d'importantes mises à jour de sécurité du noyau Linux, notamment le problème de déni de service TCP SACK ([AWS-2019-005](https://aws.amazon.com/security/security-bulletins/AWS-2019-005/)).
## Version 5.17.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.17.0. Les modifications ont été apportées à la version 5.16.0.
Date de parution initiale : 30 août 2018
**Mises à niveau**
+ Flink 1.5.2
+ HBase 1.4.6
+ Presto 0.206
**Nouvelles fonctionnalités**
+ Ajout de la prise en charge de Tensorflow. Pour de plus amples informations, veuillez consulter [TensorFlow](emr-tensorflow.md).
**Modifications, améliorations et problèmes résolus**
+ JupyterHub
+ Ajout de la prise en charge de la persistance des blocs-notes dans Amazon S3. Pour de plus amples informations, veuillez consulter [Configuration de la persistance pour les blocs-notes dans Amazon S3](emr-jupyterhub-s3.md).
+ Spark
+ Ajout de la prise en charge de [S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/). Pour de plus amples informations, veuillez consulter [Utilisation de S3 Select avec Spark pour améliorer les performances des requêtes](emr-spark-s3select.md).
+ Résolution des problèmes liés aux métriques Cloudwatch et à la fonctionnalité de mise à l'échelle automatique dans Amazon EMR version 5.14.0, 5.15.0 ou 5.16.0.
**Problèmes connus**
+ Lorsque vous créez un cluster activé pour Kerberos avec Livy installé, Livy échoue avec un message d'erreur indiquant que l'authentification simple n'est pas activée. Le redémarrage du serveur Livy résout le problème. Pour contourner le problème, ajoutez une étape lors de la création du cluster qui exécute `sudo restart livy-server` sur le nœud primaire.
+ Si vous utilisez une AMI Amazon Linux personnalisée basée sur une AMI Amazon Linux dont la date de création est le 11/08/2018, le serveur Oozie ne démarre pas. Si vous utilisez Oozie, créez une AMI personnalisée basée sur un ID d'AMI Amazon Linux avec une date de création différente. Vous pouvez utiliser la AWS CLI commande suivante pour renvoyer une liste d'images IDs pour tous les HVM Amazon Linux AMIs avec une version 2018.03, ainsi que la date de sortie, afin de pouvoir choisir une AMI Amazon Linux appropriée comme base. MyRegion Remplacez-le par l'identifiant de votre région, tel que us-west-2.
```
aws ec2 --region MyRegion describe-images --owner amazon --query 'Images[?Name!=`null`]|[?starts_with(Name, `amzn-ami-hvm-2018.03`) == `true`].[CreationDate,ImageId,Name]' --output text | sort -rk1
```
## Version 5.16.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.16.0. Les modifications ont été apportées à la version 5.15.0.
Date de parution initiale : 19 juillet 2018
**Mises à niveau**
+ Hadoop 2.8.4
+ Flink 1.5.0
+ Livy 0.5.0
+ MXNet 1.2.0
+ Phoenix 4.14.0
+ Presto 0.203
+ Spark 2.3.1
+ AWS SDK pour Java 1,1336
+ CUDA 9.2
+ Pilote JDBC Redshift 1.2.15.1025
**Modifications, améliorations et problèmes résolus**
+ HBase
+ Rétroportage de [HBASE-20723](https://issues.apache.org/jira/browse/HBASE-20723).
+ Presto
+ Modifications de configuration pour prendre en charge l'authentification LDAP. Pour de plus amples informations, veuillez consulter [Utilisation de l'authentification LDAP pour Presto sur Amazon EMR](emr-presto-ldap.md).
+ Spark
+ Apache Spark version 2.3.1, disponible à partir de la version 5.16.0 d'Amazon EMR, corrige [CVE-2018-8024](https://nvd.nist.gov/vuln/detail/CVE-2018-8024) et [CVE-2018-1334](https://nvd.nist.gov/vuln/detail/CVE-2018-1334). Nous vous recommandons de migrer les versions antérieures de Spark vers la version 2.3.1 ou ultérieure.
**Problèmes connus**
+ Cette version ne prend pas en charge les types d'instance c1.medium ou m1.small. Les clusters utilisant l'un ou l'autre de ces types d'instances ne démarrent pas. Pour contourner le problème, spécifiez un type d'instance différent ou utilisez une version différente.
+ Lorsque vous créez un cluster activé pour Kerberos avec Livy installé, Livy échoue avec un message d'erreur indiquant que l'authentification simple n'est pas activée. Le redémarrage du serveur Livy résout le problème. Pour contourner le problème, ajoutez une étape lors de la création du cluster qui exécute `sudo restart livy-server` sur le nœud primaire.
+ Après le redémarrage du nœud principal ou le redémarrage du contrôleur d'instance, les CloudWatch métriques ne seront pas collectées et la fonctionnalité de dimensionnement automatique ne sera pas disponible dans les versions 5.14.0, 5.15.0 ou 5.16.0 d'Amazon EMR. Ce problème est résolu dans Amazon EMR 5.17.0.
## Version 5.15.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.15.0. Les modifications ont été apportées à la version 5.14.0.
Date de parution initiale : 21 juin 2018
**Mises à niveau**
+ Mise à niveau HBase vers la version 1.4.4
+ Mise à niveau de Hive vers la version 2.3.3
+ Mise à niveau de Hue vers la version 4.2.0
+ Mise à niveau d'Oozie vers la version 5.0.0
+ Mise à niveau de Zookeeper vers la version 3.4.12
+ AWS SDK mis à jour vers la version 1.11.333
**Modifications, améliorations et problèmes résolus**
+ Hive
+ Rétroportage de [HIVE-18069](https://issues.apache.org/jira/browse/HIVE-18069).
+ Hue
+ Hue a été mis à jour pour s'authentifier correctement auprès de Livy lorsque Kerberos est activé. Livy est désormais pris en charge lors de l'utilisation de Kerberos avec Amazon EMR.
+ JupyterHub
+ Mis à jour JupyterHub afin qu'Amazon EMR installe les bibliothèques clientes LDAP par défaut.
+ Correction d'une erreur dans le script qui génère des certificats auto-signés.
**Problèmes connus**
+ Cette version ne prend pas en charge les types d'instance c1.medium ou m1.small. Les clusters utilisant l'un ou l'autre de ces types d'instances ne démarrent pas. Pour contourner le problème, spécifiez un type d'instance différent ou utilisez une version différente.
+ Après le redémarrage du nœud principal ou le redémarrage du contrôleur d'instance, les CloudWatch métriques ne seront pas collectées et la fonctionnalité de dimensionnement automatique ne sera pas disponible dans les versions 5.14.0, 5.15.0 ou 5.16.0 d'Amazon EMR. Ce problème est résolu dans Amazon EMR 5.17.0.
## Version 5.14.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.14.1. Les modifications ont été apportées à la version 5.14.0.
Date de parution initiale : 17 octobre 2018
Mise à jour de l'AMI par défaut pour Amazon EMR afin de corriger les vulnérabilités de sécurité potentielles.
## Version 5.14.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.14.0. Les modifications ont été apportées à la version 5.13.0.
Date de parution initiale : 4 juin 2018
**Mises à niveau**
+ Mise à niveau d'Apache Flink vers la version 1.4.2
+ Mise à niveau d'Apache MXnet vers la version 1.1.0
+ Mise à niveau d'Apache Sqoop vers la version 1.4.7
**Nouvelles fonctionnalités**
+ JupyterHub Support ajouté. Pour de plus amples informations, veuillez consulter [JupyterHub](emr-jupyterhub.md).
**Modifications, améliorations et problèmes résolus**
+ EMRFS
+ La chaîne userAgent dans les demandes adressées à Amazon S3 a été mise à jour pour contenir les informations relatives à l'utilisateur et au groupe du principal invoquant. Cela peut être utilisé avec AWS CloudTrail les journaux pour un suivi plus complet des demandes.
+ HBase
+ Inclusion de [HBASE-20447](https://issues.apache.org/jira/browse/HBASE-20447), qui corrige un problème qui pouvait causer des problèmes de cache, en particulier avec les régions divisées.
+ MXnet
+ Ajout des bibliothèques OpenCV.
+ Spark
+ Lorsque Spark écrit des fichiers Parquet sur un emplacement Amazon S3 à l'aide d'EMRFS, l' FileOutputCommitter algorithme a été mis à jour pour utiliser la version 2 au lieu de la version 1. Cela réduit le nombre de renommages, ce qui améliore les performances de l'application. Cette modification n'affecte pas :
+ Les applications autres que Spark.
+ Applications qui écrivent sur d'autres systèmes de fichiers, tels que HDFS (qui utilise toujours la version 1 de FileOutputCommitter).
+ Les applications utilisant d'autres formats de sortie, tels que le texte ou le csv, qui utilisent déjà l'écriture directe EMRFS.
**Problèmes connus**
+ JupyterHub
+ L'utilisation de classifications de configuration pour configurer JupyterHub des blocs-notes Jupyter individuels lors de la création d'un cluster n'est pas prise en charge. Modifiez manuellement le fichier jupyterhub\$1config.py et les fichiers jupyter\$1notebook\$1config.py pour chaque utilisateur. Pour de plus amples informations, veuillez consulter [Configuration JupyterHub](emr-jupyterhub-configure.md).
+ JupyterHub ne démarre pas sur des clusters au sein d'un sous-réseau privé, ce qui entraîne un échec du message`Error: ENOENT: no such file or directory, open '/etc/jupyter/conf/server.crt' `. Ce problème est dû à une erreur dans le script qui génère des certificats auto-signés. Utilisez la solution suivante pour générer des certificats auto-signés. Toutes les commandes sont exécutées lorsque vous êtes connecté au nœud primaire.
1. Copiez le script de génération de certificat du conteneur vers le nœud primaire :
```
sudo docker cp jupyterhub:/tmp/gen_self_signed_cert.sh ./
```
1. Utilisez un éditeur de texte pour modifier la ligne 23 afin de changer le nom d'hôte public en nom d'hôte local, comme indiqué ci-dessous :
```
local hostname=$(curl -s $EC2_METADATA_SERVICE_URI/local-hostname)
```
1. Exécutez le script pour générer des certificats auto-signés :
```
sudo bash ./gen_self_signed_cert.sh
```
1. Déplacez les fichiers de certificat générés par le script vers le répertoire `/etc/jupyter/conf/` :
```
sudo mv /tmp/server.crt /tmp/server.key /etc/jupyter/conf/
```
Vous pouvez vérifier que `tail` le `jupyter.log` fichier JupyterHub a redémarré et qu'il renvoie un code de réponse 200. Par exemple :
```
tail -f /var/log/jupyter/jupyter.log
```
Vous devriez obtenir une réponse similaire à la suivante :
```
# [I 2018-06-14 18:56:51.356 JupyterHub app:1581] JupyterHub is now running at https://:9443/
# 19:01:51.359 - info: [ConfigProxy] 200 GET /api/routes
```
+ Après le redémarrage du nœud principal ou le redémarrage du contrôleur d'instance, les CloudWatch métriques ne seront pas collectées et la fonctionnalité de dimensionnement automatique ne sera pas disponible dans les versions 5.14.0, 5.15.0 ou 5.16.0 d'Amazon EMR. Ce problème est résolu dans Amazon EMR 5.17.0.
## Version 5.13.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.13.0. Les modifications ont été apportées à la version 5.12.0.
**Mises à niveau**
+ Mise à niveau de Spark vers la version 2.3.0
+ Mise à niveau HBase vers la version 1.4.2
+ Mise à niveau vers de Presto vers la version 0.194
+ Mise à niveau AWS SDK pour Java vers la version 1.11.297
**Modifications, améliorations et problèmes résolus**
+ Hive
+ Rétroportage de [HIVE-15436](https://issues.apache.org/jira/browse/HIVE-15436). Hive améliorée pour ne APIs renvoyer que les vues.
**Problèmes connus**
+ MXNet ne possède actuellement pas de bibliothèques OpenCV.
## Version 5.12.2
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.12.2. Les modifications ont été apportées à la version 5.12.1.
Date de parution initiale : 29 août 2018
**Modifications, améliorations et problèmes résolus**
+ Cette version corrige une vulnérabilité de sécurité potentielle.
## Version 5.12.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.12.1. Les modifications ont été apportées à la version 5.12.0.
Date de parution initiale : 29 mars 2018
**Modifications, améliorations et problèmes résolus**
+ Mise à jour du noyau Amazon Linux de l'AMI Amazon Linux par défaut pour Amazon EMR afin de corriger les vulnérabilités potentielles.
## Version 5.12.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.12.0. Les modifications ont été apportées à la version 5.11.1.
**Mises à niveau**
+ AWS SDK pour Java 1.11.238 ⇒ 1.11.267. Pour plus d'informations, consultez le [AWS SDK for Java Change](https://github.com/aws/aws-sdk-java/blob/master/CHANGELOG.md) Log GitHub on.
+ Hadoop 2.7.3 ⇒ 2.8.3. Pour plus d'informations, consultez [Versions d'Apache Hadoop](http://hadoop.apache.org/releases.html).
+ Flink 1.3.2 ⇒ 1.4.0. Pour plus d'informations, consultez [Annonce de publication d'Apache Flink 1.4.0](https://flink.apache.org/news/2017/12/12/release-1.4.0.html).
+ HBase 1.3.1 ⇒ 1.4.0. Pour plus d'informations, consultez l'[annonce HBase de sortie](http://mail-archives.apache.org/mod_mbox/www-announce/201712.mbox/%3CCA+RK=_AU+tB=7SU1HRbeKVEd-sKA5WcJo3oa43vQ6PMB3L9pgQ@mail.gmail.com%3E).
+ Hue 4.0.1 ⇒ 4.1.0. Pour plus d'informations, veuillez consulter les [Notes de mise à jour](https://docs.gethue.com/releases/release-notes-4.10.0/).
+ MxNet 0,12,0 ⇒ 10,0. Pour plus d'informations, consultez la section [MXNet Change Log](https://github.com/apache/incubator-mxnet/releases/tag/1.0.0) on GitHub.
+ Presto 0.187 ⇒ 0.188. Pour plus d'informations, veuillez consulter les [Notes de mise à jour](https://prestodb.io/docs/current/release/release-0.188.html).
**Modifications, améliorations et problèmes résolus**
+ **Hadoop**
+ La propriété `yarn.resourcemanager.decommissioning.timeout` a été remplacée par `yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs`. Vous pouvez utiliser cette propriété pour personnaliser la réduction de la taille du cluster. Pour plus d'informations, consultez [Réduction de la taille des clusters](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-scaledown-behavior.html) dans le *Guide de gestion Amazon EMR*.
+ La CLI Hadoop a ajouté l'option `-d` à la commande `cp` (copy), qui spécifie la copie directe. Vous pouvez l'utiliser pour éviter de créer un fichier `.COPYING` intermédiaire, ce qui accélère la copie de données entre Amazon S3. Pour plus d'informations, consultez [HADOOP-12384](https://issues.apache.org/jira/browse/HADOOP-12384).
+ **Pig**
+ Ajout de la classification de configuration `pig-env`, qui simplifie la configuration des propriétés de l'environnement Pig. Pour de plus amples informations, veuillez consulter [Configuration des applications](emr-configure-apps.md).
+ **Presto**
+ Ajout de la classification de configuration, `presto-connector-redshift` que vous pouvez utiliser pour configurer des valeurs dans le fichier de configuration `redshift.properties` de Presto. Pour plus d'informations, consultez [Connecteur Redshift](https://prestodb.io/docs/current/connector/redshift.html) dans la documentation Presto, et [Configuration des applications](emr-configure-apps.md).
+ La prise en charge de Presto pour EMRFS a été ajoutée et constitue la configuration par défaut. Les versions précédentes d'Amazon EMR utilisaient PrestOS3FileSystem, qui était la seule option. Pour de plus amples informations, veuillez consulter [Configuration d'EMRFS et de PrestOS3 FileSystem](emr-presto-considerations.md#emr-presto-prestos3).
**Note**
Si vous interrogez des données sous-jacentes dans Amazon S3 avec Amazon EMR version 5.12.0, des erreurs Presto peuvent se produire. Cela est dû au fait que Presto ne parvient pas à récupérer les valeurs de classification de configuration depuis `emrfs-site.xml`. Pour contourner le problème, créez un sous-répertoire `emrfs` sous `usr/lib/presto/plugin/hive-hadoop2/` et un lien symbolique dans `usr/lib/presto/plugin/hive-hadoop2/emrfs` vers le fichier `/usr/share/aws/emr/emrfs/conf/emrfs-site.xml` existant. Redémarrez ensuite le processus presto-server (`sudo presto-server stop` suivi de `sudo presto-server start`).
+ **Spark**
+ [SPARK-22036 rétroporté : la BigDecimal multiplication](https://issues.apache.org/jira/browse/SPARK-22036) renvoie parfois la valeur nulle.
**Problèmes connus**
+ MXNet n'inclut pas les bibliothèques OpenCV.
+ SparkR n'est pas disponible pour les clusters créés à l'aide d'une AMI personnalisée car R n'est pas installé par défaut sur les nœuds du cluster.
## Version 5.11.3
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.11.3. Les modifications ont été apportées à la version 5.11.2.
Date de parution initiale : 18 juillet 2019
**Modifications, améliorations et problèmes résolus**
+ Mise à jour de l'AMI Amazon Linux par défaut pour Amazon EMR afin d'inclure d'importantes mises à jour de sécurité du noyau Linux, notamment le problème de déni de service TCP SACK ([AWS-2019-005](https://aws.amazon.com/security/security-bulletins/AWS-2019-005/)).
## Version 5.11.2
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.11.2. Les modifications ont été apportées à la version 5.11.1.
Date de parution initiale : 29 août 2018
**Modifications, améliorations et problèmes résolus**
+ Cette version corrige une vulnérabilité de sécurité potentielle.
## Version 5.11.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.11.1. Il s'agit des modifications apportées à la version Amazon EMR 5.11.0.
Date de parution initiale : 22 janvier 2018
### Modifications, améliorations et problèmes résolus
+ Mise à jour du noyau Amazon Linux de l'AMI Amazon Linux par défaut pour Amazon EMR afin de corriger les vulnérabilités associées à l'exécution spéculative (CVE-2017-5715, CVE-2017-5753 et CVE-2017-5754). Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/security/security-bulletins/AWS-2018-013/](https://aws.amazon.com/security/security-bulletins/AWS-2018-013/).
### Problèmes connus
+ MXNet n'inclut pas les bibliothèques OpenCV.
+ Hive 2.3.2 définit `hive.compute.query.using.stats=true` par défaut. Cela entraîne des requêtes pour obtenir des données à partir de statistiques existantes plutôt que directement à partir des données, ce qui peut être déroutant. Par exemple, si vous avez une table avec `hive.compute.query.using.stats=true` et que vous téléchargez de nouveaux fichiers vers la table `LOCATION`, l'exécution d'une demande `SELECT COUNT(*)` sur la table renvoie le nombre des statistiques, plutôt que de récupérer les lignes ajoutées.
Pour contourner ce problème, utilisez la commande `ANALYZE TABLE` pour collecter de nouvelles statistiques, ou définissez `hive.compute.query.using.stats=false`. Pour en savoir plus, consultez [Statistiques dans Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) dans la documentation Apache Hive.
## Version 5.11.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.11.0. Il s'agit des modifications apportées à la version Amazon EMR 5.10.0.
### Mises à niveau
Les applications et les composants suivants ont été mis à niveau dans cette édition pour inclure les versions suivantes :
+ Hive 2.3.2
+ Spark 2.2.1
+ Kit SDK pour Java 1.11.238
### Nouvelles fonctionnalités
+ **Spark**
+ Ajout du paramètre `spark.decommissioning.timeout.threshold`, qui améliore le comportement de mise hors service de Spark lors de l'utilisation d'instances Spot. Pour de plus amples informations, veuillez consulter [Configuration du comportement de mise hors service du nœud](emr-spark-configure.md#spark-decommissioning).
+ Ajout du `aws-sagemaker-spark-sdk` composant à Spark, qui installe Amazon SageMaker Spark et les dépendances associées pour l'intégration de Spark à [Amazon SageMaker](https://aws.amazon.com/sagemaker/). Vous pouvez utiliser Amazon SageMaker Spark pour créer des pipelines d'apprentissage automatique (ML) Spark à l'aide d'Amazon SageMaker Stages. Pour plus d'informations, consultez le [fichier readme de SageMaker Spark](https://github.com/aws/sagemaker-spark/blob/master/README.md) sur GitHub et [l'utilisation d'Apache Spark avec Amazon SageMaker](https://docs.aws.amazon.com/sagemaker/latest/dg/apache-spark.html) dans le manuel *Amazon SageMaker Developer Guide*.
### Problèmes connus
+ MXNet n'inclut pas les bibliothèques OpenCV.
+ Hive 2.3.2 définit `hive.compute.query.using.stats=true` par défaut. Cela entraîne des requêtes pour obtenir des données à partir de statistiques existantes plutôt que directement à partir des données, ce qui peut être déroutant. Par exemple, si vous avez une table avec `hive.compute.query.using.stats=true` et que vous téléchargez de nouveaux fichiers vers la table `LOCATION`, l'exécution d'une demande `SELECT COUNT(*)` sur la table renvoie le nombre des statistiques, plutôt que de récupérer les lignes ajoutées.
Pour contourner ce problème, utilisez la commande `ANALYZE TABLE` pour collecter de nouvelles statistiques, ou définissez `hive.compute.query.using.stats=false`. Pour en savoir plus, consultez [Statistiques dans Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) dans la documentation Apache Hive.
## Version 5.10.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.10.0. Il s'agit des modifications apportées à la version Amazon EMR 5.9.0.
### Mises à niveau
Les applications et les composants suivants ont été mis à niveau dans cette édition pour inclure les versions suivantes :
+ AWS SDK pour Java 1,11,221
+ Hive 2.3.1
+ Presto 0.187
### Nouvelles fonctionnalités
+ Ajout de la prise en charge de l'authentification Kerberos. Pour plus d'informations, consultez [Utilisation de l'authentification Kerberos](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-kerberos.html) dans le *Guide de gestion Amazon EMR*
+ Ajout de la prise en charge des rôles IAM pour les demandes EMRFS à Amazon S3. Pour plus d'informations, consultez la section [Configuration des rôles IAM pour les demandes EMRFS vers Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html) dans le *Guide de gestion Amazon EMR*.
+ Ajout de la prise en charge des types d'instances P2 et P3 basées sur GPU. Pour plus d'informations, consultez la section [Instances Amazon EC2 P2](https://aws.amazon.com/ec2/instance-types/p2/) et [instances Amazon EC2 P3](https://aws.amazon.com/ec2/instance-types/p3/). Les pilotes NVIDIA 384.81 et CUDA 9.0.176 sont installés sur ces types d'instance par défaut.
+ Ajout de la prise en charge de [Apache MXNet](emr-mxnet.md).
### Modifications, améliorations et problèmes résolus
+ Presto
+ Ajout de la prise en charge de l'utilisation du catalogue de données AWS Glue comme métastore Hive par défaut. Pour plus d'informations, consultez la section [Utilisation de Presto avec le catalogue de données AWS Glue](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto.html#emr-presto-glue).
+ Ajout de la prise en charge des [fonctions géospatiales](https://prestodb.io/docs/current/functions/geospatial.html).
+ Ajout de la prise en charge du [déversement sur le disque](https://prestodb.io/docs/current/admin/spill.html) pour les jointures.
+ Ajout de la prise en charge du [connecteur Redshift](https://prestodb.io/docs/current/connector/redshift.html).
+ Spark
+ Rétroportage de [SPARK-20640](https://issues.apache.org/jira/browse/SPARK-20640), ce qui permet de configurer le délai des appels de procédure distante et les tentatives aléatoires des enregistrements de réorganisation à l'aide des propriétés `spark.shuffle.registration.timeout` et `spark.shuffle.registration.maxAttempts`.
+ [SPARK-21549](https://issues.apache.org/jira/browse/SPARK-21549) a été rétroporté, qui corrige une erreur survenue lors de l'écriture personnalisée OutputFormat dans des emplacements autres que le HDFS.
+ Rétroportage de [Hadoop-13270](https://issues.apache.org/jira/browse/HADOOP-13270)
+ Les bibliothèques Numpy, Scipy et Matplotlib ont été supprimées de l'AMI Amazon EMR de base. Si vous avez besoin de ces bibliothèques pour votre application, elles sont disponibles dans le référentiel d'applications. Vous pouvez utiliser une action d'amorçage pour les installer sur tous les nœuds à l'aide de `yum install`.
+ L'image AMI Amazon EMR de base n'inclut plus de packages RPM d'application, de telle manière que les packages RPM ne sont plus présents sur les nœuds du cluster. Custom AMIs et l'AMI de base Amazon EMR font désormais référence au référentiel de packages RPM dans Amazon S3.
+ En raison de l'introduction d'une facturation à la seconde dans Amazon EC2, le **Comportement de réduction de capacité** par défaut est maintenant une **Résiliation à l'achèvement de la tâche** au lieu d'une **Résiliation à l'heure de l'instance**. Pour plus d'informations, consultez [Configuration de la réduction de la capacité des clusters](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-scaledown-behavior.html).
### Problèmes connus
+ MXNet n'inclut pas les bibliothèques OpenCV.
+ Hive 2.3.1 définit `hive.compute.query.using.stats=true` par défaut. Cela entraîne des requêtes pour obtenir des données à partir de statistiques existantes plutôt que directement à partir des données, ce qui peut être déroutant. Par exemple, si vous avez une table avec `hive.compute.query.using.stats=true` et que vous téléchargez de nouveaux fichiers vers la table `LOCATION`, l'exécution d'une demande `SELECT COUNT(*)` sur la table renvoie le nombre des statistiques, plutôt que de récupérer les lignes ajoutées.
Pour contourner ce problème, utilisez la commande `ANALYZE TABLE` pour collecter de nouvelles statistiques, ou définissez `hive.compute.query.using.stats=false`. Pour en savoir plus, consultez [Statistiques dans Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) dans la documentation Apache Hive.
## Version 5.9.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.9.0. Il s'agit des modifications apportées à la version Amazon EMR 5.8.0.
Date de parution : 5 octobre 2017
Dernière date de mise à jour de la fonctionnalité : 12 octobre 2017
### Mises à niveau
Les applications et les composants suivants ont été mis à niveau dans cette édition pour inclure les versions suivantes :
+ AWS SDK pour Java version 1.11.183
+ Flink 1.3.2
+ Hue 4.0.1
+ Pig 0.17.0
+ Presto 0.184
### Nouvelles fonctionnalités
+ Ajout de la prise en charge de Livy (version 0.4.0-incubating). Pour de plus amples informations, veuillez consulter [Apache Livy](emr-livy.md).
+ Ajout de la prise en charge de Hue Notebook pour Spark.
+ Ajout de la prise en charge des instances Amazon EC2 i3-series (12 octobre 2017).
### Modifications, améliorations et problèmes résolus
+ Spark
+ Ajout d'un nouvel ensemble de fonctionnalités qui permet de s'assurer que Spark gère plus élégamment la terminaison des nœuds suite à un redimensionnement manuel ou à une demande de stratégie de dimensionnement automatique. Pour de plus amples informations, veuillez consulter [Configuration du comportement de mise hors service du nœud](emr-spark-configure.md#spark-decommissioning).
+ SSL est utilisé à la place de 3DES pour le chiffrement en transit du service de transfert de bloc, ce qui améliore les performances lors de l'utilisation des types d'instance Amazon EC2 avec AES-NI.
+ Rétroportage de [SPARK-21494](https://issues.apache.org/jira/browse/SPARK-21494).
+ Zeppelin
+ Rétroportage de [ZEPPELIN-2377](https://issues.apache.org/jira/browse/ZEPPELIN-2377).
+ HBase
+ Ajout du correctif [HBASE-18533](https://issues.apache.org/jira/browse/HBASE-18533), qui autorise des valeurs supplémentaires pour la configuration à l'aide de la classification HBase BucketCache de configuration. `hbase-site`
+ Hue
+ Ajout de la prise en charge du catalogue de données AWS Glue pour l'éditeur de requêtes Hive dans Hue.
+ Par défaut, les superutilisateurs de Hue peuvent accéder à tous les fichiers auxquels les rôles IAM Amazon EMR sont autorisés à accéder. Les utilisateurs nouvellement créés n'ont pas automatiquement les autorisations d'accéder à l'explorateur de fichiers Amazon S3 et doivent avoir les autorisations `filebrowser.s3_access` activées pour leur groupe.
+ Résolution du problème qui entraînait l'impossibilité d'accéder aux données JSON sous-jacentes créées avec le catalogue de données AWS Glue.
### Problèmes connus
+ Le lancement du cluster échoue lorsque toutes les applications sont installées et que la taille du volume racine Amazon EBS par défaut n'est pas modifiée. Pour contourner le problème, utilisez la `aws emr create-cluster` commande du AWS CLI et spécifiez un `--ebs-root-volume-size` paramètre plus grand.
+ Hive 2.3.0 définit `hive.compute.query.using.stats=true` par défaut. Cela entraîne des requêtes pour obtenir des données à partir de statistiques existantes plutôt que directement à partir des données, ce qui peut être déroutant. Par exemple, si vous avez une table avec `hive.compute.query.using.stats=true` et que vous téléchargez de nouveaux fichiers vers la table `LOCATION`, l'exécution d'une demande `SELECT COUNT(*)` sur la table renvoie le nombre des statistiques, plutôt que de récupérer les lignes ajoutées.
Pour contourner ce problème, utilisez la commande `ANALYZE TABLE` pour collecter de nouvelles statistiques, ou définissez `hive.compute.query.using.stats=false`. Pour en savoir plus, consultez [Statistiques dans Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) dans la documentation Apache Hive.
## Version 5.8.2
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.8.2. Les modifications ont été apportées à la version 5.8.1.
Date de parution initiale : 29 mars 2018
**Modifications, améliorations et problèmes résolus**
+ Mise à jour du noyau Amazon Linux de l'AMI Amazon Linux par défaut pour Amazon EMR afin de corriger les vulnérabilités potentielles.
## Version 5.8.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.8.1. Il s'agit des modifications apportées à la version Amazon EMR 5.8.0.
Date de parution initiale : 22 janvier 2018
### Modifications, améliorations et problèmes résolus
+ Mise à jour du noyau Amazon Linux de l'AMI Amazon Linux par défaut pour Amazon EMR afin de corriger les vulnérabilités associées à l'exécution spéculative (CVE-2017-5715, CVE-2017-5753 et CVE-2017-5754). Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/security/security-bulletins/AWS-2018-013/](https://aws.amazon.com/security/security-bulletins/AWS-2018-013/).
## Version 5.8.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.8.0. Il s'agit des modifications apportées à la version Amazon EMR 5.7.0.
Date de parution initiale : 10 août 2017
Dernière date de mise à jour de la fonctionnalité : 25 septembre 2017
### Mises à niveau
Les applications et les composants suivants ont été mis à jour dans cette version pour inclure les versions suivantes :
+ AWS SDK 1.11.160
+ Flink 1.3.1
+ Hive 2.3.0. Pour plus d'informations, consultez [Notes de mise à jour](https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12310843&version=12340269) sur le site Apache Hive.
+ Spark 2.2.0. Pour plus d'informations, consultez [Notes de mise à jour](https://spark.apache.org/releases/spark-release-2-2-0.html) sur le site Apache Spark.
### Nouvelles fonctionnalités
+ Ajout de la prise en charge de l'affichage de l'historique de l'application (25 septembre 2017). Pour plus d'informations, consultez la section [Affichage de l'historique des applications](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html) dans le *Guide de gestion Amazon EMR*.
### Modifications, améliorations et problèmes résolus
+ **Intégration avec AWS Glue Data Catalog**
+ Hive et Spark SQL ont désormais la possibilité d'utiliser AWS Glue Data Catalog comme magasin de métadonnées Hive. Pour plus d’informations, consultez [Utiliser le catalogue de données AWS Glue comme métastore pour Hive](emr-hive-metastore-glue.md) et [Utiliser le catalogue AWS Glue Data Catalog avec Spark sur Amazon EMR](emr-spark-glue.md).
+ **Historique de l'application** ajouté aux détails du cluster, ce qui vous permet d'afficher les données historiques des applications YARN et des détails supplémentaires pour les applications Spark. Pour plus d'informations, consultez [Afficher l'historique de l'application](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html) dans le *Guide de gestion Amazon EMR*.
+ **Oozie**
+ Rétroportage de [OOZIE-2748](https://issues.apache.org/jira/browse/OOZIE-2748).
+ **Hue**
+ Rétroportage de [HUE-5859](https://issues.cloudera.org/browse/HUE-5859)
+ **HBase**
+ Ajout d'un correctif pour exposer l'heure de démarrage du serveur HBase principal via Java Management Extensions (JMX) à l'aide `getMasterInitializedTime` de.
+ Ajout d'un correctif qui améliore la date de début du cluster.
### Problèmes connus
+ Le lancement du cluster échoue lorsque toutes les applications sont installées et que la taille du volume racine Amazon EBS par défaut n'est pas modifiée. Pour contourner le problème, utilisez la `aws emr create-cluster` commande du AWS CLI et spécifiez un `--ebs-root-volume-size` paramètre plus grand.
+ Hive 2.3.0 définit `hive.compute.query.using.stats=true` par défaut. Cela entraîne des requêtes pour obtenir des données à partir de statistiques existantes plutôt que directement à partir des données, ce qui peut être déroutant. Par exemple, si vous avez une table avec `hive.compute.query.using.stats=true` et que vous téléchargez de nouveaux fichiers vers la table `LOCATION`, l'exécution d'une demande `SELECT COUNT(*)` sur la table renvoie le nombre des statistiques, plutôt que de récupérer les lignes ajoutées.
Pour contourner ce problème, utilisez la commande `ANALYZE TABLE` pour collecter de nouvelles statistiques, ou définissez `hive.compute.query.using.stats=false`. Pour en savoir plus, consultez [Statistiques dans Hive](https://cwiki.apache.org/confluence/display/Hive/StatsDev#StatsDev-ExistingTables–ANALYZE) dans la documentation Apache Hive.
+ **Spark** – Il existe un problème de fuite du gestionnaire de fichiers avec le démon apppusher lors de l'utilisation de Spark, qui peut apparaître après plusieurs heures ou jours pour une tâche Spark de longue durée. Pour corriger le problème, connectez-vous au nœud maître et tapez `sudo /etc/init.d/apppusher stop`. Cette commande arrête le démon apppusher, qu'Amazon EMR redémarre automatiquement.
+ **Historique de l'application**
+ Les données d'historique pour les exécuteurs Spark inactifs ne sont pas disponibles.
+ L'historique de l'application n'est pas disponible pour les clusters qui utilisent une configuration de sécurité pour permettre le chiffrement à la volée.
## Version 5.7.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.7.0. Il s'agit des modifications apportées à la version Amazon EMR 5.6.0.
Date de parution : 13 juillet 2017
### Mises à niveau
+ Flink 1.3.0
+ Phoenix 4.11.0
+ Zeppelin 0.7.2
### Nouvelles fonctionnalités
+ Possibilité ajoutée de spécifier une AMI Amazon Linux personnalisée lorsque vous créez un cluster. Pour en savoir plus, consultez [Utilisation d'une image AMI personnalisée](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-custom-ami.html).
### Modifications, améliorations et problèmes résolus
+ **HBase**
+ Ajout de la possibilité de configurer des clusters HBase en lecture et réplication. Consultez [Utilisation d'un cluster de réplica en lecture.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-s3.html#emr-hbase-s3-read-replica)
+ Correctifs de nombreux bogues et améliorations
+ **Presto** – ajout de la possibilité de configurer `node.properties`.
+ **YARN** – ajout de la possibilité de configurer `container-log4j.properties`.
+ **Sqoop** – [SQOOP-2880](https://issues.apache.org/jira/browse/SQOOP-2880) rétroporté, qui introduit un argument vous permettant de définir le répertoire temporaire de Sqoop.
## Version 5.6.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.6.0. Il s'agit des modifications apportées à la version Amazon EMR 5.5.0.
Date de parution : 5 juin 2017
### Mises à niveau
+ Flink 1.2.1
+ HBase 1.3.1
+ Mahout 0.13.0. Il s'agit de la première version de Mahout à prendre en charge Spark 2.x dans les versions 5.0 et ultérieures d'Amazon EMR.
+ Spark 2.1.1
### Modifications, améliorations et problèmes résolus
+ **Presto**
+ Ajout de la possibilité d'activer une communication SSL/TLS sécurisée entre les nœuds Presto en activant le chiffrement en transit à l'aide d'une configuration de sécurité. Pour plus d'informations, consultez [Chiffrement des données en transit](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-data-encryption-options.html#emr-encryption-intransit).
+ Rétroportage de [Presto 7661](https://github.com/prestodb/presto/pull/7661/commits), ce qui ajoute l'option `VERBOSE` à l'instruction `EXPLAIN ANALYZE` pour transmettre des statistiques de bas niveau plus détaillées sur un plan de la requête.
## Version 5.5.3
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.5.3. Les modifications ont été apportées à la version 5.5.2.
Date de parution initiale : 29 août 2018
**Modifications, améliorations et problèmes résolus**
+ Cette version corrige une vulnérabilité de sécurité potentielle.
## Version 5.5.2
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.5.2. Les modifications ont été apportées à la version 5.5.1.
Date de parution initiale : 29 mars 2018
**Modifications, améliorations et problèmes résolus**
+ Mise à jour du noyau Amazon Linux de l'AMI Amazon Linux par défaut pour Amazon EMR afin de corriger les vulnérabilités potentielles.
## Version 5.5.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.5.1. Il s'agit des modifications apportées à la version Amazon EMR 5.5.0.
Date de parution initiale : 22 janvier 2018
### Modifications, améliorations et problèmes résolus
+ Mise à jour du noyau Amazon Linux de l'AMI Amazon Linux par défaut pour Amazon EMR afin de corriger les vulnérabilités associées à l'exécution spéculative (CVE-2017-5715, CVE-2017-5753 et CVE-2017-5754). Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/security/security-bulletins/AWS-2018-013/](https://aws.amazon.com/security/security-bulletins/AWS-2018-013/).
## Version 5.5.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.5.0. Il s'agit des modifications apportées à la version Amazon EMR 5.4.0.
Date de parution : 26 avril 2017
### Mises à niveau
+ Hue 3.12
+ Presto 0.170
+ Zeppelin 0.7.1
+ ZooKeeper 3.4.10
### Modifications, améliorations et problèmes résolus
+ **Spark**
+ [ DAGScheduler Correctif de Spark rétroporté (SPARK-20115) permettant de recalculer tous les blocs de shuffle perdus lorsque le service de shuffle externe n'est pas disponible dans la version 2.1.0 de Spark](https://issues.apache.org/jira/browse/SPARK-20115), incluse dans cette version.
+ **Flink**
+ Flink s'appuie désormais sur Scala 2.11. Si vous utilisez l'API et les bibliothèques Scala, nous vous recommandons d'utiliser Scala 2.11 dans vos projets.
+ Résolution d'un problème où les valeurs par défaut `HADOOP_CONF_DIR` et `YARN_CONF_DIR` n'étaient pas définies correctement, si bien que `start-scala-shell.sh` ne fonctionnait pas. Ajout également de la possibilité de définir ces valeurs à l'aide de `env.hadoop.conf.dir` et `env.yarn.conf.dir` dans `/etc/flink/conf/flink-conf.yaml` ou la classification de configuration `flink-conf`.
+ Introduction d'une nouvelle commande spécifique à EMR, `flink-scala-shell` comme wrapper pour `start-scala-shell.sh`. Nous vous recommandons d'utiliser cette commande au lieu de `start-scala-shell`. La nouvelle commande simplifie l'exécution. Par exemple, `flink-scala-shell -n 2` démarre un shell Flink Scala avec un parallélisme de 2 tâches.
+ Introduction d'une nouvelle commande spécifique à EMR, `flink-yarn-session` comme wrapper pour `yarn-session.sh`. Nous vous recommandons d'utiliser cette commande au lieu de `yarn-session`. La nouvelle commande simplifie l'exécution. Par exemple, `flink-yarn-session -d -n 2` démarre une session Flink de longue durée à l'état détaché avec deux gestionnaires de tâches.
+ Résolution du problème [(FLINK-6125) commons httpclient n'est plus nuancé dans Flink 1.2](https://issues.apache.org/jira/browse/FLINK-6125).
+ **Presto**
+ Ajout de la prise en charge de l'authentification LDAP. L'utilisation de LDAP avec Presto sur Amazon EMR nécessite que vous activiez l'accès HTTPS pour le coordinateur Presto (`http-server.https.enabled=true` dans `config.properties`). Pour plus de détails sur la configuration, consultez [Authentification LDAP](https://prestodb.io/docs/current/security/ldap.html) dans la documentation Presto.
+ Ajout de la prise en charge de `SHOW GRANTS`.
+ **AMI Linux Amazon EMR de base**
+ Les versions d'Amazon EMR sont désormais basées sur Amazon Linux 2017.03. Pour plus d'informations, consultez [Notes de mise à jour Amazon Linux AMI 2017.03](https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/).
+ Suppression de Python 2.6 de l'image Linux de base d'Amazon EMR. Python 2.7 et 3.4 sont installés par défaut. Vous pouvez installer Python 2.6 manuellement si nécessaire.
## Version 5.4.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.4.0. Il s'agit des modifications apportées à la version Amazon EMR 5.3.0.
Date de parution : 8 mars 2017
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers Flink 1.2.0
+ Mise à niveau vers HBase 1.3.0
+ Mise à niveau vers Phoenix 4.9.0
**Note**
Si vous effectuez une mise à niveau depuis une version antérieure d'Amazon EMR vers Amazon EMR version 5.4.0 ou supérieure et utilisez une indexation secondaire, mettez à niveau les index locaux comme décrit dans la [documentation Apache Phoenix](https://phoenix.apache.org/secondary_indexing.html#Upgrading_Local_Indexes_created_before_4.8.0). Amazon EMR supprime les configurations requises de la classification `hbase-site`, mais les index doivent être repeuplés. La mise à niveau en ligne et hors ligne des index est prise en charge. Les mises à niveau sont par défaut en ligne, ce qui signifie que les index sont remplis de nouveau lors de l'initialisation depuis les clients Phoenix en version 4.8.0 ou supérieure. Pour spécifier des mises à niveau hors ligne, définissez la configuration `phoenix.client.localIndexUpgrade` sur false dans la classification `phoenix-site`, puis lancez SSH sur le nœud maître afin d'exécuter `psql [zookeeper] -1`.
+ Mise à niveau vers Presto 0.166
+ Mise à niveau vers Zeppelin 0.7.0
### Modifications et améliorations
Les modifications suivantes sont apportées aux versions Amazon EMR pour l'étiquette de version emr-5.4.0 :
+ Ajout de la prise en charge des instances r4. Consultez [Types d'instances Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
## Version 5.3.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.3.1. Il s'agit des modifications apportées à la version Amazon EMR 5.3.0.
Date de version : 7 février 2017
Modifications mineures pour rétroporter les correctifs Zeppelin et mettre à jour l'AMI par défaut pour Amazon EMR.
## Version 5.3.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.3.0. Il s'agit des modifications apportées à la version Amazon EMR 5.2.1.
Date de parution : 26 janvier 2017
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers Hive 2.1.1
+ Mise à niveau vers Hue 3.11.0
+ Mise à niveau vers Spark 2.1.0
+ Mise à niveau vers Oozie 4.3.0
+ Mise à niveau vers Flink 1.1.4
### Modifications et améliorations
Les modifications suivantes sont apportées aux versions Amazon EMR pour l'étiquette de version emr-5.3.0 :
+ Ajout à Hue d'un correctif qui vous permet d'utiliser le paramètre `interpreters_shown_on_wheel` pour configurer les interpréteurs à afficher en premier sur la roue de sélection Notebook quel que soit leur ordre dans le fichier `hue.ini`.
+ Ajout de la classification de configuration, `hive-parquet-logging` que vous pouvez utiliser pour configurer des valeurs dans le fichier `parquet-logging.properties` de Hive.
## Version 5.2.2
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.2.2. Il s'agit des modifications apportées à la version Amazon EMR 5.2.1.
Date de parution : 2 mai 2017
### Problèmes connus résolus depuis les versions précédentes
+ [SPARK-194459](https://issues.apache.org/jira/browse/SPARK-19459) a été rétroporté, ce qui résout un problème en cas d'échec de la lecture d'une table ORC contenant des colonnes. char/varchar
## Version 5.2.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.2.1. Il s'agit des modifications apportées à la version Amazon EMR 5.2.0.
Date de parution : 29 décembre 2016
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers Presto 0.157.1. Pour plus d'informations, consultez [Notes de mise à jour Presto](https://prestodb.io/docs/current/release/release-0.157.1.html) dans la documentation Presto.
+ Mise à niveau vers Zookeeper 3.4.9. Pour plus d'informations, consultez les [notes ZooKeeper de publication](https://zookeeper.apache.org/doc/r3.4.9/releasenotes.html) dans la ZooKeeper documentation d'Apache.
### Modifications et améliorations
Les modifications suivantes sont apportées aux versions Amazon EMR pour l'étiquette de version emr-5.2.1 :
+ Ajout de la prise en charge du type d'instance m4.16xlarge Amazon EC2 dans les versions 4.8.3 et ultérieures d'Amazon EMR, sauf les versions 5.0.0, 5.0.3 et 5.2.0.
+ Les versions d'Amazon EMR sont désormais basées sur Amazon Linux 2016.09. Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/).
+ L'emplacement des chemins de configuration Flink et YARN sont désormais définis par défaut dans `/etc/default/flink`, et vous n'avez pas besoin de définir les variables d'environnement `FLINK_CONF_DIR` et `HADOOP_CONF_DIR` lorsque vous exécutez les scripts de pilote `flink` ou `yarn-session.sh` pour lancer des tâches Flink.
+ Ajout du support pour les FlinkKinesisConsumer cours.
### Problèmes connus résolus depuis les versions précédentes
+ Correction d'un problème dans Hadoop où le ReplicationMonitor thread pouvait rester bloqué pendant longtemps en raison d'une course entre la réplication et la suppression du même fichier dans un grand cluster.
+ Correction d'un problème en raison duquel ControlledJob \$1toString échouait avec une exception de pointeur nul (NPE) lorsque le statut de la tâche n'était pas correctement mis à jour.
## Version 5.2.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.2.0. Il s'agit des modifications apportées à la version Amazon EMR 5.1.0.
Date de parution : 21 novembre 2016
### Modifications et améliorations
Les modifications et les améliorations suivantes sont disponibles dans cette version :
+ Ajout du mode de stockage Amazon S3 pour HBase.
+ Vous permet de spécifier un emplacement Amazon S3 pour le HBase rootdir. Pour plus d'informations, consultez [HBaseAmazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-s3.html).
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers Spark 2.0.2
### Problèmes connus résolus depuis les versions précédentes
+ Correction d'un problème avec /mnt tout en étant limité à 2 To sur les types d'instance uniquement EBS.
+ Correction d'un problème avec les journaux instance-controller et logpusher édités dans leurs fichiers .out correspondants au lieu de leurs fichiers .log configurés log4j, qui permutent toutes les heures. Les fichiers .out n'effectuent pas de permutation, cela remplirait finalement la partition /emr. Ce problème affecte uniquement les types d'instance de virtualisation HVM.
## Version 5.1.0
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.1.0. Il s'agit des modifications apportées à la version Amazon EMR 5.0.0.
Date de parution : 3 novembre 2016
### Modifications et améliorations
Les modifications et les améliorations suivantes sont disponibles dans cette version :
+ Support ajouté pour Flink 1.1.3.
+ Presto a été ajouté comme une option dans la section ordinateur portable de Hue.
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers la version HBase 1.2.3
+ Mise à niveau vers Zeppelin 0.6.2
### Problèmes connus résolus depuis les versions précédentes
+ Correction d'un problème avec des requêtes Tez sur Amazon S3 où les fichiers ORC ne fonctionnaient pas aussi bien qu'avec les versions antérieures d'Amazon EMR 4.x.
## Version 5.0.3
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 5.0.3. Il s'agit des modifications apportées à la version Amazon EMR 5.0.0.
Date de parution : 24 octobre 2016
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers Hadoop 2.7.3
+ Mise à niveau vers Presto 0.152.3, qui comprend la prise en charge de l'interface Web Presto. Utilisez le port 8889 du coordinateur Presto pour accéder à l'interface Web Presto. Pour plus d'informations sur l'interface Web Presto, consultez [Interface Web](https://prestodb.io/docs/current/admin/web-interface.html) dans la documentation Presto.
+ Mise à niveau vers Spark 2.0.1
+ Les versions d'Amazon EMR sont désormais basées sur Amazon Linux 2016.09. Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/).
## Version 5.0.0
Date de parution : 27 juillet 2016
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers Hive 2.1
+ Mise à niveau vers Presto 0.150
+ Mise à niveau vers Spark 2.0
+ Mise à niveau vers Hue 3.10.0
+ Mise à niveau vers Pig 0.16.0
+ Mise à niveau vers Tez 0.8.4
+ Mise à niveau vers Zeppelin 0.6.1
### Modifications et améliorations
Les modifications suivantes sont apportées aux versions Amazon EMR pour l'étiquette de version emr-5.0.0 ou ultérieures :
+ Amazon EMR prend en charge les dernières versions open source de Hive (version 2.1) et de Pig (version 0.16.0). Si vous utilisiez Hive ou Pig sur Amazon EMR auparavant, cela risque d'avoir un impact sur certains cas d'utilisation. Pour en savoir plus, consultez [Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive.html) et [Pig](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-pig.html).
+ Tez est désormais le moteur d'exécution par défaut de Hive et Pig. Pour changer cela, vous devez modifier les valeurs appropriées dans les classifications de configuration `hive-site` et `pig-properties`, respectivement.
+ Une fonction améliorée de débogage des étapes a été ajoutée, ce qui vous permet de voir la cause première des échecs des étapes si le service peut déterminer la cause. Pour plus d'informations, consultez la section [Débogage d'étape amélioré](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-enhanced-step-debugging.html) dans le Guide de gestion Amazon EMR.
+ Les applications qui se terminaient par « -Sandbox » n'ont plus ce suffixe. Cela peut interrompre l'automatisation de certaines tâches, par exemple, si vous utilisez des scripts pour lancer des clusters avec ces applications. Le tableau suivant montre les noms d'application dans Amazon EMR 4.7.2 contre Amazon EMR 5.0.0.
**Modification des noms d'application**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-whatsnew-history.html)
+ Spark est maintenant compilé pour Scala 2.11.
+ Java 8 est désormais la JVM par défaut. Toutes les applications s'exécutent avec le runtime Java 8. Aucune modification n'est apportée bytecode cible des applications. La plupart des applications continuent de cibler Java 7.
+ Zeppelin inclut désormais des fonctions d'authentification. Pour en savoir plus, consultez [Zeppelin](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-zeppelin.html).
+ Ajout de la prise en charge des configurations de sécurité, qui vous permettent de créer et d'appliquer des options de chiffrement plus facilement. Pour en savoir plus, consultez [Chiffrement des données](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-data-encryption.html).
## Version 4.9.5
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.9.5. Les modifications ont été apportées à la version 4.9.4.
Date de parution initiale : 29 août 2018
**Modifications, améliorations et problèmes résolus**
+ HBase
+ Cette version corrige une vulnérabilité de sécurité potentielle.
## Version 4.9.4
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.9.4. Les modifications ont été apportées à la version 4.9.3.
Date de parution initiale : 29 mars 2018
**Modifications, améliorations et problèmes résolus**
+ Mise à jour du noyau Amazon Linux de l'AMI Amazon Linux par défaut pour Amazon EMR afin de corriger les vulnérabilités potentielles.
## Version 4.9.3
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.9.3. Il s'agit des modifications apportées à la version Amazon EMR 4.9.2.
Date de parution initiale : 22 janvier 2018
### Modifications, améliorations et problèmes résolus
+ Mise à jour du noyau Amazon Linux de l'AMI Amazon Linux par défaut pour Amazon EMR afin de corriger les vulnérabilités associées à l'exécution spéculative (CVE-2017-5715, CVE-2017-5753 et CVE-2017-5754). Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/security/security-bulletins/AWS-2018-013/](https://aws.amazon.com/security/security-bulletins/AWS-2018-013/).
## Version 4.9.2
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.9.2. Il s'agit des modifications apportées à la version Amazon EMR 4.9.1.
Date de parution : 13 juillet 2017
Des modifications mineures, des correctifs de bogues et des améliorations ont été apportées à cette version.
## Version 4.9.1
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.9.1. Il s'agit des modifications apportées à la version Amazon EMR 4.8.4.
Date de parution : 10 avril 2017
### Problèmes connus résolus depuis les versions précédentes
+ Rétroportages de [HIVE-9976](https://issues.apache.org/jira/browse/HIVE-9976) et [HIVE-10106](https://issues.apache.org/jira/browse/HIVE-10106)
+ Résolution d'un problème dans YARN où un nombre important de nœuds (plus de 2 000) et de conteneurs (plus de 5 000) provoquait une erreur de mémoire insuffisante, par exemple : `"Exception in thread 'main' java.lang.OutOfMemoryError"`.
### Modifications et améliorations
Les modifications suivantes sont apportées aux versions Amazon EMR pour l'étiquette de version emr-4.9.1 :
+ Les versions d'Amazon EMR sont désormais basées sur Amazon Linux 2017.03. Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/](https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/).
+ Suppression de Python 2.6 de l'image Linux de base d'Amazon EMR. Vous pouvez installer Python 2.6 manuellement si nécessaire.
## Version 4.8.4
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.8.4. Il s'agit des modifications apportées à la version Amazon EMR 4.8.3.
Date de parution : 7 février 2017
Des modifications mineures, des correctifs de bogues et des améliorations ont été apportées à cette version.
## Version 4.8.3
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.8.3. Il s'agit des modifications apportées à la version Amazon EMR 4.8.2.
Date de parution : 29 décembre 2016
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers Presto 0.157.1. Pour plus d'informations, consultez [Notes de mise à jour Presto](https://prestodb.io/docs/current/release/release-0.157.1.html) dans la documentation Presto.
+ Mise à niveau vers Spark 1.6.3. Pour plus d'informations, consultez les [Notes de mise à jour Spark](http://spark.apache.org/releases/spark-release-1-6-3.html) dans la documentation Apache Spark.
+ Mise à niveau vers la version ZooKeeper 3.4.9. Pour plus d'informations, consultez les [notes ZooKeeper de publication](https://zookeeper.apache.org/doc/r3.4.9/releasenotes.html) dans la ZooKeeper documentation d'Apache.
### Modifications et améliorations
Les modifications suivantes sont apportées aux versions Amazon EMR pour l'étiquette de version emr-4.8.3 :
+ Ajout de la prise en charge du type d'instance m4.16xlarge Amazon EC2 dans les versions 4.8.3 et ultérieures d'Amazon EMR, sauf les versions 5.0.0, 5.0.3 et 5.2.0.
+ Les versions d'Amazon EMR sont désormais basées sur Amazon Linux 2016.09. Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/).
### Problèmes connus résolus depuis les versions précédentes
+ Correction d'un problème dans Hadoop où le ReplicationMonitor thread pouvait rester bloqué pendant longtemps en raison d'une course entre la réplication et la suppression du même fichier dans un grand cluster.
+ Correction d'un problème en raison duquel ControlledJob \$1toString échouait avec une exception de pointeur nul (NPE) lorsque le statut de la tâche n'était pas correctement mis à jour.
## Version 4.8.2
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.8.2. Il s'agit des modifications apportées à la version Amazon EMR 4.8.0.
Date de parution : 24 octobre 2016
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers Hadoop 2.7.3
+ Mise à niveau vers Presto 0.152.3, qui comprend la prise en charge de l'interface Web Presto. Utilisez le port 8889 du coordinateur Presto pour accéder à l'interface Web Presto. Pour plus d'informations sur l'interface Web Presto, consultez [Interface Web](https://prestodb.io/docs/current/admin/web-interface.html) dans la documentation Presto.
+ Les versions d'Amazon EMR sont désormais basées sur Amazon Linux 2016.09. Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/).
## Version 4.8.0
Date de parution : 7 septembre 2016
### Mises à niveau
Les mises à niveau suivantes sont disponibles dans cette version :
+ Mise à niveau vers la version HBase 1.2.2
+ Mise à niveau vers Presto-Sandbox 0.151
+ Mise à niveau vers Tez 0.8.4
+ Mise à niveau vers Zeppelin-Sandbox 0.6.1
### Modifications et améliorations
Les modifications suivantes sont apportées aux versions Amazon EMR pour l'étiquette de version emr-4.8.0 :
+ Correction d'un problème dans YARN à cause duquel ils ApplicationMaster tentaient de nettoyer des conteneurs qui n'existent plus parce que leurs instances avaient été fermées.
+ Correction de l'URL hive-server2 pour les actions Hive2 dans les exemples Oozie.
+ Ajout de la prise en charge d'autres catalogues Presto.
+ Correctifs rétroportés : [HIVE-8948](https://issues.apache.org/jira/browse/HIVE-8948), [HIVE-12679](https://issues.apache.org/jira/browse/HIVE-12679), [HIVE-13405](https://issues.apache.org/jira/browse/HIVE-13405), [PHOENIX-3116](https://issues.apache.org/jira/browse/PHOENIX-3116), [HADOOP-12689](https://issues.apache.org/jira/browse/HADOOP-12689)
+ Ajout de la prise en charge des configurations de sécurité, qui vous permettent de créer et d'appliquer des options de chiffrement plus facilement. Pour en savoir plus, consultez [Chiffrement des données](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-data-encryption.html).
## Version 4.7.2
Les notes de mises à jour suivantes incluent des informations sur la version Amazon EMR 4.7.2.
Date de parution : 15 juillet 2016
### Caractéristiques
Les fonctions suivantes sont disponibles dans cette version :
+ Mise à niveau vers Mahout 0.12.2
+ Mise à niveau vers Presto 0.148
+ Mise à niveau vers Spark 1.6.2
+ Vous pouvez désormais créer un AWSCredentials fournisseur à utiliser avec EMRFS en utilisant un URI comme paramètre. Pour plus d'informations, voir [Création d'un AWSCredentials fournisseur pour EMRFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-plan-credentialsprovider.html).
+ EMRFS permet maintenant aux utilisateurs de configurer un point de terminaison DynamoDB personnalisé pour les métadonnées de leur vue cohérente à l'aide de la propriété `fs.s3.consistent.dynamodb.endpoint` dans le fichier `emrfs-site.xml`.
+ Ajout d'un script dans `/usr/bin` appelé `spark-example`, qui encapsule `/usr/lib/spark/spark/bin/run-example` pour vous permettre d'exécuter des exemples directement. Par exemple, pour exécuter l' SparkPi exemple fourni avec la distribution Spark, vous pouvez l'exécuter `spark-example SparkPi 100` à partir de la ligne de commande ou en `command-runner.jar` tant qu'étape dans l'API.
### Problèmes connus résolus depuis les versions précédentes
+ Résolution d'un problème où `spark-assembly.jar` pour Oozie n'était pas à l'emplacement approprié quand Spark était également installé, ce qui provoquait un échec du lancement d'applications Spark avec Oozie.
+ Résolution d'un problème lié à la journalisation basée sur Spark Log4j dans des conteneurs YARN.
## Version 4.7.1
Date de parution : 10 juin 2016
### Problèmes connus résolus depuis les versions précédentes
+ Résolution d'un problème qui augmentait la durée de démarrage des clusters lancés dans un VPC avec des sous-réseaux privés. Ce bogue affectait uniquement les clusters lancés avec la version 4.7.0 d'Amazon EMR.
+ Résolution d'un problème où des listes de fichiers dans Amazon EMR n'étaient pas traitées correctement pour les clusters lancés avec la version 4.7.0 d'Amazon EMR.
## Version 4.7.0
**Important**
Amazon EMR 4.7.0 est obsolète. Veuillez plutôt utiliser Amazon EMR 4.7.1 ou une version ultérieure.
Date de parution : 2 juin 2016
### Caractéristiques
Les fonctions suivantes sont disponibles dans cette version :
+ Ajout d'Apache Phoenix 4.7.0
+ Ajout d'Apache Tez 0.8.3
+ Mise à niveau vers la version HBase 1.2.1
+ Mise à niveau vers Mahout 0.12.0
+ Mise à niveau vers Presto 0.147
+ Mise à niveau de la AWS SDK pour Java version 1.10.75
+ L'indicateur final a été supprimé de la propriété `mapreduce.cluster.local.dir` dans `mapred-site.xml` pour permettre aux utilisateurs d'exécuter Pig en mode local.
### Pilotes JDBC Amazon Redshift disponibles sur le cluster
Les pilotes JDBC Amazon Redshift sont maintenant inclus dans `/usr/share/aws/redshift/jdbc`. `/usr/share/aws/redshift/jdbc/RedshiftJDBC41.jar` est le pilote Amazon Redshift compatible avec JDBC 4.1 et `/usr/share/aws/redshift/jdbc/RedshiftJDBC4.jar` est le pilote Amazon Redshift compatible avec JDBC 4.0. Pour plus d'informations, consultez la section [Configuration d'une connexion JDBC](https://docs.aws.amazon.com/redshift/latest/mgmt/configure-jdbc-connection.html) dans le *Guide de gestion Amazon Redshift*.
### Java 8
Sauf pour Presto, OpenJDK 1.7 est le JDK par défaut utilisé pour toutes les applications. Cependant, OpenJDK 1.7 et 1.8 sont installés. Pour plus d'informations sur la configuration de `JAVA_HOME` pour les applications, consultez [Configuration d'applications pour utiliser Java 8](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html#configuring-java8).
### Problèmes connus résolus depuis les versions précédentes
+ Résolution d'un problème de noyau qui affectait de manière significative les performances sur les volumes HDD à débit optimisé (ST1) EBS pour Amazon EMR dans emr-4.6.0.
+ Résolution d'un problème où un cluster échouait si une zone de chiffrement HDFS était spécifiée sans que Hadoop ait été choisi comme application.
+ Remplacement de la stratégie d'écriture HDFS par défaut `RoundRobin` par `AvailableSpaceVolumeChoosingPolicy`. Certains volumes n'ont pas été utilisés correctement avec la RoundRobin configuration, ce qui a entraîné la défaillance de nœuds principaux et un HDFS peu fiable.
+ Résolution d'un problème lié à l'interface de ligne de commande EMRFS, qui entraînait une exception lors de la création de la table de métadonnées DynamoDB par défaut pour des vues cohérentes.
+ Résolution d'un problème de blocage dans EMRFS qui pouvait potentiellement se produire lors d'opérations de changement de nom et de copie en plusieurs parties.
+ Correction d'un problème lié à EMRFS qui faisait en sorte que la CopyPart taille par défaut était de 5 Mo. La valeur par défaut est maintenant correctement définie sur 128 Mo.
+ Résolution d'un problème lié à la configuration upstart dans Zeppelin qui pouvait vous empêcher potentiellement d'arrêter le service.
+ Résolution d'un problème lié à Spark et Zeppelin qui vous empêchait d'utiliser le schéma d'URI `s3a://`, car `/usr/lib/hadoop/hadoop-aws.jar` n'était pas chargé correctement dans leur chemin de classe respectif.
+ Rétroportage de [HUE-2484](https://issues.cloudera.org/browse/HUE-2484).
+ J'ai rétroporté un [commit](https://github.com/cloudera/hue/commit/c3c89f085e7a29c9fac7de016d881142d90af3eb) depuis Hue 3.9.0 (il n'existe pas de JIRA) pour corriger un problème avec l' HBase exemple de navigateur.
+ Rétroportage de [HIVE-9073](https://issues.apache.org/jira/browse/HIVE-9073).
## Version 4.6.0
Date de parution : 21 avril 2016
### Caractéristiques
Les fonctions suivantes sont disponibles dans cette version :
+ Ajouté HBase 1.2.0
+ Ajout de Zookeeper-Sandbox 3.4.8
+ Mise à niveau vers Presto-Sandbox 0.143
+ Les versions Amazon EMR sont désormais basées sur Amazon Linux 2016.03.0. Pour de plus amples informations, veuillez consulter [https://aws.amazon.com/amazon-linux-ami/2016.03-release-notes/](https://aws.amazon.com/amazon-linux-ami/2016.03-release-notes/).
### Problème affectant les types de volume HDD à débit optimisé (ST1) EBS
Un problème dans les versions 4.2 et précédentes de noyau Linux affecte de manière significative les performances sur les volumes HDD à débit optimisé (ST1) EBS pour EMR. Cette version (emr-4.6.0) utilise la version de noyau 4.4.5 et est donc concernée. Par conséquent, nous vous recommandons de ne pas utiliser emr-4.6.0 si vous voulez utiliser des volumes EBS st1. Vous pouvez utiliser emr-4.5.0 ou des versions précédentes d'Amazon EMR avec ST1 sans incidence. En outre, nous fournirons le correctif avec les versions futures.
### Valeurs par défaut de Python
Python 3.4 est maintenant installé par défaut, mais Python 2.7 reste la valeur système par défaut. Vous pouvez configurer Python 3.4 comme valeur par défaut du système à l'aide d'une action bootstrap ; vous pouvez utiliser l'API de configuration pour définir l'exportation de PYSPARK\$1PYTHON sur `/usr/bin/python3.4` dans la classification afin d'affecter la `spark-env` version de Python utilisée par. PySpark
### Java 8
Sauf pour Presto, OpenJDK 1.7 est le JDK par défaut utilisé pour toutes les applications. Cependant, OpenJDK 1.7 et 1.8 sont installés. Pour plus d'informations sur la configuration de `JAVA_HOME` pour les applications, consultez [Configuration d'applications pour utiliser Java 8](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html#configuring-java8).
### Problèmes connus résolus depuis les versions précédentes
+ Résolution d'un problème où le provisionnement d'application échouait parfois de manière aléatoire en raison d'un mot de passe généré.
+ Auparavant, `mysqld` était installé sur tous les nœuds. Maintenant, il est uniquement installé sur l'instance principale et seulement si l'application choisie inclut `mysql-server` comme composant. Actuellement, les applications suivantes incluent le `mysql-server` composant : Hive HCatalog, Hue, Presto-Sandbox et Sqoop-Sandbox.
+ Remplacement de la valeur par défaut 80 par 32 pour `yarn.scheduler.maximum-allocation-vcores`, ce qui résout un problème introduit dans emr-4.4.0 qui se produit principalement avec Spark lors de l'utilisation de l'option `maximizeResourceAllocation` dans un cluster dont le type d'instance principal est l'un des types d'instance large pour lesquels des cœurs virtuels YARN sont définis sur des valeurs supérieures à 32. Les types c4.8xlarge, cc2.8xlarge, hs1.8xlarge, i2.8xlarge, m2.4xlarge, r3.8xlarge, d2.8xlarge et m4.10xlarge étaient affectés par ce problème.
+ s3-dist-cp utilise désormais EMRFS pour toutes les nominations Amazon S3 et n'effectue plus une copie intermédiaire dans un répertoire HDFS temporaire.
+ Résolution d'un problème lié au traitement des exceptions pour le chiffrement côté client du chargement partitionné.
+ Ajout d'une option pour permettre aux utilisateurs de modifier la classe de stockage Amazon S3. Par défaut, ce paramètre est `STANDARD`. La configuration de classification `emrfs-site` est `fs.s3.storageClass`, et les valeurs possibles sont `STANDARD`, `STANDARD_IA` et `REDUCED_REDUNDANCY`. Pour plus d'informations sur les classes de stockage, consultez la section [Classes de stockage](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html) dans le Guide de l'utilisateur Amazon Simple Storage Service.
## Version 4.5.0
Date de parution : 4 avril 2016
### Caractéristiques
Les fonctions suivantes sont disponibles dans cette version :
+ Mise à niveau vers Spark 1.6.1
+ Mise à niveau vers Hadoop 2.7.2
+ Mise à niveau vers Presto 0.140
+ Ajout de la AWS KMS prise en charge du chiffrement côté serveur Amazon S3.
### Problèmes connus résolus depuis les versions précédentes
+ Résolution d'un problème où les serveurs MySQL et Apache ne démarraient pas après le redémarrage d'un nœud.
+ Résolution d'un problème où IMPORT ne fonctionnait pas correctement avec les tables non partitionnées stockées dans Amazon S3
+ Résolution d'un problème lié à Presto où le répertoire intermédiaire devait être `/mnt/tmp` au lieu de `/tmp` lors de l'écriture dans des tables Hive.
## Version 4.4.0
Date de parution : 14 mars 2016
### Caractéristiques
Les fonctions suivantes sont disponibles dans cette version :
+ Ajouté HCatalog 1.0.0
+ Ajout de Sqoop-Sandbox 1.4.6
+ Mise à niveau vers Presto 0.136
+ Mise à niveau vers Zeppelin 0.5.6
+ Mise à niveau vers Mahout 0.11.1
+ `dynamicResourceAllocation` activé par défaut.
+ Ajout d'un tableau de toutes les classifications de configuration pour la version. Pour en savoir plus, consultez le tableau Classifications des configurations dans [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
### Problèmes connus résolus depuis les versions précédentes
+ Correction d'un problème à cause duquel le `maximizeResourceAllocation` paramètre ne réservait pas suffisamment de mémoire pour les ApplicationMaster démons YARN.
+ Résolution d'un problème rencontré avec un DNS personnalisé. Si des entrées dans `resolve.conf` précèdent les entrées personnalisées fournies, les entrées personnalisées ne peuvent pas être résolues. Ce comportement était affecté par des clusters dans un VPC dans lequel le serveur de noms VPC par défaut était inséré comme première entrée dans `resolve.conf`.
+ Résolution d'un problème où la version Python par défaut passait à la version 2.7 et boto n'était pas installé pour cette version.
+ Résolution d'un problème où des conteneurs YARN et des applications Spark généraient un fichier rdd (round robin database) unique Ganglia, si bien que le premier disque attaché à l'instance se remplissait. En raison de ce correctif, les métriques de niveau conteneur YARN ont été désactivées et les métriques de niveau application Spark ont été désactivées.
+ Résolution d'un problème dans le transmetteur de journaux où celui-ci supprimait tous les dossiers de journal vides. De ce fait, l'interface de ligne de commande Hive ne pouvait pas journaliser, car le transmetteur de journaux supprimait le dossier `user` vide sous `/var/log/hive`.
+ Résolution d'un problème affectant les importations Hive qui avait une incidence sur le partitionnement et entraînait une erreur lors de l'importation.
+ Résolution d'un problème où EMRFS et s3-dist-cp ne géraient pas correctement les noms de compartiment qui contenaient des points.
+ Modification d'un comportement dans EMRFS de sorte que dans les compartiments activés pour la gestion des versions, le fichier marqueur `_$folder$` ne soit pas créé en permanence, ce qui peut contribuer à l'amélioration des performances de tels compartiments.
+ Modification d'un comportement dans EMRFS pour ne pas utiliser pas des fichiers d'instruction à l'exception des cas où le chiffrement côté client est activé. Si vous souhaitez supprimer des fichiers d'instruction tout en utilisant le chiffrement côté client, vous pouvez définir la propriété d'emrfs-site.xml `fs.s3.cse.cryptoStorageMode.deleteInstructionFiles.enabled` sur true.
+ Modification de l'agrégation de journaux YARN pour conserver les journaux dans la destination d'agrégation pendant deux jours. La destination par défaut est le stockage HDFS de votre cluster. Si vous souhaitez modifier cette durée, remplacez la valeur `yarn.log-aggregation.retain-seconds` à l'aide de la classification de configuration `yarn-site` lorsque vous créez votre cluster. Comme toujours, vous pouvez enregistrer vos journaux d'applications dans Amazon S3 à l'aide du paramètre `log-uri` lorsque vous créez votre cluster.
### Correctifs appliqués
Les correctifs suivants de projets open source ont été inclus dans cette version :
+ [HIVE-9655](https://issues.apache.org/jira/browse/HIVE-9655)
+ [HIVE-9183](https://issues.apache.org/jira/browse/HIVE-9183)
+ [HADOOP-12810](https://issues.apache.org/jira/browse/HADOOP-12810)
## Version 4.3.0
Date de parution : 19 janvier 2016
### Caractéristiques
Les fonctions suivantes sont disponibles dans cette version :
+ Mise à niveau vers Hadoop 2.7.1
+ Mise à niveau vers Spark 1.6.0
+ Mise à niveau de Ganglia vers la version 3.7.2
+ Mise à niveau vers de Presto vers la version 0.130
Amazon EMR a apporté quelques modifications au paramètre `spark.dynamicAllocation.enabled` lorsque celui-ci est défini sur true ; la valeur par défaut est false. Lorsque ce paramètre est défini sur true, cela a un effet sur les valeurs par défaut définies par le paramètre `maximizeResourceAllocation`.
+ Si `spark.dynamicAllocation.enabled` est défini sur true, `spark.executor.instances` n'est pas défini par `maximizeResourceAllocation`.
+ Le paramètre `spark.driver.memory` est désormais configuré en fonction des types d'instances du cluster d'une manière similaire à la façon dont `spark.executors.memory` est défini. Cependant, étant donné que l'application de pilote Spark peut s'exécuter soit sur le maître, soit sur une des instances principales (par exemple, dans le client YARN et les modes cluster, respectivement), le paramètre `spark.driver.memory` est défini en fonction du type d'instance du plus petit des types d'instances entre ces deux groupes d'instances.
+ Le paramètre `spark.default.parallelism` est désormais défini sur deux fois le nombre de cœurs de processeurs disponibles pour les conteneurs YARN. Dans les versions précédentes, c'était la moitié de cette valeur.
+ Les calculs de la surcharge de mémoire réservée pour les processus Spark YARN ont été ajustés pour être plus précis, ce qui se traduit par une petite augmentation de la quantité de mémoire disponible pour Spark (c'est-à-dire, `spark.executor.memory`).
### Problèmes connus résolus depuis les versions précédentes
+ L'agrégation de journaux YARN est maintenant activée par défaut.
+ Résolution d'un problème où les journaux ne pouvaient pas être transmis vers le compartiment de journaux d'un cluster Amazon S3 lorsque l'agrégation de journaux YARN était activée.
+ Les tailles de conteneur YARN ont maintenant un nouveau minimum de 32 sur tous les types de nœuds.
+ Correction d'un problème lié à Ganglia qui provoquait un excès de disque I/O sur le nœud principal dans les grands clusters.
+ Résolution d'un problème qui empêchait les journaux des applications d'être transmis à Amazon S3 lorsqu'un cluster s'arrêtait.
+ Résolution d'un problème dans l'interface de ligne de commande EMRFS qui entraînait l'échec de certaines commandes.
+ Correction d'un problème lié à Zeppelin qui empêchait le chargement des dépendances dans le sous-jacent. SparkContext
+ Résolution d'un problème provoqué par une tentative de redimensionnement pour ajouter des instances.
+ Résolution d'un problème dans Hive où CREATE TABLE AS SELECT effectuait des appels de liste excessifs vers Amazon S3.
+ Résolution d'un problème où les grands clusters n'étaient pas provisionnés correctement lorsque Hue, Oozie et Ganglia étaient installés.
+ Résolution d'un problème dans s3-dist-cp où un code de sortie zéro était renvoyé même en cas d'échec avec une erreur.
### Correctifs appliqués
Les correctifs suivants de projets open source ont été inclus dans cette version :
+ [OOZIE-2402](https://issues.apache.org/jira/browse/OOZIE-2402)
+ [HIVE-12502](https://issues.apache.org/jira/browse/HIVE-12502)
+ [HIVE-10631](https://issues.apache.org/jira/browse/HIVE-10631)
+ [HIVE-12213](https://issues.apache.org/jira/browse/HIVE-12213)
+ [HIVE-10559](https://issues.apache.org/jira/browse/HIVE-10559)
+ [HIVE-12715](https://issues.apache.org/jira/browse/HIVE-12715)
+ [HIVE-10685](https://issues.apache.org/jira/browse/HIVE-10685)
## Version 4.2.0
Date de parution : 18 novembre 2015
### Caractéristiques
Les fonctions suivantes sont disponibles dans cette version :
+ Ajout de la prise en charge de Ganglia
+ Mise à niveau vers Spark 1.5.2
+ Mise à niveau vers Presto 0.125
+ Mise à niveau d'Oozie vers la version 4.2.0
+ Mise à niveau de Zeppelin vers la version 0.5.5
+ Mise à niveau de la AWS SDK pour Java version 1.10.27
### Problèmes connus résolus depuis les versions précédentes
+ Résolution d'un problème où l'interface de ligne de commande EMRFS n'utilisait pas le nom de table de métadonnées par défaut.
+ Résolution d'un problème rencontré lors de l'utilisation de tables basée sur ORC dans Amazon S3.
+ Résolution d'un problème rencontré avec une incompatibilité de version Python dans la configuration de Spark.
+ Résolution d'un problème où un état de nœud YARN n'était pas signalé en raison de problèmes de DNS pour des clusters dans un VPC.
+ Résolution d'un problème rencontré lorsque YARN mettait hors service des nœuds, qui se traduisait le blocage d'applications ou l'incapacité de planifier de nouvelles applications.
+ Résolution d'un problème rencontré lorsque des clusters prenaient fin avec l'état TIMED\$1OUT\$1STARTING.
+ Résolution d'un problème rencontré lors de l'inclusion de la dépendance EMRFS Scala dans d'autres versions. La dépendance Scala a été supprimée.