Amazon EMR version 6.3.0

• Versions des applications dans les versions EMR 7.x d'Amazon

• Versions des applications dans les versions 6.x d'Amazon EMR

• Versions des applications dans les versions 5.x d'Amazon EMR

• Versions des applications dans les versions 4.x d'Amazon EMR

Applications prises en charge

• AWS SDK for Java version 1.11.977

• CloudWatch Version 2.1.0 de l'évier

• Connecteur DynamoDB version 4.16.0

• EMRFSversion 2.46.0

• Amazon EMR Goodies version 3.2.0

• Connecteur Amazon EMR Kinesis version 3.5.0

• Amazon EMR Record Server version 2.0.0

• Amazon EMR Scripts version 2.5.0

• Flink version 1.12.1

• Ganglia version 3.7.2

• AWS Client Glue Hive Metastore version 3.2.0

• Hadoop version 3.2.1-amzn-3

• HBaseversion 2.2.6-amzn-1

• HBase-operator-tools 1.0.0

• HCatalogversion 3.1.2-amzn-0

• Hive version 3.1.2-amzn-4

• Hudi version 0.7.0-amzn-0

• Hue version 4.9.0

• JDKVersion Java Corretto-8.282.08.1 (version 1.8.0_282-b08)

• JupyterHub version 1.2.0

• Livy version 0.7.0-incubating

• MXNetversion 1.7.0

• Oozie version 5.2.1

• Phoenix version 5.0.0

• Pig version 0.17.0

• Presto version 0.245.1-amzn-0

• Presto SQL version 350

• Apache Ranger KMS (chiffrement transparent multi-maîtres) version 2.0.0

• ranger-plugins 2.0.1-amzn-0

• ranger-s3-plugin 1.1.0

• SageMaker SDKVersion 1.4.1 de Spark

• Scala version 2.12.10 (machine virtuelle de serveur ouverte JDK 64 bits, Java 1.8.0_282)

• Spark version 3.1.1-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.4.14

• Connecteurs et pilotes : Connecteur DynamoDB 4.16.0

Nouvelles fonctionnalités

• Amazon EMR prend en charge les points d'accès Amazon S3, une fonctionnalité d'Amazon S3 qui vous permet de gérer facilement l'accès aux lacs de données partagés. En utilisant votre alias Amazon S3 Access Point, vous pouvez simplifier l'accès aux données à grande échelle sur AmazonEMR. Vous pouvez utiliser les points d'accès Amazon S3 avec toutes les versions d'Amazon EMR sans frais supplémentaires dans toutes les AWS régions où Amazon EMR est disponible. Pour en savoir plus sur les points d'accès Amazon S3 et les alias de points d'accès, consultez Utilisation d'un alias de type compartiment pour votre point d'accès dans le Guide de l'utilisateur Amazon S3.

• Les nouveaux DescribeReleaseLabel ListReleaseLabel API paramètres fournissent des informations sur les étiquettes EMR de sortie d'Amazon. Vous pouvez répertorier par programmation les versions disponibles dans la région où la API demande est exécutée et répertorier les applications disponibles pour une étiquette de EMR version Amazon spécifique. Les paramètres des étiquettes de version répertorient également les EMR versions d'Amazon qui prennent en charge une application spécifique, telle que Spark. Ces informations peuvent être utilisées pour lancer des clusters Amazon EMR par programmation. Par exemple, vous pouvez lancer un cluster à l'aide de la dernière version des résultats de ListReleaseLabel. Pour plus d'informations, consultez DescribeReleaseLabelet consultez ListReleaseLabelsle Amazon EMR API Reference.

• Avec Amazon EMR 6.3.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. 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 la section Intégrer Amazon EMR à Apache Ranger dans le guide EMR de gestion Amazon.

• 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 EMR définies dans la version v2 en remplacement des politiques qui seront déconseillées. Consultez les politiques EMR gérées par Amazon.

• État du support du service de métadonnées d'instance (IMDS) V2 : pour Amazon EMR 6.2 ou version ultérieure, les EMR composants Amazon sont utilisés IMDSv2 pour tous les IMDS appels. Pour les IMDS appels dans le code de votre application, vous pouvez utiliser les deux IMDSv1 etIMDSv2, ou les configurer IMDS pour les utiliser uniquement IMDSv2 pour renforcer la sécurité. 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

• Il s'agit d'une version destinée à résoudre les problèmes liés à Amazon EMR Scaling lorsqu'il ne parvient pas à augmenter ou à réduire la taille d'un cluster ou entraîne des défaillances d'applications.

