Amazon EMR version 5.30.0

• 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

Mises à niveau

• Mise à niveau AWS SDK for 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 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 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 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.

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

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

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

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

  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

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

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