Foire aux questions sur Amazon EMR

Amazon EMR est la plateforme de big data cloud leader du secteur pour le traitement des données, l'analyse interactive et le machine learning à l'aide de cadres open source, tels que Apache Spark, Apache Hive et Presto. EMR vous permet d'exécuter des analyses à l'échelle des pétaoctets à des coûts inférieurs de moitié à ceux des solutions sur site traditionnelles et à une vitesse 1,7 fois plus rapide que celle d'un moteur Apache Spark standard.

Amazon EMR vous permet de vous concentrer sur la transformation et l'analyse de vos données sans avoir à vous soucier de la gestion de la capacité de calcul ou des applications open source, tout en réalisant des économies. Grâce à EMR, vous pouvez instantanément allouer autant ou aussi peu de capacité que vous le souhaitez sur Amazon EC2 et définir des règles de mise à l'échelle pour gérer l'évolution de la demande de calcul. Vous pouvez configurer des alertes CloudWatch pour être informé des changements dans votre infrastructure et prendre des mesures immédiatement. Si vous utilisez Kubernetes, vous pouvez également utiliser EMR pour soumettre vos charges de travail aux clusters Amazon EKS. Que vous utilisiez EC2 ou EKS, vous bénéficiez des temps d'exécution optimisés d'EMR qui accélèrent vos analyses et vous font gagner du temps et de l'argent.

Vous pouvez déployer vos charges de travail sur EMR à l'aide d'Amazon EC2, d'Amazon Elastic Kubernetes Service (EKS) ou d'AWS Outposts sur site. Vous pouvez exécuter et gérer vos charges de travail à l'aide de la console EMR, de l'API, du kit SDK ou de CLI, et les orchestrer en utilisant Amazon Managed Workflows for Apache Airflow (MWAA) ou d'AWS Step Functions. Pour une expérience interactive, vous pouvez utiliser EMR Studio ou SageMaker Studio.

Pour vous inscrire à Amazon EMR, cliquez sur le bouton « S'inscrire maintenant » sur la page détaillée d'Amazon EMR http://aws.amazon.com/emr. Vous devez être inscrit à Amazon EC2 et Amazon S3 pour accéder à Amazon EMR ; si vous n'êtes pas inscrit à ces services, il vous sera demandé d'y remédier au cours du processus d'inscription à Amazon EMR. Une fois que vous êtes inscrit, consultez la documentation Amazon EMR qui inclut notre Guide de démarrage – le meilleur endroit pour commencer avec le service.

Consultez notre Contrat de niveau de service (SLA).

Consultez les exemples de code dans ces articles et tutoriels. Si vous utilisez EMR Studio, vous pouvez explorer les fonctions à l'aide d'un ensemble d'exemples de blocs-notes.

Vous pouvez développer, visualiser et déboguer des applications de science et d'ingénierie des données écrites en R, Python, Scala et PySpark dans Amazon EMR Studio. Vous pouvez également développer une tâche de traitement des données sur votre bureau, par exemple à l'aide d'Eclipse, de Spyder, de PyCharm ou de RStudio, et l'exécuter sur Amazon EMR. En outre, vous pouvez sélectionner JupyterHub ou Zeppelin dans la configuration logicielle lors du démarrage d'un nouveau cluster et développer votre application sur Amazon EMR en utilisant une ou plusieurs instances.

Les outils de ligne de commande fournissent la possibilité de lancer et de surveiller via un programme l'avancement des clusters en cours, de créer une fonctionnalité supplémentaire personnalisée autour des clusters (comme les séquences avec de multiples étapes de traitement, de planification, de flux de travail ou de surveillance) ou de créer des outils à valeur ajoutée ou des applications pour d'autres clients Amazon EMR. Par contraste, AWS Management Console fournit une interface graphique facile à utiliser pour le lancement et la surveillance de vos clusters directement de votre navigateur Web.

Oui. Une fois que le travail est en cours, vous pouvez ajouter d'autres étapes en option par l'intermédiaire de l'API AddJobFlowSteps. L'API AddJobFlowSteps ajoute de nouvelles étapes à la fin de la séquence d'étape. Vous pouvez utiliser cette API pour mettre en œuvre une logique conditionnelle dans votre cluster ou pour le débogage.

Vous pouvez vous inscrire à Amazon SNS et le cluster publiera sur votre rubrique SNS lorsque cela sera terminé. Vous pouvez également afficher la progression de votre cluster sur la console de gestion AWS ou utiliser la ligne de commande, le kit SDK ou les API pour obtenir un statut sur le cluster.

Oui. Vous pouvez résilier automatiquement votre cluster lorsque toutes vos étapes sont terminées. Pour ce faire, activez l'indicateur de résiliation automatique.

Amazon EMR 5.30.0 et versions ultérieures, et Amazon EMR version 6.x sont basés sur Amazon Linux 2. Vous pouvez également spécifier une AMI personnalisée que vous créez à partir d'Amazon Linux 2. Cela vous permet de réaliser une préconfiguration sophistiquée pour à peu près n'importe quelle application. Pour en savoir plus, consultez la section Utilisation d'une image AMI personnalisée.

Oui. Vous pouvez utiliser les actions d'amorçage pour installer des packages logiciels tiers sur votre cluster. Vous pouvez également charger des exécutables compilés de manière statique en utilisant le mécanisme de cache distribué Hadoop. EMR 6.x prend en charge Hadoop 3, qui permet à YARN NodeManager de lancer des conteneurs directement sur l'hôte du cluster EMR ou à l'intérieur d'un conteneur Docker. Pour en savoir plus, consultez notre documentation.

Il existe plusieurs outils que vous pouvez utiliser pour rassembler des informations sur votre cluster et déterminer les problèmes éventuels. Si vous utilisez Amazon EMR Studio, vous pouvez lancer des outils comme Spark UI et YARN Timeline Service pour simplifier le débogage. De la console Amazon EMR, vous pouvez bénéficier d'un accès hors cluster aux interfaces utilisateur d'applications persistantes pour Apache Spark, l'IU Tez et le serveur de chronologie YARN, à plusieurs interfaces utilisateur d'applications sur le cluster, et à un résumé de l'historique d'application dans la console Amazon EMR pour toutes les applications YARN. Vous pouvez également vous connecter à votre nœud principal en utilisant SSH et visualiser les instances du cluster via ces interfaces web. Pour en savoir plus, consultez notre documentation.

EMR Studio est un environnement de développement intégré (IDE) qui permet aux scientifiques et ingénieurs des données de facilement développer, visualiser et déboguer les applications d'ingénierie et de science des données écrites en R, Python, Scala et PySpark.

Il s'agit d'une application entièrement gérée avec blocs-notes Jupyter entièrement gérés à authentification unique, un provisionnement automatisé de l'infrastructure, et la faculté de déboguer les tâches sans connexion à la console AWS ou au cluster. Les scientifiques des données et les analystes peuvent installer des noyaux et des bibliothèques personnalisés, collaborer avec des pairs à l'aide de référentiels de code tels que GitHub et BitBucket, ou exécuter des blocs-notes paramétrés dans le cadre de flux de travail planifiés à l'aide de services d'orchestration comme Apache Airflow, AWS Step Functions et Amazon Managed Workflows pour Apache Airflow. Vous pouvez lire des tâches d'analyse d'orchestration sur des blocs-notes Amazon EMR au moyen d'Amazon MWAA pour en savoir plus. Les noyaux et applications EMR Studio s’exécutent sur des clusters EMR. Vous bénéficiez ainsi du traitement de données distribué en utilisant l’environnement d’exécution Amazon EMR pour Apache Spark aux performances optimisées. Les administrateurs peuvent configurer EMR Studio pour que les analystes puissent exécuter leurs applications dans les clusters EMR existants ou créer des clusters à l'aide de modèles AWS CloudFormation prédéfinis pour EMR.

