Amazon EMR version 5.30.1

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

• 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

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 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. Pour un exemple de code, consultez Exemples de commandes pour l'exécution de blocs-notes EMR par programmation.

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

  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

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

  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.

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

     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 <keytab_file> <principal>

    Généralement, le fichier keytab se trouve dans /etc/hadoop.keytab et le principal se présente sous la forme de hadoop/<hostname>@<REALM>.

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