Considérations relatives à EMR Studio

EMR Studio est disponible dans les versions suivantes : Régions AWS

* L'interface utilisateur Live de Spark n'est pas prise en charge dans ces régions.

Pour permettre aux utilisateurs de provisionner de nouveaux clusters EMR exécutés sur Amazon EC2 avec un Workspace, vous pouvez rattacher un EMR Studio à un ensemble de modèles de clusters. Les administrateurs peuvent définir des modèles de clusters avec Service Catalog et choisir si un utilisateur ou un groupe peut accéder aux modèles de clusters ou non dans un studio.

Lorsque vous définissez des autorisations d'accès aux fichiers de bloc-notes stockés dans Amazon S3 ou que vous en lisez des secrets AWS Secrets Manager, utilisez le rôle de service Amazon EMR. Les politiques de session ne sont pas prises en charge avec ces autorisations.

Vous pouvez créer plusieurs EMR Studio pour contrôler l'accès aux clusters EMR dans différents VPC.

Utilisez le AWS CLI pour configurer Amazon EMR sur des clusters EKS. Vous pouvez ensuite utiliser l'interface Studio pour rattacher des clusters à des Workspaces avec un point de terminaison géré afin d'exécuter des tâches liées aux blocs-notes.

D’autres considérations s’appliquent à EMR Studio lorsque vous utilisez la propagation d’identité approuvée avec Amazon EMR. Pour plus d’informations, consultez Considérations et limites relatives à l'intégration d'Amazon EMR avec Identity Center.

EMR Studio ne prend pas en charge les commandes magiques suivantes en Python :

Amazon EMR sur les clusters EKS ne prend pas en charge SparkMagic les commandes pour EMR Studio.

Pour écrire des instructions Scala multilignes dans des cellules du bloc-notes, assurez-vous que toutes les lignes, sauf la dernière, se terminent par un point. L'exemple suivant utilise la syntaxe correcte pour les instructions Scala multilignes.