Avec EMR Studio, vous pouvez vous connecter directement à des blocs-notes Jupyter entièrement gérés à l'aide de vos identifiants d'entreprise sans devoir accéder à la console AWS, démarrer des blocs-notes en quelques secondes, faire vos premiers pas avec des exemples de blocs-notes, et procéder à l'exploration de vos données. Vous pouvez également personnaliser votre environnement en chargeant des noyaux et bibliothèques Python personnalisés à partir des blocs-notes. Les noyaux et applications EMR Studio s’exécutent sur des clusters EMR. Vous bénéficiez ainsi du traitement de données distribué en utilisant l’environnement d’exécution Amazon EMR pour Apache Spark aux performances optimisées. Vous pouvez partager vos blocs-notes avec des pairs grâce à GitHub et à d'autres référentiels. Vous pouvez également exécuter directement les blocs-notes en tant que pipelines d'intégration et de déploiement continus. Vous pouvez transmettre différentes valeurs de paramètres à un bloc-notes. Vous pouvez également associer des blocs-notes et intégrer des blocs-notes à des flux de travail planifiés à l'aide de services d'orchestration de flux de travail, comme Apache Airflow. En outre, vous pouvez déboguer des clusters et tâches en quelques clics au moyen d'interfaces d'applications natives, telles que l'IU Spark et le service de chronologie YARN.

Il existe cinq différences principales.

1. L'utilisation d'EMR Studio n'implique pas de devoir accéder à AWS Management Console. EMR Studio est hébergé en dehors d'AWS Management Console. Cela s'avère utile si vous n'accordez pas l'accès à la console de gestion AWS aux scientifiques ou aux ingénieurs de données.

