Usare le librerie Python con AWS Aderenza

Puoi installare moduli e librerie Python aggiuntivi da utilizzare con AWS Glue ETL. Per AWS Glue 2.0 e versioni successive, AWS Glue utilizza Python Package Installer (pip3) per installare moduli aggiuntivi utilizzati da Glue ETL. AWS AWS Glue offre diverse opzioni per portare i moduli Python aggiuntivi nell'ambiente di lavoro Glue. AWS Puoi usare il --additional-python-modules parametro per inserire nuovi moduli usando file zip contenenti le ruote Python in bundle (note anche come «zip of wheels», disponibili per AWS Glue 5.0 e versioni successive), singoli file di ruote Python, file dei requisiti (requirements.txt, disponibile per AWS Glue 5.0 e versioni successive) o un elenco di moduli Python separati da virgole. Potrebbe anche essere usato per cambiare la versione dei moduli Python forniti nell'ambiente AWS Glue (vedi per maggiori dettagli). Moduli Python già forniti in AWS Aderenza

Installazione di moduli Python aggiuntivi con pip in AWS Glue 2.0 o successivo

AWS Glue utilizza Python Package Installer (pip3) per installare moduli aggiuntivi da utilizzare da Glue ETL. AWS Puoi utilizzare il parametro --additional-python-modules con un elenco di moduli Python separati da virgole per aggiungere un nuovo modulo o modificare la versione di un modulo esistente. Puoi installare gli artefatti della ruota incorporata tramite una zip of wheels o un artefatto a sé stante caricando il file su Amazon S3, quindi includendo il percorso dell'oggetto Amazon S3 nell'elenco di moduli. Per ulteriori informazioni sull'impostazione dei parametri dei job, consulta Using job parameters in Glue jobs. AWS

Puoi passare opzioni aggiuntive a pip3 tramite il parametro --python-modules-installer-option. Ad esempio, potresti --only-binary forzare pip a installare solo artefatti precompilati per i pacchetti specificati da. --additional-python-modules Per altri esempi, vedi Creare moduli Python da una ruota per carichi di lavoro Spark ETL usando Glue 2.0. AWS

Le migliori pratiche per la gestione delle dipendenze in Python

Per i carichi di lavoro di produzione, AWS Glue consiglia di impacchettare tutte le dipendenze Python come file wheel in un unico artefatto zip. Questo approccio fornisce:

Considerazioni importanti

Secondo il modello di responsabilità AWS condivisa, sei responsabile della gestione di moduli Python aggiuntivi, librerie e delle loro dipendenze. Questo include:

Se hai dipendenze minime, puoi prendere in considerazione l'utilizzo di singoli file wheel.

--additional-python-modules s3://amzn-s3-demo-bucket/path/to/zip-of-wheels-1.0.0.gluewheels.zip
--python-modules-installer-option --no-index

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

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

Inclusi file Python con funzionalità native PySpark

AWS Glue utilizza PySpark per includere file Python nei lavori ETL di AWS Glue. Quando possibile, ti consigliamo di usare --additional-python-modules per gestire le dipendenze. Puoi utilizzare il parametro del processo --extra-py-files per includere i file Python. Le dipendenze devono essere ospitate in Amazon S3 e il valore dell'argomento deve essere un elenco delimitato da virgole di percorsi Amazon S3 senza spazi. Questa funzionalità si comporta come la gestione delle dipendenze Python che useresti con Spark. Per ulteriori informazioni sulla gestione delle dipendenze di Python in Spark, consulta la pagina Using PySpark Native Features nella documentazione di Apache Spark. --extra-py-filesè utile nei casi in cui il codice aggiuntivo non è impacchettato o quando si sta migrando un programma Spark con una toolchain esistente per la gestione delle dipendenze. Affinché gli strumenti di dipendenza siano gestibili, sarà necessario raggruppare le dipendenze prima di inviarle.

Script di programmazione che utilizzano trasformazioni visive

Quando crei un job AWS Glue utilizzando l'interfaccia visiva di AWS Glue Studio, puoi trasformare i tuoi dati con nodi di trasformazione dei dati gestiti e trasformazioni visive personalizzate. Per ulteriori informazioni sui nodi di trasformazione dei dati, consultare Trasformare i dati con AWS Glue trasformazioni gestite. Per ulteriori informazioni sulle trasformazioni visive, consultare Trasforma i dati con le trasformazioni visive personalizzate. Gli script che utilizzano le trasformazioni visive possono essere generati solo quando il linguaggio del processo è impostato per utilizzare Python.

Quando si genera un lavoro AWS Glue utilizzando trasformazioni visive, AWS Glue Studio includerà queste trasformazioni nell'ambiente di runtime utilizzando il --extra-py-files parametro nella configurazione del lavoro. Per ulteriori informazioni sui parametri di processo, consulta Utilizzo dei parametri del lavoro in AWS Lavori di incollaggio. Quando a si apportano modifiche a uno script o a un ambiente di runtime generato, è necessario mantenere questa configurazione del lavoro affinché lo script venga eseguito correttamente.

Compressione delle librerie per l'inclusione

A meno che una libreria non sia contenuta in un singolo file .py, deve essere compressa in un archivio .zip. La directory del pacchetto deve trovarsi al livello radice dell'archivio e deve contenere un file __init__.py per il pacchetto. Python sarà in grado di importare il pacchetto nel modo normale.

