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

• Ganglia version 3.7.2

• Hadoop version 3.2.1

• HBaseversion 2.2.3

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

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

Nouvelles fonctionnalités

• YARNDocker Runtime Support : YARN les applications, telles que les tâches Spark, peuvent désormais s'exécuter dans le contexte d'un conteneur Docker. Cela vous permet de définir facilement les dépendances dans une image Docker sans avoir à installer de bibliothèques personnalisées sur votre EMR cluster Amazon. Pour plus d'informations, consultez Configurer l'intégration de Docker et exécuter des applications Spark avec Docker à l'aide d'Amazon EMR 6.0.0.

• LLAPSupport Hive - Hive prend désormais en charge le mode LLAP d'exécution pour améliorer les performances des requêtes. Pour plus d'informations, consultez la section Utilisation de Hive. LLAP

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

• Amazon Linux

  • Amazon Linux 2 est le système d'exploitation de la série de versions EMR 6.x.

  • systemdest utilisé pour la gestion des services au lieu de upstart inAmazon Linux 1.

• Kit de développement Java (JDK)

  • JDKCorretto 8 est la version JDK par défaut pour la série de versions 6.xEMR.

• Scala

  • Scala 2.12 est utilisé avec Apache Spark et Apache Livy.

• Python 3

  • Python 3 est désormais la version par défaut de Python dansEMR.

• YARNétiquettes de nœuds

  • À compter de la série de versions Amazon EMR 6.x, la fonctionnalité d'étiquettes de YARN nœuds 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 fonctionnalité d'étiquettes de YARN nœuds en configurant les propriétés suivantes : yarn.node-labels.enabled etyarn.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.

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

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

• Les fonctionnalités Live Long et Process (LLAP) ne sont pas prises 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 de Spark et Docker, vous devez configurer les instances de votre cluster avec le même type d'instance et le même nombre de EBS volumes afin d'éviter toute défaillance lors de la soumission d'une tâche Spark avec Docker Runtime.

• Dans Amazon EMR 6.0.0, HBase le mode de stockage Amazon S3 est concerné par le problème HBASE-24286. HBasemaster 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 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é.