FAQ sur Amazon EMR

Q : Qu'est-ce qu'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.

Q : Pourquoi devrais-je utiliser Amazon EMR ?

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.

Q : Comment déployer et gérer Amazon EMR ?

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.

Q : Comment puis-je démarrer avec Amazon EMR ?

Q : Où puis-je trouver des exemples de code ?

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.

Q : Comment développer une application de traitement de données?

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.

Q : Quel bénéfice y a-t-il à utiliser des outils de ligne de commande ou des API par comparaison à AWS Management Console ?

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.

Q : Puis-je ajouter des étapes à un cluster qui est déjà en cours d'exécution ?

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.

Q : Puis-je recevoir une notification quand mon cluster est fini ?

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.

 Q : Puis-je résilier mon cluster lorsque mes étapes sont terminées ?

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.

Q : Quelles sont les versions de systèmes d'exploitation prises en charge avec Amazon EMR ?

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.

Q : Amazon EMR prend-il en charge des packages tiers ?

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. Consultez notre documentation pour en savoir plus.

Q : Quels outils ai-je à disposition pour le débogage ?

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.

Q : Qu'est-ce qu'EMR Studio ?

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

Q : Que puis-je faire avec EMR Studio ?

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

Q : En quoi EMR Studio est-il différent d'EMR Notebooks ?

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

Q : En quoi EMR Studio est-il différent de SageMaker Studio ?

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

Q : Comment démarrer avec EMR Studio ?

Votre administrateur doit d'abord configurer un EMR Studio. 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.

Q : Dois-je me connecter à AWS Management Console pour utiliser EMR Studio ?

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

Q : Quels fournisseurs d'identités sont pris en charge pour l'expérience d'authentification unique dans EMR Studio ?

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.

Q : Qu'est-ce qu'un espace de travail (WorkSpace) ?

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.

Q : Dans EMR Studio, puis-je créer un WorkSpace ou ouvrir un WorkSpace sans cluster ?

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.

Q : Puis-je installer des bibliothèques personnalisées pour les utiliser dans mon code de bloc-notes ?

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.

Q : Où sont enregistrés les blocs-notes ?

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.

Q : Comment utiliser le contrôle de version avec mon bloc-notes ? Puis-je utiliser des référentiels tels que GitHub ?

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

Q : Dans EMR Studio, sur quelles ressources de calcul puis-je exécuter des blocs-notes ?

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.

Q : Puis-je lier à nouveau un WorkSpace à une ressource de calcul différente dans EMR Studio ?

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

Q : Où puis-je trouver tous mes WorkSpaces dans EMR Studio ?

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.

Q : Quelles sont les stratégies IAM requises pour utiliser EMR Studio ?

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 Stratégies et autorisations du Guide de l'utilisateur AWS Identity and Access Management.

Q : Existe-t-il des limitations sur les clusters EMR auxquels je peux lier mon WorkSpace dans EMR Studio ?

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

Q : Quel est le coût d'utilisation d'Amazon EMR ?

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.

Q : Qu'est-ce-qu'EMR Notebooks ?

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

Q : Que puis-je faire avec EMR Notebooks ?

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.

Q : Comment démarrer avec les Blocs-EMR Notebooks?

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.

Q : Quelles versions d'EMR sont prises en charge par EMR Notebooks ?

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

Q : Quel est le coût d'utilisation d'EMR Notebooks ?

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/   

Q : Comment puis-je transférer mes données vers Amazon S3 ?

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.

Q : Comment puis-je obtenir les journaux de clusters résiliés ?

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.

Q : Compressez-vous les journaux ?

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

Q : Puis-je charger mes données à partir d'Internet ou ailleurs que dans Amazon S3 ?

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 plus d'informations, reportez-vous à notre documentation.

Q : Est-ce qu'Amazon EMR peut estimer le temps nécessaire au traitement de mes données d'entrée ?

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.

Q : Combien coûte Amazon EMR ?

La tarification d'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.

Q : Quelles sont les dates de fin et de début de facturation pour mon cluster 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.

Q : Où puis-je suivre mon utilisation d'Amazon EMR, d'Amazon EC2 et d'Amazon S3 ?

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

Q : Comment calculez-vous le nombre d'heures-instances normalisées affiché dans la console ?

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.

Q : Amazon EMR prend-il en charge les instances à la demande, Spot et réservées Amazon EC2 ?

Oui. Amazon EMR prend en charge à la fois des instances à la demande, Spot et réservées de manière transparente. 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.

Q : Vos prix sont-ils toutes taxes comprises ?

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. 

Q : Comment puis-je empêcher d'autres personnes de visualiser mes données pendant l'exécution du cluster ?

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.

Q : Quel est le niveau de sécurité de mes données ?

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.

Q : Puis-je obtenir un historique de tous les appels API EMR effectués sur mon compte pour un audit de sécurité ou de conformité ?

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.

Q : Comment contrôler ce à quoi les utilisateurs EMR peuvent accéder dans Amazon S3 ?

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 Amazon EMR Notebooks 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 de tirer parti des 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.

Q : Comment Amazon EMR utilise-t-il les zones de disponibilité ?

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.

Q : Dans quelles régions le service Amazon EMR est-il disponible ?

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.

Q : Le service Amazon EMR est-il pris en charge dans AWS Local Zones ?

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.

Q : Quelle région sélectionner pour exécuter mes clusters ?

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

Q : Puis-je utiliser des données européennes dans un cluster qui s'exécute dans la région USA et vice versa ?

Oui, vous pouvez. Si vous transférez des données d'une région à l'autre, vous serez facturé pour les frais de bande passante. Pour les informations sur la facturation de la bande passante, visitez la section facturation à la page de détails EC2.

Q : En quoi la région AWS GovCloud (US) est-elle différente ?

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.

Q : Qu'est-ce qu'un cluster Amazon EMR ?
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- ».

Q : Quels sont les types de nœuds dans un cluster ?
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.
   
   

Q : Qu'est-ce qu'une étape de cluster ?
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.

Q : Quels sont les différents états du cluster ?
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.

Q : Que sont les différents états d'étape ?
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.

Q : Comment puis-je lancer un cluster ?
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.

Q : Comment puis-je arrêter un cluster ?
À 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é rendu persistant vers Amazon S3 sera perdu et toutes les instances Amazon EC2 seront fermées.

Q : Amazon EMR prend-il en charge plusieurs clusters simultanés ?
Vous pouvez démarrer autant de clusters que vous le souhaitez. Lorsque vous démarrez, 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 atteinte, la nouvelle limite sera automatiquement appliquée à vos clusters Amazon EMR.

Q : Comment Amazon EMR utilise-t-il Amazon EC2 et Amazon S3 ?

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.

Q : Comment un calcul est-il effectué dans Amazon EMR ?

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.

Q : Quels sont les types d'instances Amazon EC2 pris en charge par Amazon EMR ?

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

Q : Combien de temps faut-il pour exécuter mon cluster ?

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.

Q : Si le nœud maître dans un cluster baisse, Amazon EMR peut-il le récupérer ?

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. 

Q : Si un autre échec de nœud se produit dans un cluster, Amazon EMR peut-il procéder à une récupération ?

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.

Q : Puis-je utiliser le protocole SSH sur mes nœuds principaux ?

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.

Q : Qu'est-ce qu'Amazon EMR Boostrap Actions ?

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.

Q : Comment puis-je utiliser Bootstrap Actions ?

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.

Q : Comment puis-je configurer les paramètres Hadoop pour mon cluster ?

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.

Q : Puis-je modifier le nombre de nœuds dans un cluster en cours d'exécution ?

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.

Q : Quand serait-il préférable d'utiliser des nœuds principaux par opposition à des nœuds de tâches ?

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.

Q : Pourquoi modifier le nombre de nœuds esclaves dans mon cluster en cours d'exécution ?

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.

Q : Puis-je modifier automatiquement le nombre de nœuds entre les étapes du cluster ?

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.

Q : Comment permettre à d'autres utilisateurs IAM d'accéder à mon cluster ?

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.

Q : À quelles ressources Amazon EMR puis-je ajouter une balise ?

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.

Q : Les permissions liées aux ressources avec les utilisateurs IAM sont-elles prises en charge lors de l'ajout de balises Amazon EMR ?

Non. Amazon EMR ne prend pas en charge les permissions 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 agira donc sur les balises répercutées depuis Amazon EMR si ces dernières répondent aux exigences de cette politique.

Q : Combien de balises puis-je ajouter à une ressource ?

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

Q : Est-ce que mes balises Amazon EMR sur un cluster figurent sur chaque instance Amazon EC2 du cluster en question ? Si je supprime une balise sur mon cluster Amazon EMR, cette balise sera-t-elle automatiquement supprimée de toutes les instances EC2 associées ?

Oui. Amazon EMR répercute les balises ajoutées à un cluster sur toutes les 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é d'ajout de balises d'Amazon EMR, vous devriez vérifier que vous disposez de la permission d'utiliser les API de balises Amazon EC2 CreateTags et DeleteTags.

Q : Comment puis-je faire apparaître mes balises dans mon document de facturation pour fractionner les coûts ?

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.

Q : Comment puis-je déterminer quelles instances Amazon EC2 font partie d'un cluster Amazon EMR ?

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]

Q : Puis-je modifier les balises directement sur les instances Amazon EC2 ?

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.

Q : Qu'est-ce qu'Amazon EMR Serverless ?

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.

Q : Qui peut utiliser EMR Serverless ?

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.

Q : Comment démarrer avec EMR Serverless ?

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 démarrer 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 démarrage 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.

Q : Quelles cadres open-source sont pris en charge par EMR Serverless ?

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.

Q : Dans quelles régions EMR Serverless est-il disponible ?

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

Q : Quelle est la différence entre Amazon EMR Serverless, Amazon EMR sur EC2, Amazon EMR sur AWS Outposts et Amazon EMR sur EKS ?

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.

Q : Quelles sont les différences de fonctions entre EMR Serverless et Amazon EMR sur EC2 ?

Q : Quelles versions d'EMR sont prises en charge par EMR Serverless ?

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.

Q. Les frais relatifs à la capacité pré-initialisée sont-ils inclus dans BilledResourceUtilization ?

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

Q. Quelle est la différence entre BilledResourceUtilization et TotalResourceUtilization ?

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.

Q : Qu'est-ce qu'une application et comment puis-je la créer ?

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.

Q : Qu'est-ce qu'un travailleur ?

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.

Q : Puis-je spécifier le nombre minimum et maximum de travailleurs que mes tâches peuvent utiliser ?

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.

Q : Quand dois-je créer plusieurs applications ?

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é

Q : Puis-je modifier les propriétés par défaut d'une application EMR Serverless après sa création ?

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.

Q : Quand dois-je créer une application avec un groupe pré-initialisé de travailleurs ?

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.

Q : Comment puis-je soumettre et gérer des tâches sur EMR Serverless ?

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.