2. Vous pouvez utiliser les informations d'identification d'entreprise de votre fournisseur d'identité à l'aide de AWS IAM Identity Center (successeur d'AWS SSO) pour vous connecter à EMR Studio. 

3. EMR Studio vous offre une toute première expérience du blocs-notes. Les noyaux et applications EMR Studio s’exécutent sur des clusters EMR. Vous bénéficiez ainsi du traitement de données distribué en utilisant l’environnement d’exécution Amazon EMR pour Apache Spark aux performances optimisées. L'exécution de code sur un cluster s'avère être aussi simple que de lier le bloc-notes à un cluster existant ou d'en allouer un nouveau.

4. EMR Studio est doté d'une interface utilisateur simplifiée et élimine la nécessité des configurations matérielles. Par exemple, vous pouvez configurer des modèles de cluster une seule fois, et les utiliser pour démarrer de nouveaux clusters. 

5. EMR Studio offre une expérience de débogage simplifiée, de sorte que vous pouvez accéder aux interfaces utilisateur d'applications natives en un endroit et en quelques clics seulement.

Vous pouvez utiliser à la fois EMR Studio et SageMaker Studio avec Amazon EMR. EMR Studio fournit un environnement de développement intégré (IDE) qui vous permet de facilement développer, visualiser et déboguer les applications d'ingénierie et de science des données écrites en R, Python, Scala et PySpark. Amazon SageMaker Studio fournit une interface visuelle unique, basée sur le web, qui vous permet de mettre en œuvre toutes les étapes du développement de machine learning. Grâce à SageMaker Studio, vous avez un accès, un contrôle et une visibilité complets sur chaque étape nécessaire à la création, à la formation et au déploiement de modèles. Vous pouvez télécharger des données, créer des blocs-notes, entraîner et affiner des modèles, faire des aller-retours entre les étapes pour ajuster les expériences, comparer les résultats et déployer des modèles en production ; le tout rapidement et au même endroit, ce qui accroît votre productivité. 

Votre administrateur doit d'abord configurer un studio EMR. Dès que vous recevez de votre administrateur une URL d'authentification unique pour votre Amazon EMR Studio, vous pouvez vous y connecter directement à l'aide des identifiants d'entreprise.

Non. Après que votre administrateur a configuré un EMR Studio et vous a communiqué l'URL d'accès Studio, votre équipe peut se connecter à l'aide des informations d’identification d'entreprise. Il n'est nullement nécessaire de se connecter à AWS Management Console. Dans un EMR Studio, votre équipe peut effectuer des tâches et accéder à des ressources configurées par votre administrateur.

AWS IAM Identity Center (successeur d'AWS SSO) est le fournisseur de services d'authentification unique pour EMR Studio. Vous trouverez la liste des fournisseurs d'identités pris en charge par AWS IAM dans notre documentation.

Les WorkSpaces vous aident à organiser vos blocs-notes Jupyter. Tous les blocs-notes dans un WorkSpace sont enregistrés au sein du même emplacement Amazon S3 et s'exécutent sur le même cluster. Vous pouvez également lier un référentiel de code, comme un référentiel GitHub, à tous les blocs-notes se trouvant dans un WorkSpace. Vous pouvez créer et configurer un WorkSpace avant de le lier à un cluster, mais vous devez vous connecter à un cluster avant d'exécuter un bloc-notes.

Oui, vous pouvez créer ou ouvrir un WorkSpace sans le lier à un cluster. Notez toutefois que pour l'exécution, vous devez le connecter à un cluster. Les noyaux et applications EMR Studio sont exécutés dans des clusters EMR. Vous bénéficiez ainsi du traitement de données distribué en utilisant l'environnement d'exécution Amazon EMR pour Apache Spark aux performances optimisées.

Toutes les requêtes Spark s'exécutant sur votre cluster EMR, vous devez donc installer toutes les bibliothèques d'exécution utilisées par votre application Spark sur le cluster. Vous pouvez aisément installer des bibliothèques de portée bloc-notes dans une cellule de bloc-notes. Vous pouvez également installer les noyaux Jupyter Notebook et les bibliothèques Python sur un nœud principal du cluster, soit à l'intérieur d'une cellule Notebook, soit en étant connecté au nœud principal du cluster via SSH. Pour plus d'informations, consultez la documentation. En outre, vous pouvez utiliser une action d'amorçage ou une AMI personnalisée pour installer les bibliothèques requises lorsque vous créez un cluster. Pour plus d'informations, consultez Création d'actions d'amorçage pour installer des logiciels supplémentaires et Utilisation d'une image AMI personnalisée dans le guide de gestion Amazon EMR.

L'espace de travail ainsi que les fichiers du bloc-notes qu'il contient sont enregistrés automatiquement à intervalles réguliers au format de fichier ipynb dans l'emplacement Amazon S3 que vous spécifiez lors de la création de l'espace de travail. Le fichier de bloc-notes porte le même nom que votre bloc-notes dans Amazon EMR Studio.

Vous pouvez associer des référentiels basés sur Git à vos blocs-notes Amazon EMR Studio pour enregistrer vos blocs-notes dans un environnement contrôlé.

Avec EMR Studio, vous pouvez exécuter du code de bloc-notes sur Amazon EMR s'exécutant sur Amazon Elastic Compute Cloud (Amazon EC2) ou Amazon EMR sur Amazon Elastic Kubernetes Service (Amazon EKS). Vous pouvez lier des blocs-notes à des clusters nouveaux ou existants. Vous pouvez créer des clusters EMR de deux manières différentes dans EMR Studio : soit en utilisant un modèle de cluster pré-configuré via AWS Service Catalog, soit en spécifiant le nom du cluster, le nombre d'instances et le type d'instance.

Oui. Vous pouvez ouvrir votre WorkSpace, sélectionner l'icône EMR Clusters (Clusters EMR) sur la gauche, appuyer sur le bouton Detach (Délier), puis sélectionner un cluster depuis le menu déroulant Select cluster (Sélectionner le cluster), et appuyer sur le bouton Attach (Lier).

Dans EMR Studio, vous pouvez sélectionner l'onglet WorkSpaces sur la gauche et consulter tous les WorkSpaces que vous et d'autres utilisateurs avez créés au sein du même compte AWS.

Chaque EMR Studio a besoin d'autorisations pour interagir avec d'autres services AWS. Pour octroyer à vos EMR Studios les autorisations nécessaires, vos administrateurs doivent créer un rôle de service EMR Studio avec les stratégies fournies. Ils doivent également spécifier pour EMR Studio un rôle utilisateur qui définit les autorisations au niveau Studio. Lorsqu'ils ajoutent des utilisateurs et des groupes à EMR Studio à partir d'AWS IAM Identity Center (successeur d'AWS SSO), les administrateurs peuvent attribuer une politique de session à un utilisateur ou un groupe, afin de mettre en place des contrôles d'autorisation précis. Les politiques de session permettent aux administrateurs d'améliorer les autorisations utilisateur sans devoir créer plusieurs rôles IAM. Pour en savoir plus sur les stratégies de session, reportez-vous à la section Politiques et autorisations du Guide de l'utilisateur AWS Identity and Access Management.

Oui. Les clusters à haute disponibilité (multimaître), les clusters kerberisés et les clusters AWS Lake Formation ne sont actuellement pas pris en charge.

Amazon EMR Studio vous est fourni sans frais supplémentaires. Les frais en vigueur pour le stockage Amazon Simple Storage Service et les clusters Amazon EMR s'appliquent lorsque vous utilisez EMR Studio. Pour plus d'informations sur les détails et options de tarification, consultez Tarification Amazon EMR.

Nous recommandions aux nouveaux clients d'utiliser Amazon EMR Studio, et non pas EMR Notebooks. Les blocs-notes EMR Notebooks offrent un environnement géré, basé sur le bloc-notes Jupyter, qui permet aux scientifiques, analystes et développeurs de données de préparer et de visualiser les données, de collaborer avec leurs pairs, de créer des applications et d'effectuer des analyses interactives en utilisant les clusters EMR. Bien que nous recommandions aux nouveaux clients d'utiliser EMR Studio, EMR Notebooks est pris en charge pour des raisons de compatibilité.

Vous pouvez utiliser EMR Notebooks pour créer des applications Apache Spark et exécuter des requêtes interactives sur votre cluster EMR avec un minimum d'effort. Plusieurs utilisateurs peuvent créer des blocs-notes serverless directement à partir de la console, les joindre à un cluster EMR partagé existant, ou allouer un cluster directement à partir de la console et commencer immédiatement à expérimenter avec Spark. Vous pouvez délier les blocs-notes et les relier à de nouveaux clusters. Les Notebooks sont automatiquement sauvegardés vers des compartiments S3, et vous pouvez récupérer les blocs-notes sauvegardés à partir de la console afin de reprendre le travail. Les Blocs-EMR Notebooks sont préconditionnés avec les bibliothèques qui se trouvent dans le répertoire Anaconda, vous permettant d’importer et d’utiliser ces bibliothèques dans le code de vos blocs-notes et de les utiliser pour manipuler les données et visualiser les résultats. De plus, les blocs-EMR Notebooks ont intégré des fonctionnalités de contrôle Spark que vous pouvez utiliser afin de contrôler la progression de vos tâches Spark et déboguer le code à partir du blocs-notes.

Pour démarrer avec les Blocs-EMR Notebooks, ouvrez la console EMR et sélectionnez Blocs-notes dans le panneau de navigation. À partir de là, il vous suffit de sélectionner Créer un Bloc-notes , de saisir un nom pour votre Bloc-notes, de choisir un cluster EMR ou d'en créer un nouveau instantanément, de lui attribuer un rôle de service et de choisir un compartiment S3 dans lequel vous souhaitez enregistrer vos fichiers de bloc-notes, puis cliquez sur Créer un bloc-notes. Une fois que le bloc-notes affiche un statut Prêt , sélectionnez Ouvrir pour lancer l'éditeur de bloc-notes.

Les blocs-notes EMR Notebooks peuvent être associés aux clusters EMR exécutant la version EMR 5.18.0 ou ultérieure.

Les services EMR Notebooks vous sont fournis sans frais supplémentaires. Vous serez facturé comme d'habitude pour les clusters EMR liés à votre compte. Pour en savoir plus sur la tarification de votre cluster, consultez https://aws.amazon.com/emr/pricing/ 

Amazon EMR permet de transférer des données sur un cluster de plusieurs manières différentes. La méthode la plus courante consiste à charger les données vers Amazon S3 et à utiliser les fonctionnalités intégrées d'Amazon EMR pour charger les données sur votre cluster. Vous pouvez utiliser la fonctionnalité de cache distribué d'Hadoop pour transférer des fichiers d'un système de fichiers distribué à un système de fichiers local. Pour plus de détails, consultez la documentation. Autrement, si vous migrez des données de votre site vers le cloud, vous pouvez utiliser l'un des services Cloud Data Migration d'AWS.

Les journaux système Hadoop, ainsi que les journaux utilisateur, sont placés dans le compartiment Amazon S3 que vous spécifiez quand vous créez un cluster. Les IU d'applications persistantes sont exécutées hors cluster ; les journaux du serveur d'historique Spark, de l'IU Tez et des serveurs de chronologie YARN sont disponibles pendant 30 jours après résiliation d'une application.

Actuellement Amazon EMR ne compresse pas les journaux puisqu'il les déplace vers Amazon S3.

Q : Compressez-vous les journaux ?

Oui. Vous pouvez utiliser AWS Direct Connect pour établir une connexion réseau dédiée privée vers AWS. Si vous disposez de grandes quantités de données, vous pouvez utiliser AWS Import/Export. Pour en savoir plus, reportez-vous à notre documentation.

Non. Comme chaque cluster et chaque donnée d'entrée sont différents, nous ne pouvons pas estimer la durée de votre travail.

La tarification pour Amazon EMR est simple et prévisible : vous payez à la seconde ce que vous utilisez avec un forfait d'une minute minimum. Vous pouvez calculer votre facture à l'aide du calculateur de tarification AWS. L'utilisation des autres services Amazon Web Services, y compris Amazon EC2, est facturée séparément d'Amazon EMR.

La facturation Amazon EMR commence lorsque le cluster est prêt à exécuter les étapes. La facturation Amazon EMR se termine lorsque vous demandez de fermer le cluster. Pour plus d'informations sur les dates de début et de fin de la facturation Amazon EC2, consultez la section FAQ sur la facturation Amazon EC2.

Vous pouvez effectuer le suivi de votre utilisation dans la console de facturation et de gestion des coûts.

Dans AWS Management Console, chaque cluster possède une colonne Heures-instances normalisées qui affiche le nombre approximatif d'heures de calcul utilisées par le cluster, arrondi à l'heure la plus proche.

Les heures-instances normalisées sont des heures de temps de calcul basées sur la norme de 1 heure d'utilisation de m1.small = 1 heure de temps de calcul normalisée. Vous pouvez consulter notre documentation pour bénéficier d'une liste des tailles différentes au sein d'une famille d'instance, et du facteur de normalisation correspondant par heure.

Par exemple, si vous exécutez un cluster r3.8xlarge à 10 nœuds pendant une heure, le nombre total d'heures-instances normalisées affiché sur la console sera de 640 (10 (nombre de nœuds) x 64 (facteur de normalisation) x 1 (nombre d'heures d'exécution du cluster) = 640).

Il s'agit d'un nombre approximatif qui ne doit pas être utilisé à des fins de facturation. Consultez la console de facturation et de gestion des coûts pour connaître l'utilisation d'Amazon EMR facturable.

Oui. Amazon EMR prend en charge à la fois des instances à la demande, Spot et réservées sans problème. Cliquez ici pour en savoir plus sur les instances réservées Amazon EC2. Cliquez ici pour en savoir plus sur les instances Spot Amazon EC2. Cliquez ici pour en savoir plus sur les réservations de capacité Amazon EC2.

Sauf indication contraire, nos prix n'incluent pas les taxes et redevances applicables, y compris la TVA et les taxes sur les ventes applicables. Pour les clients dont l'adresse de facturation est située au Japon, l'utilisation de services AWS est soumise à la taxe sur la consommation applicable dans ce pays. En savoir plus. 

Amazon EMR démarre vos instances dans deux groupes de sécurité Amazon EC2, l’un pour le nœud principal et l’autre pour les autres nœuds du cluster. Le groupe de sécurité maître possède un port ouvert pour la communication avec le service. Il dispose également d'un port SSH ouvert pour vous permettre d'utiliser le protocole SSH vers les instances, en utilisant la clé spécifiée au démarrage. Les autres nœuds démarrent dans un groupe de sécurité distinct, qui autorise uniquement l'interaction avec l'instance principale. Par défaut, les deux groupes de sécurité sont définis afin de ne pas autoriser l'accès à des ressources externes, y compris les instances Amazon EC2 appartenant à d'autres clients. Puisqu'il s'agit de groupes de sécurité à l'intérieur de votre compte, vous pouvez les reconfigurer en utilisant les outils standard EC2 ou le tableau de bord. Cliquez ici pour en savoir plus sur les groupes de sécurité EC2. En outre, vous pouvez configurer l'accès public aux blocs Amazon EMR dans chaque région que vous utilisez afin d'empêcher la création de clusters si une règle autorise l'accès public sur n'importe quel port que vous n'ajoutez pas à une liste d'exceptions.

Amazon S3 fournit les mécanismes d'authentification pour s'assurer que les données stockées sont sécurisées contre un accès non autorisé. Sauf indication contraire par le client qui télécharge les données, seul ce client peut accéder aux données. Les clients Amazon EMR peuvent également choisir d'envoyer les données à Amazon S3 en utilisant le protocole HTTPS pour une transmission sécurisée. De plus, Amazon EMR utilise toujours HTTPS pour envoyer des données entre Amazon S3 et Amazon EC2. Pour une sécurité renforcée, il se peut que les clients chiffrent les données d'entrée avant de les télécharger vers Amazon S3 (en utilisant un outil de chiffrement des données quelconque) ; ils ont ensuite besoin d'une étape de déchiffrement jusqu'au début de leur cluster quand Amazon EMR va chercher les données depuis Amazon S3.

Oui. AWS CloudTrail est un service Web qui enregistre les appels d'API AWS pour votre compte et vous les présente sous forme de fichier journal. L’historique des appels d’API AWS généré par CloudTrail permet de réaliser une analyse de sécurité, le suivi des modifications au niveau des ressources, ainsi que l’audit de conformité. Pour en savoir plus sur CloudTrail, consultez la page de présentation détaillée d'AWS CloudTrail et, pour l'activer, utilisez la console de gestion AWS de CloudTrail.

Par défaut, les processus d'application Amazon EMR utilisent les profils d'instance EC2 lorsqu'ils appellent d'autres services AWS. Pour les clusters à locataires multiples, Amazon EMR offre trois options afin de gérer l'accès des utilisateurs aux données Amazon S3.

1. L’intégration avec AWS Lake Formation vous permet de définir et de gérer des stratégies d’autorisation précises dans AWS Lake Formation pour accéder aux bases de données, tableaux et colonnes du catalogue de données AWS Glue. Vous pouvez appliquer les stratégies d’autorisation aux tâches soumises via les Blocs-notes Amazon EMR et Apache Zeppelin pour les charges de travail EMR Spark interactives, et envoyer les événements d’audit à AWS CloudTrail. En permettant cette intégration, vous permettez également une authentification unique fédérée pour EMR Notebooks ou Apache Zeppelin à partir de systèmes d'identité d'entreprise compatibles avec Security Assertion Markup Language (SAML) 2.0.

2. Grâce à l’intégration native avec Apache Ranger, vous pouvez configurer un nouveau serveur ou un serveur existant Apache Ranger afin de définir et de gérer des stratégies d’autorisation précises permettant aux utilisateurs d’accéder aux bases de données, tables et colonnes de données Amazon S3 via Hive Metastore. Apache Ranger est un outil open source qui active, surveille et gère la sécurité exhaustive des données sur la plateforme Hadoop.
   
   Cette intégration native vous permet de définir trois types de stratégies d’autorisation sur le serveur Policy Admin Apache Ranger. Vous pouvez configurer des autorisations au niveau des lignes, colonnes et tables pour Hive, au niveau des colonnes et des tables pour Spark, et au niveau des objets et des préfixes pour Amazon S3. Amazon EMR installe et configure automatiquement les modules d'extension Apache Ranger correspondants sur le cluster. Ces modules d’extension Ranger se synchronisent avec le serveur Policy Admin pour les stratégies d’autorisation, appliquent des contrôles d’accès aux données et envoient des événements d’audit à Amazon CloudWatch Logs.

3. Amazon EMR User Role Mapper vous permet d’exploiter les autorisations AWS IAM pour gérer les accès aux ressources AWS. Vous pouvez créer des mappages entre les utilisateurs (ou groupes) et personnaliser les rôles IAM. Un utilisateur ou un groupe ne peut accéder qu'aux données autorisées par le rôle IAM personnalisé. Cette fonctionnalité est actuellement disponible via AWS Labs.

Amazon EMR lance tous les nœuds pour un cluster donné dans la même zone de disponibilité Amazon EC2. Exécuter un cluster dans la même zone améliore la performance des flux de travail. Par défaut, Amazon EMR choisit la zone de disponibilité avec les ressources les plus disponibles dans lesquelles vous pouvez exécuter votre cluster. Cependant, vous pouvez spécifier une autre zone de disponibilité si nécessaire. Vous avez également la possibilité d'optimiser votre allocation pour obtenir des instances à la demande au prix le plus bas, une capacité ponctuelle optimale, ou d'utiliser les réservations de capacité à la demande.

Pour obtenir la liste des régions AWS prenant en charge Amazon EMR, consultez le tableau des régions AWS qui constitue un aperçu de toute l’infrastructure mondiale AWS.

EMR prend en charge le lancement de clusters dans la zone locale AWS de Los Angeles. Vous pouvez utiliser EMR dans la région USA Ouest (Oregon) pour lancer des clusters dans les sous-réseaux associés à la zone locale AWS de Los Angeles.

Quand vous créez un cluster, vous devez généralement sélectionner la région dans laquelle vos données sont situées.

Oui, vous pouvez. Si vous transférez des données d'une région à l'autre, des frais de bande passante vous seront facturés. Pour obtenir des informations sur les tarifs de bande passante, consultez la section Tarifs à la page de détaillée EC2.

La région AWS GovCloud (US) est destinée aux agences et clients de l'administration américaine. Elle respecte la réglementation américaine contre le trafic d'armes au niveau international (ITAR). Au sein de la région GovCloud, EMR ne prend pas en charge les instances Spot ou la fonction d'activation du débogage. La console de gestion EMR n'est pour l'instant pas disponible dans la région GovCloud.

Amazon EMR sur Amazon EC2

Amazon EMR sur Amazon EKS

Amazon EMR sur AWS Outposts

Lancement

Gérer

Balisage

Un cluster est une collection d'instances Amazon Elastic Compute Cloud (Amazon EC2). Chaque instance du cluster est appelée un nœud et possède un rôle au sein du cluster, appelé type de nœud. Amazon EMR installe également différents composants logiciels sur chaque type de nœud, conférant à chacun un rôle dans une application distribuée comme Apache Hadoop. Chaque cluster dispose d'un identifiant unique commençant par « j- ».

Un cluster Amazon EMR comporte trois types de nœud :

1. Nœud principal : nœud qui gère le cluster en exécutant des composants logiciels pour coordonner la répartition des données et des tâches entre les autres nœuds pour le traitement. Le nœud principal suit l'état des tâches et surveille l'intégrité du cluster. Chaque cluster a un nœud principal, et il est possible de créer un cluster à nœud unique avec uniquement le nœud principal.

2. Nœud principal : nœud possédant des composants logiciels qui exécutent des tâches et stockent des données dans le système de fichiers distribués Hadoop (HDFS) sur votre cluster. Les clusters multinœuds doivent comporter au moins un nœud principal.

3. Nœud de tâche : nœud possédant des composants logiciels qui n'exécute que des tâches et ne stocke pas de données dans HDFS. Les nœuds de tâches sont facultatifs.

Une étape de cluster est une unité de traitement définie par l'utilisateur; établissant une correspondance approximative vers un algorithme qui manipule les données. Une étape est une application Hadoop MapReduce mise en œuvre comme une ressource jar (Java) ou un programme de diffusion en continu écrit en Java, Ruby, Perl, Python, PHP,R ou C++. Par exemple, compter la fréquence à laquelle les mots apparaissent dans un document et les sortir triés par nombre, la première étape serait une application MapReduce qui compte les occurrences de chaque mot, et la seconde étape serait une application MapReduce qui trie les données sortantes à partir de la première étape basée sur le nombre.

STARTING – Le cluster démarre en configurant les instances EC2.
BOOTSTRAPPING – Des actions d'amorçage sont en cours d'exécution sur le cluster.
RUNNING – Une étape du cluster est en cours d'exécution.
WAITING – Le cluster est actuellement actif, mais n'a aucune étape à exécuter.
TERMINATING – Le cluster est en cours de fermeture.
TERMINATED – Le cluster a été fermé sans erreur.
TERMINATED_WITH_ERRORS – Le cluster a été fermé avec des erreurs.

PENDING – L'étape est prête à être exécutée.

RUNNING – L'étape est en cours d'exécution.

COMPLETED – L'étape s'est achevée avec succès.

CANCELLED – L'étape a été annulée avant d'être exécutée, car une étape antérieure a échoué ou parce que le cluster a été interrompu avant qu'elle ne puisse être exécutée.

FAILED – L'étape a échoué pendant qu'elle était en cours d'exécution.

Vous pouvez lancer un cluster via AWS Management Console en remplissant un simple formulaire de demande de cluster. Dans le formulaire de demande, vous spécifiez le nom de votre cluster, l'emplacement de vos données d'entrée dans Amazon S3, votre application de traitement, l'emplacement désiré de la sortie de vos données, et le nombre et le type d'instances Amazon EC2 que vous souhaiteriez utiliser. Vous pouvez éventuellement spécifier un emplacement pour stocker vos fichiers journaux de cluster et la clé SSH pour vous connecter à votre cluster lorsqu'il est en cours d'exécution. Autrement, vous pouvez lancer un cluster en utilisant l'API RunJobFlow ou en utilisant la commande « create » dans les outils de ligne de commande. Pour lancer un cluster avec EMR Studio, consultez la section EMR Studio ci-dessus.

À tout moment, vous pouvez arrêter un cluster via AWS Management Console en le sélectionnant, puis en cliquant sur le bouton Arrêter. Autrement, vous pouvez utiliser l'API TerminateJobFlows. Si vous arrêtez un cluster en cours d'exécution, tout résultat qui n'aura pas été transféré vers Amazon S3 sera perdu et toutes les instances Amazon EC2 seront fermées.

Vous pouvez démarrer autant de clusters que vous le souhaitez. Lorsque vous commencez, vous êtes limité à 20 instances dans tous vos clusters. Si vous souhaitez disposer de plus d'instances, remplissez le formulaire de demande d'instance Amazon EC2. Une fois votre limite Amazon EC2 augmentée, la nouvelle limite sera automatiquement appliquée à vos clusters Amazon EMR.

Vous pouvez télécharger vos données d'entrée et une application de traitement de données dans Amazon S3. Amazon EMR lance ensuite un nombre d'instances Amazon EC2 que vous spécifiez. Le service commence l'exécution du cluster tandis qu'il dépile les données d'entrée depuis Amazon S3 en utilisant le schéma d'URI S3 vers les instances Amazon EC2 lancées. Une fois le cluster fini, Amazon EMR transfère les données de sortie vers Amazon S3, où vous pouvez alors les récupérer ou les utiliser comme des données d'entrée dans un autre cluster.

Amazon EMR utilise le moteur de traitement de données Hadoop pour effectuer les calculs mis en œuvre dans le modèle de programmation MapReduce. Le client met en œuvre son algorithme en termes de fonctions map() et reduce(). Le service démarre un nombre d'instances Amazon EC2 spécifié par le client, comprenant un nœud principal et de plusieurs autres nœuds. Amazon EMR exécute le logiciel Hadoop sur ces instances. Le nœud principal divise les données d'entrée en blocs, et répartit le traitement des blocs entre les autres nœuds. Chaque nœud gère ensuite la fonction map sur les données qui lui ont été attribuées, en générant des données intermédiaires. Les données intermédiaires sont ensuite triées et partagées, puis envoyées vers des processus qui leur appliquent la fonction de réducteur. Finalement, les sorties depuis les tâches de réducteur sont collectées en fichiers. Il se peut qu'un seul « cluster » implique une séquence de telles étapes MapReduce.

Consultez la page de tarification EMR pour en savoir plus sur les derniers types d'instances disponibles et la tarification par région.

Cela dépend de plusieurs facteurs, notamment le type de cluster, la quantité de données d'entrée, ainsi que le nombre et le type d'instances Amazon EC2 que vous choisissez.

Oui. Vous pouvez lancer un cluster EMR (version 5.23 ou supérieure) avec trois nœuds principaux et prendre en charge la haute disponibilité d’applications telles que YARN Resource Manager, HDFS Name Node, Spark, Hive et Ganglia. Amazon EMR procède automatiquement au basculement vers un nœud principal en veille en cas de panne du nœud principal initial ou de crash de processus essentiels, par exemple, Resource Manager ou Name Code. Étant donné que le nœud principal n'est pas un point de défaillance unique potentiel, vous pouvez exécuter vos clusters EMR à longue durée de vie sans interruption. En cas de basculement, Amazon EMR remplace automatiquement le nœud principal en panne par un nouveau nœud principal doté d'une configuration et d'actions d'amorçage identiques. 

Oui. Amazon EMR est tolérant aux pannes pour les échecs de nœud et continue l'exécution du travail si un nœud tombe en panne. Amazon EMR fournit également un nouveau nœud en cas d'échec d'un nœud principal. Cependant, Amazon EMR ne remplacera pas les nœuds si tous les nœuds du cluster sont perdus.

Oui. Vous pouvez utiliser le protocole SSH sur vos nœuds de cluster et exécuter les commandes Hadoop directement à partir de là. Si vous avez besoin d'utiliser le protocole SSH dans un nœud spécifique, vous devez d'abord utiliser le protocole SSH dans le nœud principal, puis dans le nœud de votre choix.

Bootstrap Actions est une caractéristique dans Amazon EMR qui fournit aux utilisateurs un moyen d'exécuter un paramétrage personnalisé, antérieur à l'exécution du cluster. Bootstrap Actions peut être utilisé pour installer un logiciel ou pour configurer des instances avant d'exécuter votre cluster. Vous pouvez découvrir les actions d'amorçage (bootstrap) dans le Guide du développeur d'EMR.

Vous pouvez écrire un script Bootstrap Action dans n'importe quel langage déjà installé sur l'instance du cluster, y compris Bash, Perl, Python, Ruby, C++, ou Java. Plusieurs actions de démarrages pré-définies sont disponibles. Une fois le script écrit, vous devez le télécharger vers Amazon S3 et référencer son emplacement lorsque vous commencez un cluster. Consultez le Guide du développeur pour en savoir plus sur la manière d'utiliser Bootstrap Actions.

La configuration Hadoop par défaut d'EMR est adaptée à la majorité des charges de travail. Toutefois, en fonction des exigences spécifiques de mémoire et de traitement de votre cluster, il peut être plus adapté de personnaliser ces paramètres. Par exemple, si les tâches de votre cluster utilisent intensivement la mémoire, vous pouvez choisir d'utiliser moins de tâches par nœud principal et de réduire la taille du segment de mémoire du pistage de votre travail. Dans cette situation, une action de démarrage prédéfinie est disponible pour configurer votre cluster au lancement. Consultez la section Configure Memory Intensive Bootstrap Action du Guide du développeur pour en savoir plus sur la configuration et les instructions d'utilisation. Une action de démarrage prédéfinie supplémentaire est disponible et vous permet de personnaliser vos paramètres de cluster sur n'importe quelles valeurs de votre choix. Consultez la section Configure Hadoop Bootstrap Action du Guide du développeur pour connaître les instructions d'utilisation.

Oui. Il existe deux types de nœuds : (1) les nœuds principaux qui hébergent des données persistantes via le système de fichiers distribué Hadoop (HDFS) et exécutent des tâches Hadoop et (2) les nœuds de tâches qui exécutent seulement des tâches Hadoop. Quand un cluster est en cours d'exécution, vous pouvez augmenter le nombre de nœuds principaux et vous pouvez soit augmenter soit diminuer le nombre de nœuds de tâches. Ceci peut être fait via l'API, JAVA SDK ou via la ligne de commande client. Consultez la section Redimensionnement des clusters en cours d'exécution du Guide du développeur pour obtenir des détails sur la manière de modifier la taille de votre cluster en cours d'exécution. Vous pouvez également utiliser Amazon EMR Managed Scaling.

Comme les nœuds principaux hébergent des données persistantes dans HDFS et ne peuvent pas être supprimés, ils doivent être réservés à la capacité requise jusqu'à la fin du cluster. Comme les nœuds de tâches peuvent être ajoutés ou supprimés et ne contiennent pas HDFS, ils sont idéaux pour une capacité requise seulement sur une base temporaire. Vous pouvez lancer des flottes d'instances de tâche sur les instances Spot afin d'accroître les capacités tout en minimisant les coûts.

Il existe plusieurs scénarii dans lesquels vous pouvez vouloir modifier le nombre de nœuds dans un cluster en cours d'exécution. Si votre cluster s'exécute plus lentement que prévu, ou que les exigences de rythme changent, vous pouvez augmenter le nombre de nœuds principaux pour augmenter la performance du cluster. Si différentes phases de votre cluster ont des exigences de capacité différentes, vous pouvez commencer avec un petit nombre de nœuds principaux et augmenter ou diminuer le nombre de nœuds de tâches afin de satisfaire les exigences de capacités variables de votre cluster. Vous pouvez également utiliser Amazon EMR Managed Scaling.

Oui. Vous pouvez inclure une étape pré-définie dans votre cluster qui redimensionne automatiquement un cluster entre les étapes, connues comme ayant des exigences de capacité différentes. Dans la mesure où toutes les étapes sont garanties de s'exécuter de façon séquentielle, vous pouvez définir le nombre de nœuds qu'exécutera une étape de cluster donnée.

Afin de créer un cluster visible par tous les utilisateurs IAM, procédez comme suit au sein de l'interface de ligne de commande EMR : ajoutez l'indication --visible-to-all-users au moment où vous créez le cluster. Exemple : elastic-mapreduce --create --visible-to-all-users. Dans la console de gestion, sélectionnez simplement « Visible to all IAM Users » dans le volet Advanced Options de l'assistant de création de cluster.

Afin qu'un cluster existant devienne visible par tous les utilisateurs IAM, vous devez utiliser l'interface de ligne de commande EMR. Utilisez --set-visible-to-all-users et spécifiez l'identifiant du cluster. Exemple : elastic-mapreduce --set-visible-to-all-users true --jobflow j-xxxxxxx. Seul le créateur du cluster peut effectuer cette tâche.

Pour en savoir plus, consultez la section Configuration des autorisations utilisateur du Guide du développeur EMR.

Vous pouvez ajouter des balises à un cluster Amazon EMR actif. Un cluster Amazon EMR se compose d'instances Amazon EC2, et une balise ajoutée à un cluster Amazon EMR est répercutée sur chaque instance Amazon EC2 active du cluster en question. Vous ne pouvez pas ajouter, modifier ou supprimer de balises à des clusters interrompus ou à des instances Amazon EC2 terminées qui faisaient partie d'un cluster actif.

Non. Amazon EMR ne prend pas en charge les autorisations liées aux ressources par balise. Cependant, il convient de noter que les balises répercutées sur les instances Amazon EC2 se comportent comme des balises Amazon EC2 normales. Une politique IAM pour Amazon EC2 s’appliquera aux balises propagées depuis Amazon EMR si ces dernières répondent aux exigences de cette politique.

Vous pouvez ajouter jusqu'à 10 balises sur un cluster Amazon EMR.

Oui. Amazon EMR propage les balises ajoutées à un cluster aux instances EC2 sous-jacentes du cluster en question. Si vous ajoutez une balise à un cluster Amazon EMR, la balise apparaîtra aussitôt sur les instances Amazon EC2 liées. De même, si vous supprimez une balise d'un cluster Amazon EMR, la balise sera également supprimée des instances Amazon EC2 associées. Toutefois, si vous utilisez les politiques IAM pour Amazon EC2 et prévoyez d'utiliser la fonctionnalité de balisage d'Amazon EMR, vous devez vous assurer que la permission d'utiliser les API pour créer les balises et supprimer les balises Amazon EC2 est accordée.

Sélectionnez les balises que vous souhaitez utiliser dans votre rapport de facturation AWS ici. Puis, pour consulter le coût de vos ressources combinées, vous pouvez organiser vos données de facturation en fonction des ressources présentant les mêmes valeurs de clé de balise.

Une instance Amazon EC2 associée à un cluster Amazon EMR bénéficie de deux balises de système :

• aws:elasticmapreduce:instance-group-role=CORE

  • Clé = instance-group-role ; Valeur = [CORE ou TASK]

• aws:elasticmapreduce:job-flow-id=j-12345678

  • Key = job-flow-id ; Value = [JobFlowID]

Oui. Vous pouvez ajouter ou supprimer des balises directement sur les instances Amazon EC2 faisant partie d'un cluster Amazon EMR. Néanmoins, nous vous déconseillons de le faire, car le système de balise d'Amazon EMR ne procédera pas à la synchronisation des changements effectués directement sur une instance Amazon EC2 associée. Nous vous recommandons d'ajouter et de supprimer les balises des clusters Amazon EMR depuis la console, la CLI ou l'API Amazon EMR afin de vous assurer que le cluster et les instances Amazon EC2 associées disposent des bonnes balises.

Amazon EMR Serverless est une nouvelle option de déploiement dans Amazon EMR qui vous permet d'exécuter des cadres de big data tels qu'Apache Spark et Apache Hive sans avoir à configurer, gérer et mettre à l'échelle des clusters.

Les ingénieurs de données, les analystes et les scientifiques peuvent utiliser EMR Serverless pour créer des applications à l'aide de cadres open-source tels qu'Apache Spark et Apache Hive. Ils peuvent utiliser ces cadres pour transformer les données, exécuter des requêtes SQL interactives et des charges de travail de machine learning.

Vous pouvez utiliser EMR Studio, AWS CLI ou les API pour soumettre des tâches, suivre leur statut et créer vos pipelines de données à exécuter sur EMR Serverless. Pour commencer avec EMR Studio, connectez-vous à la console de gestion AWS, accédez à Amazon EMR dans la catégorie Analytique, puis sélectionnez Amazon EMR Serverless. Suivez les instructions de la console de gestion AWS, accédez à Amazon EMR dans la catégorie Analytique, puis sélectionner Amazon EMR Serverless. Suivre les instructions du guide de prise en main pour créer votre application EMR Serverless et soumettre des tâches. Vous pouvez vous référer à la page Interagir avec votre application sur l'AWS CLI pour lancer vos applications et soumettre des tâches à l'aide de la CLI. Vous pouvez également trouver des exemples et des modèles de code EMR Serverless dans notre référentiel GitHub.

EMR Serverless prend actuellement en charge les moteurs Apache Spark et Apache Hive. Si vous souhaitez obtenir la prise en charge de cadres supplémentaires tels que Apache Presto ou Apache Flink, veuillez envoyer une demande à emr-feedback@amazon.com.

L’EMR sans serveur est disponible dans les régions AWS suivantes : Asie-Pacifique (Mumbai), Asie-Pacifique (Séoul), Asie-Pacifique (Singapour), Asie-Pacifique (Sydney), Asie-Pacifique (Tokyo), Canada (Centre), Europe (Francfort), Europe (Irlande), Europe (Londres), Europe (Paris), Europe (Stockholm), Amérique du Sud (São Paulo), USA Est (Virginie du Nord), USA Est (Ohio), USA Ouest (Californie du Nord), et USA Ouest (Oregon).

Amazon EMR offre la possibilité d'exécuter des applications sur des clusters basés sur EC2, des clusters EKS, des Outposts ou des services sans serveur. Les clusters EMR sur EC2 conviennent aux clients qui ont besoin d'un contrôle et d'une flexibilité maximum pour exécuter leur application. Avec les clusters EMR sur EC2, les clients peuvent choisir le type d'instance EC2 pour répondre aux besoins de performance spécifiques à l'application, personnaliser l'AMI Linux, personnaliser la configuration de l'instance EC2, personnaliser et étendre les cadres open-source et installer des logiciels personnalisés supplémentaires sur les instances du cluster. Amazon EMR sur EKS convient aux clients qui souhaitent standardiser sur EKS pour gérer les clusters entre les applications ou utiliser différentes versions d'un cadre open-source sur le même cluster. Amazon EMR sur AWS Outposts est destiné aux clients qui souhaitent exécuter EMR plus près de leur centre de données, dans un Outpost. EMR Serverless convient aux clients qui souhaitent éviter de gérer et d'exploiter des clusters et préfèrent exécuter des applications à l'aide de cadres open-source.

EMR Serverless prend en charge les versions 6.6 de EMR et supérieures. Avec EMR Serverless, vous bénéficiez du même environnement d'exécution EMR optimisé en termes de performances que celui disponible dans les autres options de déploiement EMR, qui est 100 % compatible avec l'API des cadres open-source standard.

BilledResourceUtilization prend uniquement en compte la durée pendant laquelle la capacité préinitialisée a été utilisée pour la tâche, et ne prend pas en compte le temps d'inactivité de cette capacité.

Si la durée d'exécution d'un travailleur est inférieure à 60 secondes, BilledResourceUtilization la comptabilise comme 60 secondes, tandis que TotalResourceUtilization l'arrondit à la seconde la plus proche. En outre, BilledResourceUtilization exclut 20 Go de stockage gratuit du calcul.

Avec Amazon EMR Serverless, vous pouvez créer une ou plusieurs applications EMR Serverless qui utilisent des cadres analytiques open-source. Pour créer une application, vous devez spécifier les attributs suivants : 1) la version Amazon EMR pour la version du cadre open-source que vous voulez utiliser et 2) les moteurs analytiques spécifiques que vous voulez que votre application utilise, tels que Apache Spark 3.1 ou Apache Hive 3.0. Après avoir créé une application, vous pouvez commencer à exécuter vos tâches de traitement de données ou des requêtes interactives dans votre application.

Une application EMR Serverless utilise en interne des travailleurs pour exécuter vos charges de travail. Lorsqu'une tâche est soumise, EMR Serverless calcule les ressources nécessaires à la tâche et planifie les travailleurs. EMR Serverless divise vos charges de travail en tâches, fournit et configure les travailleurs avec le cadre open-source, et les désactive une fois la tâche terminée. EMR Serverless met automatiquement à l'échelle les travailleurs en fonction de la charge de travail et du parallélisme requis à chaque étape de la tâche, ce qui vous évite d'avoir à estimer le nombre de travailleurs requis pour exécuter vos charges de travail. La taille par défaut de ces travailleurs est basée sur votre type d'application et la version de l'Amazon EMR. Vous pouvez utiliser d'autres tailles lors de la planification de l'exécution de la tâche.

Avec EMR Serverless, vous pouvez spécifier le nombre minimum et maximum de travailleurs simultanés et la configuration vCPU et mémoire des travailleurs. Vous pouvez également définir les limites de capacité maximale des ressources de l'application afin de contrôler les coûts.

Envisagez de créer plusieurs applications lorsque vous effectuez l'une des opérations suivantes :

1. Utilisation de différents cadres open-source

2. Utilisation de différentes versions de cadres open-source pour différents cas d'utilisation

3. Exécution de tests A/B lors de la mise à niveau d'une version à une autre

4. Maintient d'environnements logiques distincts pour les scénarios de test et de production

5. Fourniture d'environnements logiques distincts pour les différentes équipes, avec des contrôles des coûts et un suivi de l'utilisation indépendants

6. Séparation des applications des différents secteurs d'activité

Oui, vous pouvez modifier les propriétés de l'application telles que la capacité initiale, les limites de capacité maximale et la configuration du réseau à l'aide d'EMR Studio ou en appelant l'API/la CLI update-application.

Une application EMR Serverless sans travailleurs pré-initialisés prend jusqu'à 120 secondes pour déterminer les ressources nécessaires et les fournir. EMR Serverless propose une fonction optionnelle qui permet de garder les travailleurs initialisés et prêts à répondre en quelques secondes, créant ainsi un groupe de travailleurs disponibles sur appel pour une application. Cette fonction est appelée capacité pré-initialisée et peut être configurée pour chaque application en définissant le paramètre initial-capacité d'une application.

La capacité pré-initialisée permet aux tâches de démarrer immédiatement, ce qui la rend idéale pour la mise en œuvre de tâches sensibles au facteur temps. Vous pouvez spécifier le nombre de travailleurs que vous souhaitez pré-initialiser lorsque vous démarrez une application EMR Serverless. Par la suite, lorsque les utilisateurs soumettent des tâches, les travailleurs pré-initialisés peuvent être utilisés pour démarrer immédiatement les tâches. Si la tâche exige plus de travailleurs que ce que vous avez choisi de pré-initialiser, EMR Serverless ajoute automatiquement des travailleurs supplémentaires (jusqu'à la limite maximale simultanée que vous spécifiez). Une fois la tâche terminée, EMR Serverless revient automatiquement à la conservation des travailleurs pré-initialisés que vous avez spécifiés. Les travailleurs s'arrêtent automatiquement s'ils sont restés inactifs pendant 15 minutes. Vous pouvez modifier la durée d'inactivité par défaut de votre application en utilisant l'API updateApplication ou EMR Studio.

Vous pouvez soumettre et gérer les tâches EMR Serverless à l'aide de EMR Studio, du kit SDK/de la CLI ou de nos connecteurs Apache Airflow.

Pour PySpark, vous pouvez empaqueter vos dépendances Python à l'aide de virtualenv et transmettre le fichier d'archive à l'aide de l'option --archives, ce qui permet à vos travailleurs d'utiliser les dépendances pendant l'exécution de la tâche. Pour Scala ou Java, vous pouvez empaqueter vos dépendances comme des jars, les charger sur Amazon S3 et les transmettre à l'aide des options --jars ou --packages avec l'exécution de votre tâche EMR Serverless.

EMR Serverless prend en charge les UDF basés sur Java. Vous pouvez les compresser sous forme de fichiers jars, les télécharger sur S3 et les utiliser dans vos scripts Spark ou HiveQL.

Reportez-vous à la configuration des travailleurs pris en charge pour plus de détails.

Oui, vous pouvez annuler une tâche EMR Serverless qui est en cours d'exécution depuis EMR Studio ou en appelant l'API/la CLI cancelJobRun.

Vous pouvez ajouter du stockage supplémentaire aux travailleurs dans EMR sans serveur en sélectionnant l'option de stockage appropriée lors de la soumission de la tâche. EMR sans serveur propose deux options de stockage éphémère :

• Stockage standard : cette option est fournie par défaut avec 20 Go de stockage éphémère par travailleur. Vous pouvez la personnaliser lors de la soumission des tâches et augmenter la capacité de stockage de 20 Go à 200 Go par travailleur.

• Stockage sur disque optimisé pour la lecture aléatoire : cette option fournit jusqu'à 2 To de stockage éphémère par collaborateur, optimisé pour les charges de travail intensives en mode aléatoire.

Vous pouvez trouver des échantillons de code EMR Serverless dans notre référentiel GitHub.

EMR Serverless propose deux options aux travailleurs : les travailleurs à la demande et les travailleurs préinitialisés.

Les travailleurs à la demande sont lancés uniquement lorsque cela est nécessaire pour une tâche et sont automatiquement libérés lorsque la tâche est terminée. Cela vous permet de réduire les coûts en ne payant que pour les ressources que vous utilisez et d'éviter tout coût supplémentaire lié à la capacité inutilisée. Les travailleurs à la demande adaptent votre application à la hausse ou à la baisse en fonction de votre charge de travail, de sorte que vous n'avez pas à vous soucier du surapprovisionnement ou du sous-approvisionnement des ressources.

Les collaborateurs préinitialisés sont une fonctionnalité optionnelle qui vous permet de garder les collaborateurs prêts à répondre en quelques secondes. Cela crée efficacement un bassin de travailleurs chaleureux pour une application. Cela permet aux tâches de démarrer instantanément, ce qui le rend idéal pour les applications itératives et les tâches urgentes.

Oui, il est possible de configurer des applications EMR Serverless sur plusieurs zones de disponibilité. Le processus de configuration de plusieurs AZ dépend du type de travailleurs que vous utilisez.

Lorsque vous utilisez uniquement des travailleurs à la demande, EMR Serverless distribue les tâches sur plusieurs zones de disponibilité par défaut, mais chaque tâche ne s'exécute que dans une zone de disponibilité. Vous pouvez choisir les zones de disponibilité à utiliser en associant des sous-réseaux aux zones de disponibilité. En cas de défaillance d'une zone de disponibilité, EMR Serverless exécute automatiquement votre travail dans une autre zone de disponibilité saine.

Lorsque vous utilisez des serveurs préinitialisés, EMR Serverless sélectionne une zone de disponibilité saine parmi les sous-réseaux que vous spécifiez. Les tâches sont soumises dans cette zone de disponibilité jusqu'à ce que vous arrêtiez l’application. Si une zone de disponibilité est altérée, vous pouvez redémarrer l'application pour passer à une autre zone de disponibilité saine.

EMR Serverless ne peut accéder à certaines ressources AWS de la même région que lorsqu'il est configuré sans connectivité VPC. Consultez la section considérations. Pour accéder aux ressources AWS dans une autre région ou à des ressources n'appartenant pas à AWS, vous devez configurer un accès VPC et une passerelle NAT pour acheminer les ressources AWS vers des points de terminaison publics.

Les mesures au niveau des applications et des tâches Amazon EMR Serverless sont publiées toutes les 30 secondes sur Amazon CloudWatch.

Depuis EMR Studio, vous pouvez sélectionner une tâche EMR Serverless en cours d'exécution ou terminée, puis cliquer sur le bouton Spark UI ou Tez UI pour les lancer.

Oui, vous pouvez configurer les applications Amazon EMR Serverless pour accéder aux ressources de votre propre VPC. Pour en savoir plus, reportez-vous à la section Configurer l'accès VPC de la documentation. 

Chaque application EMR Serverless est isolée des autres applications et s'exécute sur un Amazon VPC sécurisé.

Amazon EMR Serverless introduit un nouveau quota de service appelé Max vCPU concurrent par compte. Ce quota basé sur les vCPU vous permet de définir le nombre maximum de vCPU agrégés que vos applications peuvent atteindre dans une région. Les quotas existants au niveau des applications, basés sur les travailleurs (nombre maximum de travailleurs actifs), ne seront plus pris en charge à partir du 1er février 2023.

Vous pouvez afficher, gérer et demander l'augmentation des quotas dans la console de gestion AWS Service Quotas. Pour plus d'informations, consultez la section Demander une augmentation des quotas dans le guide Service Quotas.

EMR Serverless fournit deux contrôles de coûts - 1/ Le quota maximum de vCPU simultanés par compte est appliqué à toutes les applications EMR Serverless dans une région de votre compte. 2/ Le paramètre maximumCapacity limite le vCPU d'une application EMR Serverless spécifique. Vous devez utiliser le quota basé sur le vCPU pour limiter le nombre maximum de vCPU simultanés utilisés par toutes les applications dans une région, et la propriété maximumCapacity pour limiter les ressources utilisées par une application spécifique. Par exemple, si vous avez 5 applications et que chaque application peut atteindre 1 000 vCPU, définissez la propriété maximumCapacity à 1 000 vCPU pour chaque application et configurez le quota basé sur les vCPU au niveau du compte à 5 * 1 000 = 5 000 vCPU.

Si vous dépassez votre quota de vCPU au niveau du compte, EMR Serverless cessera de fournir de la capacité supplémentaire. Si vous essayez de créer une nouvelle application après avoir dépassé le quota, la création de l'application échouera avec un message d'erreur « L'application n'a pas pu être créée car vous avez dépassé le quota de service maximum de vCPU simultanés par compte. Vous pouvez afficher et gérer votre quota de service à l'aide de la console AWS Service Quotas. » Si vous soumettez une nouvelle tâche après avoir dépassé le quota, la tâche échouera avec un message d'erreur : « La tâche a échoué car vous avez dépassé le quota maximum de vCPU simultanés par service de compte. Vous pouvez afficher et gérer votre quota de service à l'aide de la console AWS Service Quotas. » Veuillez consulter la documentation pour plus de détails.

Amazon EMR Serverless peut vous aider à réduire vos coûts de trois manières. Premièrement, il n'y a pas de frais opérationnels liés à la gestion, à la sécurisation et à la mise à l'échelle des clusters. Deuxièmement, EMR Serverless met automatiquement à l'échelle les travailleurs à chaque étape du traitement de votre tâche et les réduit lorsqu'ils ne sont pas nécessaires. Vous êtes facturé pour les ressources vCPU, mémoire et stockage agrégées utilisées à partir du moment où un travailleur commence à s'exécuter jusqu'à ce qu'il s'arrête. La durée est arrondie à la seconde la plus proche, avec un minimum d'une minute. Par exemple, votre tâche peut exiger 10 travailleurs pour les 10 premières minutes de traitement de la tâche et 50 travailleurs pour les 5 minutes suivantes. Avec la mise à l'échelle précise automatique, vous n'engagez des coûts que pour 10 travailleurs pendant 10 minutes et 50 travailleurs pendant 5 minutes. Ainsi, vous n'avez pas à payer pour des ressources sous-utilisées. Troisièmement, EMR Serverless inclut un environnement d'exécution Amazon EMR optimisé pour Apache Spark et Apache Hive, ainsi que Presto. L'environnement d'exécution Amazon EMR est compatible avec les API et plus de deux fois plus rapide que les moteurs analytiques open-source standard, ce qui permet à vos tâches de s'exécuter plus rapidement et de réduire les coûts de calcul.

Cela dépend de l'utilisation actuelle de votre cluster EMR sur EC2. Si vous exécutez des clusters EMR en utilisant des instances à la demande EC2, EMR Serverless offrira un coût total de possession (TCO) inférieur si l'utilisation actuelle de votre cluster est inférieure à 70 %. Si vous utilisez les Savings Plans EC2, EMR Serverless vous offrira un TCO inférieur si l'utilisation actuelle de votre cluster est inférieure à 50 %. Et si vous utilisez des instances Spot EC2, Amazon EMR sur EC2 et Amazon EMR sur EKS resteront plus rentables.

Oui, si vous n'arrêtez pas les travailleurs après la fin de la tâche, vous subirez des frais sur les travailleurs pré-initialisés.

Pour PySpark, vous pouvez empaqueter vos dépendances Python à l'aide de virtualenv et transmettre le fichier d'archive à l'aide de l'option --archives, ce qui permet à vos travailleurs d'utiliser les dépendances pendant l'exécution de la tâche. Pour Scala ou Java, vous pouvez empaqueter vos dépendances comme des jars, les charger sur Amazon S3 et les transmettre à l'aide des options --jars ou --packages avec l'exécution de votre tâche EMR Serverless.

Pour PySpark, vous pouvez empaqueter vos dépendances Python à l'aide de virtualenv et transmettre le fichier d'archive à l'aide de l'option --archives, ce qui permet à vos travailleurs d'utiliser les dépendances pendant l'exécution de la tâche. Pour Scala ou Java, vous pouvez empaqueter vos dépendances comme des jars, les charger sur Amazon S3 et les transmettre à l'aide des options --jars ou --packages avec l'exécution de votre tâche EMR Serverless.

Amazon EMR Serverless élimine la mise en service du stockage local pour les charges de travail Apache Spark, réduisant ainsi les coûts de traitement des données jusqu'à 20 % et empêchant les échecs de tâches dus à des contraintes de capacité de disque. EMR Serverless gère automatiquement les opérations de données intermédiaires, telles que le mélange de données, sans nécessiter de décisions d'infrastructure. En gérant automatiquement les données intermédiaires indépendamment des opérateurs informatiques, cette optimisation permet à l'allocation dynamique des ressources (DRA) de Spark de libérer les ressources de calcul dès qu'elles ne sont plus nécessaires pour le traitement, au lieu de les maintenir en activité uniquement pour préserver les données locales temporaires. Cette amélioration automatique offre une plus grande élasticité pour les charges de travail de transformation étendues, telles que les agrégations importantes, les jointures et les analyses nécessitant un tri intensif, permettant aux ressources de calcul d'évoluer dynamiquement vers le haut et vers le bas à travers les étapes de la tâche sans être limitées par les données stockées localement.

Il vous suffit de vous inscrire lorsque vous utilisez la version 7.12 ou ultérieure d'EMR. Vos tâches Spark bénéficieront automatiquement d'un traitement optimisé des données intermédiaires sans nécessiter aucune configuration de votre part. Vous pouvez surveiller vos tâches en temps réel à l'aide de l'interface utilisateur de Spark Live et consulter les métriques détaillées de répartition aléatoire et de déversement par étape pour les tâches terminées sur le Spark History Server.

Vos données intermédiaires sont stockées uniquement pendant l'exécution de votre tâche et sont automatiquement supprimées lorsque celle-ci est terminée, ce qui garantit qu'aucune donnée ne persiste au-delà de son cycle de vie.

Cette optimisation automatique maintient les mêmes normes de sécurité professionnelles qu'EMR Serverless grâce à plusieurs niveaux de protection. Toutes les données sont chiffrées à la fois en transit entre votre application EMR Serverless et la couche intermédiaire de traitement des données, et au repos pendant leur stockage temporaire, à l'aide de clés de chiffrement gérées par AWS. Cette fonctionnalité applique une isolation des données et un contrôle d'accès stricts en stockant vos données intermédiaires sous des identifiants spécifiques à la tâche dans votre espace de noms, garantissant ainsi que vos données restent accessibles uniquement pour votre tâche spécifique. Vos contrôles d'accès et autorisations EMR Serverless existants continuent de s'appliquer, de sorte que les données régies par les politiques de table ou de Lake Formation demeurent entièrement protégées. Pour une sécurité renforcée, EMR Serverless utilise un rôle appartenant au service pour gérer le traitement des données intermédiaires plutôt que le rôle d'exécution de votre tâche, empêchant ainsi l'escalade des privilèges ou les accès inter-comptes non autorisés. Si un contrôle de sécurité échoue, votre tâche s'arrête immédiatement afin garantir la protection de vos données en permanence.