Amazon EMR version 5.30.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

Mises à niveau

• Amélioré AWS SDK for Java vers la version 1.11.759

• Mise à niveau d'Amazon SageMaker Spark SDK vers la version 1.3.0

• Serveur d'EMRenregistrement mis à niveau 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 améliorés : Amazon Glue Connector 1.12.0 ; Amazon Kinesis Connector 3.5.0 ; DynamoDB Connector 4.14.0 EMR

Nouvelles fonctionnalités

• EMRBlocs-notes — Lorsqu'ils sont utilisés avec des EMR clusters créés à l'aide de la version 5.30.0, les noyaux des EMR blocs-notes s'exécutent sur le 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 la section Installation et utilisation des noyaux et des bibliothèques dans le Guide EMR de gestion.

• Dimensionnement géré : avec Amazon EMR version 5.30.0 et versions ultérieures, vous pouvez activer le dimensionnement EMR géré pour augmenter ou diminuer automatiquement le nombre d'instances ou d'unités dans votre cluster en fonction de la charge de travail. Amazon évalue EMR en permanence les indicateurs des clusters afin de prendre des décisions de dimensionnement qui optimisent les coûts et la rapidité de vos clusters. Pour plus d'informations, consultez la section Scaling Cluster Resources dans le guide EMR de gestion Amazon.

• Chiffrer les fichiers journaux stockés dans Amazon S3 — Avec les EMR versions 5.30.0 et ultérieures d'Amazon, vous pouvez chiffrer les fichiers journaux stockés dans Amazon S3 à l'aide d'un AWS KMS clé gérée par le client. Pour plus d'informations, consultez la section Chiffrer les fichiers journaux stockés dans Amazon S3 dans le guide EMR de gestion Amazon.

• Support d'Amazon Linux 2 : dans les EMR versions 5.30.0 et ultérieures, EMR usesAmazon système d'exploitation Linux 2. La nouvelle personnalisation AMIs (Amazon Machine Image) doit être basée sur theAmazon Linux 2AMI. Pour plus d'informations, consultez la section Utilisation d'une personnalisation AMI.

• Presto Graceful Auto Scale : les EMR clusters utilisant la version 5.30.0 peuvent être définis avec un délai de mise à l'échelle automatique qui donne aux tâches Presto le temps de terminer leur exécution avant que leur nœud ne soit mis 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 EMR versions 5.12.1 et ultérieures. 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 EMR service autres que ceux par défaut sont requises. Consultez Configuration de parcs d'instances.

• Commandes sudo systemctl stop et sudo systemctl start : dans les EMR versions 5.30.0 et ultérieures, quel système d'exploitation useAmazon Linux 2 utilise et commande pour redémarrer les services. EMR sudo systemctl stop sudo systemctl start Pour plus d'informations, consultez Comment redémarrer un service sur Amazon EMR ? .

Modifications, améliorations et problèmes résolus

• EMRla 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 EMR version par défaut d'Amazon 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 Amazon EMR -Managed Security Group for Service Access (sous-réseaux privés). Si vous utilisez un rôle de service personnalisé pour AmazonEMR, vous devez accorder l'autorisation ec2:describeSecurityGroups EMR afin de valider si les groupes de sécurité ont été 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]. 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

• 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 EMR versions 5.30.0 et 5.30.1 d'Amazon, 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 principaux et une authentification Kerberos dans les EMR versions 5.20.0 et ultérieures d'Amazon, vous risquez de rencontrer des problèmes avec les opérations de cluster, telles que la réduction ou la soumission par étapes, une fois le cluster en cours d'exécution 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 :

  • SSHen tant qu'hadooputilisateur du nœud principal du EMR cluster comportant plusieurs nœuds principaux.

  • 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 estSQLite, 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 EMR version 5.30.1 d'Amazon.

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