Q : Comment puis-je inclure des dépendances avec les tâches que je veux exécuter sur 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.

Q : Est-ce que les applications EMR Serverless Spark et Hive prennent en charge les fonctions définies par l'utilisateur (UDF) ?

EMR Serverless prend en charge les UDF basés sur Java. Vous pouvez les empaqueter comme des jars, les charger sur S3 et les utiliser dans vos scripts Spark ou HiveQL.

Q : Quelles sont les configurations de travailleurs prises en charge par EMR Serverless ?

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

Q : Puis-je annuler une tâche EMR Serverless si elle prend plus de temps que prévu ?

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.

Q : Puis-je ajouter du stockage supplémentaire aux travailleurs ?

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.

Q : Où puis-je trouver des exemples de code ?

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

Q : Quelles sont les options de travail disponibles dans EMR Serverless ?

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.

Q : Puis-je configurer des applications EMR sans serveur dans plusieurs zones de disponibilité (AZ) ?

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.

Q : Puis-je me connecter à des magasins de données situés dans une autre région ?

EMR Serverless ne peut accéder à certaines ressources AWS de la même région que lorsqu'il est configuré sans connectivité VPC. Consultez considérations. Pour accéder aux ressources AWS d'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.

Q : Comment puis-je surveiller les applications Amazon EMR Serverless et les exécutions de tâches ?

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

Q : Comment puis-je lancer Spark UI et Tez UI avec EMR Serverless ?

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.

Q : Puis-je accéder aux ressources de mon cloud privé virtuel (VPC) Amazon ?

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. 

Q : Quel type d'isolation puis-je obtenir avec une application EMR Serverless ?

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

Q. Qu'est-ce qui change avec les Service Quotas d'Amazon EMR Serverless ?
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.

Q. Où puis-je voir et gérer le quota de vCPU de mon compte ?
Vous pouvez afficher, gérer et demander l'augmentation des quotas dans la console de gestion AWS Service Quotas. Pour plus d'informations, consultez Demander une augmentation des quotas dans le guide Service Quotas.

Q. Quelle est la différence entre le quota vCPU au niveau du compte et la propriété maximumCapacity au niveau de l'application ?
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.

Q. Comment saurai-je si j'ai atteint mon quota de compte basé sur les 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.

Q : Comment Amazon EMR Serverless permet-il de réduire les coûts des déploiements de big data ?

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.

Q : Est-ce que le coût d'EMR Serverless est comparable à celui d'Amazon EMR sur les instances Spot EC2 ?

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.

Q : Est-ce que les travailleurs pré-initialisés sont facturés même après que les tâches aient été menées à terme ?

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.

Q : Qui puis-je contacter pour des questions, des commentaires et des demandes de fonctions ?

Veuillez nous envoyer un courriel à emr-feedback@amazon.com pour nous faire part de vos questions et de vos commentaires sur EMR Serverless.

Q : Qu'est-ce qu'Amazon EMR sur Amazon EKS ?
Amazon EMR sur Amazon EKS est un modèle de déploiement d'Amazon EMR qui permet aux clients de traiter facilement et économiquement de grandes quantités de données. Ce service utilise des frameworks analytiques hébergés s'exécutant sur le service géré flexible Amazon EKS dans des conteneurs, avec l'infrastructure web d'Amazon Elastic Compute Cloud (Amazon EC2), d'AWS Fargate et d'Amazon Simple Storage Service (Amazon S3).

Q : Pourquoi utiliser Amazon EMR sur Amazon EKS ?
Amazon EMR sur Amazon EKS découple la tâche analytique des services et de l'infrastructure qui traitent la tâche en utilisant une approche fondée sur les conteneurs. Vous pouvez davantage vous concentrer sur le développement de votre application et moins sur le fonctionnement de l'infrastructure, car EMR sur EKS configure l'infrastructure de manière dynamique en fonction du calcul, de la mémoire et des dépendances d'application de la tâche. Les équipes de l'infrastructure peuvent gérer une plateforme de calcul commune de manière centrale, pour renforcer les charges de travail EMR avec d'autres applications basées sur les conteneurs. Plusieurs équipes, organisations ou unités opérationnelles peuvent exécuter leurs processus analytiques simultanément et indépendamment sur l'infrastructure partagée, tout en conservant l'isolement offert par Amazon EKS et AWS Identity and Access Management (IAM).

Q : Quels sont les avantages pour les utilisateurs exécutant déjà Apache Spark sur Amazon EKS ?
Si vous exécutez déjà Apache Spark sur Amazon EKS, vous pouvez profiter de tous les avantages d'Amazon EMR, comme le provisionnement et la mise à l'échelle automatiques, et la faculté d'utiliser les dernières versions entièrement gérées de frameworks analytiques open source Big Data. Vous pouvez bénéficier d'un environnement d'exécution EMR optimisé pour Apache Spark avec des performances trois fois plus rapides qu'Apache Spark open source sur EKS, d'une expérience de science des données serverless avec EMR Studio et l'IU Apache Spark, d'un contrôle précis des accès aux données, et d'une assistance pour le chiffrement des données.

Q : Quelle relation existe-t-il entre cette fonctionnalité et d'autres services AWS ?
Amazon EKS offre aux clients une expérience gérée pour l'exécution de Kubernetes sur AWS, et leur permet d'ajouter des capacités de calcul à l'aide des groupes de nœuds gérés EKS ou d'AWS Fargate. L'exécution des tâches EMR sur EKS leur permet d'accéder à leurs données sur Amazon S3, tandis que la surveillance et la connexion peuvent être intégrées avec Amazon CloudWatch. AWS Identity and Access Management (IAM) garantit un contrôle des accès basé sur les rôles pour les tâches et services AWS dépendants.

Q : Comment fonctionne Amazon EMR sur Amazon EKS ?
Enregistrez votre cluster EKS avec Amazon EMR. Ensuite, soumettez vos tâches Spark à EMR à l'aide de l'interface de ligne de commande, de SDK ou d'EMR Studio. EMR requiert le planificateur Kubernetes sur EKS, pour programmer les pods. Pour chaque tâche que vous exécutez, EMR sur EKS crée un conteneur. Le conteneur contient l'image de base Amazon Linux 2 avec des mises à jour de sécurité, plus Apache Spark et les dépendances associées pour exécuter Spark, plus les dépendances spécifiques à votre application. Chaque tâche s'exécute dans un pod. Le pod télécharge ce conteneur et commence à l'exécuter. Si l'image du conteneur a déjà été déployée sur le nœud, une image mise en cache est utilisée et le téléchargement est contourné. Les conteneurs side-car, tels que les redirecteurs de journaux et de métriques, peuvent être déployés sur le pod. Le pod prend fin une fois la tâche résiliée. Une fois la tâche résiliée, vous pouvez toujours la déboguer à l'aide de l'IU Spark.

Q : Quels services de calcul AWS puis-je utiliser avec Amazon EMR sur EKS ?
Vous pouvez utiliser Amazon EMR sur EKS avec les instances Amazon Elastic Compute Cloud (EC2) pour prendre en charge de plus larges options de personnalisation, ou le service AWS Fargate serverless pour traiter vos analytiques sans devoir allouer ou gérer des instances EC2. La disponibilité des applications peut s'améliorer automatiquement par répartition de vos tâches analytiques sur plusieurs zones de disponibilité AWS.

Q : Comment démarrer avec EMR sur EKS ?
Pour démarrer, enregistrez votre cluster Amazon EKS avec Amazon EMR. Une fois l'enregistrement effectué, consignez-le dans la définition de votre tâche (qui inclut les dépendances d'application et les paramètres de framework) en soumettant vos charges de travail à EMR pour exécution. Avec EMR sur EKS, vous pouvez utiliser différents frameworks analytiques open source Big Data, versions et configurations pour les applications analytiques s'exécutant sur le même cluster EKS. Pour plus d'informations, consultez notre documentation.

Q : Puis-je utiliser la même version EMR pour les clusters EMR et les applications s'exécutant sur EKS ?

Oui, vous pouvez utiliser la même version EMR pour les applications qui s'exécutent sur les clusters EMR et les applications qui s'exécutent sur EKS.

Q : Comment réparer une application analytique ?
Vous pouvez utiliser l'IU Amazon EMR Spark pour diagnostiquer et résoudre les problèmes liés aux applications Spark. Pour toutes les applications analytiques, EMR fournit un accès aux détails de l'application, aux journaux associés et aux métriques jusqu'à 30 jours après leur exécution. Les tâches peuvent être configurées individuellement pour envoyer des journaux à un emplacement Amazon S3 ou Amazon CloudWatch.

Q : Puis-je voir les applications EMR dans EKS ?
Oui, les applications EMR s'affichent dans la console EKS, comme les tâches Kubernetes et déploiements.

Q : Puis-je isoler plusieurs tâches ou applications les uns des autres sur le même cluster EKS ?
Oui, Kubernetes garantit l'isolement des tâches en natif. En outre, chaque tâche peut être configurée pour s'exécuter avec son propre rôle d'exécution, pour limiter les ressources AWS auxquelles la tâche peut accéder.

Q : Comment EMR sur EKS contribue-t-il à réduire les coûts ?
EMR sur EKS réduit les coûts en éliminant le besoin d'exécuter des clusters dédiés. Vous pouvez utiliser un cluster EKS commun partagé pour exécuter des applications analytiques qui nécessitent différentes versions de frameworks analytiques open source Big Data. Vous pouvez également utiliser le même cluster EKS pour exécuter vos autres applications non EMR conteneurisées.

Q : Comment facturez-vous EMR sur EKS ?
La tarification Amazon EMR sur EKS est calculée en fonction du vCPU et des ressources de mémoire demandés pour le(s) pod(s) exécutant votre tâche selon une précision par minute. Pour plus d'informations sur la tarification, consultez la page de tarification d'Amazon EMR.

Q : Quelles sont les différences entre EMR sur EKS et EMR sur EC2 ?

Q : Qu'est-ce qu'AWS Outposts ?

AWS Outposts apporte les services, l'infrastructure et les modèles d'exploitation AWS natifs à la quasi-totalité de centres de données, d'espaces d'hébergement d'infrastructures ou d'installations sur site. En utilisant EMR sur Outposts, vous pouvez déployer, gérer et mettre à l'échelle des clusters EMR sur site, exactement comme vous le feriez dans le cloud.

Q : Quand dois-je utiliser EMR sur Outposts ?

Si vous avez des déploiements Apache Hadoop sur site et que vous éprouvez des difficultés pour répondre aux demandes de capacité lors des pics d'utilisation, vous pouvez utiliser EMR sur Outposts pour augmenter votre capacité de traitement sans devoir déplacer les données dans le cloud. EMR on Outposts vous permet de démarrer un nouveau cluster EMR sur site en quelques minutes et de vous connecter à des bases de données existantes dans le stockage HDFS sur site, afin de répondre à cette demande et de maintenir les niveaux de service.