val df = spark.sql("SELECT * from table_name).
        filter("col1=='value'").
        limit(50)

Pour renforcer la sécurité des applications hors console que vous pouvez utiliser avec Amazon EMR, les domaines hébergeant les applications sont enregistrés dans la liste des suffixes publics (PSL). Voici des exemples de ces domaines d’hébergement : emrstudio-prod.us-east-1.amazonaws.com, emrnotebooks-prod.us-east-1.amazonaws.com, emrappui-prod.us-east-1.amazonaws.com. Pour plus de sécurité, si vous avez besoin de définir des cookies sensibles dans le nom de domaine par défaut, nous vous recommandons d’utiliser des cookies avec un préfixe __Host-. Cela vous permettra de protéger votre domaine contre les tentatives de falsification de requêtes intersites (CSRF). Pour plus d’informations, voir la page Set-Cookie du Mozilla Developer Network.

Un studio EMR qui utilise IAM Identity Center avec la propagation d’identité approuvée ne peut être associé qu’aux clusters EMR qui utilisent également la propagation d’identité approuvée.

Avant de créer un Studio, assurez-vous de désactiver les outils de gestion de proxy comme FoxyProxy ou SwitchyOmega dans le navigateur. Les proxys actifs peuvent provoquer des erreurs lorsque vous choisissez Créer un studio et générer un message d'erreur de défaillance du réseau.

Les noyaux qui s'exécutent sur Amazon EMR sur des clusters EKS peuvent ne pas démarrer en raison de problèmes d'expiration du délai. Si vous rencontrez une erreur ou un problème lors du démarrage du noyau, fermez le fichier de bloc-notes, arrêtez le noyau, puis rouvrez le fichier de bloc-notes.

L'opération de redémarrage du noyau ne fonctionne pas comme prévu lorsque vous utilisez un cluster Amazon EMR sur EKS. Après avoir sélectionné Redémarrer le noyau, actualisez le Workspace pour que le redémarrage prenne effet.

Si aucun Workspace n'est rattaché à un cluster, un message d'erreur s'affiche lorsqu'un utilisateur de Studio ouvre un fichier de bloc-notes et tente de sélectionner un noyau. Vous pouvez ignorer ce message d'erreur en choisissant Ok, mais vous devez rattacher le Workspace à un cluster et sélectionner un noyau avant de pouvoir exécuter le code du bloc-notes.

Lorsque vous utilisez Amazon EMR 6.2.0 avec une configuration de sécurité pour configurer la sécurité du cluster, l'interface Workspace apparaît vide et ne fonctionne pas comme prévu. Si vous souhaitez configurer le chiffrement des données ou l'autorisation Amazon S3 pour EMRFS avec un cluster, nous vous recommandons d'utiliser une autre version prise en charge d'Amazon EMR. EMR Studio fonctionne avec les versions 5.32.0 (série Amazon EMR 5.x) ou 6.2.0 (série Amazon EMR 6.x) et les versions ultérieures d’Amazon EMR.

Lorsque vous Déboguer Amazon EMR en cours d'exécution sur Amazon Jobs EC2, les liens vers l'interface utilisateur Spark intégrée au cluster peuvent ne pas fonctionner ou ne pas s'afficher. Pour régénérer les liens, créez une nouvelle cellule de bloc-notes et exécutez la commande %%info.

Jupyter Enterprise Gateway ne nettoie pas les noyaux inactifs sur le nœud primaire d'un cluster dans les versions Amazon EMR suivantes : 5.32.0, 5.33.0, 6.2.0 et 6.3.0. Les noyaux inactifs consomment des ressources informatiques et peuvent entraîner la défaillance de clusters qui fonctionnent depuis longtemps. Vous pouvez configurer le nettoyage du noyau inactif pour Jupyter Enterprise Gateway à l'aide de l'exemple de script suivant. Vous pouvez Connectez-vous au nœud principal à l'aide de SSH, ou soumettre le script en tant qu'étape. Pour plus d'informations, consultez Exécuter des commandes et des scripts sur un cluster Amazon EMR.

#!/bin/bash
sudo tee -a /emr/notebook-env/conf/jupyter_enterprise_gateway_config.py << EOF
c.MappingKernelManager.cull_connected = True
c.MappingKernelManager.cull_idle_timeout = 10800
c.MappingKernelManager.cull_interval = 300
EOF
sudo systemctl daemon-reload
sudo systemctl restart jupyter_enterprise_gateway

Lorsque vous utilisez une politique d'arrêt automatique avec les versions 5.32.0, 5.33.0, 6.2.0 ou 6.3.0 d'Amazon EMR, Amazon EMR marque un cluster comme étant inactif et peut automatiquement le mettre fin à celui-ci, même si vous avez un noyau Python3 actif. Cela est dû au fait que l'exécution d'un noyau Python3 ne soumet pas de tâche Spark sur le cluster. Pour utiliser l'arrêt automatique avec un noyau Python3, nous vous recommandons d'utiliser Amazon EMR version 6.4.0 ou ultérieure. Pour plus d'informations sur l'arrêt automatique, consultez Utilisation d'une politique de résiliation automatique.

Lorsque vous %%display affichez un Spark DataFrame dans un tableau, les tableaux très larges peuvent être tronqués. Cliquez avec le bouton droit sur la sortie et sélectionnez Créer une nouvelle vue pour la sortie afin d'obtenir une vue défilante de la sortie.

Le démarrage d'un noyau basé sur Spark, tel que PySpark Spark ou SparkR, démarre une session Spark, et l'exécution d'une cellule dans un bloc-notes place les tâches Spark dans la file d'attente de cette session. Lorsque vous interrompez une cellule en cours d'exécution, la tâche Spark continue de s'exécuter. Pour arrêter la tâche Spark, vous devez utiliser l'interface utilisateur Spark intégrée au cluster. Pour plus d'informations sur la façon de se connecter à l'interface utilisateur Spark, consultez Déboguer des applications et des tâches avec Studio EMR.

L'utilisation d'Amazon EMR Studio Workspaces en tant qu'utilisateur root dans an Compte AWS provoque une erreur. 403: Forbidden Cela est dû au fait que la configuration de Jupyter Enterprise Gateway dans Amazon EMR n'autorise pas l'accès à l'utilisateur root. Nous vous recommandons de ne pas utiliser l'utilisateur root pour vos tâches quotidiennes. Pour les autres options d'authentification, consultez AWS Identity and Access Management Amazon EMR.

Attacher et exécuter des tâches sur des clusters EMR avec une configuration de sécurité qui spécifie l'authentification Kerberos

Clusters dotés de plusieurs nœuds primaires

Clusters utilisant des instances Amazon EC2 basées sur AWS Graviton2 pour les versions d'Amazon EMR 6.x inférieures à 6.9.0 et 5.x inférieures à 5.36.1

Création de clusters EMR sans modèle

Utilisation d’applications EMR sans serveur

Lancement d’Amazon EMR sur des clusters EKS

Utilisation d’un rôle d’exécution

Activation de la collaboration avec SQL Explorer ou Workspace

Vous pouvez spécifier un maximum de cinq sous-réseaux dans votre VPC à rattacher au studio. Afin de garantir la disponibilité du Workspace et de permettre aux utilisateurs de Studio d'accéder à des clusters dans différentes zones de disponibilité, nous vous recommandons de fournir plusieurs sous-réseaux dans différentes zones de disponibilité. Pour en savoir plus sur l'utilisation des VPC, des sous-réseaux et des zones de disponibilité, consultez la section VPC et sous-réseaux du Guide de l'utilisateur Amazon Virtual Private Cloud .

Les sous-réseaux que vous spécifiez doivent pouvoir communiquer entre eux.

Pour permettre aux utilisateurs de lier un Workspace à des référentiels Git hébergés sur un serveur public, vous devez spécifier uniquement les sous-réseaux privés ayant accès à Internet via la traduction d'adresses réseau (NAT). Pour plus d'informations sur la configuration d'un sous-réseau privé pour Amazon EMR, consultez Sous-réseaux privés.

Lorsque vous utilisez Amazon EMR sur EKS avec EMR Studio, il doit y avoir au moins un sous-réseau commun entre votre studio et le cluster Amazon EKS que vous utilisez pour enregistrer un cluster virtuel. Dans le cas contraire, votre point de terminaison géré n'apparaîtra pas en tant qu'option dans les Workspaces Studio. Vous pouvez créer un cluster Amazon EKS et l'rattacher à un sous-réseau appartenant au studio, ou créer un studio et spécifier les sous-réseaux de votre cluster EKS.

Si vous prévoyez d'utiliser Amazon EMR sur EKS avec EMR Studio, choisissez le même VPC que vos composants master de cluster Amazon EKS.

Le cluster doit fonctionner avec les versions 5.32.0 (série Amazon EMR 5.x) ou 6.2.0 (série Amazon EMR 6.x) et versions ultérieures d'Amazon EMR. Vous pouvez créer un cluster à l'aide de la console Amazon EMR, ou SDK AWS Command Line Interface, puis l'associer à un espace de travail EMR Studio. Les utilisateurs de Studio peuvent également provisionner et rattacher des clusters lors de la création ou de l'utilisation d'un Workspace Amazon EMR. Pour plus d’informations, consultez Associer un ordinateur à un espace de travail de EMR studio.

Le cluster doit se trouver dans un cloud privé virtuel Amazon. La plateforme EC2-Classic n'est pas prise en charge.

Spark, Livy et Jupyter Enterprise Gateway doivent être installés sur le cluster. Si vous envisagez d'utiliser le cluster pour SQL Explorer, vous devez installer Presto et Spark.

Pour utiliser SQL Explorer, le cluster doit fonctionner avec Amazon EMR version 5.34.0 ou ultérieure ou version 6.4.0 ou ultérieure, et Presto doit être installé. Si vous souhaitez spécifier le catalogue AWS Glue Data comme métastore Hive pour Presto, vous devez le configurer sur le cluster. Pour plus d'informations, consultez Utilisation de Presto avec le catalogue de données AWS Glue.

Le cluster doit se trouver dans un sous-réseau privé avec traduction d'adresses réseau (NAT) pour utiliser les référentiels Git hébergés publiquement avec EMR Studio.

Définissez le mode de déploiement pour les sessions Spark sur le mode Cluster. Le mode Cluster place les processus principaux de l'application sur les nœuds principaux et non sur le nœud primaire d'un cluster. Cela soulage le nœud primaire des pressions potentielles sur la mémoire. Pour plus d'informations, consultez Présentation du mode cluster dans la documentation Apache Spark.

Modifiez le délai d'expiration de Livy d'une heure par défaut à six heures, comme dans l'exemple de configuration suivant.

{
    "classification":"livy-conf",
        "Properties":{
            "livy.server.session.timeout":"6h",
            "livy.spark.deploy-mode":"cluster"
        }
}

Créez des flottes d'instances variées comprenant jusqu'à 30 instances et sélectionnez plusieurs types d'instances dans votre flotte d'instances Spot. Par exemple, pour les charges de travail Spark, vous pouvez spécifier les types d'instances à mémoire optimisée suivants : r5.2x, r5.4x, r5.8x, r5.12x, r5.16x, r4.2x, r4.4x, r4.8x, r4.12, etc. Pour plus d’informations, consultez Configuration de parcs d'instances.

Utilisez la stratégie d'allocation optimisée pour les instances Spot afin d'aider Amazon EMR à effectuer des sélections d'instances efficaces, sur la base des informations de capacité en temps réel fournies par Amazon EC2. Pour plus d’informations, consultez Stratégie d'allocation pour les flottes d'instance.

Activer la mise à l'échelle gérée sur votre cluster. Définissez le paramètre « Nombre maximal de nœuds principaux » sur la capacité persistante minimale que vous prévoyez d'utiliser, puis, afin de réduire les coûts, configurez la mise à l'échelle sur une flotte de tâches bien diversifiée qui s'exécute sur des instances Spot. Pour plus d’informations, consultez Utilisation du dimensionnement géré dans Amazon EMR.

Créez un point de terminaison HTTPS géré pour le cluster Amazon EMR sur EKS. Les utilisateurs associent un Workspace à un point de terminaison géré. Le cluster Amazon Elastic Kubernetes Service (EKS) que vous utilisez pour enregistrer un cluster virtuel doit disposer d'un sous-réseau privé pour prendre en charge les points de terminaison gérés.

Utilisez un cluster Amazon EKS avec au moins un sous-réseau privé et une traduction d'adresses réseau (NAT) lorsque vous souhaitez utiliser des référentiels Git hébergés sur un serveur public.

Évitez d'utiliser les AMI Arm Amazon Linux optimisées par Amazon EKS : elles ne sont pas prises en charge pour Amazon EMR sur les points de terminaison gérés par EKS.

Évitez d'utiliser AWS Fargate uniquement des clusters Amazon EKS, qui ne sont pas pris en charge.