Se la tua libreria è composta da un singolo modulo Python in un file .py, non è necessario trasferirla in un file .zip.

Caricamento delle librerie Python in AWS Taccuini Glue Studio

Per specificare le librerie Python nei notebook AWS Glue Studio, vedi Installazione di moduli Python aggiuntivi. https://docs.aws.amazon.com/glue/latest/dg/manage-notebook-sessions.html#specify-default-modules

Caricamento delle librerie Python in un endpoint di sviluppo in AWS Colla 0. 9/10.

Se utilizzi diversi set di librerie per diversi script ETL, puoi impostare un endpoint di sviluppo separato per ciascun set oppure sovrascrivere i file .zip della libreria che l'endpoint di sviluppo carica ogni volta che si cambia script.

Puoi utilizzare la console per specificare uno o più file .zip di libreria per un endpoint di sviluppo al momento della creazione. Dopo l'assegnazione di un nome e un ruolo IAM, scegli Script Libraries and job parameters (optional) (Librerie di Script e parametri di processo -opzionale) e immetti il percorso Amazon S3 completo per i tuoi file .zip della libreria nella casella Python library path (Percorso libreria Python). Ad esempio:

s3://bucket/prefix/site-packages.zip

Se lo desideri, puoi specificare più percorsi completi per i file, separandoli con virgole ma non spazi, in questo modo:

s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zip

Se aggiorni questi file .zip in un secondo momento, puoi utilizzare la console per importarli nuovamente nell'endpoint di sviluppo. Individua l'endpoint dello sviluppatore in questione, verifica la casella a esso corrispondente e scegli Update ETL libraries (Aggiorna librerie ETL) dal menu Action (Operazione).

In modo simile, puoi specificare i file di libreria utilizzando le API AWS Glue. Quando crei un endpoint di sviluppo chiamando CreateDevEndpoint azione (Python: create_dev_endpoint), puoi specificare uno o più percorsi completi per le librerie nel parametro ExtraPythonLibsS3Path in una chiamata come la seguente:

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

Quando aggiorni un endpoint di sviluppo, puoi anche aggiornare le librerie caricate utilizzando un oggetto DevEndpointCustomLibraries e impostare il parametro UpdateEtlLibraries su True durante la chiamata UpdateDevEndpoint (update_dev_endpoint).

Usare le librerie Python in un lavoro o JobRun

Quando si crea un nuovo processo nella console, è possibile specificare uno o più file ZIP di libreria scegliendo Script Libraries and job parameters (optional) (Librerie di script e parametri di processo - opzionale) e immettendo percorsi di librerie Amazon S3 completi, analogamente a come si farebbe quando si crea un endpoint di sviluppo:

s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zip

Se si sta chiamando CreateJob (create_job), è possibile specificare uno o più percorsi completi alle librerie predefinite utilizzando il parametro predefinito --extra-py-files, come segue:

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'})

Quindi, quando si avvia una JobRun, è possibile sovrascrivere l'impostazione predefinita della libreria con una diversa:

runId = glue.start_job_run(JobName='sampleJob',
                           Arguments={'--extra-py-files': 's3://bucket/prefix/lib_B.zip'})

Analizza in modo proattivo le dipendenze di Python

Per identificare in modo proattivo i potenziali problemi di dipendenza prima della distribuzione su AWS Glue, puoi utilizzare lo strumento di analisi delle dipendenze per convalidare i tuoi pacchetti Python rispetto all'ambiente Glue di destinazione. AWS

AWS fornisce uno strumento di analisi delle dipendenze Python open source progettato specificamente per gli ambienti Glue. AWS Questo strumento è disponibile nel repository degli esempi di AWS Glue e può essere utilizzato localmente per convalidare le dipendenze prima della distribuzione.

Questa analisi aiuta a garantire che le dipendenze seguano la pratica consigliata del pinning di tutte le versioni della libreria per implementazioni di produzione coerenti. Per maggiori dettagli, consultare la sezione README dello strumento.

# 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

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.

Moduli Python già forniti in AWS Aderenza

È possibile modificare la versione dei moduli disponibili con il parametro di processo --additional-python-modules.

Appendice A: Creazione di un artefatto con Zip of Wheels

Dimostriamo con un esempio come creare un artefatto con zip of wheels. L'esempio mostrato scarica i pacchetti cryptography scipy in un artefatto con zip of wheels e copia lo zip of wheels in una posizione Amazon S3.

Appendice B: AWS Dettagli sull'ambiente di incollaggio

Secondo il modello di responsabilità AWS condivisa, sei responsabile della gestione dei moduli Python aggiuntivi, delle librerie e delle relative dipendenze che usi con i tuoi lavori Glue ETL. AWS Ciò include l'applicazione di aggiornamenti e patch di sicurezza.

AWS Glue non supporta la compilazione di codice nativo nell'ambiente di lavoro. Tuttavia, i lavori AWS Glue vengono eseguiti in un ambiente Amazon-managed Linux. È possibile fornire le dipendenze native in un formato compilato tramite un file wheel Python. Fai riferimento alla tabella precedente per i dettagli sulla compatibilità delle versioni di AWS Glue.