Si vous avez besoin de traiter des données qui doivent rester sur site pour des raisons de gouvernance, de conformité ou pour d'autres raisons, vous pouvez utiliser EMR sur Outposts pour déployer et exécuter des applications telles qu'Apache Hadoop et Apache Spark sur site, à proximité de vos données. Cela réduit la nécessité de déplacer d'importantes quantités de données sur site vers le cloud, réduisant ainsi le temps global nécessaire pour traiter ces données.

Si vous êtes en pleine migration de données et de charges de travail Apache Hadoop vers le cloud et que vous souhaitez commencer à utiliser EMR avant la fin de votre migration, vous pouvez utiliser AWS Outposts pour lancer des clusters EMR qui se connectent à votre stockage HDFS sur site existant. Vous pouvez ensuite migrer progressivement vos données vers Amazon S3 dans le cadre d'une évolution vers une architecture cloud.

Q : Quelles versions d'EMR sont prises en charge par EMR sur Outposts ?

La version minimum d'Amazon EMR prise en charge est la 5.28.0.

Q : Quelles applications EMR sont disponibles lors de l'utilisation d'Outposts ?

Toutes les applications des versions 5.28.0 et supérieures d'EMR sont prises en charge. Consultez nos notes de mise à jour pour une liste complète des applications EMR.

Q : Quelles fonctions d'EMR ne sont pas prises en charge par EMR sur Outposts ?

• Les instances Spot EC2 ne sont pas disponibles dans AWS Outposts. Lorsque vous créez un cluster, vous devez choisir les instances EC2 à la demande.
• Un sous-ensemble des types d'instances EC2 est disponible dans AWS Outposts. Pour une liste des types d'instances pris en charge avec EMR et Outposts, consultez notre documentation.
• Lorsque vous ajoutez des volumes Amazon EBS à des instances, seul le type de stockage SSD à usage général (GP2) est pris en charge dans AWS Outposts.

Q : Puis-je utiliser des clusters EMR dans un Outpost pour lire des données depuis mes clusters Apache Hadoop sur site existants ?

Les charges de travail qui s'exécutent sur EMR dans un Outpost peuvent lire et écrire des données dans le stockage HDFS existant, vous permettant de les intégrer facilement à des déploiements Apache Hadoop sur site existants. Cela vous donne la possibilité d'accroître vos besoins en traitement des données à l'aide d'EMR sans avoir besoin de migrer des données.

Q : Puis-je choisir où stocker mes données ?

Lorsqu'un cluster EMR est lancé dans un Outpost, toutes les ressources de calcul et de stockage des données sont déployées dans votre Outpost. Les données écrites localement dans le cluster EMR sont stockées sur des volumes EBS locaux dans votre Outpost. Des outils tels que Apache Hive, Apache Spark, Presto et d'autres applications EMR peuvent chacun être configurés de manière à écrire des données localement dans un Outpost, dans un système de fichiers externe comme une installation HDFS existante, ou dans Amazon S3. Avec EMR sur Outposts, vous disposez d'un contrôle total sur le stockage de vos données dans Amazon S3 ou localement dans votre Outpost.

Q : Y a-t-il des fonctions EMR qui nécessitent des données chargées dans S3 ?

Lorsque vous lancez un cluster EMR dans un Outpost, vous avez la possibilité d'activer la journalisation. Lorsque la journalisation est activée, les journaux de clusters seront chargés dans le compartiment S3 que vous spécifiez. Ces journaux sont utilisés pour simplifier le débogage des clusters une fois qu'ils ont été résiliés. Lorsque cette option est désactivée, aucun journal n'est chargé dans S3.

Q : Que se passe-t-il si mon Outpost a une capacité insuffisante ?

Lorsque vous lancez un cluster dans un Outpost, EMR essaiera de lancer le nombre et le type d'instances EC2 à la demande que vous avez demandés. S'il n'y a pas de capacité disponible dans l'Outpost, EMR recevra une notification de capacité insuffisante. EMR réessaiera pendant un moment, et si aucune capacité ne devient disponible, le lancement du cluster échouera. Le même processus s'applique lors du redimensionnement d'un cluster. En cas de capacité insuffisante sur l'Outpost pour les types d'instances demandés, EMR ne sera pas en mesure de mettre à l'échelle le cluster. Vous pouvez facilement configurer des alertes Amazon CloudWatch pour surveiller votre utilisation de la capacité sur les Outposts et recevoir des alertes lorsque la capacité d'instance est inférieure au seuil souhaité.

Q : Que se passe-t-il si la connectivité réseau est interrompue entre mon Outpost et AWS ?

Si la connectivité réseau entre votre Outpost et sa région AWS est perdue, vos clusters dans Outposts continueront à s'exécuter, mais vous ne pourrez pas effectuer certaines actions tant que la connectivité n'aura pas été rétablie. Tant que la connectivité n'a pas été rétablie, vous ne pouvez pas créer de nouveaux clusters ou effectuer de nouvelles actions sur les clusters existants. Si une instance échoue, elle ne sera pas remplacée automatiquement. Par ailleurs, les actions comme l'ajout d'étapes à un cluster en cours d'exécution, la vérification du statut d'exécution de l'étape et l'envoi de métriques et d'événements CloudWatch seront retardées jusqu'à ce que la connectivité soit restaurée.

Nous vous recommandons de fournir une connectivité réseau fiable et hautement disponible entre votre Outpost et la région AWS. Si la connectivité réseau entre votre Outpost et sa région AWS est perdue pendant plus de quelques heures, les clusters pour lesquels la protection contre la résiliation est activée continueront à s'exécuter et les clusters pour lesquels la protection contre la résiliation est désactivée pourront être résiliés. Si la connectivité réseau est affectée par une maintenance de routine, nous recommandons d'activer la protection contre la résiliation de manière proactive.

Q : Que puis-je faire aujourd'hui que je ne pouvais pas faire auparavant ?

La plupart des instances EC2 sont fournies avec une capacité de stockage fixe qui leur est propre, appelée « stockage d'instance ». Vous pouvez maintenant ajouter des volumes EBS aux instances dans votre cluster Amazon EMR, afin de modifier la capacité de stockage d'une instance donnée. Cette fonctionnalité vous permet également d'exécuter des clusters Amazon EMR sur des familles d'instances EBS uniquement, comme les instances M4 et C4.

Q : Quels sont les avantages associés à l'ajout de volumes EBS à une instance exécutée sur Amazon EMR ?

L'ajout de volumes EBS à une instance est avantageux dans les situations suivantes :

1. Vos besoins de traitement sont si élevés que vous avez besoin d'une plus grande capacité de stockage HDFS (ou local) que celle proposée aujourd'hui sur une instance donnée. Avec la prise en charge des volumes EBS, vous pouvez modifier la capacité de stockage d'une instance par rapport à la capacité de calcul fournie par l'instance. En optimisant la capacité de stockage de votre instance, vous faites des économies.
2. Vous exécutez une famille d'instance ancienne génération (comme les familles M1 et M2) et vous désirez passer à la famille d'instance dernière génération, mais vous êtes limité par la capacité de stockage disponible par nœud sur les types d'instance nouvelle génération. Vous pouvez maintenant utiliser l'un des types d'instance nouvelle génération et ajouter des volumes EBS pour optimiser la capacité de stockage. Des comparatifs réalisés en interne indiquent qu'il est possible d'économiser de l'argent et d'améliorer les performances en passant d'une famille d'instance ancienne génération (M1 ou M2) à une famille nouvelle génération (M4, C4 et R3). L'équipe d'Amazon EMR recommande d'exécuter votre application pour arriver à la bonne conclusion.
3. Vous désirez utiliser ou migrer vers la famille M4 ou C4 nouvelle génération EBS uniquement.

Q : Puis-je conserver mes données sur un volume EBS après la suppression d'un cluster ?

À l'heure actuelle, Amazon EMR efface les volumes quand le cluster est supprimé. Si vous désirez conserver vos données au-delà du cycle de vie d'un cluster, nous vous conseillons d'utiliser Amazon S3 comme magasin de données.

Q : Quels types de volumes EBS puis-je associer à une instance ?

Amazon EMR vous permet d'utiliser différents types de volume EBS : les disques SSD à usage général (GP2), les volumes magnétiques et les Provisioned IOPS (SSD).

Q : Qu'arrive-t-il aux volumes EBS quand je supprime mon cluster ?

Amazon EMR efface les volumes quand le cluster EMR est supprimé.

Q : Puis-je utiliser un volume EBS avec une instance déjà dotée d'un stockage d'instance ?

Oui, vous pouvez ajouter des volumes EBS à des instances dotées d'un stockage d'instance.

Q : Puis-je associer un volume EBS à un cluster en cours d'exécution ?

Non. À l'heure actuelle, il est seulement possible d'ajouter des volumes EBS au lancement d'un cluster.

Q : Puis-je prendre des instantanés de volumes depuis un cluster ?

L'API d'EBS vous permet de prendre un instantané (snapshot) d'un cluster. Cependant, Amazon EMR ne vous permet pas, à l'heure actuelle, de faire une restauration depuis un instantané.

Q : Puis-je utiliser des volumes EBS chiffrés ?

Vous pouvez chiffrer le périphérique racine EBS et les volumes de stockage à l'aide d'AWS KMS en tant que votre fournisseur clé. Pour plus d'informations, consultez la section Chiffrement de disque local.

Q : Que se passe-t-il si je retire un volume associé à un cluster en cours d'exécution ?

Le retrait d'un volume associé à un cluster en cours d'exécution sera considéré comme une défaillance de nœud. Amazon EMR remplacera le nœud et le volume EBS par des dispositifs identiques.

Q : Qu'est-ce qu'Apache Spark ?

Apache Spark^TMest un système de traitement open source distribué, utilisé pour les charges de travail de big data. Il utilise la mise en cache en mémoire, ainsi que l'exécution de requête optimisée pour les requêtes d'analyse rapides par rapport aux données de toutes tailles. Amazon EMR est l'emplacement idéal pour déployer Apache Spark dans le cloud, car il combine l'intégration et la rigueur du test des distributions commerciales Spark à la mise à l'échelle, la simplicité et la rentabilité du cloud. Il vous permet de lancer des clusters Spark en quelques minutes sans avoir besoin d'allouer des nœuds, de configurer des clusters, de configurer Spark ou d'ajuster des clusters. Amazon EMR présente l'environnement d'exécution EMR pour Apache Spark, un environnement optimisé et activé par défaut sur les clusters Amazon EMR. L'environnement d'exécution Amazon EMR pour Apache Spark peut être jusqu'à trois fois plus rapide que les clusters sans environnement d'exécution EMR, et offre 100 % de compatibilité avec l'API standard Apache Spark. En savoir plus sur Spark et Spark sur Amazon EMR.

Q : Qu'est-ce que Presto ?