• Correction d'un problème en raison duquel les demandes de dimensionnement échouaient pour un cluster volumineux et très utilisé lorsque des EMR démons Amazon présents sur le cluster exécutaient des activités de vérification de l'état, telles que la collecte de l'état du nœud et HDFS de l'état du YARN nœud. Cela était dû au fait que les démons du cluster n'étaient pas en mesure de communiquer les données d'état de santé 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 dimensionnement.

• 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. Correction d'un problème en raison duquel des échecs de tâches se produisaient en raison d'une situation de course lors de la YARN mise hors service lorsque le cluster tentait d'augmenter ou de réduire son échelle.

• Résolution d'un problème lié aux échecs d'étapes ou de tâches lors de la mise à l'échelle du cluster en garantissant que les états des nœuds sont toujours cohérents entre les EMR démons Amazon du cluster et/. YARN HDFS

• Correction d'un problème en raison duquel les opérations de cluster telles que la réduction et la soumission par étapes échouaient pour les EMR clusters Amazon activés avec l'authentification Kerberos. Cela est dû au fait que le démon Amazon EMR on-cluster n'a pas renouvelé le ticket Kerberos, qui est nécessaire pour communiquer en toute sécurité HDFS YARN avec/exécuté sur le nœud principal.

• Les nouvelles EMR versions d'Amazon résolvent le problème en abaissant la limite maximale de fichiers ouverts sur les anciennes versions AL2 d'AmazonEMR. EMRLes 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 incluent désormais un correctif permanent avec un paramètre « Nombre maximum de fichiers ouverts » plus élevé.

• La valeur par défaut du mode d'explication de l'SQLinterface utilisateur de Spark extended est passée de à formatted dans Spark 3.1. Amazon l'EMRa rétabli extended pour inclure les informations du plan logique dans l'SQLinterface utilisateur de Spark. Ceci peut être inversé en définissant spark.sql.ui.explainMode sur formatted.

• Les commits suivants ont été rétroportés depuis la branche master de Spark.

  - [SPARK-34752] [BUILD] Passez Jetty au 9.4.37 à l'adresse -2020-27223. CVE

  - [SPARK-34534] Corrige l' blockIds ordre lors de l'utilisation FetchShuffleBlocks pour récupérer des blocs.

  - [SPARK-34681] [SQL] Correction d'un bogue concernant la jointure par hachage externe complète lors de la construction du côté gauche avec des conditions inégales.

  - [SPARK-34497] [SQL] Corrigez les fournisseurs de JDBC connexion intégrés pour rétablir les modifications du contexte de JVM sécurité.

• Pour améliorer l'interopérabilité avec le RAPIDs plugin Nvidia Spark, une solution de contournement a été ajoutée pour résoudre un problème empêchant le déclenchement de l'élagage dynamique des partitions lors de l'utilisation de Nvidia Spark RAPIDs avec l'exécution adaptative des requêtes désactivée, voir les RAPIDSproblèmes #1378 et # RAPIDS #1386. Pour plus de détails sur la nouvelle configurationspark.sql.optimizer.dynamicPartitionPruning.enforceBroadcastReuse, consultez le RAPIDSnuméro #1386.

• L'algorithme par défaut du validateur de sortie de fichier a été modifié de l'algorithme v2 à l'algorithme v1 dans Spark 3.1 open source. Pour plus d'informations, consultez cet article Amazon EMR optimisant les performances de Spark : élagage dynamique des partitions.

• Amazon EMR est revenu à l'algorithme v2, l'algorithme par défaut utilisé dans les versions précédentes d'Amazon EMR 6.x, pour empêcher la régression des performances. Pour rétablir le comportement de Spark 3.1 open source, définissez spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version sur 1. Le Spark open source a apporté cette modification parce que la validation des tâches dans l'algorithme v2 du validateur de sortie de fichier n'est pas atomique, ce qui peut entraîner un problème d'exactitude des données de sortie dans certains cas. Cependant, la validation des tâches dans l'algorithme v1 n'est pas non plus atomique. Dans certains scénarios, la validation des tâches comprend une suppression effectuée avant un changement de nom. Cela peut entraîner un problème silencieux d'exactitude des données.

• Les problèmes de Managed Scaling rencontrés dans les EMR versions précédentes d'Amazon ont été corrigés et des améliorations ont été apportées afin de réduire de manière significative les taux d'échec des applications.

• Le AWS Java SDK Bundle a été installé sur chaque nouveau cluster. Il s'agit d'un fichier jar unique contenant tous les services SDKs et leurs dépendances, au lieu de fichiers jar de composants individuels. Pour plus d'informations, consultez Java SDK Bundled Dependency.

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 WebUIs, 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.

