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

• emr-record-server version 1.7.0

• Flink version 1.11.2

• Ganglia version 3.7.2

• Hadoop version 3.2.1-amzn-1

• HBaseversion 2.2.6-amzn-0

• HBase-operator-tools 1.0.0

• HCatalogversion 3.1.2-amzn-0

• Hive version 3.1.2-amzn-3

• Hudi version 0.6.0-amzn-1

• Hue version 4.8.0

• JupyterHub version 1.1.0

• Livy version 0.7.0

• MXNetversion 1.7.0

• Oozie version 5.2.0

• Phoenix version 5.0.0

• Pig version 0.17.0

• Presto version 0.238.3-amzn-1

• Presto SQL version 343

• Spark version 3.0.1-amzn-0

• spark-rapids 0.2.0

• TensorFlow version 2.3.1

• Zeppelin version 0.9.0-preview1

• Zookeeper version 3.4.14

• Connecteurs et pilotes : Connecteur DynamoDB 4.16.0

Nouvelles fonctionnalités

• HBase: Suppression du changement de nom lors de la phase de validation et ajout d'un HFile suivi persistant. Consultez la section HFileSuivi permanent dans le guide de EMR mise à jour d'Amazon.

• HBase: Rétroporté Créez une configuration qui oblige à mettre en cache les blocs lors du compactage.

• PrestoDB : améliorations apportées à l'élimination dynamique des partitions. Join Reorder basée sur des règles fonctionne sur des données non partitionnées.

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

• Spark : amélioration des performances dans l'environnement d'exécution de Spark.

Problèmes connus

• Amazon EMR 6.2 possède des autorisations incorrectes définies sur le répertoire the /etc/cron.d/libinstance-controller-java file in EMR 6.2.0. Permissions on the file are 645 (-rw-r--r-x), when they should be 644 (-rw-r--r--). As a result, Amazon EMR version 6.2 does not log instance-state logs, and the /emr/instance -logs qui est vide. Ce problème est résolu dans Amazon EMR 6.3.0 et versions ultérieures.

  Pour contourner ce problème, exécutez le script suivant en tant qu'action d'amorçage lors du lancement du cluster.

  #!/bin/bash
  sudo chmod 644 /etc/cron.d/libinstance-controller-java
              

• Pour les clusters de sous-réseaux privés Amazon EMR 6.2.0 et 6.3.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.

• Amazon EMR 6.2.0 présente un problème selon lequel httpd échoue continuellement, ce qui rend Ganglia indisponible. Le message d'erreur « Impossible de se connecter au serveur » s'affiche. Pour réparer un cluster déjà en cours d'exécution présentant ce problème, accédez SSH au nœud principal du cluster et ajoutez la ligne Listen 80 au fichier httpd.conf situé dans/etc/httpd/conf/httpd.conf. Ce problème est résolu dans Amazon EMR 6.3.0.

• HTTPDéchoue sur les clusters EMR 6.2.0 lorsque vous utilisez une configuration de sécurité. Cela rend l'interface utilisateur de l'application web Ganglia indisponible. Pour accéder à l'interface utilisateur de l'application web Ganglia, ajoutez Listen 80 au fichier /etc/httpd/conf/httpd.conf sur le nœud primaire de votre cluster. Pour plus d'informations sur la connexion à votre cluster, consultez la section Se connecter au nœud principal à l'aide deSSH.

  EMRLes ordinateurs portables ne parviennent pas non plus à établir de connexion avec les clusters EMR 6.2.0 lorsque vous utilisez une configuration de sécurité. Le bloc-notes ne parviendra pas à répertorier les noyaux et à soumettre les tâches Spark. Nous vous recommandons d'utiliser EMR plutôt EMR des blocs-notes avec une autre version d'Amazon.

• 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

  Amazon EMR 6.1.0 et 6.2.0 incluent un problème de performance qui peut affecter de manière critique toutes les opérations d'insertion, de modification et de suppression de Hudi. Si vous envisagez d'utiliser Hudi avec Amazon EMR 6.1.0 ou 6.2.0, vous devez contacter le AWS support pour obtenir un Hudi corrigé. RPM

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

• Les artefacts Amazon EMR 6.2.0 Maven ne sont pas publiés. Ils seront publiés avec une future version d'AmazonEMR.

• Le HFile suivi permanent à l'aide de la table système HBase Storefile ne prend pas en charge la fonctionnalité de réplication des HBase régions. Pour plus d'informations sur HBase la réplication régionale, consultez la section Nombre élevé de lectures disponibles cohérentes avec la chronologie.

• Différences entre les versions de bucket d'Amazon EMR EMR 6.x et 5.x Hive

  EMRLa version 5.x utilise OOS Apache Hive 2, tandis que la version EMR 6.x utilise OOS Apache Hive 3. La version open source Hive2 utilise la version 1 de Bucketing, tandis que la version open source Hive3 utilise la version 2. Cette différence de version entre Hive 2 (EMR5.x) et Hive 3 (EMR6.x) signifie que le hachage des compartiments Hive fonctionne différemment. Consultez l'exemple ci-dessous.

  Le tableau suivant est un exemple créé dans les versions EMR 6.x et EMR 5.x, respectivement.

  -- Using following LOCATION in EMR 6.x
  CREATE TABLE test_bucketing (id INT, desc STRING)
  PARTITIONED BY (day STRING)
  CLUSTERED BY(id) INTO 128 BUCKETS
  LOCATION 's3://your-own-s3-bucket/emr-6-bucketing/';
  
  -- Using following LOCATION in EMR 5.x 
  LOCATION 's3://your-own-s3-bucket/emr-5-bucketing/';

  Insérer les mêmes données dans les versions EMR 6.x et EMR 5.x.

  INSERT INTO test_bucketing PARTITION (day='01') VALUES(66, 'some_data');
  INSERT INTO test_bucketing PARTITION (day='01') VALUES(200, 'some_data');

  La vérification de l'emplacement S3 montre que le nom du fichier de compartiment est différent, car la fonction de hachage est différente entre EMR 6.x (Hive 3) et EMR 5.x (Hive 2).

  [hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-6-bucketing/day=01/
  2020-10-21 20:35:16         13 000025_0
  2020-10-21 20:35:22         14 000121_0
  [hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-5-bucketing/day=01/
  2020-10-21 20:32:07         13 000066_0
  2020-10-21 20:32:51         14 000072_0
  

  Vous pouvez également voir la différence de version en exécutant la commande suivante dans Hive CLI dans la version EMR 6.x. Notez qu'il renvoie la version 2 de compartimentation.

  hive> DESCRIBE FORMATTED test_bucketing;
  ...
  Table Parameters:
      bucketing_version       2
  ...

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

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