Presto est un moteur de requête SQL distribué open source désigné dès le départ pour des requêtes d'analyse rapides par rapport aux données de toutes tailles. Avec Amazon EMR, vous pouvez lancer des clusters Presto en quelques minutes sans avoir besoin d'allouer des nœuds, de configurer des clusters, de configurer Presto ou d'ajuster des clusters. Amazon EMR vous permet d'allouer une, des centaines ou des milliers d'instances de calcul en quelques minutes. Presto possède deux projets communautaires : PrestoDB et PrestoSQL. Amazon EMR prend en charge ces deux projets. En savoir plus sur Presto et sur Presto sur Amazon EMR.

Q : Qu'est-ce qu'Apache Hive ?

Hive est un entrepôt de données open source et un package analytique qui s'exécute au-dessus d'Hadoop. Hive est exploité avec un langage de base SQL, appelé Hive QL, qui permet aux utilisateurs de structurer, résumer et interroger des sources de données stockées dans Amazon S3. Hive QL va au-delà du SQL standard, en ajoutant une assistance de première catégorie en ce qui concerne les fonctions map/reduce et les types de données complexes extensibles définies par l'utilisateur comme Json et Thrift. Cette capacité permet le traitement de sources de données complexes et même non structurées comme les documents textes et les fichiers journaux. Hive rend possible les extensions utilisateurs via les fonctions définies par l'utilisateur, écrites en Java et déployées par le stockage dans Amazon S3. Pour en savoir plus sur Apache Hive, cliquez ici.

Q : Que puis-je faire avec Hive s'exécutant sur Amazon EMR ?

En utilisant Hive avec Amazon EMR, vous pouvez mettre en œuvre des applications élaborées de traitement de données avec un langage familier du type SQL et des outils faciles à utiliser avec Amazon EMR. Avec Amazon EMR, vous pouvez transformer vos applications Hive en entrepôts de données fiables pour exécuter les tâches telles que des analyses de données, la surveillance et des tâches de veille économique.

Q : En quoi Hive est-il différent des systèmes traditionnels SGBDR (RDBMS) ?

Les systèmes SGBDR traditionnels fournissent les sémantiques de transaction et les propriétés ACID. Ils permettent également aux tables d'être indexées et mises en cache, de façon à ce que de petites quantités de données puissent être récupérées très rapidement. Ils fournissent une mise à jour rapide de petites quantités de données et le renforcement de contraintes d'intégrité référentielle. Traditionnellement, ils s'exécutent sur une seule machine de grande taille et ne fournissent pas d'assistance pour l'exécution des fonctions map/reduce sur la table ; ils ne fournissent pas non plus d'assistance en ce qui concerne les types complexes de données, définis par l'utilisateur.

Par opposition, Hive exécute des demandes similaires à SQL en utilisant MapReduce. En conséquence, il est optimisé dans les numérisations de tables entières pendant qu'il fonctionne sur un cluster de machines et est par conséquent capable de traiter de très grandes quantités de données. Hive fournit des tables partitionnées, ce qui lui permet de numériser une partition de table plutôt que la table entière pour la requête qu'il est en train d'exécuter, si c'est approprié.

Les systèmes SGRBD traditionnels sont meilleurs pour les situations dans lesquelles la sémantique transactionnelle et l'intégrité référentielle sont requises et de petites mises à jour fréquentes effectuées. Hive est meilleur pour le rapport hors ligne, la transformation et l'analyse de grands ensembles de données ; par exemple, effectuer une analyse de parcours d'un grand site ou d'un ensemble de sites.

L'une des méthodes courantes est d'exporter les données des systèmes SGRBD dans Amazon S3 lorsque l'analyse hors ligne peut être effectuée en utilisant les clusters Amazon EMR exécutant Hive.

Q : Comment commencer à utiliser Hive exécuté sur Amazon EMR ?

Pour vos premiers pas, nous vous conseillons de consulter notre documentation écrite, qui se trouve ici.

Q : Existe-t-il de nouvelles fonctionnalités dans Hive spécifiques à Amazon EMR ?

Oui. Consultez notre documentation pour obtenir plus d'informations :

• Vous pouvez lancer un cluster EMR avec plusieurs nœuds principaux afin de prendre en charge une disponibilité élevée pour Apache Hive. 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. Cela signifie que vous pouvez exécuter Apache Hive sur les clusters EMR, et ce, sans interruption.
• Amazon EMR vous permet de définir EMR Managed Scaling pour les clusters Apache Hive, afin de vous aider à optimiser votre utilisation des ressources. Avec EMR Managed Scaling, vous pouvez automatiquement redimensionner votre cluster pour de meilleures performances, au coût le plus faible possible. Avec Amazon EMR Managed Scaling, vous spécifiez les limites de calcul minimum et maximum pour vos clusters, et Amazon EMR les redimensionne automatiquement pour de meilleures performances et une utilisation des ressources optimisée. EMR Managed Scaling échantillonne continuellement les métriques clés associées aux charges de travail s'exécutant sur les clusters.
• Amazon EMR 6.0.0 ajoute la prise en charge de Hive LLAP, qui multiplie la vitesse moyenne par deux par rapport à EMR 5.29. Vous pouvez en savoir plus en cliquant ici.
• Amazon EMR garantit également des performances élevées sur les requêtes Apache Hive complexes. EMR utilise Apache Tez par défaut, qui s'avère être considérablement plus rapide qu'Apache MapReduce. Apache MapReduce utilise des phases multiples, de sorte qu'une requête Apache Hive complexe est divisée en quatre ou cinq tâches. Apache Tez est conçu pour les requêtes plus complexes, de sorte que la même tache sur Apache Tez s'exécute en une seule tâche. Ce service est donc considérablement plus rapide qu'Apache MapReduce.
  