• Lorsque AWS Glue Data Catalog est activé, l'utilisation de Spark pour accéder à une base de données AWS Glue avec un emplacement de chaîne nul URI peut échouer. Cela se produit pour les EMR versions antérieures d'Amazon, mais SPARK -31709 (https://issues.apache. org/jira/browse/SPARK-31709) le rend applicable à un plus grand nombre de cas. Par exemple, lors de la création d'une table dans la base de données AWS Glue par défaut dont l'emplacement URI est une chaîne nulle, le message « Impossible de créer un chemin à partir d'une chaîne vide » spark.sql("CREATE TABLE mytest (key string) location '/table_path';") échoue. Pour contourner ce problème, définissez manuellement l'emplacement URI de vos bases de données AWS Glue, puis créez des tables dans ces bases de données à l'aide de Spark.

• Dans Amazon EMR 6.3.0, Presto SQL est passé de la version 343 à la version 350. Il y a deux changements liés à la sécurité de l'open source qui se rapportent à ce changement de version. Le contrôle d'accès au catalogue basé sur les fichiers passe de deny à allow lorsque les règles de propriété de table, de schéma ou de session ne sont pas définies. De même, le contrôle d'accès au système basé sur les fichiers est modifié pour prendre en charge les fichiers sans règles de catalogue définies. Dans ce cas, tous les accès aux catalogues sont autorisés.

  Pour plus d'informations, consultez Version 344 (9 octobre 2020).

• Notez que le répertoire utilisateur Hadoop (/) home/hadoop) is readable by everyone. It has Unix 755 (drwxr-xr-x) directory permissions to allow read access by frameworks like Hive. You can put files in /home/hadoop et ses sous-répertoires, mais soyez conscient des autorisations associées à ces répertoires afin de protéger les informations sensibles.

• Réduction de la limite du « nombre maximum de fichiers ouverts » pour les anciennes versions AL2 [corrigée dans les nouvelles versions]. EMRLes versions Amazon : 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 de Linux ofAmazon 2 (), qui ont un paramètre ulimit inférieur pour le « Nombre maximum de fichiers ouverts » lorsque les clusters Amazon sont créés avec la valeur par AL2 défaut. EMR AMI EMRLes 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 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, le paramètre ulimit EMR par défaut d'Amazon AMI est de 4096 pour le « Nombre maximum de fichiers ouverts », ce qui est inférieur à la limite de fichiers de 65536 sous Linux 2. latestAmazon AMI 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 bootstrap (BA) qui ajuste le paramètre ulimit lors de la création du cluster.

  Si vous utilisez une ancienne EMR version d'Amazon qui ne contient pas de solution permanente à ce problème, la solution suivante vous permet de définir explicitement l'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

  2. 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

  EMRles clusters qui exécutent Amazon Linux ou Amazon Linux 2 Amazon Machine Images (AMIs) utilisent le comportement par défaut d'Amazon Linux et ne téléchargent ni n'installent automatiquement les mises à jour importantes et critiques du noyau nécessitant un redémarrage. Ce comportement est identique à celui des autres EC2 instances Amazon qui exécutent Amazon Linux par défautAMI. Si de nouvelles mises à jour logicielles Amazon Linux nécessitant un redémarrage (telles que le noyau et les CUDA mises à jour) sont disponibles après la EMR sortie d'une version d'Amazon, les instances de EMR cluster qui exécutent la version par défaut AMI ne téléchargent ni n'installent automatiquement ces mises à jour. NVIDIA Pour obtenir les mises à jour du noyau, vous pouvez personnaliser votre Amazon EMR AMI pour qu'il utilise la dernière version d'Amazon Linux AMI.

• 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 B EMRFS seront absentes du classpath des exécuteurs Spark lancés par Oozie.

  <spark-opts>--conf spark.yarn.populateHadoopClasspath=true</spark-opts>

• Lorsque vous utilisez Spark avec le formatage de l'emplacement des partitions Hive pour lire des données dans Amazon S3 et que vous exécutez Spark sur Amazon EMR versions 5.30.0 à 5.36.0 et 6.2.0 à 6.9.0, vous pouvez rencontrer un problème empêchant 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 l'autre répertoire de partitions possède une valeur UTF -8 inférieure au / caractère (U+002F). Par exemple, le caractère d'espace (U+0020) 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 la table de codage UTF -8 et les caractères Unicode.

  Pour contourner ce problème, définissez la configuration spark.sql.sources.fastS3PartitionDiscovery.enabled sur false dans la classification spark-defaults.