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à.
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 di Apache Airflow su Amazon MWAA
Aggiungere un'opzione di configurazione di Apache Airflow
Utilizzate la procedura seguente per aggiungere un'opzione di configurazione Airflow al vostro ambiente.
-
Apri la pagina Ambienti sulla console Amazon MWAA.
-
Scegli un ambiente.
-
Scegli Modifica.
-
Scegli Next (Successivo).
-
Scegliete Aggiungi configurazione personalizzata nel riquadro delle opzioni di configurazione Airflow.
-
Scegliete una configurazione dall'elenco a discesa e immettete un valore, oppure inserite una configurazione personalizzata e immettete un valore.
-
Scegli Aggiungi configurazione personalizzata per ogni configurazione che desideri aggiungere.
-
Scegli Save (Salva).
Per saperne di più, consultaUtilizzo delle opzioni di configurazione di Apache Airflow su Amazon MWAA.
Pianificatore Apache Airflow
Lo scheduler Apache Airflow è un componente fondamentale di Apache Airflow. Un problema con lo scheduler può impedire l'analisi dei DAG e la pianificazione delle attività. Per ulteriori informazioni sull'ottimizzazione dello scheduler di Apache Airflow, consultate le prestazioni dello scheduler nel sito Web della documentazione di Fine-tuning Apache Airflow.
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_parallelism
Il numero di processi utilizzati da Celery Executor per sincronizzare lo stato delle attività.
Impostazione predefinita: 1
|
Usa questa opzione per prevenire i conflitti tra le code limitando i processi utilizzati da Celery Executor. Per impostazione predefinita, è impostato un valore per evitare errori nella consegna dei log delle attività 1 ai log. CloudWatch Impostare il valore su 0 significa utilizzare il numero massimo di processi, ma può causare errori durante la distribuzione dei log delle attività.
|
|
scheduler.scheduler_idle_sleep_time
Il numero di secondi di attesa tra i «loop» consecutivi dello scheduler se non c'era nulla da fare nel loop.
Impostazione predefinita: 1
|
Utilizzate questa opzione per liberare l'utilizzo della CPU sullo scheduler aumentando il tempo di sospensione dello scheduler dopo aver terminato un «ciclo». L'aumento di questo valore riduce i thread dello scheduler disponibili in dag_processor.parsing_processes Apache Airflow v2 e Apache Airflow v3. Ciò può ridurre la capacità degli scheduler di analizzare i DAG e aumentare il tempo impiegato dai DAG per la compilazione nel server web.
|
|
scheduler.max_dagruns_to_create_per_loop
Il numero massimo di DAG da creare per ogni «loop» dello scheduler. DagRuns
Impostazione predefinita: 10
|
Utilizzate questa opzione per liberare risorse per la pianificazione delle attività diminuendo il numero massimo di «loop» dello DagRuns scheduler.
|
|
dag_processor.parsing_processes
Il numero di thread che lo scheduler può eseguire in parallelo per pianificare i DAG.
Predefinito: Usa (2 * number of vCPUs) - 1
|
Usa questa opzione per liberare risorse diminuendo il numero di processi che lo scheduler esegue in parallelo per analizzare i DAG. Consigliamo di mantenere questo numero basso se l'analisi del DAG influisce sulla pianificazione delle attività. È necessario specificare un valore inferiore al numero di vCPU presenti nell'ambiente. Per saperne di più, consulta Limits Limiti.
|
- Apache Airflow v2
-
| Configurazione |
Caso d’uso |
|
celery.sync_parallelism
Il numero di processi utilizzati da Celery Executor per sincronizzare lo stato delle attività.
Impostazione predefinita: 1
|
Usa questa opzione per prevenire i conflitti tra le code limitando i processi utilizzati da Celery Executor. Per impostazione predefinita, è impostato un valore per evitare errori nella consegna dei log delle attività 1 ai log. CloudWatch Impostare il valore su 0 significa utilizzare il numero massimo di processi, ma può causare errori durante la distribuzione dei log delle attività.
|
|
scheduler.scheduler_idle_sleep_time
Il numero di secondi di attesa tra i «loop» consecutivi dello scheduler se non c'era nulla da fare nel loop.
Impostazione predefinita: 1
|
Utilizzate questa opzione per liberare l'utilizzo della CPU sullo scheduler aumentando il tempo di sospensione dello scheduler dopo aver terminato un «ciclo». L'aumento di questo valore riduce i thread dello scheduler disponibili in dag_processor.parsing_processes Apache Airflow v2 e Apache Airflow v3. Ciò può ridurre la capacità degli scheduler di analizzare i DAG e aumentare il tempo impiegato dai DAG per la compilazione nel server web.
|
|
scheduler.max_dagruns_to_create_per_loop
Il numero massimo di DAG da creare per ogni «loop» dello scheduler. DagRuns
Impostazione predefinita: 10
|
Utilizzate questa opzione per liberare risorse per la pianificazione delle attività diminuendo il numero massimo di «loop» dello DagRuns scheduler.
|
|
scheduler.parsing_processes
Il numero di thread che lo scheduler può eseguire in parallelo per pianificare i DAG.
Predefinito: Usa (2 * number of vCPUs) - 1
|
Usa questa opzione per liberare risorse diminuendo il numero di processi che lo scheduler esegue in parallelo per analizzare i DAG. Consigliamo di mantenere questo numero basso se l'analisi del DAG influisce sulla pianificazione delle attività. È necessario specificare un valore inferiore al numero di vCPU presenti nell'ambiente. Per saperne di più, consulta Limits Limiti.
|
Limits
Questa sezione descrive i limiti da considerare quando si regolano i parametri predefiniti per lo scheduler.
- scheduler.parsing_processes, scheduler.max_threads (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. Ad esempio, un ambiente di grandi dimensioni ha un'istanza del contenitore Fargate con 4 vCPU per lo scheduler. Ciò significa che è disponibile un massimo di thread 7 totali da utilizzare per altri processi. Ovvero, due thread moltiplicano quattro vCPU, meno una 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 il numero di 3 thread per altri processi. Il thread rimanente è riservato allo scheduler.
-
mw1.large — Non deve superare il numero di 7 thread per altri processi. Il thread rimanente è riservato allo scheduler.
Cartelle DAG
Lo scheduler Apache Airflow esegue una scansione continua della cartella DAG nell'ambiente in uso. 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 cartella DAG (Apache Airflow v2 e versioni successive) e i relativi casi d'uso.
- Apache Airflow v3
-
| Configurazione |
Caso d’uso |
|
dag_processor.refresh_interval
Il numero di secondi in cui la cartella DAG deve essere scansionata alla ricerca di nuovi file.
Impostazione predefinita: 300 secondi
|
Usa questa opzione per liberare risorse aumentando il numero di secondi per analizzare la cartella DAG. Ti consigliamo di aumentare questo valore se i tempi di analisi sono lunghitotal_parse_time metrics, il che potrebbe essere dovuto all'elevato numero di file nella cartella DAG.
|
|
dag_processor.min_file_process_interval
Il numero di secondi dopo i quali lo scheduler analizza un DAG e gli aggiornamenti al DAG vengono riflessi.
Impostazione predefinita: 30 secondi
|
Utilizzate questa opzione per liberare risorse aumentando il numero di secondi di attesa dello scheduler prima di analizzare un DAG. Ad esempio, se si specifica un valore di30, 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_dir_list_interval
Il numero di secondi in cui la cartella DAG deve essere scansionata alla ricerca di nuovi file.
Impostazione predefinita: 300 secondi
|
Usa questa opzione per liberare risorse aumentando il numero di secondi per analizzare la cartella DAG. Ti consigliamo di aumentare questo valore se i tempi di analisi sono lunghitotal_parse_time metrics, il che potrebbe essere dovuto all'elevato numero di file nella cartella DAG.
|
|
scheduler.min_file_process_interval
Viene indicato il numero di secondi trascorsi i quali lo scheduler analizza un DAG e gli aggiornamenti al DAG.
Impostazione predefinita: 30 secondi
|
Utilizzate questa opzione per liberare risorse aumentando il numero di secondi di attesa dello scheduler prima di analizzare un DAG. Ad esempio, se si specifica un valore di30, 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 di 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 DAG di Apache Airflow (Apache Airflow v2 e versioni successive) e i relativi casi d'uso.
- Apache Airflow v3
-
| Configurazione |
Caso d’uso |
|
dag_processor.dag_file_processor_timeout
Il numero di secondi prima del timeout dell'elaborazione di un file DAG. DagFileProcessor
Impostazione predefinita: 50 secondi
|
Usa questa opzione per aumentare il tempo necessario prima dei DagFileProcessor timeout. Consigliamo di aumentare questo valore se si verificano dei timeout nei log di elaborazione del DAG che non comportano il caricamento di DAG validi.
|
|
core.dagbag_import_timeout
Il numero di secondi prima dell'importazione di un file Python scade.
Impostazione predefinita: 30 secondi
|
Utilizzate questa opzione per aumentare 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 indag_processor.dag_file_processor_timeout.
|
|
core.min_serialized_dag_update_interval
Il numero minimo di secondi dopo i quali i DAG serializzati nel database vengono aggiornati.
Predefinito: 30
|
Utilizzate questa opzione per liberare risorse aumentando il numero di secondi dopo i quali i DAG serializzati nel database vengono aggiornati. Si consiglia di aumentare questo valore se si dispone di un numero elevato di DAG o di DAG complessi. L'aumento di questo valore riduce il carico sullo scheduler e sul database man mano che i DAG vengono serializzati.
|
|
core.min_serialized_dag_fetch_interval
Il numero di secondi in cui un DAG serializzato viene recuperato dal database quando è già stato caricato nel. DagBag
Impostazione predefinita: 10
|
Usa 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 i DAG vengono serializzati.
|
- Apache Airflow v2
-
| Configurazione |
Caso d’uso |
|
core.dag_file_processor_timeout
Il numero di secondi prima del timeout dell'elaborazione di un file DAG. DagFileProcessor
Impostazione predefinita: 50 secondi
|
Usa questa opzione per aumentare il tempo necessario prima dei DagFileProcessor timeout. Consigliamo di aumentare questo valore se si verificano dei timeout nei log di elaborazione del DAG che non comportano il caricamento di DAG validi.
|
|
core.dagbag_import_timeout
Il numero di secondi prima dell'importazione di un file Python scade.
Impostazione predefinita: 30 secondi
|
Utilizzate questa opzione per aumentare 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_serialized_dag_update_interval
Il numero minimo di secondi dopo i quali i DAG serializzati nel database vengono aggiornati.
Predefinito: 30
|
Utilizzate questa opzione per liberare risorse aumentando il numero di secondi dopo i quali i DAG serializzati nel database vengono aggiornati. Si consiglia di aumentare questo valore se si dispone di un numero elevato di DAG o di DAG complessi. L'aumento di questo valore riduce il carico sullo scheduler e sul database man mano che i DAG vengono serializzati.
|
|
core.min_serialized_dag_fetch_interval
Il numero di secondi in cui un DAG serializzato viene recuperato dal database quando è già stato caricato nel. DagBag
Impostazione predefinita: 10
|
Usa 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 i DAG vengono serializzati.
|
Processi
Lo scheduler e i lavoratori di Apache Airflow sono entrambi coinvolti nelle attività di accodamento e rimozione della coda. Lo scheduler prende le attività analizzate pronte per essere pianificate da uno stato Nessuno a uno stato Pianificato. L'esecutore, anch'esso in esecuzione sul contenitore di pianificazione di Fargate, mette in coda tali attività e ne imposta lo stato su In coda. Quando i lavoratori hanno la capacità, preleva l'attività dalla coda e imposta lo stato su In esecuzione, che successivamente cambia il suo stato in Successo o Fallito 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 sostituite da Amazon MWAA sono contrassegnate. red
- Apache Airflow v3
-
| Configurazione |
Caso d’uso |
|
core.parallelism
Il numero massimo di istanze di attività che ogni scheduler può monitorare ed eseguire contemporaneamente.
Predefinito: impostato dinamicamente in base a. (maxWorkers * maxCeleryWorkers) / schedulers * 1.5
|
Usa questa opzione per controllare il limite massimo globale del totale delle attività in esecuzione. Ad esempio, potete aumentare questo valore per proteggere il metadatabase da troppe connessioni simultanee o per limitare i costi. Il valore predefinito è elevatoworker_autoscale, in modo che altri controlli (slot del poolmax_active_tasks_per_dag) fungano da limiti effettivi di concorrenza.
|
|
core.max_active_tasks_per_dag
Il numero massimo di istanze di attività che possono essere eseguite contemporaneamente in ogni esecuzione del DAG.
Predefinito: 16
|
Usa questa opzione per liberare risorse aumentando il numero di istanze di attività che possono essere eseguite contemporaneamente. Ad esempio, se hai 100 DAG con 10 attività parallele e desideri che tutti i DAG vengano eseguiti contemporaneamente, calcola il parallelismo massimo. Moltiplica il numero di lavoratori disponibili per la densità di attività incelery.worker_concurrency, quindi dividi per il numero di DAG.
|
|
core.execute_tasks_new_python_interpreter
Determina se Apache Airflow esegue le attività eseguendo il fork del processo principale o creando un nuovo processo Python.
Default: True
|
Se impostato suTrue, Apache Airflow riconosce le modifiche apportate ai plug-in come un nuovo processo Python creato per eseguire le attività.
|
|
celery.worker_concurrency
Amazon MWAA sostituisce l'installazione di base di Airflow per questa opzione per scalare i lavoratori come parte del suo componente di scalabilità automatica.
Impostazione predefinita: non applicabile
|
Any value specified for this option is ignored.
|
|
celery.worker_autoscale
La concorrenza delle attività per i lavoratori.
Valori predefiniti:
mw1.micro - 3,0 mw1. piccolo - 5,0 mw1.medio - 10,0 mw1. grande - 20,0 mw1.xlarge - 40,0 mw1.2xlarge - 80,0
|
Utilizzate questa opzione per liberare risorse riducendo la concorrenza delle attività dei maximum lavoratori. minimum I lavoratori accettano fino alle attività maximum simultanee configurate, indipendentemente dal fatto che vi siano risorse sufficienti per eseguirle. Se le attività vengono 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 valori inferiori a quelli predefiniti per consentire una maggiore capacità per attività.
|
- Apache Airflow v2
-
| Configurazione |
Caso d’uso |
|
core.parallelism
Il numero massimo di istanze di attività che ogni scheduler può monitorare ed eseguire contemporaneamente.
Predefinito: impostato dinamicamente in base a. (maxWorkers * maxCeleryWorkers) / schedulers * 1.5
|
Usa questa opzione per controllare il limite massimo globale del totale delle attività in esecuzione. Ad esempio, potete aumentare questo valore per proteggere il metadatabase da troppe connessioni simultanee o per limitare i costi. Il valore predefinito è elevatoworker_autoscale, in modo che altri controlli (slot del poolmax_active_tasks_per_dag) fungano da limiti effettivi di concorrenza.
|
|
core.dag_concurrency
Il numero di istanze di attività che possono essere eseguite contemporaneamente per ogni DAG.
Predefinito: 16
Questa configurazione è obsoleta a partire da Airflow 2.2.0 ed è stata sostituita da. core.max_active_tasks_per_dag
|
Utilizzate questa opzione per liberare risorse aumentando il numero di istanze di attività che possono essere eseguite contemporaneamente. Ad esempio, se hai 100 DAG con 10 attività parallele e desideri che tutti i DAG vengano eseguiti contemporaneamente, calcola il parallelismo massimo. Moltiplica il numero di lavoratori disponibili per la densità di attività incelery.worker_concurrency, quindi dividi per il numero di DAG.
|
|
core.execute_tasks_new_python_interpreter
Determina se Apache Airflow esegue le attività eseguendo il fork del processo principale o creando un nuovo processo Python.
Default: True
|
Se impostato suTrue, Apache Airflow riconosce le modifiche apportate ai plug-in come un nuovo processo Python creato per eseguire le attività.
|
|
celery.worker_concurrency
Amazon MWAA sostituisce l'installazione di base di Airflow per questa opzione per scalare i lavoratori come parte del suo componente di scalabilità automatica.
Impostazione predefinita: non applicabile
|
Any value specified for this option is ignored.
|
|
celery.worker_autoscale
La concorrenza delle attività per i lavoratori.
Valori predefiniti:
mw1.micro - 3,0 mw1. piccolo - 5,0 mw1.medio - 10,0 mw1. grande - 20,0 mw1.xlarge - 40,0 mw1.2xlarge - 80,0
|
Utilizzate questa opzione per liberare risorse riducendo la concorrenza delle attività dei maximum lavoratori. minimum I lavoratori accettano fino alle attività maximum simultanee configurate, indipendentemente dal fatto che vi siano risorse sufficienti per eseguirle. Se le attività vengono 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 quelli predefiniti per consentire una maggiore capacità per attività.
|