• Avec Amazon EMR, vous disposez de l'option de laisser le métastore en local, ou de l'externaliser. EMR fournit une intégration avec AWS Glue Data Catalog, Amazon Aurora, Amazon RDS et AWS Lake Formation. Amazon EMR peut extraire des informations directement de Glue ou de Lake Formation pour renseigner le métastore.
• Vous pouvez charger des partitions de table automatiquement depuis Amazon S3. Auparavant, pour importer une table partitionnée, vous aviez besoin d'une autre instruction de table séparée pour chaque partition individuelle de la table. Amazon EMR inclut maintenant un nouveau type d'instruction pour le langage Hive : « alter table recover partitions ». Cette instruction vous permet d'importer facilement des tables simultanément dans de nombreux clusters sans avoir à entretenir un magasin de métadonnées partagées. Utilisez cette fonctionnalité pour lire à partir des tables dans lesquelles des processus externes déposent des données, comme des fichiers journaux.
• Vous pouvez écrire des données directement vers Amazon S3. Quand elle écrit des données sur des tables sur Amazon S3, la version de Hive installée dans Amazon EMR écrit directement sur Amazon S3 sans l'utilisation de fichiers temporaires. Ceci produit une amélioration de performance considérable mais signifie que HDFS et S3 se comportent différemment du point de vue de Hive. Vous ne pouvez pas lire et modifier la même table à l'intérieur de la même instruction si cette table est placée dans Amazon S3. Si vous voulez mettre à jour une table placée dans S3, créez alors une table temporaire dans le fichier système HDFS local du cluster, modifiez les résultats de cette table, et copiez-les vers Amazon S3.
• Vous pouvez accéder aux ressources situées dans Amazon S3. La version Hive installée dans Amazon EMR vous permet de référencer des ressources, telles que les scripts pour des opérations Map et Reduce personnalisées ou des bibliothèques supplémentaires situées dans Amazon S3, directement au sein de votre script Hive (par ex., add jar s3://elasticmapreduce/samples/hive-ads/libs/jsonserde.jar).
  
  

Q : Quels types de clusters Hive sont pris en charge ?

Deux types de clusters sont pris en charge avec Hive : le mode interactif et le mode lot. Dans un mode interactif, un client peut démarrer un cluster et exécuter des scripts Hive de façon interactive et directement sur le nœud maître. Traditionnellement, ce mode est utilisé pour faire des analyses de données ad hoc et pour le développement d'application. Dans le mode lot, le script Hive est stocké dans Amazon S3 et référencé au début du cluster. Traditionnellement, le mode lot est utilisé pour des séquences qui peuvent être répétées telles que la génération de rapport.

Q : Comment puis-je lancer un cluster Hive ?

Les clusters en mode lot et en mode interactif peuvent tous être démarrés à partir d'AWS Management Console, du client de ligne de commande EMR ou d'une API. Consultez la section Hive du Guide du développeur pour plus d'informations sur la façon de lancer un cluster Hive.

Q : Quand devrais-je privilégier l'utilisation de Hive par opposition à PIG ?

Hive et PIG fournissent tous les deux des langages de traitement de données de haut niveau avec une assistance pour les types de données complexes dans le cadre du fonctionnement de grands ensembles de données. Le langage Hive est une variante de SQL et est ainsi plus accessible aux personnes déjà familières avec les bases de données SQL et les bases de données relationnelles. Hive prend en charge les tables partitionnées, ce qui permet aux clusters Amazon EMR de détruire seulement la partition de table appropriée à la requête en cours d'exécution plutôt que de numériser une table entière. PIG et Hive proposent tous deux une optimisation de plan de requête. PIG est capable d'optimiser à travers un script entier pendant que des requêtes Hive sont optimisées au niveau de l'instruction.

Finalement, le choix entre Hive ou PIG dépendra des exigences exactes du domaine d'application et des préférences des ingénieurs de mise en application et de ceux qui écrivent des requêtes.

Q : Quelle version de Hive est prise en charge par Amazon EMR ?

Pour la dernière version de Hive sur Amazon EMR, consultez la documentation.

Q : Puis-je écrire simultanément sur une table à partir de deux clusters ?

Non. Hive ne prend pas en charge l'écriture simultanée sur des tables. Vous devriez éviter d'écrire simultanément sur la même table ou de lire à partir d'une table pendant que vous écrivez dessus. Hive a un comportement non déterministe quand il lit et écrit en même temps ou écrit et modifie en même temps.

Q : Puis-je partager des données entre des clusters ?

Oui. Vous pouvez lire des données dans Amazon S3 à l'intérieur d'un script Hive en ayant des instructions « créer une table externe » en amont de votre script. Vous avez besoin d'une instruction de création de table pour chaque ressource externe à laquelle vous avez accès.

Q : Est-il préférable d'exécuter un grand cluster et de le répartir entre de nombreux utilisateurs ou d'exécuter de nombreux clusters plus petits ?

Amazon EMR fournit une opportunité unique afin de vous permettre d'utiliser les deux méthodes. D'un côté, un important cluster peut être plus efficace pour le traitement de charges de travail par lot régulières. D'un autre côté, si vous avez besoin d'effectuer des requêtes ou des charges de travail ad hoc qui varient dans le temps, vous pouvez choisir de créer plusieurs clusters séparés, adaptés à une tâche spécifique de partage de sources de données stockées dans Amazon S3. Vous pouvez utiliser EMR Managed Scaling pour optimiser l'utilisation des ressources.

Q : Puis-je accéder à une ressource script ou jar qui est sur mon système de fichiers local ?

Vous devez télécharger le script ou la ressource jar vers Amazon S3 ou le nœud maître du cluster avant qu'il puisse être référencé. Pour télécharger vers Amazon S3, vous pouvez utiliser les outils, y compris s3cmd, jets3t ou S3Organizer.

Q : Puis-je exécuter un cluster persistant exécutant des requêtes Hive multiples ?

Oui. Vous exécutez un cluster selon un mode d'arrêt manuel de façon à ce qu'il ne s'arrête pas entre des étapes Hive. Pour réduire le risque de perte de données, nous vous recommandons de conserver périodiquement toutes vos données importantes dans Amazon S3. Une bonne habitude consiste à transférer régulièrement votre travail vers un nouveau cluster pour tester votre processus de récupération en cas de défaillance d'un nœud maître.

Q : Des utilisateurs multiples peuvent-ils exécuter des étapes Hive sur la même base de données ?

Oui. Les scripts Hive exécutés par des utilisateurs multiples sur des clusters séparés peuvent contenir des instructions de tables externes pour importer simultanément des données sources qui résident dans Amazon S3.

Q : Des utilisateurs multiples peuvent-ils exécuter des requêtes sur le même cluster ?

Oui. Dans le mode lot, les étapes sont exécutées en série. Les utilisateurs multiples peuvent ajouter des étapes Hive au même cluster. Cependant, les étapes seront exécutées en série. Dans le mode interactif, plusieurs utilisateurs peuvent se connecter sur le même cluster et exécuter les instructions Hive simultanément.

Q : Est-ce que les données peuvent être partagées entre des utilisateurs AWS multiples ?

Oui. Les données peuvent être partagées en utilisant un mécanisme de partage Amazon S3 standard décrit ici.

Q : Est-ce que Hive prend en charge l'accès à partir de JDBC ?

Oui. Hive fournit un lecteur JDBC, qui peut être utilisé pour exécuter les instructions Hive via un programme. Pour démarrer un service JDBC dans votre cluster, vous devez passer un paramètre facultatif dans la ligne de commande client Amazon EMR. Vous devez également établir un tunnel SSH parce que le groupe de sécurité ne permet pas de connexions externes.

Q : Quelle est la procédure pour mettre à jour les packages sur les AMI EMR ?

Au premier démarrage, les AMI Amazon Linux pour EMR se connectent aux référentiels yum d'AMI Amazon Linux pour installer des mises à jour de sécurité. Lorsque vous utilisez une AMI personnalisée, vous pouvez désactiver cette fonctionnalité, mais nous ne recommandons pas cette manœuvre pour des raisons de sécurité.

Q : Puis-je mettre à jour mes propres packages sur les clusters EMR ?

Oui. Vous pouvez utiliser des actions de démarrage pour installer des mises à jour des packages sur vos clusters.

Q : Puis-je traiter des données DynamoDB à l'aide de Hive ?

Oui. Définissez simplement une table Hive externe basée sur votre table DynamoDB. Vous pouvez ensuite utiliser Hive pour analyser les données stockées dans DynamoDB et soit recharger les résultats dans DynamoDB, soit les archiver dans Amazon S3. Pour plus d'informations, consultez notre Guide du développeur.

Q : Qu'est-ce qu'Apache Hudi ?

Apache Hudi est un framework de gestion des données open source utilisé pour simplifier le traitement des données incrémentielles et le développement de pipelines de données. Apache Hudi vous permet de gérer les données au niveau de l'enregistrement dans Amazon S3 afin de simplifier la capture des données modifiées (CDC) et la transmission en continu des données. Il fournit également un framework permettant de gérer les cas d'utilisation de la confidentialité des données nécessitant des mises à jour et suppressions au niveau de l'enregistrement. Les ensembles de données gérés par Apache Hudi sont stockés dans S3 à l’aide de formats de stockage ouverts. Les intégrations avec Presto, Apache Hive, Apache Spark et le catalogue de données AWS Glue vous offrent un accès quasi temps réel aux données mises à jour au moyen des outils courants.

Q : Quand utiliser Apache Hudi ?

Apache Hudi vous aide avec les cas d'utilisation nécessitant une gestion de données au niveau de l'enregistrement sur S3. Cinq cas d'utilisation courants bénéficient de ces fonctionnalités :

1. Conformité aux réglementations relatives à la confidentialité des données, qui obligent les organisations à supprimer les données utilisateur ou à mettre à jour les préférences de l'utilisateur lorsque l'utilisateur choisit de modifier ses préférences quant à la manière dont ses données peuvent être utilisées. Apache Hudi vous permet d'effectuer des opérations d'insertion, de mise à jour et de suppression au niveau de l'enregistrement sur vos données stockées dans S3, à l'aide de formats de données open source tels qu'Apache Parquet et Apache Avro.
2. Consommation de flux de données en temps réel et application de journaux de capture des données modifiées à partir de systèmes d'entreprise. De nombreuses organisations exigent que les données EDW (Enterprise Data Warehouse) et ODS (Operational Data Warehouse) soient disponibles dans Amazon S3 afin que les moteurs SQL, tels que Apache Hive et Presto, puissent y accéder pour le traitement et à l’analyse des données. Apache Hudi simplifie l'application des journaux des modifications et offre aux utilisateurs un accès aux données en quasi-temps réel.
3. Réactivation des données tardives incorrectes. Les données tardives ou incorrectes nécessitent de réactiver les données, et de mettre à jour les ensembles de données pour incorporer les enregistrements nouveaux ou mis à jour. Apache Hudi vous permet d’« insérer »des enregistrements dans un ensemble de données existant, en s’appuyant sur le cadre pour insérer ou mettre à jour des enregistrements en fonction de leur présence dans l’ensemble de données.
4. Suivi des modifications apportées aux ensembles de données et possibilité d'annuler les modifications. Avec Apache Hudi, chaque modification apportée à un ensemble de données est suivie comme une validation et peut être facilement annulée, ce qui permet de rechercher des modifications spécifiques dans un ensemble de données et de les « annuler ».
5. Simplification de la gestion des fichiers sur S3. Pour que les fichiers de données soient correctement dimensionnés, les clients doivent créer des solutions personnalisées qui surveillent et réécrivent de nombreux petits fichiers dans un moins grand nombre de fichiers plus volumineux. Avec Apache Hudi, les fichiers de données sur S3 sont gérés, et les utilisateurs peuvent simplement configurer une taille de fichier optimale pour stocker leurs données. Hudi fusionne les fichiers pour créer des fichiers de taille efficace.
6. Écriture des deltas sur un ensemble de données Hudi cible. Les ensembles de données Hudi peuvent être extraits de manière incrémentielle. Cela signifie que vous pouvez obtenir TOUT et UNIQUEMENT les lignes mises à jour et nouvelles depuis un instant T spécifié.

Q : Comment créer un ensemble de données Apache Hudi ?

Les ensembles de données Apache Hudi sont créés à l'aide d'Apache Spark. La création d'un ensemble de données est aussi simple que d'écrire un Apache Spark DataFrame. Les métadonnées des ensembles de données Apache Hudi peuvent être éventuellement stockées dans le catalogue de données AWS Glue ou dans le métastore Hive afin de simplifier la découverte des données et de les intégrer à Apache Hive et Presto.

Q : Comment Apache Hudi gère-t-il les ensembles de données ?

Lors de la création d'un ensemble de données avec Apache Hudi, vous pouvez choisir le type de modèle d'accès aux données pour lequel l'ensemble de données doit être optimisé. Pour les cas d'utilisation à lecture intensive, vous pouvez sélectionner la stratégie de gestion de données « Copy on Write » (Copier sur écriture) pour optimiser les lectures fréquentes de l'ensemble de données. Cette stratégie organise les données au moyen de formats de stockage en colonnes et fusionne les données existantes et les nouvelles mises à jour lors de l'écriture des mises à jour. Pour les charges de travail à écriture intensive, Apache Hudi utilise la stratégie de gestion de données « Merge on Read » (Fusionner sur lecture), qui organise les données à l'aide d'une combinaison de formats de stockage en colonnes et en lignes, où les mises à jour sont ajoutées à un fichier sous forme de format de stockage en lignes, et où la fusion est effectuée lors de la lecture, pour fournir des résultats mis à jour.

Q : Comment écrire dans un ensemble de données Apache Hudi ?

Les modifications apportées aux ensembles de données Apache Hudi sont effectuées à l'aide d'Apache Spark. Avec Apache Spark, les ensembles de données Apache Hudi sont exploités à l'aide de l'API Spark DataSource, ce qui vous permet de lire et d'écrire des données. Un DataFrame contenant des données récemment ajoutées ou des mises à jour de données existantes peut être écrit à l'aide de la même API Spark DataSource. Vous pouvez également utiliser l'utilitaire Hudi DeltaStreamer.

Q : Comment lire depuis un ensemble de données Apache Hudi ?

Vous pouvez lire des données au moyen d'Apache Spark, d'Apache Hive, de Presto, d'Amazon Redshift Spectrum, ou d'Amazon Athena. Lorsque vous créez un ensemble de données, vous avez la possibilité de publier les métadonnées de cet ensemble de données dans le catalogue de données AWS Glue ou dans le métastore Hive. Si vous choisissez de publier les métadonnées dans un métastore, votre ensemble de données ressemble à une table ordinaire, et vous pouvez interroger la table à l'aide d'Apache Hive et de Presto.

Q : Quelles sont les considérations ou les limites à prendre en compte lors de l'utilisation d'Apache Hudi ?

Pour obtenir la liste complète des considérations et des limitations lors de l'utilisation d'Apache Hudi sur Amazon EMR, consultez notre documentation Amazon EMR.

Q : Comment mes données existantes fonctionnent-elles avec Apache Hudi ?

Si vous souhaitez gérer maintenant des données existantes avec Apache Hudi, vous pouvez facilement convertir vos données Apache Parquet en ensembles de données Apache Hudi à l'aide d'un outil d'importation fourni avec Apache Hudi sur Amazon EMR. Vous pouvez également utiliser l'utilitaire Hudi DeltaStreamer ou Apache Spark pour réécrire vos données existantes comme ensemble de données Apache Hudi.

Q : Qu'est-ce qu'Impala ?

Impala est un outil open source dans l'écosystème Hadoop. Il est utilisé pour effectuer des requêtes interactives et ad hoc à l'aide de la syntaxe SQL. À l'inverse de MapReduce, Impala exploite un moteur de traitement massivement parallèle (MPP) similaire à celui des systèmes de gestion de base de données relationnelle traditionnels (SGBDR). Avec cette architecture, vous pouvez rapidement interroger vos données dans HDFS ou les tables HBase, exploiter la capacité d'Hadoop à traiter divers types de données et fournir un schéma lors de l'exécution de cet outil. De ce fait, Impala génère des analyses interactives et à faible latence. En outre, Impala utilise le Hive metastore pour stocker les informations relatives aux données d'entrée, y compris le nom de partition et le type de données. Impala sur Amazon EMR nécessite également des AMI exécutant Hadoop 2.x ou version ultérieure. Cliquez ici pour en savoir plus sur Impala.

Q : Que puis-je faire avec Impala s'exécutant sur Amazon EMR ?

À l'instar de Hive avec Amazon EMR, exploiter Impala avec Amazon EMR peut mettre en place des applications de traitement de données sophistiquées avec la syntaxe SQL. Cependant, Impala est conçu pour s'exécuter plus rapidement dans certains cas d'utilisation (voir ci-dessous). Avec Amazon EMR, vous pouvez utiliser Impala comme un entrepôt de données fiable pour exécuter certaines données telles que des tâches analytiques de données, de surveillance et d'informatique décisionnelle. Voici les trois cas d'utilisation de cet outil :

• Utilisation d'Impala à la place de Hive sur les clusters de longue durée pour effectuer les requêtes ad hoc. Avec Impala, les requêtes interactives ne prennent que quelques secondes, ce qui en fait un excellent outil pour les requêtes rapides. Vous pouvez exécuter Impala sur le même cluster que vos clusters exécutés par lots MapReduce, utiliser Impala sur un cluster d'analyses de longue durée avec Hive et Pig ou créer un cluster spécifiquement ajusté pour les requêtes Impala.
• Utilisation d'Impala à la place de Hive pour les travaux ETL exécutés par lots sur les clusters Amazon EMR transitoires. Impala est plus rapide que Hive pour de nombreuses requêtes, ce qui fournit de meilleures performances pour ces charges de travail. À l'instar de Hive, Impala utilise SQL, de sorte que les requêtes puissent être facilement modifiées depuis Hive vers Impala.
• Utilisation d'Impala en parallèle d'un outil d'informatique décisionnelle tiers. Connectez un pilote client ODBC ou JDBC à votre cluster pour utiliser Impala comme moteur de puissants outils et tableaux de bord de virtualisation.

Les clusters Impala exécutés par lots et interactifs peuvent être créés dans Amazon EMR. Pour les instances, vous pouvez bénéficier d'un cluster Amazon EMR de longue durée exécutant Impala pour les requêtes ad hoc et interactives ou utiliser des clusters transitoires Impala pour les flux de travail ETL rapides.

Q : En quoi Impala est-il différent des systèmes traditionnels SGBDR (RDBMS) ?

Les systèmes de gestion de base de données relationnelle traditionnels (SGBDR) fournissent les sémantiques de transaction et les propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID) aux bases de données. Ils permettent également aux tables d'être indexées et mises en cache, de façon à ce que de petites quantités de données puissent être récupérées très rapidement, fournissent des mises à jour rapides de petites quantités de données et le renforcement de contraintes d'intégrité référentielle. Traditionnellement, ils s'exécutent sur une seule machine de grande taille et ne fournissent pas d'assistance pour ce qui concerne les types complexes de données définis par l'utilisateur. Impala utilise un système d'interrogation distribué similaire à ceux des systèmes SGBDR (RDBMS), mais interroge les données stockées dans HDFS et utilise le Hive metastore pour conserver les informations relatives aux données d'entrée. Comme pour Hive, le schéma d'une requête est fourni lors de l'exécution d'Impala, permettant de changer plus facilement de schéma. En outre, Impala peut interroger différents types de données complexes et exécuter les fonctions définies par l'utilisateur. Cependant, comme Impala traite les données stockées dans la mémoire, vous devez bien comprendre les limites matérielles de votre cluster et optimiser vos requêtes pour obtenir les meilleures performances.

