Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migration depuis les tâches shell AWS Glue Python

AWS a lancé les tâches shell AWS Glue Python en 2018. AWS a lancé les tâches shell AWS Glue Python en 2018 afin de permettre aux clients d’exécuter facilement des scripts Python pour des tâches ETL de petite et moyenne taille, mais aussi de déclencher des requêtes SQL. Cependant, il existe désormais des options plus modernes et plus flexibles pour gérer les charges de travail actuellement exécutées sur PythonShell. Cette rubrique explique comment migrer vos charges de travail depuis les tâches shell AWS Glue Python vers l’une de ces alternatives afin de tirer parti des nouvelles fonctionnalités disponibles.

Cette rubrique explique comment migrer des tâches shell AWS Glue Python vers des options alternatives.

Migration de la charge de travail vers des tâches AWS Glue Spark

Les tâches AWS Glue Spark et PySpark vous permettent d’exécuter vos charges de travail de manière distribuée. Comme les tâches shell AWS Glue Python et les tâches AWS Glue Spark s’exécutent sur la même plateforme, la migration est simple et vous pouvez continuer à utiliser les fonctionnalités AWS Glue existantes que vous utilisez avec les tâches shell Python, telles que les flux de travail AWS Glue, les déclencheurs AWS Glue, l’intégration Amazon EventBridge d’AWS Glue, l’installation de packages basée sur PIP, etc.

Cependant, les tâches AWS Glue Spark sont conçues pour exécuter des charges de travail Spark, et le nombre minimum de travailleurs est de deux. Si vous migrez à partir de tâches shell Python sans modifier vos scripts, un seul travailleur sera réellement utilisé et les autres resteront inactifs. Cela augmentera vos coûts.

Pour que l’opération soit efficace, réécrivez votre script de tâche Python afin d’utiliser les fonctionnalités de Spark et de répartir la charge de travail entre plusieurs travailleurs. Si votre script Python est basé sur Pandas, il est facile de le migrer à l’aide de la nouvelle API Pandas sur Spark. Pour en savoir plus, consultez AWS Big Data Blog: Dive deep into AWS Glue 4.0 for Apache Spark.

Migration de la charge de travail vers AWS Lambda

AWS Lambda est un service informatique sans serveur qui vous permet d’exécuter un code sans demander la mise en service ou la gestion des serveurs. Comme AWS Lambda a des temps de démarrage plus courts et des options de capacité de calcul plus flexibles, vous pouvez bénéficier de ces avantages. Pour gérer des bibliothèques Python supplémentaires, les tâches shell AWS Glue Python utilisent une installation basée sur PIP. Cependant, pour AWS Lambda, vous devez choisir l’une des options suivantes : une archive zip, une image de conteneur ou des couches Lambda.

En revanche, le délai d’attente maximal pour AWS Lambda est de 900 secondes (15 minutes). Si la durée de tâche de votre charge de travail de tâche shell AWS Glue Python existante est supérieure, ou si votre charge de travail présente un schéma au trafic important susceptible de prolonger la durée des tâches, nous vous recommandons d’explorer d’autres options au lieu de AWS Lambda.

Migration de la charge de travail vers Amazon ECS/Fargate

Amazon Elastic Container Service (Amazon ECS) est un service entièrement géré qui simplifie le déploiement, la gestion et la mise à l’échelle des applications conteneurisées. AWS Fargate est un moteur de calcul sans serveur pour les charges de travail conteneurisées exécutées sur Amazon ECS et Amazon Elastic Kubernetes Service (Amazon EKS). Il n’y a pas de délai d’expiration maximal sur Amazon ECS et Fargate, c’est donc une bonne option pour les tâches de longue durée. Comme vous avez le contrôle total sur l’image de votre conteneur, vous pouvez importer votre script Python et des bibliothèques Python supplémentaires dans le conteneur et les utiliser. Cependant, vous devez conteneuriser votre script Python pour utiliser cette approche.

Migration de la charge de travail vers Amazon Managed Workflows pour Apache Airflow Python Operator

Amazon Managed Workflows pour Apache Airflow (Managed Workflows pour Apache Airflow) est un service d’orchestration géré pour Apache Airflow qui facilite la configuration et l’exploitation de pipelines de données de bout en bout dans le cloud à grande échelle. Si vous disposez déjà d’un environnement MWAA, il sera facile d’utiliser l’opérateur Python au lieu des tâches shell AWS Glue Python. L’opérateur Python est un opérateur qui exécute du code Python dans un flux de travail Airflow. Toutefois, si vous ne disposez pas d’un environnement MWAA existant, nous vous recommandons d’explorer d’autres options.

Migration de la charge de travail vers des tâche d’entraînement Amazon SageMaker AI AI

L’entraînement Amazon SageMaker AI est un service de machine learning (ML) entièrement géré proposé par Amazon SageMaker AI qui vous aide à entraîner efficacement un large éventail de modèles de ML à grande échelle. Le cœur des tâches d’Amazon SageMaker AI AI est la conteneurisation des charges de travail de ML et la capacité à gérer les ressources de calcul AWS. Si vous préférez un environnement sans serveur où il n’y a pas de délai d’attente maximal, les tâches d’entraînement Amazon SageMaker AI AI pourraient vous convenir. Cependant, la latence de démarrage a tendance à être plus longue que celle des tâches shell AWS Glue Python. Pour les tâches sensibles à la latence, nous vous recommandons d’explorer d’autres options.