Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Le migliori pratiche per Amazon Managed Workflows per Apache Airflow
Questa guida descrive le best practice che consigliamo per l'utilizzo di Amazon Managed Workflows for Apache Airflow.
**Topics**
+ [Ottimizzazione delle prestazioni per Apache Airflow su Amazon MWAA](best-practices-tuning.md)
+ [Gestione delle dipendenze Python in requirements.txt](best-practices-dependencies.md)
# Ottimizzazione delle prestazioni per Apache Airflow su Amazon MWAA
Questo argomento descrive come ottimizzare le prestazioni di un ambiente Amazon Managed Workflows for Apache Airflow utilizzando. [Utilizzo delle opzioni di configurazione Apache Airflow su Amazon MWAA](configuring-env-variables.md)
**Contents**
+ [Aggiungere un'opzione di configurazione Apache Airflow](#best-practices-tuning-console-add)
+ [Pianificatore Apache Airflow](#best-practices-tuning-scheduler)
+ [Parameters](#best-practices-tuning-scheduler-params)
+ [Limits](#best-practices-tuning-scheduler-limits)
+ [Cartelle DAG](#best-practices-tuning-dag-folders)
+ [Parameters](#best-practices-tuning-dag-folders-params)
+ [File DAG](#best-practices-tuning-dag-files)
+ [Parameters](#best-practices-tuning-dag-files-params)
+ [Processi](#best-practices-tuning-tasks)
+ [Parameters](#best-practices-tuning-tasks-params)
## Aggiungere un'opzione di configurazione Apache Airflow
Utilizzate la seguente procedura per aggiungere un'opzione di configurazione Airflow al vostro ambiente.
1. Apri la pagina [Ambienti](https://console.aws.amazon.com/mwaa/home#/environments) sulla console Amazon MWAA.
1. Scegli un ambiente.
1. Scegli **Modifica**.
1. Scegli **Next (Successivo)**.
1. Scegli **Aggiungi configurazione personalizzata** nel riquadro delle **opzioni di configurazione Airflow**.
1. Scegli una configurazione dall'elenco a discesa e inserisci un valore, oppure inserisci una configurazione personalizzata e inserisci un valore.
1. Scegli **Aggiungi configurazione personalizzata** per ogni configurazione che desideri aggiungere.
1. Scegli **Save** (Salva).
Per ulteriori informazioni, consulta[Utilizzo delle opzioni di configurazione Apache Airflow su Amazon MWAA](configuring-env-variables.md).
## Pianificatore Apache Airflow
Lo scheduler Apache Airflow è un componente fondamentale di Apache Airflow. Un problema con lo scheduler può DAGs impedire l'analisi e la pianificazione delle attività. Per ulteriori informazioni sull'ottimizzazione [dello scheduler di Apache Airflow, consulta la sezione Ottimizzazione delle prestazioni dello scheduler nel sito Web della documentazione di Apache Airflow.](https://airflow.apache.org/docs/apache-airflow/2.2.2/concepts/scheduler.html#fine-tuning-your-scheduler-performance)
### Parameters
Questa sezione descrive le opzioni di configurazione disponibili per lo scheduler Apache Airflow (Apache Airflow v2 e versioni successive) e i relativi casi d'uso.
------
#### [ Apache Airflow v3 ]
| Configurazione | Caso d’uso |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Il numero di processi utilizzati da Celery Executor per sincronizzare lo stato delle attività. **Impostazione predefinita**: 1 | È possibile utilizzare questa opzione per prevenire i conflitti di coda limitando i processi utilizzati da Celery Executor. Per impostazione predefinita, viene impostato un valore per `1` prevenire errori nella consegna dei registri delle attività ai registri. CloudWatch Impostare il valore su `0` significa utilizzare il numero massimo di processi, ma può causare errori durante la consegna dei registri delle attività. |
| **[scheduler.scheduler\$1idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#scheduler-idle-sleep-time)** Il numero di secondi di attesa tra un'elaborazione consecutiva dei file DAG nel «ciclo» dello scheduler. **Impostazione predefinita**: 1 | *È possibile utilizzare questa opzione per liberare l'utilizzo della CPU sullo scheduler **aumentando** il tempo di inattività dello scheduler dopo aver terminato il recupero dei risultati dell'analisi DAG, la ricerca e l'accodamento delle attività e l'esecuzione delle attività in coda nell'Executor.* L'aumento di questo valore consuma il numero di thread di pianificazione eseguiti su un ambiente in `dag_processor.parsing_processes` Apache Airflow v2 e Apache Airflow v3. Ciò può ridurre la capacità di analisi degli scheduler e aumentare il tempo necessario per il DAGs popolamento nel server web. DAGs |
| **[scheduler.max\$1dagruns\$1to\$1create\$1per\$1loop](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#max-dagruns-to-create-per-loop)** Il numero massimo di elementi da creare per ogni «ciclo» dello scheduler. DAGs *DagRuns* **Impostazione predefinita**: 10 | È possibile utilizzare questa opzione per liberare risorse per la pianificazione delle attività **diminuendo** il numero massimo di «loop» dello *DagRuns*scheduler. |
| **[dag\$1processor.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parsing-processes)** Il numero di thread che lo scheduler può eseguire in parallelo alla pianificazione. DAGs **Predefinito**: Usa `(2 * number of vCPUs) - 1` | È possibile utilizzare questa opzione per liberare risorse **diminuendo** il numero di processi che lo scheduler esegue in parallelo per analizzare. DAGs Si consiglia di mantenere basso questo numero se l'analisi del DAG influisce sulla pianificazione delle attività. È **necessario** specificare un valore inferiore al numero di vCPU nell'ambiente. Per ulteriori informazioni, consulta [Limiti](#best-practices-tuning-scheduler-limits). |
------
#### [ Apache Airflow v2 ]
| Configurazione | Caso d’uso |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Il numero di processi utilizzati da Celery Executor per sincronizzare lo stato delle attività. **Impostazione predefinita**: 1 | È possibile utilizzare questa opzione per prevenire i conflitti di coda limitando i processi utilizzati da Celery Executor. Per impostazione predefinita, viene impostato un valore per `1` prevenire errori nella consegna dei registri delle attività ai registri. CloudWatch Impostare il valore su `0` significa utilizzare il numero massimo di processi, ma può causare errori durante la consegna dei registri delle attività. |
| **[scheduler.idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#scheduler-idle-sleep-time)** Il numero di secondi di attesa tra un'elaborazione consecutiva dei file DAG nel «ciclo» dello scheduler. **Impostazione predefinita**: 1 | *È possibile utilizzare questa opzione per liberare l'utilizzo della CPU sullo scheduler **aumentando** il tempo di inattività dello scheduler dopo aver terminato il recupero dei risultati dell'analisi DAG, la ricerca e l'accodamento delle attività e l'esecuzione delle attività in coda nell'Executor.* L'aumento di questo valore consuma il numero di thread di pianificazione eseguiti su un ambiente in `scheduler.parsing_processes` Apache Airflow v2 e Apache Airflow v3. Ciò può ridurre la capacità di analisi degli scheduler e aumentare il tempo necessario per il DAGs popolamento nel server web. DAGs |
| **[scheduler.max\$1dagruns\$1to\$1create\$1per\$1loop](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#max-dagruns-to-create-per-loop)** Il numero massimo di elementi da creare per ogni «ciclo» dello scheduler. DAGs *DagRuns* **Impostazione predefinita**: 10 | È possibile utilizzare questa opzione per liberare risorse per la pianificazione delle attività **diminuendo** il numero massimo di «loop» dello *DagRuns*scheduler. |
| **[scheduler.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes)** Il numero di thread che lo scheduler può eseguire in parallelo alla pianificazione. DAGs **Predefinito**: Usa `(2 * number of vCPUs) - 1` | È possibile utilizzare questa opzione per liberare risorse **diminuendo** il numero di processi che lo scheduler esegue in parallelo per analizzare. DAGs Si consiglia di mantenere basso questo numero se l'analisi del DAG influisce sulla pianificazione delle attività. È **necessario** specificare un valore inferiore al numero di vCPU nell'ambiente. Per ulteriori informazioni, consulta [Limiti](#best-practices-tuning-scheduler-limits). |
------
### Limits
Questa sezione descrive i limiti da considerare quando si regolano i parametri predefiniti per lo scheduler.
**scheduler.parsing\$1processes, scheduler.max\$1threads (solo v2)**
Sono consentiti due thread per vCPU per una classe di ambiente. Almeno un thread deve essere riservato allo scheduler per una classe di ambiente. Se si nota un ritardo nella pianificazione delle attività, potrebbe essere necessario aumentare la [classe di ambiente](environment-class.md). Ad esempio, un ambiente di grandi dimensioni ha un'istanza del contenitore Fargate a 4 vCpu come scheduler. Ciò significa che è disponibile un massimo di thread `7` totali da utilizzare per altri processi. Cioè, due thread moltiplicati per quattro vCPUs, meno uno per lo scheduler stesso. Il valore specificato in `scheduler.max_threads` (solo v2) non `scheduler.parsing_processes` deve superare il numero di thread disponibili per una classe di ambiente, come elencato:
+ **mw1.small** — Non deve superare il numero di `1` thread per altri processi. Il thread rimanente è riservato allo scheduler.
+ **mw1.medium** — Non deve superare i `3` thread per altri processi. Il thread rimanente è riservato allo scheduler.
+ **mw1.large** — Non deve superare i `7` thread per altri processi. Il thread rimanente è riservato allo scheduler.
## Cartelle DAG
L'utilità di pianificazione Apache Airflow analizza DAGs continuamente la cartella nel tuo ambiente. Qualsiasi `plugins.zip` file contenuto o file Python (`.py`) contenente istruzioni di importazione «airflow». Tutti gli oggetti Python DAG risultanti vengono quindi inseriti in un file *DagBag*affinché quel file venga elaborato dallo scheduler per determinare quali attività, se del caso, devono essere pianificate. L'analisi dei file DAG avviene indipendentemente dal fatto che i file contengano oggetti DAG validi.
### Parameters
Questa sezione descrive le opzioni di configurazione disponibili per la DAGs cartella (Apache Airflow v2 e versioni successive) e i relativi casi d'uso.
------
#### [ Apache Airflow v3 ]
| Configurazione | Caso d’uso |
| --- | --- |
| **[dag\$1processor.refresh\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#config-dag-processor-refresh-interval)** Il numero di secondi in cui la cartella deve essere scansionata alla ricerca di nuovi file. DAGs **Impostazione predefinita:** 300 secondi | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di secondi di analisi della DAGs cartella. Ti consigliamo di aumentare questo valore se riscontri lunghi tempi di analisi in`total_parse_time metrics`, ad esempio a causa dell'elevato numero di file nella cartella DAGs . |
| **[dag\$1processor.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-file-process-interval)** Il numero di secondi dopo i quali lo scheduler analizza un DAG e vengono riflessi gli aggiornamenti al DAG. **Impostazione predefinita: 30 secondi** | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di secondi che lo scheduler attende prima di analizzare un DAG. Ad esempio, se si specifica un valore di`30`, il file DAG viene analizzato ogni 30 secondi. Si consiglia di mantenere questo numero elevato per ridurre l'utilizzo della CPU nell'ambiente. |
------
#### [ Apache Airflow v2 ]
| Configurazione | Caso d’uso |
| --- | --- |
| **[scheduler.dag\$1dir\$1list\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-dir-list-interval)** Il numero di secondi in cui la cartella deve essere scansionata alla ricerca di nuovi file. DAGs **Impostazione predefinita:** 300 secondi | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di secondi di analisi della DAGs cartella. Ti consigliamo di aumentare questo valore se riscontri lunghi tempi di analisi in`total_parse_time metrics`, ad esempio a causa dell'elevato numero di file nella cartella DAGs . |
| **[scheduler.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-file-process-interval)** Il numero di secondi dopo i quali lo scheduler analizza un DAG e vengono riflessi gli aggiornamenti al DAG. **Impostazione predefinita: 30 secondi** | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di secondi che lo scheduler attende prima di analizzare un DAG. Ad esempio, se si specifica un valore di`30`, il file DAG viene analizzato ogni 30 secondi. Si consiglia di mantenere questo numero elevato per ridurre l'utilizzo della CPU nell'ambiente. |
------
## File DAG
Come parte del ciclo di pianificazione Apache Airflow, i singoli file DAG vengono analizzati per estrarre oggetti DAG Python. [In Apache Airflow v2 e versioni successive, lo scheduler analizza un numero massimo di processi di analisi contemporaneamente.](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes) Il numero di secondi specificato in `scheduler.min_file_process_interval` (v2) o `dag_processor.min_file_process_interval` (v3) deve trascorrere prima che lo stesso file venga nuovamente analizzato.
### Parameters
Questa sezione descrive le opzioni di configurazione disponibili per i file Apache Airflow DAG (Apache Airflow v2 e versioni successive) e i relativi casi d'uso.
------
#### [ Apache Airflow v3 ]
| Configurazione | Caso d’uso |
| --- | --- |
| **[dag\$1processor.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dag-file-processor-timeout)** Il numero di secondi prima del timeout dell'elaborazione di un file DAG. *DagFileProcessor* **Impostazione predefinita:** 50 secondi | È possibile utilizzare questa opzione per liberare risorse **aumentando** il tempo necessario prima del *DagFileProcessor*timeout. Si consiglia di aumentare questo valore se si verificano dei timeout nei registri di elaborazione DAG che impediscono il caricamento di file validi. DAGs |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dagbag-import-timeout)** Il numero di secondi prima dell'importazione di un file Python scade. **Impostazione predefinita: 30 secondi** | È possibile utilizzare questa opzione per liberare risorse **aumentando** il tempo necessario prima che lo scheduler scada durante l'importazione di un file Python per estrarre gli oggetti DAG. Questa opzione viene elaborata come parte del «ciclo» dello scheduler e deve contenere un valore inferiore al valore specificato in. `dag_processor.dag_file_processor_timeout` |
| **[core.min\$1serialized\$1dag\$1update\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-update-interval)** Il numero minimo di secondi dopo il quale vengono aggiornati i serializzati nel database. DAGs Valore **predefinito: 30** | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di secondi dopo i quali vengono aggiornati i dati serializzati DAGs nel database. Si consiglia di aumentare questo valore se si dispone di DAGs un numero elevato o complesso DAGs. L'aumento di questo valore riduce il carico sullo scheduler e sul database man mano che DAGs vengono serializzati. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-fetch-interval)** Il numero di secondi in cui un DAG serializzato viene recuperato nuovamente dal database quando è già caricato in. DagBag **Impostazione predefinita**: 10 | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di secondi di recupero di un DAG serializzato. Il valore deve essere maggiore del valore specificato in `core.min_serialized_dag_update_interval` per ridurre le velocità di «scrittura» del database. L'aumento di questo valore riduce il carico sul server web e sul database man mano che DAGs vengono serializzati. |
------
#### [ Apache Airflow v2 ]
| Configurazione | Caso d’uso |
| --- | --- |
| **[core.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-file-processor-timeout)** Il numero di secondi prima del timeout dell'elaborazione di un file DAG. *DagFileProcessor* **Impostazione predefinita:** 50 secondi | È possibile utilizzare questa opzione per liberare risorse **aumentando** il tempo necessario prima del *DagFileProcessor*timeout. Si consiglia di aumentare questo valore se si verificano dei timeout nei registri di elaborazione DAG che impediscono il caricamento di file validi. DAGs |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dagbag-import-timeout)** Il numero di secondi prima dell'importazione di un file Python scade. **Impostazione predefinita: 30 secondi** | È possibile utilizzare questa opzione per liberare risorse **aumentando** il tempo necessario prima che lo scheduler scada durante l'importazione di un file Python per estrarre gli oggetti DAG. Questa opzione viene elaborata come parte del «ciclo» dello scheduler e deve contenere un valore inferiore al valore specificato in. `core.dag_file_processor_timeout` |
| **[core.min\$1serialized\$1dag\$1update\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-update-interval)** Il numero minimo di secondi dopo il quale vengono aggiornati i serializzati nel database. DAGs Valore **predefinito: 30** | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di secondi dopo i quali vengono aggiornati i dati serializzati DAGs nel database. Si consiglia di aumentare questo valore se si dispone di DAGs un numero elevato o complesso DAGs. L'aumento di questo valore riduce il carico sullo scheduler e sul database man mano che DAGs vengono serializzati. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-fetch-interval)** Il numero di secondi in cui un DAG serializzato viene recuperato nuovamente dal database quando è già caricato in. DagBag **Impostazione predefinita**: 10 | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di secondi di recupero di un DAG serializzato. Il valore deve essere maggiore del valore specificato in `core.min_serialized_dag_update_interval` per ridurre le velocità di «scrittura» del database. L'aumento di questo valore riduce il carico sul server web e sul database man mano che DAGs vengono serializzati. |
------
## Processi
Lo scheduler e gli operatori di Apache Airflow sono entrambi coinvolti nelle attività di attesa e disattesa. ****Lo scheduler prende le attività analizzate pronte per essere pianificate dallo stato Nessuno allo stato Pianificato.**** **L'esecutore, anch'esso in esecuzione nel contenitore scheduler di Fargate, mette in coda tali attività e ne imposta lo stato su In coda.** Quando i lavoratori hanno capacità, preleva l'operazione dalla coda e imposta lo stato su In **esecuzione**, che successivamente modifica lo stato in Operazione completata o **Non riuscita a seconda che l'attività abbia **esito positivo** o negativo**.
### Parameters
Questa sezione descrive le opzioni di configurazione disponibili per le attività di Apache Airflow e i relativi casi d'uso.
Le opzioni di configurazione predefinite che Amazon MWAA sostituisce sono contrassegnate. *red*
------
#### [ Apache Airflow v3 ]
| Configurazione | Caso d’uso |
| --- | --- |
| **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Il numero massimo di istanze di attività che possono avere uno stato. `Running` **Predefinito:** impostato dinamicamente in base a. `(maxWorkers * maxCeleryWorkers) / schedulers * 1.5` | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di istanze di attività che possono essere eseguite contemporaneamente. Il valore specificato deve essere il numero di lavoratori disponibili moltiplicato per la densità delle attività dei lavoratori. Si consiglia di modificare questo valore solo quando si verifica un gran numero di attività bloccate nello stato «In esecuzione» o «In coda». |
| **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#execute-tasks-new-python-interpreter)** Determina se Apache Airflow esegue le attività biforcando il processo principale o creando un nuovo processo Python. **Default**: `True` | Se impostato su`True`, Apache Airflow riconosce le modifiche apportate ai plugin come un nuovo processo Python creato per eseguire attività. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA sostituisce l'installazione di base Airflow per questa opzione per scalare i lavoratori come parte del componente di scalabilità automatica. **Impostazione** predefinita: non applicabile | *Any value specified for this option is ignored.* |
| **[celery.worker\$1autoscale](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-autoscale)** La concorrenza delle attività per i lavoratori. **Valori predefiniti:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/mwaa/latest/userguide/best-practices-tuning.html) | È possibile utilizzare questa opzione per liberare risorse **riducendo** la concomitanza tra le mansioni dei `maximum` lavoratori. `minimum` I lavoratori accettano fino alle attività `maximum` simultanee configurate, indipendentemente dal fatto che vi siano risorse sufficienti per farlo. Se le attività sono pianificate senza risorse sufficienti, le attività falliscono immediatamente. Si consiglia di modificare questo valore per le attività che richiedono molte risorse riducendo i valori a un valore inferiore a quello predefinito per consentire una maggiore capacità per attività. |
------
#### [ Apache Airflow v2 ]
| Configurazione | Caso d’uso |
| --- | --- |
| **[core.parallelismo](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Il numero massimo di istanze di attività che possono avere uno stato. `Running` **Predefinito:** impostato dinamicamente in base a. `(maxWorkers * maxCeleryWorkers) / schedulers * 1.5` | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di istanze di attività che possono essere eseguite contemporaneamente. Il valore specificato deve essere il numero di lavoratori disponibili moltiplicato per la densità delle attività dei lavoratori. Si consiglia di modificare questo valore solo quando si verifica un gran numero di attività bloccate nello stato «In esecuzione» o «In coda». |
| **[core.dag\$1concurrency](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-concurrency)** Il numero di istanze di attività che possono essere eseguite contemporaneamente per ogni DAG. **Valore predefinito: 10000** | È possibile utilizzare questa opzione per liberare risorse **aumentando** il numero di istanze di attività consentite per l'esecuzione simultanea. Ad esempio, se si dispone di cento attività parallele DAGs con dieci e si desidera che tutte vengano DAGs eseguite contemporaneamente, è possibile calcolare il parallelismo massimo come il numero di lavoratori disponibili moltiplicato per la densità delle attività dei lavoratori in`celery.worker_concurrency`, diviso per il numero di. DAGs |
| **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#execute-tasks-new-python-interpreter)** Determina se Apache Airflow esegue le attività biforcando il processo principale o creando un nuovo processo Python. **Default**: `True` | Se impostato su`True`, Apache Airflow riconosce le modifiche apportate ai plugin come un nuovo processo Python creato per eseguire attività. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA sostituisce l'installazione di base Airflow per questa opzione per scalare i lavoratori come parte del componente di scalabilità automatica. **Impostazione** predefinita: non applicabile | *Any value specified for this option is ignored.* |
| **[celery.worker\$1autoscale](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-autoscale)** La concorrenza delle attività per i lavoratori. **Valori predefiniti:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/mwaa/latest/userguide/best-practices-tuning.html) | È possibile utilizzare questa opzione per liberare risorse **riducendo** la concomitanza tra le mansioni dei `maximum` lavoratori. `minimum` I lavoratori accettano fino alle attività `maximum` simultanee configurate, indipendentemente dal fatto che vi siano risorse sufficienti per farlo. Se le attività sono pianificate senza risorse sufficienti, le attività falliscono immediatamente. Si consiglia di modificare questo valore per le attività che richiedono molte risorse riducendo i valori a un valore inferiore a quello predefinito per consentire una maggiore capacità per attività. |
------
# Gestione delle dipendenze Python in requirements.txt
Questo argomento descrive come installare e gestire le dipendenze Python in un `requirements.txt` file per un ambiente Amazon Managed Workflows for Apache Airflow.
**Contents**
+ [Test DAGs con l'utilità CLI di Amazon MWAA](#best-practices-dependencies-cli-utility)
+ [Installazione delle dipendenze Python utilizzando il formato file dei requisiti PyPi .org](#best-practices-dependencies-different-ways)
+ [Opzione uno: dipendenze Python dal Python Package Index](#best-practices-dependencies-pip-extras)
+ [Opzione due: Python wheels (.whl)](#best-practices-dependencies-python-wheels)
+ [Utilizzo del `plugins.zip` file su un bucket Amazon S3](#best-practices-dependencies-python-wheels-s3)
+ [Utilizzando un file WHL ospitato su un URL](#best-practices-dependencies-python-wheels-url)
+ [Creazione di un file WHL da un DAG](#best-practices-dependencies-python-wheels-dag)
+ [Opzione tre: dipendenze Python ospitate su un repository privato PyPi conforme a /PEP-503](#best-practices-dependencies-custom-auth-url)
+ [Abilitazione dei log sulla console Amazon MWAA](#best-practices-dependencies-troubleshooting-enable)
+ [Accesso ai log sulla console Logs CloudWatch](#best-practices-dependencies-troubleshooting-view)
+ [Accesso agli errori nell'interfaccia utente di Apache Airflow](#best-practices-dependencies-troubleshooting-aa)
+ [Accedi ad Apache Airflow](#airflow-access-and-login)
+ [Scenari di esempio `requirements.txt`](#best-practices-dependencies-ex-mix-match)
## Test DAGs con l'utilità CLI di Amazon MWAA
+ L'utilità CLI (Command Line Interface) replica localmente un ambiente Amazon Managed Workflows for Apache Airflow.
+ La CLI crea localmente un'immagine del contenitore Docker simile a un'immagine di produzione Amazon MWAA. Puoi utilizzarlo per eseguire un ambiente Apache Airflow locale per sviluppare e DAGs testare plugin personalizzati e dipendenze prima della distribuzione su Amazon MWAA.
+ Per eseguire la CLI, fare riferimento a [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)on. GitHub
## Installazione delle dipendenze Python utilizzando il formato file dei requisiti PyPi .org
La sezione seguente descrive i diversi modi per installare le dipendenze Python in base al PyPi formato.org [Requirements](https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format) File.
### Opzione uno: dipendenze Python dal Python Package Index
La sezione seguente descrive come specificare le dipendenze Python dall'indice dei pacchetti [Python in un file](https://pypi.org/). `requirements.txt`
------
#### [ Apache Airflow v3 ]
1. **Esegui il test localmente.** Aggiungi altre librerie in modo iterativo per trovare la giusta combinazione di pacchetti e le relative versioni, prima di creare un `requirements.txt` file. Per eseguire l'utilità CLI di Amazon MWAA, consulta on. [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images) GitHub
1. **Consulta gli extra del pacchetto Apache Airflow**. Per accedere a un elenco dei pacchetti installati per Apache Airflow v3 su Amazon MWAA, consulta il sito Web. [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt) GitHub
1. **Aggiungi una dichiarazione di vincoli.** Aggiungi il file dei vincoli per il tuo ambiente Apache Airflow v3 nella parte superiore del file. `requirements.txt` I file dei vincoli di Apache Airflow specificano le versioni del provider disponibili al momento di una versione di Apache Airflow.
Nell'esempio seguente, sostituisci *\$1environment-version\$1* con il numero di versione del tuo ambiente e *\$1Python-version\$1* con la versione di Python compatibile con il tuo ambiente.
[Per informazioni sulla versione di Python compatibile con il tuo ambiente Apache Airflow, consulta le versioni di Apache Airflow.](airflow-versions.md#airflow-versions-official)
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Se il file dei vincoli determina che il `xyz==1.0` pacchetto non è compatibile con altri pacchetti dell'ambiente, non `pip3 install` riesce a impedire l'installazione di librerie incompatibili nell'ambiente. Se l'installazione non riesce per qualsiasi pacchetto, puoi accedere ai log degli errori per ogni componente Apache Airflow (lo scheduler, il worker e il server web) nel flusso di log corrispondente su Logs. CloudWatch Per ulteriori informazioni sui tipi di registro, fare riferimento a. [Accesso ai log Airflow in Amazon CloudWatch](monitoring-airflow.md)
1. **Pacchetti Apache Airflow**. Aggiungi gli [extra del pacchetto e la](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) versione (). `==` Questo aiuta a evitare che pacchetti con lo stesso nome, ma con una versione diversa, vengano installati nell'ambiente.
```
apache-airflow[package-extra]==2.5.1
```
1. **Librerie Python**. Aggiungi il nome del pacchetto e la versione (`==`) nel tuo `requirements.txt` file. In questo modo si evita l'applicazione automatica di future interruzioni del [PyPisito .org](https://pypi.org).
```
library == version
```
**Example Boto3 e psycopg2-binary**
Questo esempio viene fornito a scopo dimostrativo. Le librerie boto e psycopg2-binary sono incluse nell'installazione di base per Apache Airflow v3 e non devono essere specificate in un file. `requirements.txt`
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Se viene specificato un pacchetto senza una versione, Amazon MWAA installa la versione più recente del pacchetto da .org. PyPi](https://pypi.org) Questa versione può entrare in conflitto con altri pacchetti presenti nel tuo. `requirements.txt`
------
#### [ Apache Airflow v2 ]
1. **Esegui il test localmente**. Aggiungi altre librerie in modo iterativo per trovare la giusta combinazione di pacchetti e le relative versioni, prima di creare un `requirements.txt` file. Per eseguire l'utilità CLI di Amazon MWAA, consulta on. [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images) GitHub
1. **Consulta gli extra del pacchetto Apache Airflow**. Per accedere a un elenco dei pacchetti installati per Apache Airflow v2 su Amazon MWAA, accedi al sito Web. [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt) GitHub
1. **Aggiungi una dichiarazione di vincoli.** Aggiungi il file dei vincoli per il tuo ambiente Apache Airflow v2 nella parte superiore del file. `requirements.txt` I file dei vincoli di Apache Airflow specificano le versioni del provider disponibili al momento di una versione di Apache Airflow.
A partire da Apache Airflow v2.7.2, il file dei requisiti deve includere una dichiarazione. `--constraint` Se non fornisci un vincolo, Amazon MWAA te ne specificherà uno per garantire che i pacchetti elencati nei tuoi requisiti siano compatibili con la versione di Apache Airflow che stai utilizzando.
Nell'esempio seguente, sostituisci *\$1environment-version\$1* con il numero di versione del tuo ambiente e *\$1Python-version\$1* con la versione di Python compatibile con il tuo ambiente.
[Per informazioni sulla versione di Python compatibile con il tuo ambiente Apache Airflow, consulta le versioni di Apache Airflow.](airflow-versions.md#airflow-versions-official)
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Se il file dei vincoli determina che il `xyz==1.0` pacchetto non è compatibile con altri pacchetti dell'ambiente, non `pip3 install` riesce a impedire l'installazione di librerie incompatibili nell'ambiente. Se l'installazione non riesce per qualsiasi pacchetto, puoi accedere ai log degli errori per ogni componente Apache Airflow (lo scheduler, il worker e il server web) nel flusso di log corrispondente su Logs. CloudWatch Per ulteriori informazioni sui tipi di registro, fare riferimento a. [Accesso ai log Airflow in Amazon CloudWatch](monitoring-airflow.md)
1. **Pacchetti Apache Airflow**. Aggiungi gli [extra del pacchetto e la](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) versione (). `==` Questo aiuta a evitare che pacchetti con lo stesso nome, ma con una versione diversa, vengano installati nell'ambiente.
```
apache-airflow[package-extra]==2.5.1
```
1. **Librerie Python**. Aggiungi il nome del pacchetto e la versione (`==`) nel tuo `requirements.txt` file. In questo modo si evita l'applicazione automatica di future interruzioni del [PyPisito .org](https://pypi.org).
```
library == version
```
**Example Boto3 e psycopg2-binary**
Questo esempio viene fornito a scopo dimostrativo. Le librerie boto e psycopg2-binary sono incluse nell'installazione di base di Apache Airflow v2 e non devono essere specificate in un file. `requirements.txt`
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Se viene specificato un pacchetto senza una versione, Amazon MWAA installa la versione più recente del pacchetto da .org. PyPi](https://pypi.org) Questa versione può entrare in conflitto con altri pacchetti presenti nel tuo. `requirements.txt`
------
### Opzione due: Python wheels (.whl)
Una ruota Python è un formato di pacchetto progettato per spedire librerie con artefatti compilati. I pacchetti wheel offrono diversi vantaggi come metodo per installare le dipendenze in Amazon MWAA:
+ **Installazione più rapida**: i file WHL vengono copiati nel contenitore come singolo ZIP e quindi installati localmente, senza dover scaricare ciascuno di essi.
+ **Meno conflitti**: è possibile determinare in anticipo la compatibilità delle versioni dei pacchetti. Di conseguenza, non è necessario elaborare in modo ricorsivo versioni compatibili. `pip`
+ **Maggiore resilienza**: con le librerie ospitate esternamente, i requisiti a valle possono cambiare, con conseguente incompatibilità di versione tra i contenitori in un ambiente Amazon MWAA. Non dipendendo da una fonte esterna per le dipendenze, ogni contenitore ha le stesse librerie indipendentemente dal momento in cui viene creata l'istanza di ogni contenitore.
Consigliamo i seguenti metodi per installare le dipendenze Python da un archivio Python wheel () nel tuo. `.whl` `requirements.txt`
**Topics**
+ [Utilizzo del `plugins.zip` file su un bucket Amazon S3](#best-practices-dependencies-python-wheels-s3)
+ [Utilizzando un file WHL ospitato su un URL](#best-practices-dependencies-python-wheels-url)
+ [Creazione di un file WHL da un DAG](#best-practices-dependencies-python-wheels-dag)
#### Utilizzo del `plugins.zip` file su un bucket Amazon S3
Lo scheduler, i worker e il server web di Apache Airflow (per Apache Airflow v2.2.2 e versioni successive) cercano plugin personalizzati durante l'avvio nel contenitore Fargate gestito per il vostro ambiente in. AWS`/usr/local/airflow/plugins/*` Questo processo inizia prima dell'avvio del servizio Amazon MWAA `pip3 install -r requirements.txt` for Python e del servizio Apache Airflow. Un `plugins.zip` file può essere utilizzato per tutti i file che non si desidera modificare continuamente durante l'esecuzione dell'ambiente o per i quali non si desidera concedere l'accesso agli utenti che scrivono. DAGs Ad esempio, i file della ruota della libreria Python, i file PEM dei certificati e i file YAML di configurazione.
La sezione seguente descrive come installare una ruota contenuta nel `plugins.zip` file sul tuo bucket Amazon S3.
1. **Scarica i file WHL necessari**. Puoi utilizzarli [https://pip.pypa.io/en/stable/cli/pip_download/](https://pip.pypa.io/en/stable/cli/pip_download/)con quelli esistenti `requirements.txt` in Amazon MWAA o in un [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)altro contenitore [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2) per risolvere e scaricare i file di Python wheel necessari.
```
pip3 download -r "$AIRFLOW_HOME/dags/requirements.txt" -d "$AIRFLOW_HOME/plugins"
cd "$AIRFLOW_HOME/plugins"
zip "$AIRFLOW_HOME/plugins.zip" *
```
1. **Specificate il percorso nel vostro. `requirements.txt`** Specificate la directory dei plugins nella parte superiore del file requirements.txt usando [https://pip.pypa.io/en/stable/cli/pip_install/#install-find-links](https://pip.pypa.io/en/stable/cli/pip_install/#install-find-links)e chiedete di `pip` non installarlo da altre fonti utilizzando [https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index](https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index), come elencato nel codice seguente:
```
--find-links /usr/local/airflow/plugins
--no-index
```
**Example ruota in requirements.txt**
L'esempio seguente presuppone che tu abbia caricato la ruota in un `plugins.zip` file nella radice del tuo bucket Amazon S3. Esempio:
```
--find-links /usr/local/airflow/plugins
--no-index
numpy
```
Amazon MWAA recupera la `numpy-1.20.1-cp37-cp37m-manylinux1_x86_64.whl` ruota dalla `plugins` cartella e la installa nel tuo ambiente.
#### Utilizzando un file WHL ospitato su un URL
La sezione seguente descrive come installare una ruota ospitata su un URL. L'URL deve essere accessibile pubblicamente o dall'interno del VPC Amazon personalizzato specificato per il tuo ambiente Amazon MWAA.
+ **Fornisci un URL**. Fornisci l'URL a una ruota nel tuo`requirements.txt`.
**Example archivio wheel su un URL pubblico**
L'esempio seguente scarica una ruota da un sito pubblico.
```
--find-links https://files.pythonhosted.org/packages/
--no-index
```
Amazon MWAA recupera la ruota dall'URL specificato e la installa nel tuo ambiente.
**Nota**
URLs non sono accessibili da server Web privati che installano i requisiti in Amazon MWAA v2.2.2 e versioni successive.
#### Creazione di un file WHL da un DAG
Se disponi di un server Web privato che utilizza Apache Airflow v2.2.2 o versione successiva e non riesci a installare i requisiti perché il tuo ambiente non ha accesso a repository esterni, puoi utilizzare il seguente DAG per prendere i requisiti Amazon MWAA esistenti e impacchettarli su Amazon S3:
```
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from airflow.utils.dates import days_ago
S3_BUCKET = 'my-s3-bucket'
S3_KEY = 'backup/plugins_whl.zip'
with DAG(dag_id="create_whl_file", schedule_interval=None, catchup=False, start_date=days_ago(1)) as dag:
cli_command = BashOperator(
task_id="bash_command",
bash_command=f"mkdir /tmp/whls;pip3 download -r /usr/local/airflow/requirements/requirements.txt -d /tmp/whls;zip -j /tmp/plugins.zip /tmp/whls/*;aws s3 cp /tmp/plugins.zip s3://amzn-s3-demo-bucket/{S3_KEY}"
)
```
Dopo aver eseguito il DAG, usa questo nuovo file come Amazon MWAA`plugins.zip`, facoltativamente, impacchettato con altri plugin. Quindi, aggiorna il file preceduto da e senza aggiungere. `requirements.txt` `--find-links /usr/local/airflow/plugins` `--no-index` `--constraint`
Questo metodo è possibile utilizzare per utilizzare le stesse librerie offline.
### Opzione tre: dipendenze Python ospitate su un repository privato PyPi conforme a /PEP-503
La sezione seguente descrive come installare un extra Apache Airflow ospitato su un URL privato con autenticazione.
1. Aggiungi nome utente e password come opzioni di configurazione di [Apache Airflow](configuring-env-variables.md). Esempio:
+ `foo.user` : `YOUR_USER_NAME`
+ `foo.pass` : `YOUR_PASSWORD`
1. Crea il tuo file. `requirements.txt` Sostituisci i segnaposto nell'esempio seguente con il tuo URL privato e il nome utente e la password che hai aggiunto come opzioni di configurazione di Apache [Airflow](configuring-env-variables.md). Esempio:
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
```
1. Aggiungi eventuali librerie aggiuntive al tuo file. `requirements.txt` Esempio:
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
my-private-package==1.2.3
```
## Abilitazione dei log sulla console Amazon MWAA
Il [ruolo di esecuzione](mwaa-create-role.md) per il tuo ambiente Amazon MWAA richiede l'autorizzazione per inviare log a Logs. CloudWatch Per aggiornare le autorizzazioni di un ruolo di esecuzione, consulta. [Ruolo di esecuzione di Amazon MWAA](mwaa-create-role.md)
È possibile abilitare i log di Apache Airflow a livello `INFO``WARNING`,, `ERROR` o. `CRITICAL` Quando scegli un livello di log, Amazon MWAA invia i log per quel livello e tutti i livelli di gravità più elevati. Ad esempio, se abiliti i log a `INFO` livello, Amazon MWAA invia `INFO` log e `WARNING``ERROR`, e livelli di `CRITICAL` log a Logs. CloudWatch Consigliamo di abilitare i log di Apache Airflow al livello che consente `INFO` allo scheduler di accedere ai log ricevuti per. `requirements.txt`
![\[Questa immagine mostra come abilitare i log a livello INFO.\]](http://docs.aws.amazon.com/it_it/mwaa/latest/userguide/images/mwaa-console-logs-info.png)
## Accesso ai log sulla console Logs CloudWatch
Puoi accedere ai log di Apache Airflow per lo scheduler che pianifica i flussi di lavoro e analizza la cartella. `dags` I passaggi seguenti descrivono come aprire il gruppo di log per lo scheduler sulla console Amazon MWAA e accedere ai log di Apache Airflow sulla console Logs. CloudWatch
**Per accedere ai log di un `requirements.txt`**
1. Apri la pagina [Ambienti](https://console.aws.amazon.com/mwaa/home#/environments) sulla console Amazon MWAA.
1. Scegli un ambiente.
1. Scegli il **gruppo di log dello scheduler Airflow** nel riquadro **Monitoraggio**.
1. Scegli il `requirements_install_ip` log in **Log** Streams.
1. Fate riferimento all'elenco dei pacchetti che sono stati installati nell'ambiente all'indirizzo`/usr/local/airflow/.local/bin`. Esempio:
```
Collecting appdirs==1.4.4 (from -r /usr/local/airflow/.local/bin (line 1))
Downloading https://files.pythonhosted.org/packages/3b/00/2344469e2084fb28kjdsfiuyweb47389789vxbmnbjhsdgf5463acd6cf5e3db69324/appdirs-1.4.4-py2.py3-none-any.whl
Collecting astroid==2.4.2 (from -r /usr/local/airflow/.local/bin (line 2))
```
1. Controlla l'elenco dei pacchetti e verifica se qualcuno di questi ha riscontrato un errore durante l'installazione. Se qualcosa è andato storto, potresti ricevere un errore simile al seguente:
```
2021-03-05T14:34:42.731-07:00
No matching distribution found for LibraryName==1.0.0 (from -r /usr/local/airflow/.local/bin (line 4))
No matching distribution found for LibraryName==1.0.0 (from -r /usr/local/airflow/.local/bin (line 4))
```
## Accesso agli errori nell'interfaccia utente di Apache Airflow
Puoi anche controllare l'interfaccia utente di Apache Airflow per identificare se un errore è correlato a un altro problema. L'errore più comune che puoi riscontrare con Apache Airflow su Amazon MWAA è:
```
Broken DAG: No module named x
```
Se trovi questo errore nell'interfaccia utente di Apache Airflow, è probabile che nel file manchi una dipendenza richiesta. `requirements.txt`
### Accedi ad Apache Airflow
Hai bisogno [Politica di accesso all'interfaccia utente di Apache Airflow: Amazon MWAAWeb ServerAccess](access-policies.md#web-ui-access) delle autorizzazioni per il tuo Account AWS in AWS Identity and Access Management (IAM) per accedere all'interfaccia utente di Apache Airflow.
**Per accedere all'interfaccia utente di Apache Airflow**
1. Apri la pagina [Ambienti](https://console.aws.amazon.com/mwaa/home#/environments) sulla console Amazon MWAA.
1. Scegli un ambiente.
1. Scegli **Open Airflow UI**.
## Scenari di esempio `requirements.txt`
Puoi mescolare e abbinare diversi formati nel tuo`requirements.txt`. L'esempio seguente utilizza una combinazione dei diversi modi per installare gli extra.
**Example Extra su PyPi .org e un URL pubblico**
È necessario utilizzare l'`--index-url`opzione quando si specificano i pacchetti da PyPi .org, oltre ai pacchetti su un URL pubblico, come un repository personalizzato conforme a PEP 503. URLs
```
aws-batch == 0.6
phoenix-letter >= 0.3
--index-url http://dist.repoze.org/zope2/2.10/simple
zopelib
```