Q : En quoi Impala est-il différent de Hive ?

Impala exécute les requêtes SQL à l'aide d'un moteur de traitement massivement parallèle (MPP), tandis que Hive exécute les requêtes SQL au moyen de MapReduce. Impala évite le temps système de Hive destiné à créer des travaux MapReduce, ce qui lui confère des délais d'interrogation plus courts que Hive. Cependant, Impala a recours à des ressources mémoire considérables et la mémoire disponible du cluster constitue une contrainte pesant sur la quantité de mémoire pouvant être consommée par chaque requête. Hive n'est pas limité de la même manière et peut traiter des ensembles de données plus volumineux avec le même matériel. En général, vous devriez utiliser Impala pour les requêtes rapides et interactives et Hive pour les charges de travail ETL sur de larges ensembles de données. Impala est conçu pour être rapide et est idéal pour les requêtes ad hoc, mais il nécessite une quantité de mémoire considérable pour exécuter les requêtes coûteuses ou traiter des ensembles de données très volumineux. C'est pourquoi Hive est recommandé pour les charges de travail où la rapidité n'est pas aussi cruciale que l'achèvement de la tâche. Cliquez ici pour consulter l'évaluation comparative des performances d'Impala et de Hive.

Q : Puis-je utiliser Hadoop 1 ?

Non. Impala requiert Hadoop 2 et ne s'exécute pas sur un cluster avec une AMI exécutant Hadoop 1.x.

Q : Quels types d'instances devrais-je utiliser pour mon cluster Impala ?

Pour profiter de la meilleure expérience avec Impala, nous vous recommandons d'utiliser des instances optimisées pour la mémoire pour votre cluster. Toutefois, nous avons démontré qu'Impala est également plus performant que Hive lors de l'utilisation de types d'instances standard. Nous vous suggérons de lire la section Performance Testing and Query Optimization du Guide du développeur Amazon EMR pour mieux estimer les ressources mémoire dont votre cluster aura besoin en fonction de votre ensemble de données et des types de requêtes. Le type de compression, les partitions et la requête réelle (nombre de jonctions, taille du résultat, etc.) constituent des éléments déterminant la mémoire requise. Vous pouvez utiliser l'instruction EXPLAIN pour estimer la quantité de mémoire et autres ressources nécessaires à une requête Impala.

Q : Que se passe-t-il si la mémoire est saturée lors d'une requête ?

Si la mémoire est saturée, les requêtes échoueront et le démon Impala sur le nœud touché s'arrêtera. Amazon EMR redémarrera ensuite le démon sur le nœud de sorte qu'Impala soit prêt à exécuter une autre requête. Vos données dans HDFS sur le nœud restent disponibles, car c'est plus le démon exécuté sur le nœud, que le nœud en lui-même, qui s'arrête. Concernant les analyses ad hoc avec Impala, le délai d'interrogation peut souvent se mesurer en secondes. Par conséquent, si une requête échoue, vous pouvez rapidement déceler le problème et être en mesure de soumettre une nouvelle requête.

Q : Est-ce qu'Impala prend en charge les fonctions définies par l'utilisateur ?

Oui. Impala prend en charge les fonctions définies par l'utilisateur (UDF). Vous pouvez écrire des UDF spécifiques Impala dans Java ou C++. Vous pouvez également modifier les UDF ou les fonctions d'agrégat définies par l'utilisateur créées pour Hive afin de les utiliser avec Impala. Pour en savoir sur les UDF Hive, cliquez ici.

Q : Où sont stockées les données qu'Impala interroge ?

Impala interroge les données stockées dans HDFS ou dans les tables HBase.

Q : Puis-je exécuter Impala et MapReduce en même temps sur un cluster ?

Oui. Vous pouvez mettre en place un cluster partagé avec Impala et MapReduce. Toutefois, vous devez vous assurer d'allouer des ressources (mémoire, disque, CPU) à chaque application utilisant YARN sur Hadoop 2.x. Les ressources allouées dépendent des tâches que vous prévoyez d'exécuter sur chaque application.

Q : Est-ce qu'Impala prend en charge les pilotes ODBC et JDBC ?

Alors que vous pouvez utiliser des pilotes ODBC, Impala est également un moteur idéal pour les outils tiers connectés à l'aide des pilotes JDBC. Vous pouvez télécharger et installer le pilote client JDBC pour Impala à partir du fichier suivant : http://elasticmapreduce.s3.amazonaws.com/libs/impala/1.2.1/impala-jdbc-1.2.1.zip. Depuis l'ordinateur client sur lequel vous avez installé l'outil d'informatique décisionnelle, connectez le pilote JDBC au nœud maître d'un cluster à l'aide de SSH ou d'une connexion VPN sur le port 21050. Pour en savoir plus, consultez la section Open an SSH Tunnel to the Master Node.

Q : Qu'est-ce qu'Apache Pig ?

Pig est un package analytique open source qui s'exécute au-dessus de Hadoop. Pig est exploité avec un langage de base SQL appelé Pig Latin qui permet aux utilisateurs de structurer, résumer et interroger des sources de données stockées dans Amazon S3. Tout comme les opérations de type SQL, Pig Latin ajoute également une assistance de première catégorie pour les fonctions map/reduce et les types de données complexes et extensibles définis par l'utilisateur. Cette capacité permet le traitement de sources de données complexes et même non structurées comme les documents textes et les fichiers journaux. Pig permet les extensions utilisateurs par les fonctions définies par l'utilisateur, écrites en Java et déployées par le stockage dans Amazon S3.

Q : Que puis-je faire avec Pig s'exécutant sur Amazon EMR ?

En utilisant Pig avec Amazon EMR, vous pouvez mettre en œuvre des applications élaborées de traitement de données avec un langage familier du type de SQL et des outils faciles à utiliser avec Amazon EMR. Avec Amazon EMR, vous pouvez transformer vos applications Pig en entrepôts de données fiables pour exécuter les données telles que des tâches analytiques de données, de surveillance et des tâches de veille économique.

Q : Comment commencer avec Pig exécuté sur Amazon EMR ?

Pour vos premiers pas, nous vous conseillons de consulter notre documentation écrite, qui se trouve ici.

Q : Existe-t-il de nouvelles fonctionnalités dans Pig spécifiques à Amazon EMR ?

Oui. Trois nouvelles fonctionnalités existent et font de Pig un outil encore plus puissant quand il est utilisé avec Amazon EMR, y compris :

a/ l'accès à des fichiers systèmes multiples : Par défaut, un travail Pig peut seulement accéder à un système de fichier distant, qu'il soit dans un magasin HDFS ou un compartiment S3, pour des données d'entrée, de sortie ou temporaires. EMR a étendu Pig de telle manière qu'une tâche puisse accéder à autant de systèmes de fichiers. Un avantage de cette caractéristique est que les données temporaires internes à la tâche sont toujours stockées sur le HDFS local, qui conduit à l'amélioration des performances.

b/ le chargement de ressources à partir de S3. EMR a étendu Pig afin que les ressources JAR et les scripts personnalisés puissent être chargés à partir du système de fichiers S3, par exemple via « REGISTER s3:///my-bucket/piggybank.jar »

