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.
Utiliser les bibliothèques Python avec AWS Glue
Vous pouvez installer des modules et bibliothèques Python supplémentaires à utiliser avec AWS Glue ETL. Pour AWS Glue 2.0 et versions ultérieures, AWS Glue utilise le Python Package Installer (pip3) pour installer les modules supplémentaires utilisés par AWS Glue ETL. AWS Glue propose plusieurs options pour intégrer les modules Python supplémentaires à votre environnement de travail AWS Glue. Vous pouvez utiliser le paramètre « — additional-python-modules » pour importer des modules à l'aide de fichiers de roue Python, d'un fichier d'exigences (requirement.txt, AWS Glue 5.0 et versions ultérieures) ou d'une liste de modules Python séparés par des virgules.
Rubriques
Installation de modules Python supplémentaires avec pip dans AWS Glue 2.0 ou version ultérieure
Meilleures pratiques pour installer des bibliothèques Python supplémentaires dans AWS Glue
Y compris des fichiers Python dotés de fonctionnalités PySpark natives
Scripts de programmation utilisant des transformations visuelles
Chargement de bibliothèques Python dans les blocs-notes AWS Glue Studio
Chargement de bibliothèques Python dans un endpoint de développement dans AWS Glue 0.9/1.0
Utilisation de bibliothèques Python dans une tâche ou JobRun
| Version Glue | Version Python | Image de base | version de la glibc | Méthodes d'installation prises en charge |
|---|---|---|---|---|
| 5.0 | 3,11 | Amazon Linux 2023 (AL2023) |
2,34 | |
| 4.0 | 3,10 | Amazon Linux (2AL2) |
2,26 |
Meilleures pratiques pour installer des bibliothèques Python supplémentaires dans AWS Glue |
| 3.0 | 3.7 | Amazon Linux (2AL2) |
2,26 |
Meilleures pratiques pour installer des bibliothèques Python supplémentaires dans AWS Glue |
| 2.0 | 3.7 | AMI Amazon Linux (AL1) |
2,17 | Meilleures pratiques pour installer des bibliothèques Python supplémentaires dans AWS Glue |
| 1.0 | 3.6 | AMI Amazon Linux (AL1) |
2,17 |
Meilleures pratiques pour installer des bibliothèques Python supplémentaires dans AWS Glue |
| 0.9 | 2.7 | AMI Amazon Linux (AL1) |
2,17 | Meilleures pratiques pour installer des bibliothèques Python supplémentaires dans AWS Glue |
Dans le cadre du modèle de responsabilitéAWS partagée
AWS Glue ne prend pas en charge la compilation de code natif dans l'environnement de travail. Cependant, les tâches AWS Glue s'exécutent dans un environnement Linux géré par Amazon. Vous pourrez peut-être fournir vos dépendances natives sous une forme compilée via un fichier Python Wheel. Reportez-vous au tableau ci-dessus pour plus d'informations sur la compatibilité des versions de AWS Glue.
Si vos dépendances Python dépendent de manière transitive d'un code natif compilé, vous risquez de vous heurter à la limitation suivante : AWS Glue ne prend pas en charge la compilation de code natif dans l'environnement de travail. Cependant, les tâches AWS Glue s'exécutent dans un environnement Linux géré par Amazon. Vous pourrez peut-être fournir vos dépendances natives sous une forme compilée via une distribution de roues. Reportez-vous au tableau ci-dessus pour plus d'informations sur la compatibilité des versions de AWS Glue.
Important
L'utilisation de dépendances incompatibles peut entraîner des problèmes d'exécution, en particulier pour les bibliothèques dont les extensions natives doivent correspondre à l'architecture et aux bibliothèques système de l'environnement cible. Chaque version de AWS Glue fonctionne sur une version spécifique de Python avec des bibliothèques et des configurations système préinstallées.
Installation de modules Python supplémentaires avec pip dans AWS Glue 2.0 ou version ultérieure
AWS Glue utilise le Python Package Installer (pip3) pour installer des modules supplémentaires qui seront utilisés par AWS Glue ETL. Vous pouvez utiliser le paramètre --additional-python-modules avec une liste de modules Python séparés par des virgules pour ajouter un nouveau module ou modifier la version d'un module existant. Vous pouvez installer des distributions personnalisées d'une bibliothèque en chargeant la distribution sur Amazon S3, puis en incluant le chemin d'accès à l'objet Amazon S3 dans votre liste de modules.
Vous pouvez transmettre des options supplémentaires à pip3 à l'aide du paramètre --python-modules-installer-option. Par exemple, vous pouvez transmettre "--upgrade" pour mettre à niveau les packages spécifiés par "--additional-python-modules". Pour plus d'exemples, voir Création de modules Python à partir d'une roue pour les charges de travail Spark ETL à l'aide de AWS Glue 2.0
AWS Glue prend en charge l'installation de packages Python personnalisés à l'aide de fichiers wheel (.whl) stockés dans Amazon S3. Pour inclure des fichiers de roues dans vos tâches AWS Glue, fournissez une liste séparée par des virgules de vos fichiers de roues stockés dans s3 dans le paramètre de --additional-python-modules tâche. Par exemple :
--additional-python-modules s3://amzn-s3-demo-bucket/path/to/package-1.0.0-py3-none-any.whl,s3://your-bucket/path/to/another-package-2.1.0-cp311-cp311-linux_x86_64.whl
Cette approche est également utile lorsque vous avez besoin de distributions personnalisées ou de packages avec des dépendances natives précompilés pour le système d'exploitation approprié. Pour plus d'exemples, voir Création de modules Python à partir d'une roue pour les charges de travail Spark ETL à l'aide de AWS Glue 2.0
Vous le spécifiez --additional-python-modules dans le champ Paramètres du job de la console AWS Glue ou en modifiant les arguments du job dans le AWS SDK. Pour plus d'informations sur la définition des paramètres des tâches, consultez la section Utilisation des paramètres des tâches dans les tâches AWS Glue.
Dans AWS Glue 5.0, vous pouvez fournir le standard de facto pour requirements.txt gérer les dépendances des bibliothèques Python. Pour ce faire, fournissez les deux paramètres de tâche suivants :
-
Clé :
--python-modules-installer-optionValeur :
-r -
Clé :
--additional-python-modulesValeur :
s3://path_to_requirements.txt
AWS Les nœuds Glue 5.0 chargent initialement les bibliothèques python spécifiées dansrequirements.txt.
Voici un exemple de fichier requirements.txt :
awswrangler==3.9.1 elasticsearch==8.15.1 PyAthena==3.9.0 PyMySQL==1.1.1 PyYAML==6.0.2 pyodbc==5.2.0 pyorc==0.9.0 redshift-connector==2.1.3 scipy==1.14.1 scikit-learn==1.5.2 SQLAlchemy==2.0.36
Important
Évitez les versions de bibliothèque non épinglées dans votre fichier requirements.txt afin de disposer d'un environnement AWS Glue fiable et déterministe pour vos tâches.
Lorsque vous utilisez Wheel pour les dépendances directes, vous pouvez introduire une version incompatible de vos dépendances transitives si elles ne sont pas correctement épinglées. La meilleure pratique consiste à épingler toutes les versions de bibliothèques pour des raisons de cohérence dans les tâches AWS Glue. AWS Glue recommande d'empaqueter votre environnement python dans un fichier Wheel afin de garantir la cohérence et la fiabilité de votre charge de travail de production.
Pour mettre à jour ou ajouter un nouveau module Python, AWS Glue permet de transmettre des --additional-python-modules paramètres avec une liste de modules Python séparés par des virgules sous forme de valeurs. Par exemple, pour mettre à jour/ajouter le module scikit-learn, utilisez la clé/valeur suivante : "--additional-python-modules",
"scikit-learn==0.21.3" Vous avez deux options pour configurer directement les modules python.
-
Module Python épinglé (recommandé)
"--additional-python-modules", "scikit-learn==0.21.3,ephem==4.1.6" -
Module Python non épinglé : (non recommandé pour les charges de travail de production)
"--additional-python-modules", "scikit-learn>==0.20.0,ephem>=4.0.0"OU
"--additional-python-modules", "scikit-learn,ephem"
Important
Lorsque vous configurez les modules python directement dans AWS Glue--additional-python-modules, il est recommandé d'utiliser des versions de bibliothèques épinglées pour garantir la cohérence de l'environnement de travail AWS Glue. L'utilisation de versions de bibliothèques non épinglées permet d'extraire la dernière version des modules python, mais cela peut introduire des modifications importantes ou entraîner l'apparition d'un module python incompatible, entraînant un échec de la tâche en raison d'un échec de l'installation de python dans l'environnement de travail AWS Glue. Nous recommandons aux clients de ne pas utiliser de versions de bibliothèques non épinglées pour la charge de travail de production. En tant que bonne pratique, AWS Glue recommande d'empaqueter votre environnement python dans un fichier Wheel afin de garantir la cohérence et la fiabilité de votre charge de travail de production.
Meilleures pratiques pour installer des bibliothèques Python supplémentaires dans AWS Glue
(Recommandé) Empaqueter l'environnement Python dans un fichier à roue unique
Pour un environnement sûr et cohérent, AWS Glue vous recommande de créer une capture instantanée de votre environnement python et de l'empaqueter dans un fichier wheel. L'avantage est que votre environnement python pour les modules python de référence et ses dépendances transitives seront verrouillés. Cela garantit que votre tâche AWS Glue n'est pas affectée lorsqu'un référentiel en amont tel que PyPI ou les dépendances introduit des mises à jour incompatibles.
Ce fichier peut ensuite être utilisé dans votre tâche AWS Glue à l'aide du --additional-python-modules drapeau.
Important
Vous devez exécuter le script suivant dans un environnement similaire à celui de la version de AWS Glue que vous utilisez. Reportez-vous au tableau détaillé de l'environnement Glue et assurez-vous que vous utilisez la même image du système d'exploitation de base et la même version de python.
#!/bin/bash set -e REQUIREMENTS_FILE="requirements.txt" FINAL_WHEEL_OUTPUT_DIRECTORY="." PACKAGE_NAME=$(basename "$(pwd)") PACKAGE_VERSION="0.1.0" # Help message show_help() { echo "Usage: $0 [options]" echo "" echo "Options:" echo " -r, --requirements FILE Path to requirements.txt file (default: requirements.txt)" echo " -o, --wheel-output DIR Output directory for final wheel (default: current directory)" echo " -n, --name NAME Package name (default: current directory name)" echo " -v, --version VERSION Package version (default: 0.1.0)" echo " -h, --help Show this help message" echo " -g, --glue-version Glue version (required)" echo "" echo "Example:" echo " $0 -r custom-requirements.txt -o dist -n my_package -v 1.2.3 -g 4.0" } # Parse command line arguments while [[ $# -gt 0 ]]; do key="$1" case $key in -r | --requirements) REQUIREMENTS_FILE="$2" shift 2 ;; -o | --wheel-output) FINAL_WHEEL_OUTPUT_DIRECTORY="$2" shift 2 ;; -n | --name) PACKAGE_NAME="$2" shift 2 ;; -v | --version) PACKAGE_VERSION="$2" shift 2 ;; -g | --glue-version) GLUE_VERSION="$2" shift 2 ;; -h | --help) show_help exit 0 ;; *) echo "Unknown option: $1" show_help exit 1 ;; esac done # If package name has dashes, convert to underscores and notify user. We need to check this since we cant import a package with dashes. if [[ "$PACKAGE_NAME" =~ "-" ]]; then echo "Warning: Package name '$PACKAGE_NAME' contains dashes. Converting to underscores." PACKAGE_NAME=$(echo "$PACKAGE_NAME" | tr '-' '_') fi UBER_WHEEL_NAME="${PACKAGE_NAME}-${PACKAGE_VERSION}-py3-none-any.whl" # Check if glue version is provided if [ -z "$GLUE_VERSION" ]; then echo "Error: Glue version is required." exit 1 fi # Validate version format (basic check) if [[ ! "$PACKAGE_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]] && [[ ! "$PACKAGE_VERSION" =~ ^[0-9]+\.[0-9]+$ ]]; then echo "Warning: Version '$PACKAGE_VERSION' doesn't follow semantic versioning (x.y.z or x.y)" fi # Check if requirements file exists if [ ! -f "$REQUIREMENTS_FILE" ]; then echo "Error: Requirements file '$REQUIREMENTS_FILE' not found." exit 1 fi # Get relevant platform tags/python versions based on glue version if [[ "$GLUE_VERSION" == "5.0" ]]; then PYTHON_VERSION="3.11" GLIBC_VERSION="2.34" elif [[ "$GLUE_VERSION" == "4.0" ]]; then PYTHON_VERSION="3.10" GLIBC_VERSION="2.26" elif [[ "$GLUE_VERSION" == "3.0" ]]; then PYTHON_VERSION="3.7" GLIBC_VERSION="2.26" elif [[ "$GLUE_VERSION" == "2.0" ]]; then PYTHON_VERSION="3.7" GLIBC_VERSION="2.17" elif [[ "$GLUE_VERSION" == "1.0" ]]; then PYTHON_VERSION="3.6" GLIBC_VERSION="2.17" elif [[ "$GLUE_VERSION" == "0.9" ]]; then PYTHON_VERSION="2.7" GLIBC_VERSION="2.17" else echo "Error: Unsupported glue version '$GLUE_VERSION'." exit 1 fi echo "Using Glue version $GLUE_VERSION" echo "Using Glue python version $PYTHON_VERSION" echo "Using Glue glibc version $GLIBC_VERSION" PIP_PLATFORM_FLAG="" is_glibc_compatible() { # assumes glibc version in the form of major.minor (ex: 2.17) # glue glibc must be >= platform glibc local glue_glibc_version="$GLIBC_VERSION" local platform_glibc_version="$1" # 2.27 (platform) can run on 2.27 (glue) if [[ "$platform_glibc_version" == "$glue_glibc_version" ]]; then return 0 fi local glue_glibc_major="${glue_glibc_version%%.*}" local glue_glibc_minor="${glue_glibc_version#*.}" local platform_glibc_major="${platform_glibc_version%%.*}" local platform_glibc_minor="${platform_glibc_version#*.}" # 3.27 (platform) cannot run on 2.27 (glue) if [[ "$platform_glibc_major" -gt "$glue_glibc_major" ]]; then return 1 fi # 2.34 (platform) cannot run on 2.27 (glue) if [[ "$platform_glibc_major" -eq "$glue_glibc_major" ]] && [[ "$platform_glibc_minor" -gt "$glue_glibc_minor" ]]; then return 1 fi # 2.17 (platform) can run on 2.27 (glue) return 0 } PIP_PLATFORM_FLAG="" if is_glibc_compatible "2.17"; then PIP_PLATFORM_FLAG="${PIP_PLATFORM_FLAG} --platform manylinux2014_x86_64" fi if is_glibc_compatible "2.28"; then PIP_PLATFORM_FLAG="${PIP_PLATFORM_FLAG} --platform manylinux_2_28_x86_64" fi if is_glibc_compatible "2.34"; then PIP_PLATFORM_FLAG="${PIP_PLATFORM_FLAG} --platform manylinux_2_34_x86_64" fi if is_glibc_compatible "2.39"; then PIP_PLATFORM_FLAG="${PIP_PLATFORM_FLAG} --platform manylinux_2_39_x86_64" fi echo "Using pip platform flags: $PIP_PLATFORM_FLAG" # Convert to absolute paths REQUIREMENTS_FILE=$(realpath "$REQUIREMENTS_FILE") FINAL_WHEEL_OUTPUT_DIRECTORY=$(realpath "$FINAL_WHEEL_OUTPUT_DIRECTORY") TEMP_WORKING_DIR=$(mktemp -d) VENV_DIR="${TEMP_WORKING_DIR}/.build_venv" WHEEL_OUTPUT_DIRECTORY="${TEMP_WORKING_DIR}/wheelhouse" # Cleanup function cleanup() { echo "Cleaning up temporary files..." rm -rf "$TEMP_WORKING_DIR" } trap cleanup EXIT echo "=========================================" echo "Building wheel for $PACKAGE_NAME with all dependencies from $REQUIREMENTS_FILE" echo "=========================================" # Determine Python executable to use consistently PYTHON_EXEC=$(which python3 2>/dev/null || which python 2>/dev/null) if [ -z "$PYTHON_EXEC" ]; then echo "Error: No Python executable found" exit 1 fi echo "Using Python: $PYTHON_EXEC" echo "" # Install build requirements echo "Step 1/5: Installing build tools..." echo "----------------------------------------" "$PYTHON_EXEC" -m pip install --upgrade pip build wheel setuptools echo "✓ Build tools installed successfully" echo "" # Create a virtual environment for building echo "Step 2/5: Creating build environment..." echo "----------------------------------------" "$PYTHON_EXEC" -m venv "$VENV_DIR" # Check if virtual environment was created successfully if [ ! -f "$VENV_DIR/bin/activate" ]; then echo "Error: Failed to create virtual environment" exit 1 fi source "$VENV_DIR/bin/activate" # Install pip-tools for dependency resolution "$VENV_DIR/bin/pip" install pip-tools echo "✓ Build environment created successfully" echo "" # Compile requirements to get all transitive dependencies GLUE_PIP_ARGS="$PIP_PLATFORM_FLAG --python-version $PYTHON_VERSION --only-binary=:all:" echo "Step 3/5: Resolving all dependencies..." echo "----------------------------------------" if ! "$VENV_DIR/bin/pip-compile" --pip-args "$GLUE_PIP_ARGS" --no-emit-index-url --output-file "$TEMP_WORKING_DIR/.compiled_requirements.txt" "$REQUIREMENTS_FILE"; then echo "Error: Failed to resolve dependencies. Check for conflicts in $REQUIREMENTS_FILE" exit 1 fi echo "✓ Dependencies resolved successfully" echo "" # Download all wheels for dependencies echo "Step 4/5: Downloading all dependency wheels..." echo "----------------------------------------" "$VENV_DIR/bin/pip" download -r "$TEMP_WORKING_DIR/.compiled_requirements.txt" -d "$WHEEL_OUTPUT_DIRECTORY" $GLUE_PIP_ARGS # Check if any wheels were downloaded if [ ! "$(ls -A "$WHEEL_OUTPUT_DIRECTORY")" ]; then echo "Error: No wheels were downloaded. Check your requirements file." exit 1 fi # Count downloaded wheels (using find instead of ls for better handling) WHEEL_COUNT=$(find "$WHEEL_OUTPUT_DIRECTORY" -name "*.whl" -type f | wc -l | tr -d ' ') echo "✓ Downloaded $WHEEL_COUNT dependency wheels successfully" echo "" # Create a single uber wheel with all dependencies echo "Step 5/5: Creating uber wheel with all dependencies included..." echo "----------------------------------------" # Create a temporary directory for the uber wheel UBER_WHEEL_DIR="$TEMP_WORKING_DIR/uber" mkdir -p "$UBER_WHEEL_DIR" # Create the setup.py file with custom install command cat >"$UBER_WHEEL_DIR/setup.py" <<EOF from setuptools import setup, find_packages import setuptools.command.install import os import glob import subprocess import sys setup( name='${PACKAGE_NAME}', version='${PACKAGE_VERSION}', description='Bundle containing dependencies for ${PACKAGE_NAME}', author='Package Builder', author_email='builder@example.com', packages=['${PACKAGE_NAME}'], # Include the package directory to hold wheels include_package_data=True, package_data={ '${PACKAGE_NAME}': ['wheels/*.whl'], # Include wheels in the package directory } ) EOF # Create a MANIFEST.in file to include all wheels cat >"$UBER_WHEEL_DIR/MANIFEST.in" <<EOF recursive-include ${PACKAGE_NAME}/wheels *.whl EOF # Create an __init__.py file that imports all the bundled wheel files (no auto-install logic) mkdir -p "$UBER_WHEEL_DIR/${PACKAGE_NAME}" cat >"$UBER_WHEEL_DIR/${PACKAGE_NAME}/__init__.py" <<EOF """ ${PACKAGE_NAME} - dependencies can be installed at runtime using the $(load_wheels) function """ from pathlib import Path import logging import subprocess import sys __version__ = "${PACKAGE_VERSION}" def load_wheels(log_level=logging.INFO): logger = logging.getLogger(__name__) handler = logging.StreamHandler(sys.stdout) formatter = logging.Formatter("[Glue Python Wheel Installer] %(asctime)s - %(name)s - %(levelname)s - %(message)s") handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(log_level) logger.info("Starting wheel installation process") package_dir = Path(__file__).parent.absolute() wheels_dir = package_dir / "wheels" logger.debug(f"Package directory: {package_dir}") logger.debug(f"Looking for wheels in: {wheels_dir}") if not wheels_dir.exists(): logger.error(f"Wheels directory not found: {wheels_dir}") return False wheel_files = list(wheels_dir.glob("*.whl")) if not wheel_files: logger.warning(f"No wheels found in: {wheels_dir}") return False logger.info(f"Found {len(wheel_files)} wheels") wheel_file_paths = [str(wheel_file) for wheel_file in wheel_files] logger.info(f"Installing {wheel_file_paths}...") try: result = subprocess.run( [sys.executable, "-m", "pip", "install", *wheel_file_paths], check=True, capture_output=True, text=True ) logger.info(f"✓ Successfully installed wheel files") logger.debug(f"pip output: {result.stdout}") except subprocess.CalledProcessError as e: error_msg = f"Failed to install wheel files" logger.error(f"✗ {error_msg}: {e}") if e.stderr: logger.error(f"Error details: {e.stderr}") return False logger.info("All wheels installed successfully") return True EOF cat >"$UBER_WHEEL_DIR/${PACKAGE_NAME}/auto.py" <<EOF """ ${PACKAGE_NAME} - utility module that allows users to automatically install modules by adding $(import ${PACKAGE_NAME}.auto) to the top of their script """ from ${PACKAGE_NAME} import load_wheels load_wheels() EOF # Copy all wheels to the uber wheel directory mkdir -p "$UBER_WHEEL_DIR/${PACKAGE_NAME}/wheels" cp "$WHEEL_OUTPUT_DIRECTORY"/*.whl "$UBER_WHEEL_DIR/${PACKAGE_NAME}/wheels/" # Build the uber wheel echo "Building uber wheel package..." # Install build tools in the current environment "$VENV_DIR/bin/pip" install build if ! (cd "$UBER_WHEEL_DIR" && "$VENV_DIR/bin/python" -m build --skip-dependency-check --wheel --outdir .); then echo "Error: Failed to build uber wheel" exit 1 fi # Ensure output directory exists mkdir -p "$FINAL_WHEEL_OUTPUT_DIRECTORY" # Copy the uber wheel to the output directory FINAL_WHEEL_OUTPUT_PATH="$FINAL_WHEEL_OUTPUT_DIRECTORY/$UBER_WHEEL_NAME" # Find the generated wheel (should be only one in the root directory) GENERATED_WHEEL=$(find "$UBER_WHEEL_DIR" -maxdepth 1 -name "*.whl" -type f | head -1) if [ -z "$GENERATED_WHEEL" ]; then echo "Error: No uber wheel was generated" exit 1 fi cp "$GENERATED_WHEEL" "$FINAL_WHEEL_OUTPUT_PATH" # Get final wheel size for user feedback WHEEL_SIZE=$(du -h "$FINAL_WHEEL_OUTPUT_PATH" | cut -f1) echo "✓ Uber wheel created successfully!" echo "" echo "=========================================" echo "BUILD COMPLETED SUCCESSFULLY!" echo "=========================================" echo "Final wheel: $FINAL_WHEEL_OUTPUT_PATH" echo "Wheel size: $WHEEL_SIZE" echo "Dependencies included: $WHEEL_COUNT packages" echo "" echo "To install the bundle, run:" echo " pip install $FINAL_WHEEL_OUTPUT_PATH" echo "" echo "After installation, you can verify that the bundle works by running:" echo " python -c \"import ${PACKAGE_NAME}; ${PACKAGE_NAME}.load_wheels()\"" echo " or " echo " python -c \"import ${PACKAGE_NAME}.auto\"" echo "========================================="
./wheel_packager.sh -r <path to requirements.txt> -g <glue version> -o <wheel output directory> -n <package name> -v <wheel version>
--additional-python-modules s3://your-bucket/path/to/package_with_dependencies-1.0.0-py3-none-any.whl
# Option 1: automatic installation via import import package_with_dependencies.auto # Option 2: manual installation from package_with_dependencies import load_wheels load_wheels()
Y compris des fichiers Python dotés de fonctionnalités PySpark natives
AWS Glue est utilisé PySpark pour inclure des fichiers Python dans les tâches AWS Glue ETL. Vous aurez envie d'utiliser --additional-python-modules pour gérer vos dépendances lorsqu'elles sont disponibles. Vous pouvez utiliser le paramètre de tâche --extra-py-files pour inclure des fichiers Python. Les dépendances doivent être hébergées dans Amazon S3, et la valeur de l'argument doit être une liste de chemins non-espacés Amazon S3 délimités par des virgules. Cette fonctionnalité se comporte comme la gestion des dépendances Python que vous utiliseriez avec Spark. Pour plus d'informations sur la gestion des dépendances Python dans Spark, consultez la page Utilisation des fonctionnalités PySpark natives--extra-py-filesest utile dans les cas où votre code supplémentaire n'est pas empaqueté ou lorsque vous migrez un programme Spark avec une chaîne d'outils existante pour gérer les dépendances. Pour que vos outils de dépendance soient gérables, vous devez regrouper vos dépendances avant de les soumettre.
Scripts de programmation utilisant des transformations visuelles
Lorsque vous créez une tâche AWS Glue à l'aide de l'interface visuelle de AWS Glue Studio, vous pouvez transformer vos données à l'aide de nœuds de transformation de données gérés et de transformations visuelles personnalisées. Pour plus d'informations sur les nœuds de transformation de données gérés, consultezTransformez les données grâce AWS Glue à des transformations gérées. Pour plus d'informations sur les transformations visuelles personnalisées, consultez Transformez les données grâce à des transformations visuelles personnalisées . Les scripts utilisant des transformations visuelles ne peuvent être générés que lorsque le langage de votre tâche est configuré pour utiliser Python.
Lors de la génération d'une tâche AWS Glue à l'aide de transformations visuelles, AWS Glue Studio inclut ces transformations dans l'environnement d'exécution en utilisant le --extra-py-files paramètre de configuration de la tâche. Pour de plus amples informations sur la définition des paramètres de la tâche, consultez Utilisation des paramètres des tâches dans les tâches AWS Glue. Lorsque vous apportez des modifications à un script généré ou à un environnement d'exécution, vous devez conserver cette configuration de tâche pour que votre script s'exécute correctement.
Compression de bibliothèques pour intégration
Sauf si elle est comprise dans un seul fichier .py, une bibliothèque doit être packagée dans une archive .zip. Le répertoire du package doit être à la racine de l'archive et contenir un fichier __init__.py pour le package. Python sera alors en mesure d'importer le package normalement.
Si votre bibliothèque se compose d'un seul module Python dans un fichier .py, vous n'avez pas besoin de la mettre dans un fichier .zip.
Chargement de bibliothèques Python dans les blocs-notes AWS Glue Studio
Pour spécifier les bibliothèques Python dans les blocs-notes AWS Glue Studio, consultez la section Installation de modules Python supplémentaires.
Chargement de bibliothèques Python dans un endpoint de développement dans AWS Glue 0.9/1.0
Si vous utilisez différents ensembles de bibliothèques pour différents scripts ETL, vous pouvez configurer un point de terminaison de développement distinct pour chaque ensemble, ou écraser le(s) fichier(s) .zip de bibliothèque que votre point de terminaison de développement charge à chaque fois que vous basculez d'un script à un autre.
Vous pouvez utiliser la console pour spécifier un ou plusieurs fichiers .zip de bibliothèque pour un point de terminaison de développement lorsque vous créez celui-ci. Après avoir attribué un nom et un rôle IAM, sélectionnez Script Libraries and job parameters (optional) (Bibliothèques de scripts et paramètres de tâches [facultatif]) et saisissez le chemin d'accès Amazon S3 complet à votre fichier .zip de bibliothèque dans la zone Python library path (Chemin de bibliothèque Python). Par exemple :
s3://bucket/prefix/site-packages.zipSi vous le souhaitez, vous pouvez spécifier plusieurs chemins complets pour les fichiers, en les séparant par des virgules, mais sans espace, comme l'exemple suivant :
s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zipSi vous mettez à jour ces fichiers .zip ultérieurement, vous pouvez utiliser la console pour les importer de nouveau dans votre point de terminaison de développement. Naviguez vers le point de terminaison de développement concerné, cochez la case située en regard, puis choisissez Update ETL libraries (Mettre à jour des bibliothèques ETL) dans le menu Action.
De la même manière, vous pouvez spécifier des fichiers de bibliothèque à l'aide de la AWS Glue APIs. Lorsque vous créez un point de terminaison de développement en appelant CreateDevEndpoint action (Python : create_dev_endpoint), vous pouvez spécifier un ou plusieurs chemins complets de bibliothèques dans le paramètre ExtraPythonLibsS3Path, dans un appel ressemblant à ceci :
dep = glue.create_dev_endpoint(
EndpointName="testDevEndpoint",
RoleArn="arn:aws:iam::123456789012",
SecurityGroupIds="sg-7f5ad1ff",
SubnetId="subnet-c12fdba4",
PublicKey="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtp04H/y...",
NumberOfNodes=3,
ExtraPythonLibsS3Path="s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zip")Lorsque vous mettez à jour un point de terminaison de développement, vous pouvez également mettre à jour les bibliothèques chargées par ce point de terminaison en utilisant un objet DevEndpointCustomLibraries et en définissant le paramètre UpdateEtlLibraries sur True lors de l'appel de UpdateDevEndpoint (update_dev_endpoint).
Utilisation de bibliothèques Python dans une tâche ou JobRun
Lorsque vous créez un objet Job sur la console, vous pouvez spécifier un ou plusieurs fichiers .zip de bibliothèque en sélectionnant Script Libraries and job parameters (optional) (Bibliothèques de scripts et paramètres de tâches [facultatif]) et en entrant le ou les chemins d'accès Amazon S3 complets aux bibliothèques, comme vous le feriez lors de la création d'un point de terminaison de développement :
s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zipSi vous appelez CreateJob (créer_job), vous pouvez spécifier un ou plusieurs chemins d'accès complets aux bibliothèques par défaut en utilisant les paramètres par défaut --extra-py-files, comme suit :
job = glue.create_job(Name='sampleJob',
Role='Glue_DefaultRole',
Command={'Name': 'glueetl',
'ScriptLocation': 's3://my_script_bucket/scripts/my_etl_script.py'},
DefaultArguments={'--extra-py-files': 's3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zip'})Ensuite, lorsque vous démarrez une JobRun, vous pouvez remplacer le paramètre de bibliothèque par défaut par un autre :
runId = glue.start_job_run(JobName='sampleJob',
Arguments={'--extra-py-files': 's3://bucket/prefix/lib_B.zip'})Analyser les dépendances Python de manière proactive
Pour identifier de manière proactive les problèmes de dépendance potentiels avant le déploiement sur AWS Glue, vous pouvez utiliser l'outil d'analyse des dépendances pour valider vos packages Python par rapport à votre environnement AWS Glue cible.
AWS fournit un outil d'analyse de dépendance Python open source spécialement conçu pour les environnements AWS Glue. Cet outil est disponible dans le référentiel d'échantillons AWS Glue et peut être utilisé localement pour valider vos dépendances avant le déploiement.
Cette analyse permet de garantir que vos dépendances respectent la pratique recommandée qui consiste à épingler toutes les versions de bibliothèque pour des déploiements de production cohérents. Pour plus de détails, veuillez consulter le fichier README
L'analyseur de dépendance AWS Glue Python permet d'identifier les dépendances non épinglées et les conflits de versions en simulant l'installation de pip avec des contraintes spécifiques à la plate-forme qui correspondent à votre environnement Glue cible. AWS
# Analyze a single Glue job python glue_dependency_analyzer.py -j my-glue-job # Analyze multiple jobs with specific AWS configuration python glue_dependency_analyzer.py -j job1 -j job2 --aws-profile production --aws-region us-west-2
L'outil signalera :
-
Dépendances non épinglées susceptibles d'installer différentes versions au cours de l'exécution des tâches
-
Conflits de version entre les packages
-
Dépendances non disponibles pour votre environnement AWS Glue cible
Amazon Q Developer est un assistant conversationnel basé sur l'intelligence artificielle générative (IA) qui peut vous aider à comprendre, créer, étendre et exploiter AWS des applications. Vous pouvez le télécharger en suivant les instructions du guide de démarrage d'Amazon Q.
Amazon Q Developer peut être utilisé pour analyser et corriger les échecs de tâches dus à la dépendance à Python. Nous vous suggérons d'utiliser l'invite suivante en remplaçant l'<Job-Name>espace réservé à la tâche par le nom de votre tâche de collage.
I have an AWS Glue job named <Job-Name> that has failed due to Python module installation conflicts. Please assist in diagnosing and resolving this issue using the following systematic approach. Proceed once sufficient information is available. Objective: Implement a fix that addresses the root cause module while minimizing disruption to the existing working environment. Step 1: Root Cause Analysis • Retrieve the most recent failed job run ID for the specified Glue job • Extract error logs from CloudWatch Logs using the job run ID as a log stream prefix • Analyze the logs to identify: • The recently added or modified Python module that triggered the dependency conflict • The specific dependency chain causing the installation failure • Version compatibility conflicts between required and existing modules Step 2: Baseline Configuration Identification • Locate the last successful job run ID prior to the dependency failure • Document the Python module versions that were functioning correctly in that baseline run • Establish the compatible version constraints for conflicting dependencies Step 3: Targeted Resolution Implementation • Apply pinning by updating the job's additional_python_modules parameter • Pin only the root cause module and its directly conflicting dependencies to compatible versions, and do not remove python modules unless necessary • Preserve flexibility for non-conflicting modules by avoiding unnecessary version constraints • Deploy the configuration changes with minimal changes to the existing configuration and execute a validation test run. Do not change the Glue versions. Implementation Example: Scenario: Recently added pandas==2.0.0 to additional_python_modules Error: numpy version conflict (pandas 2.0.0 requires numpy>=1.21, but existing job code requires numpy<1.20) Resolution: Update additional_python_modules to "pandas==1.5.3,numpy==1.19.5" Rationale: Use pandas 1.5.3 (compatible with numpy 1.19.5) and pin numpy to last known working version Expected Outcome: Restore job functionality with minimal configuration changes while maintaining system stability.
L'invite demande à Q de :
-
Récupère l'ID d'exécution de la dernière tâche ayant échoué
-
Rechercher les journaux et les détails associés
-
Trouvez des exécutions de tâches réussies pour détecter tout package Python modifié
-
Apportez des corrections de configuration et déclenchez un autre test
Modules Python déjà fournis dans AWS Glue
Pour modifier la version de ces modules fournis, fournissez de nouvelles versions avec le paramètre de tâche --additional-python-modules.
