Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Exigences relatives au cluster Amazon EMR
Clusters Amazon EMR exécutés sur Amazon EC2
Tous les clusters Amazon EMR exécutés sur Amazon EC2 que vous créez pour un espace de travail EMR Studio doivent répondre aux exigences suivantes. Les clusters que vous créez à l'aide de l'interface EMR Studio répondent automatiquement à ces exigences.
-
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 de plus amples informations, veuillez consulter Attacher un calcul à un espace de travail 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.
Lorsque vous travaillez avec EMR Studio, nous recommandons les configurations de cluster suivantes.
-
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 de plus amples informations, veuillez consulter Planification et configuration de flottes d'instances pour votre cluster Amazon EMR.
-
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 de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter Utiliser la mise à l'échelle gérée dans Amazon EMR.
Nous vous conseillons également de laisser Amazon EMR Block Public Access activé, afin de limiter le trafic SSH entrant à des sources fiables. L'accès entrant à un cluster permet aux utilisateurs d'exécuter des blocs-notes sur le cluster. Pour plus d’informations, consultez Utilisation du blocage de l'accès public Amazon EMR et Contrôlez le trafic réseau avec des groupes de sécurité pour votre cluster Amazon EMR.
Amazon EMR sur des clusters EKS
Outre les clusters EMR exécutés sur Amazon EC2, vous pouvez configurer et gérer les clusters Amazon EMR on EKS pour EMR Studio à l'aide du. AWS CLI Configurez Amazon EMR sur des clusters EKS en suivant les directives suivantes :
-
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 Arm Amazon Linux optimisé pour Amazon EKS AMIs, qui n'est pas pris en charge par 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.