c/ la fonction Piggybank additionnelle pour le traitement String et DateTime.

Q : Quels types de clusters Pig sont pris en charge ?

Deux types de clusters sont pris en charge avec Pig : le mode interactif et le mode lot. Dans un mode interactif, un client peut démarrer un cluster, et exécuter des scripts Pig de façon interactive et directement sur le nœud maître. Traditionnellement, ce mode est utilisé pour faire des analyses de données ad hoc et pour le développement d'application. Dans le mode lot, le script Pig est stocké dans Amazon S3 et référencé au début du cluster. Traditionnellement, le mode lot est utilisé pour des séquences qui peuvent être répétées telles que la génération de rapport.

Q : Comment puis-je lancer un cluster Pig ?

Les clusters en mode lot et en mode interactif peuvent tous être démarrés à partir d'AWS Management Console, du client de ligne de commande EMR ou d'une API.

Q : Quelle version de Pig est prise en charge par Amazon EMR ?

Amazon EMR prend en charge différentes versions de Pig.

Q : Puis-je écrire simultanément sur un compartiment S3 à partir de deux clusters ?

Oui. Vous pouvez modifier le même compartiment à partir de deux clusters simultanés.

Q : Puis-je partager des données d'entrée dans S3 entre deux clusters ?

Oui. Vous pouvez lire les mêmes données dans S3 à partir de deux clusters simultanés.

Q : Est-ce que les données peuvent être partagées entre des utilisateurs AWS multiples ?

Oui. Les données peuvent être partagées en utilisant un mécanisme de partage Amazon S3 standard, décrit ici http://docs.amazonwebservices.com/AmazonS3/latest/index.html?S3_ACLs.html

Q : Est-il préférable d'exécuter un grand cluster et de le répartir entre de nombreux utilisateurs ou d'exécuter de nombreux clusters plus petits ?

Amazon EMR fournit une opportunité unique afin de vous permettre d'utiliser les deux méthodes. D'un côté, un important cluster peut être plus efficace pour le traitement de charges de travail par lot régulières. D'un autre côté, si vous avez besoin d'effectuer des requêtes ou des charges de travail ad hoc qui varient dans le temps, vous pouvez choisir de créer plusieurs clusters séparés, adaptés à une tâche spécifique de partage de sources de données stockées dans Amazon S3.

Q : Puis-je accéder à une ressource script ou jar qui est sur mon système de fichiers local ?

Vous devez télécharger le script ou la ressource jar vers Amazon S3 ou le nœud maître du cluster avant qu'il puisse être référencé. Pour télécharger vers Amazon S3, vous pouvez utiliser les outils, y compris s3cmd, jets3t ou S3Organizer.

Q : Puis-je exécuter un cluster persistant exécutant des requêtes Pig multiples ?

Oui. Vous exécutez un cluster selon un mode d'arrêt manuel de façon à ce qu'il ne s'arrête pas entre des étapes Pig. Pour réduire le risque de perte de données, nous vous recommandons de conserver périodiquement toutes vos données importantes dans Amazon S3. Une bonne habitude consiste à transférer régulièrement votre travail vers un nouveau cluster pour tester votre processus de récupération en cas de défaillance d'un nœud maître.

Q : Est-ce que Pig prend en charge un accès à partir de JDBC ?

Non. Pig ne prend pas en charge l'accès via JDBC. 

Q : Qu'est-ce qu'Apache HBase ?

HBase est une base de données open source, non relationnelle et distribuée, conçue sur le modèle de BigTable de Google. Elle a été développée dans le cadre du projet Apache Sofware Foundation de Hadoop et elle s'exécute au-dessus du système de fichiers distribués Hadoop (HDFS, Hadoop Distributed File System) afin de lui fournir des capacités comparables à celles de BigTable. HBase offre un stockage tolérant aux pannes et efficace de volumes importants de données dispersées, qui utilise la compression et le stockage basés sur des colonnes. En outre, il permet de rechercher rapidement des données, car celles-ci sont stockées en mémoire au lieu d'un disque. Il est optimisé pour les opérations d'écriture séquentielle et très efficace pour l'insertion, la mise à jour et la suppression de lots. Il fonctionne de manière fluide avec Hadoop en partageant son système de fichiers et en servant d'entrée et de sortie directe pour les tâches dans Hadoop. HBase intègre également Apache Hive, ce qui rend possible l’exécution de requêtes de type SQL sur les tables HBase, se joint aux tables basées sur Hive et permet la prise en charge de la connectivité des bases de données JDBC (Java Database Connectivity). Pour en savoir plus sur Apache HBase, cliquez ici.

Q : Existe-t-il de nouvelles fonctionnalités dans HBase spécifiques à Amazon EMR ?

Avec Amazon EMR, vous pouvez utiliser HBase sur Amazon S3 pour stocker le répertoire racine HBase et les métadonnées d'un cluster directement sur Amazon S3, et créer des réplicas et instantanés de lecture. Consultez notre documentation pour en savoir plus.

Q : Quelles sont les versions de HBase prises en charge sur Amazon EMR ?

Vous pouvez consulter ici les dernières versions de HBase prises en charge sur Amazon EMR.

Q : Que permet de faire le connecteur EMR à Kinesis ?

Le connecteur permet à EMR de lire et d'interroger directement des données provenant de flux Kinesis. Vous pouvez désormais procéder au traitement par lot de flux Kinesis à l'aide des outils existants de l'écosystème Hadoop tels que Hive, Pig, MapReduce, Hadoop Streaming et Cascading.

Q : Quelles sont les nouvelles possibilités offertes par le connecteur EMR à Kinesis ?

En temps normal, pour lire et traiter des données provenant d'un flux Kinesis, vous devez écrire, déployer et tenir à jour des applications de traitement de flux indépendantes. Cela prend du temps et demande beaucoup d'efforts. Cependant, grâce à ce connecteur, vous pouvez commencer à lire et analyser un flux Kinesis en écrivant un simple script Hive ou Pig. Autrement dit, vous pouvez analyser des flux Kinesis en utilisant SQL. Vous pouvez, bien sûr, utiliser d'autres outils de l'écosystème Hadoop si vous le souhaitez. Vous n'avez pas besoin de développer ni de tenir à jour des applications de traitement supplémentaires.

Q : Pour quels types d'utilisateurs cette fonctionnalité peut-elle se révéler utile ?

Cette intégration profite aux types d'utilisateurs suivants :

• Les utilisateurs Hadoop souhaitant mettre à profit les nombreux outils de l'écosystème Hadoop pour analyser des flux Kinesis
  
• Les utilisateurs Kinesis recherchant une méthode simple pour mettre en place des processus de traitement des flux et d'ETL des données Kinesis
  
• Les analystes d'affaires et professionnels de l'informatique souhaitant réaliser une analyse ad hoc des données de flux Kinesis à l'aide d'outils courants tels que SQL (via Hive) ou de langages de script tels que Pig
  

Q : Quels sont les principaux cas d'utilisation de cette intégration ?

Voici quelques-uns des cas d'utilisation spécifiques permis par cette intégration :

• Analyse de fichiers journaux de diffusion continue : vous pouvez analyser les fichiers journaux Web de vos flux de diffusion continue afin de générer la liste des 10 principales erreurs par région, navigateur et domaine d'accès, et de l'actualiser à intervalles de quelques minutes.
  
• Processus de traitement de données complexes : vous pouvez combiner un flux Kinesis à des données stockées dans S3, HDFS et des tables Dynamo DB. Vous pouvez écrire des requêtes associant des données de parcours de navigation provenant de Kinesis à des informations sur une campagne publicitaire stockées dans une table DynamoDB, dans le but d'identifier les catégories de publicité les plus efficaces parmi celles affichées sur des sites Web donnés.
  
• Requêtes Spot : vous pouvez charger périodiquement des données provenant de Kinesis dans HDFS et les exporter dans une table Impala locale permettant d'effectuer des requêtes analytiques rapides et interactives.
  

Q : Quelle version de l'AMI EMR dois-je choisir pour utiliser le connecteur ?

Vous devez utiliser la version 3.0.4 de l'AMI EMR ou une version ultérieure.

Q : Le connecteur constitue-t-il un outil indépendant ?

Non. Il s'agit d'un composant intégré à la distribution d'Hadoop proposée par Amazon. Le connecteur est disponible dans la version 3.0.4 et les versions ultérieures de l'AMI EMR. Pour utiliser cette fonctionnalité, le client doit simplement mettre en service un cluster avec une AMI de version 3.0.4 ou ultérieure.

Q : Quel est le format de données requis pour permettre à EMR de lire les données d'un flux Kinesis ?

L'intégration entre EMR et Kinesis n'impose pas de format de données particulier. Vous pouvez lire tous les formats des données. Chaque enregistrement Kinesis est présenté à Hadoop en tant qu'enregistrement standard pouvant être lu avec n'importe quel framework MapReduce Hadoop. Les différents cadres tels que Hive, Pig et Cascading intègrent des composants facilitant la sérialisation et la désérialisation. Les développeurs peuvent ainsi interroger facilement des données dans de nombreux formats, sans avoir à implémenter de code personnalisé. Par exemple, dans Hive, les utilisateurs peuvent lire des données issues de fichiers JSON, XML et SEQ en utilisant le SerDe Hive approprié lors de la définition d'une table. Pig propose un composant similaire, appelé Loadfunc/Evalfunc, de même que Cascading avec Tap. Les utilisateurs Hadoop peuvent exploiter l'ensemble de l'écosystème d'adaptateurs Hadoop sans avoir à écrire de code déterminé par un format précis. Vous pouvez également implémenter des formats de désérialisation personnalisés pour lire des données spécifiques à un domaine avec l'un de ces outils.

Q : Comment analyser un flux Kinesis avec Hive dans EMR ?

Créez une table qui référence un flux Kinesis. Vous pouvez alors analyser la table dans Hive selon la procédure habituelle. Pour plus de détails, consultez nos didacticiels.

Q : J'utilise Hive, comment puis-je créer des requêtes qui combinent des données de flux Kinesis à d'autres sources de données ?

Commencez par créer une table qui référence un flux Kinesis. Une fois la table Hive créée, vous pouvez l'associer à des tables renvoyant vers d'autres sources données comme Amazon S3, Amazon Dynamo DB et HDFS. Cette procédure permet d'associer efficacement des données provenant de flux Kinesis à d'autres sources de données.

Q : Cette intégration est-elle uniquement disponible pour Hive ?

Non. Vous pouvez utiliser Hive, Pig, MapReduce, Hadoop Streaming et Cascading.

Q : Comment puis-je configurer des tâches planifiées devant s'exécuter sur un flux Kinesis ?

Le connecteur d'entrée EMR Kinesis propose des fonctionnalités qui vous aident à configurer et gérer des tâches périodiques planifiées dans des moteurs de planification classiques de type Cron. Vous pouvez, par exemple, développer un script Hive qui s'exécute toutes les n minutes. Dans les paramètres de configuration des tâches, vous pouvez attribuer un nom logique à la tâche. Ce nom logique est un intitulé qui indique au connecteur d'entrée EMR Kinesis que les différentes instances de la tâche font partie du même calendrier périodique. Le nom logique permet au processus d'exploiter le système d'itérations, présenté ci-après.

MapReduce est un framework de traitement par lot. Pour analyser un flux Kinesis à l'aide d'EMR, ce flux doit donc être divisé en lots. Chaque lot constitue une itération. Ces itérations portent chacune un numéro, en partant de 0. Les limites des itérations sont définies par un numéro de début de séquence et un numéro de fin de séquence. Les itérations sont ensuite traitées de manière séquentielle par EMR.

En cas d'échec d'une tentative, le connecteur d'entrée EMR Kinesis relancera le traitement de l'itération correspondant au nom logique, à partir du numéro de début de séquence connu de l'itération. Grâce à cette fonctionnalité, les tentatives successives sur une même itération concernent exactement les mêmes enregistrements d'entrée du flux Kinesis que les tentatives précédentes. Cela garantit la cohérence (idempotence) du traitement du flux Kinesis.

Vous pouvez spécifier des noms logiques et des itérations en tant que paramètres d'exécution dans les outils Hadoop que vous utilisez. Par exemple, la section consacrée à l'exécution de requêtes avec points de contrôle de ce didacticiel comprend un exemple de code pour une requête Hive planifiée spécifiant un nom logique de requête, avec passage à l'itération suivante à chaque exécution successive de la tâche.

Vous pourrez également trouver un exemple de script de planification cron dans les didacticiels.

Q : Où sont stockées les métadonnées des noms logiques et itérations ?

Les métadonnées permettant au connecteur d'entrée EMR Kinesis de fonctionner selon des processus de planification périodique sont stockées dans Amazon DynamoDB. Vous devez mettre en service une table Amazon Dynamo DB et la désigner en tant que paramètre d'entrée de la tâche Hadoop. Pour garantir la réussite de l'intégration, veillez à configurer le débit d'E/S par seconde approprié pour la table. Référez-vous au didacticiel de mise en route pour en savoir plus sur la configuration des tables Amazon Dynamo DB.

Q : Que se passe-t-il en cas d'échec du traitement d'une itération ?

Les identificateurs d'itération sont des valeurs indiquées par l'utilisateur pour l'associer à des limites spécifiques (numéros de début et de fin de séquence) au sein d'un flux Kinesis. Les données comprises dans ces limites sont chargées pendant la phase de traitement (« Map ») de la tâche MapReduce. Cette phase, gérée par le framework, est automatiquement relancée (trois fois par défaut) en cas d'échec de la tâche. Si toutes les tentatives échouent, vous disposez encore d'options permettant de relancer le traitement à partir de la dernière limite de données traitée avec succès, ou de limites de données précédentes. Pendant le traitement, vous pouvez contrôler ce comportement en indiquant le paramètre kinesis.checkpoint.iteration.no. Référez-vous au didacticiel de mise en route pour en savoir plus sur la configuration de cette valeur dans les différents outils de l'écosystème Hadoop.

Q : Puis-je exécuter plusieurs requêtes sur une même itération ?

Oui. Vous pouvez sélectionner une itération ayant déjà fait l'objet d'une requête en définissant le paramètre kinesis.checkpoint.iteration.no lors de traitements ultérieurs. En utilisant ce paramètre, vous avez la certitude que les exécutions successives sur une même itération concernent exactement les mêmes enregistrements d'entrée du flux Kinesis que les exécutions précédentes.

Q : Que se passe-t-il si les enregistrements d'une itération ont expiré dans le flux Kinesis ?

Dans le cas où le numéro de début et/ou de fin de séquence d'une itération concerne des enregistrements du flux Kinesis ayant expiré, la tâche Hadoop échoue. Vous devez alors utiliser un autre nom logique pour traiter les données depuis le début du flux Kinesis.

Q : Puis-je transférer des données depuis EMR vers le flux Kinesis ?

À l'heure actuelle, le connecteur EMR Kinesis ne permet pas d'écrire des données dans un flux Kinesis.

Q : Le connecteur d'entrée EMR Hadoop pour Kinesis permet-il le traitement de flux en continu ?

Le framework Hadoop MapReduce est un système de traitement par lot. En tant que tel, il ne prend pas en charge les requêtes en continu. Il existe cependant un certain nombre de frameworks émergents de l'écosystème Hadoop, tels que Twitter Storm et Spark Streaming, qui permettent aux développeurs de créer des applications de traitement de flux en continu. Un connecteur Storm pour Kinesis est disponible sur cette page GitHub. Vous pouvez consulter un didacticiel expliquant comment configurer Spark Streaming sur EMR et exécuter des requêtes en continu ici.

Les développeurs peuvent, en outre, utiliser la bibliothèque client Kinesis pour développer des applications de traitement de flux en temps réel. Vous trouverez des informations plus complètes sur le développement d'applications Kinesis personnalisées dans la documentation de Kinesis, disponible ici.

Q : Puis-je indiquer des informations d'identification pour accéder à un flux Kinesis géré par un autre compte AWS ?

Oui. Vous pouvez lire les flux d'un autre compte AWS en indiquant les informations d'identification d'accès du compte auquel appartient ce flux Kinesis. Par défaut, le connecteur Kinesis utilise les informations d'identification d'accès fournies par l'utilisateur au moment de la création du cluster. Vous pouvez utiliser des informations d'identification différentes pour accéder à des flux d'autres comptes AWS : pour cela, définissez les paramètres kinesis.accessKey et kinesis.secretKey. Les exemples suivants vous montrent comment définir les paramètres kinesis.accessKey et kinesis.secretKey dans Hive et Pig.

Exemple de code pour Hive :
...
STORED BY
'com.amazon.emr.kinesis.hive.KinesisStorageHandler'
TBLPROPERTIES(
"kinesis.accessKey"="AwsAccessKey",
"kinesis.secretKey"="AwsSecretKey",
);

Exemple de code pour Pig :
…
raw_logs = LOAD 'AccessLogStream' USING com.amazon.emr.kinesis.pig.Kin
esisStreamLoader('kinesis.accessKey=AwsAccessKey', 'kinesis.secretKey=AwsSecretKey'
) AS (line:chararray);

Q : Puis-je exécuter plusieurs requêtes en parallèle sur un même flux Kinesis ? Cela influera-t-il sur les performances ?

Oui. Il est possible d'exécuter plusieurs requêtes en parallèle sur un même flux en utilisant des noms logiques différents pour chaque requête. Cependant, les opérations de lecture depuis une partition du flux Kinesis sont soumises à une limitation de débit de 2 Mo/s. Ainsi, si N requêtes s'exécutent en parallèle sur le même flux, chacune d'elles obtiendra un débit en sortie d'environ (2/N) Mo/s par partition composant le flux. Cela risque de ralentir le traitement et, dans certains cas, d'entraîner l'échec des requêtes.

Q : Puis-je associer et analyser plusieurs flux Kinesis dans EMR ?

Oui. Dans Hive, par exemple, vous pouvez créer deux tables associées à des flux Kinesis différents, puis créer des jointures entre les tables.

Q : Le connecteur EMR Kinesis peut-il gérer les événements de dimensionnement Kinesis, par exemple les fusions et subdivisions ?

Oui. L'implémentation peut gérer les événements de scission et de subdivision. Le connecteur Kinesis relie chaque partition Kinesis (unité de mesure logique au sein d'un flux Kinesis) aux tâches de traitement Hadoop MapReduce. Chaque partition unique existant au sein d'un flux pendant la période logique d'une itération entraîne la création d'une tâche de mappage. En cas de division ou de fusion d'une partition, Kinesis crée de nouveaux ID de partition uniques. En conséquence, le framework MapReduce met en service des tâches de mappage supplémentaires pour la lecture depuis Kinesis. Toutes ces opérations sont transparentes pour l'utilisateur.

Q : Que se passe-t-il si mon flux contient des périodes de « silence » ?

L'implémentation vous permet de configurer un paramètre appelé kinesis.nodata.timeout. Imaginons, par exemple, le scénario suivant : le paramètre kinesis.nodata.timeout est défini sur 2 minutes et vous souhaitez exécuter une requête Hive toutes les 10 minutes. Des données sont par ailleurs venues s'ajouter au flux depuis la dernière itération (il y a 10 minutes). Cependant, aucun nouvel enregistrement n'est transmis actuellement, ce qui signifie que le flux connaît une période de silence. Dans ce cas, lorsque l'itération actuelle de la requête est lancée, le connecteur Kinesis ne trouve aucun nouvel enregistrement en cours de transmission. Le connecteur continue à interroger le flux pendant 2 minutes. Si aucun enregistrement n'est reçu dans cet intervalle, le connecteur interrompt la requête et traite uniquement les enregistrements qui ont déjà été lus dans le lot actuel du flux. Cependant, si de nouveaux enregistrements arrivent avant que la durée définie pour kinesis.nodata.timeout soit écoulée, le connecteur patiente pendant un intervalle de temps supplémentaire, correspondant au paramètre kinesis.iteration.timeout. Pour savoir comment définir ces paramètres, consultez les didacticiels.

Q : Comment déboguer une requête qui échoue systématiquement pour chaque itération ?

En cas d'échec du traitement, vous pouvez utiliser les mêmes outils que ceux auxquels vous avez actuellement recours pour déboguer des tâches Hadoop, notamment la console Web Amazon EMR, qui vous aide à identifier les journaux d'erreurs et à y accéder. Pour plus de détails sur le débogage des tâches EMR, cliquez ici.

Q : Que se passe-t-il si je spécifie une table DynamoDB à laquelle je n'ai pas accès ?

La tâche échoue et l'exception est enregistrée dans les fichiers journaux d'erreurs de la tâche.

Q : Que se passe-t-il si la tâche s'exécute correctement, mais que l'enregistrement de points de contrôle dans DynamoDB échoue ?

La tâche échoue et l'exception est enregistrée dans les fichiers journaux d'erreurs de la tâche.

Q : Comment puis-je maximiser le débit en lecture depuis le flux Kinesis vers EMR ?

Le débit provenant du flux Kinesis augmente proportionnellement à la taille d'instance utilisée et à la taille des enregistrements du flux Kinesis. Nous vous recommandons d'utiliser des instances m1.xlarge ou de taille supérieure pour les nœuds maîtres et principaux afin d'exploiter au mieux cette fonctionnalité. 

Q : Qu'est-ce que le Contrat de niveau de service (SLA) Amazon EMR ?

Consultez notre Contrat de niveau de service (SLA).

Q : Qu'est-ce que fournit votre contrat de niveau de service (SLA) d'Amazon EMR Service ?