Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Prácticas recomendadas para el uso de Amazon Managed Workflows para Apache Airflow
En esta guía se describen las prácticas recomendadas para utilizar Amazon Managed Workflows para Apache Airflow.
**Topics**
+ [Ajuste del desempeño de Apache Airflow en Amazon MWAA](best-practices-tuning.md)
+ [Administración de las dependencias de Python en requirements.txt](best-practices-dependencies.md)
# Ajuste del desempeño de Apache Airflow en Amazon MWAA
En esta página, se describe cómo ajustar el rendimiento de un entorno de Amazon Managed Workflows para Apache Airflow mediante [Uso de las opciones de configuración de Apache Airflow en Amazon MWAA](configuring-env-variables.md).
**Contents**
+ [Adición de una opción de configuración de Apache Airflow](#best-practices-tuning-console-add)
+ [Programador de Apache Airflow](#best-practices-tuning-scheduler)
+ [Parameters](#best-practices-tuning-scheduler-params)
+ [Límites](#best-practices-tuning-scheduler-limits)
+ [Carpetas de los DAG](#best-practices-tuning-dag-folders)
+ [Parameters](#best-practices-tuning-dag-folders-params)
+ [Archivos DAG](#best-practices-tuning-dag-files)
+ [Parameters](#best-practices-tuning-dag-files-params)
+ [Tareas](#best-practices-tuning-tasks)
+ [Parameters](#best-practices-tuning-tasks-params)
## Adición de una opción de configuración de Apache Airflow
Siga los siguientes pasos para agregar una opción de configuración de Apache Airflow a su entorno.
1. Abra la página [Entornos](https://console.aws.amazon.com/mwaa/home#/environments) en la consola de Amazon MWAA.
1. Seleccione un entorno.
1. Elija **Editar**.
1. Elija **Siguiente**.
1. Seleccione **Agregar configuración personalizada** en el panel **Opciones de configuración de Airflow**.
1. En la lista desplegable, elija una opción de configuración e introduzca un valor. También puede escribir una configuración personalizada e introducir un valor.
1. Seleccione **Agregar configuración personalizada** para cada configuración que desee agregar.
1. Seleccione **Save**.
Consulte [Uso de las opciones de configuración de Apache Airflow en Amazon MWAA](configuring-env-variables.md) para obtener más información.
## Programador de Apache Airflow
El programador de Apache Airflow es un componente básico de Apache Airflow. Un problema con el programador puede DAGs impedir que se analicen y que las tareas se programen. Para obtener más información sobre cómo ajustar el programador de Apache Airflow, consulte cómo [ajustar el funcionamiento del programador](https://airflow.apache.org/docs/apache-airflow/2.2.2/concepts/scheduler.html#fine-tuning-your-scheduler-performance) en el sitio web de documentación de Apache Airflow.
### Parameters
En esta sección, se describen las opciones de configuración disponibles para el programador de Apache Airflow (Apache Airflow v2 y versiones posteriores) y sus casos de uso.
------
#### [ Apache Airflow v3 ]
| Configuración | Caso de uso |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Cantidad de procesos que utiliza el ejecutor Celery para sincronizar el estado de las tareas. **Valor predeterminado**: 1 | Esta opción puede utilizarse para evitar conflictos en las colas ya que limita los procesos que utiliza el ejecutor Celery. De forma predeterminada, se establece un valor para evitar errores `1` al enviar los registros de tareas a CloudWatch los registros. Si se emplea el valor `0`, se estará usando la cantidad máxima de procesos, lo que podría provocar errores al entregar los registros de tareas. |
| **[scheduler.scheduler\$1idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#scheduler-idle-sleep-time)** Cantidad de segundos que debe esperar entre procesamientos consecutivos de archivos DAG en el “bucle” del programador. **Valor predeterminado**: 1 | Se puede usar esta opción para reducir el uso de la CPU por parte del programador **aumentando** el tiempo de inactividad del programador una vez que haya terminado de recuperar los resultados del análisis de los DAG, de buscar las tareas y ponerlas en cola y de ejecutar las tareas en cola en el *ejecutor*. Al aumentar este valor, se consume la cantidad de hilos del programador que se ejecutan en un entorno en `dag_processor.parsing_processes` en el caso de Apache Airflow v2 y v3. Esto puede reducir la capacidad de análisis DAGs de los programadores y aumentar el tiempo que tardan en DAGs rellenarse en el servidor web. |
| **[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)** El número máximo que se debe DAGs crear *DagRuns*por «bucle» del programador. **Valor predeterminado**: 10 | Puede usar esta opción para liberar recursos para programar tareas **reduciendo** el número máximo del *DagRuns*«bucle» del planificador. |
| **[dag\$1processor.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parsing-processes)** El número de subprocesos que el programador puede ejecutar en paralelo para programar DAGs. **De forma predeterminada:** use `(2 * number of vCPUs) - 1` | Puede usar esta opción para liberar recursos **reduciendo** el número de procesos que el programador ejecuta en paralelo para DAGs analizarlos. Recomendamos utilizar una cantidad baja si el análisis de los DAG afecta a la programación de tareas. **Debe especificar** un valor inferior al recuento de la CPU virtual (vCPU) de su entorno. Consulte los [límites](#best-practices-tuning-scheduler-limits) para obtener más información. |
------
#### [ Apache Airflow v2 ]
| Configuración | Caso de uso |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Cantidad de procesos que utiliza el ejecutor Celery para sincronizar el estado de las tareas. **Valor predeterminado**: 1 | Esta opción puede utilizarse para evitar conflictos en las colas ya que limita los procesos que utiliza el ejecutor Celery. De forma predeterminada, se establece un valor para evitar errores `1` al enviar los registros de tareas a los CloudWatch registros. Si se emplea el valor `0`, se estará usando la cantidad máxima de procesos, lo que podría provocar errores al entregar los registros de tareas. |
| **[scheduler.idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#scheduler-idle-sleep-time)** Cantidad de segundos que debe esperar entre procesamientos consecutivos de archivos DAG en el “bucle” del programador. **Valor predeterminado**: 1 | Se puede usar esta opción para reducir el uso de la CPU por parte del programador **aumentando** el tiempo de inactividad del programador una vez que haya terminado de recuperar los resultados del análisis de los DAG, de buscar las tareas y ponerlas en cola y de ejecutar las tareas en cola en el *ejecutor*. Al aumentar este valor, se consume la cantidad de hilos del programador que se ejecutan en un entorno en `scheduler.parsing_processes` en el caso de Apache Airflow v2 y v3. Esto puede reducir la capacidad de análisis DAGs de los programadores y aumentar el tiempo que tardan en DAGs rellenarse en el servidor web. |
| **[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)** El número máximo que se debe DAGs crear *DagRuns*por «bucle» del programador. **Valor predeterminado**: 10 | Puede usar esta opción para liberar recursos para programar tareas **reduciendo** el número máximo del *DagRuns*«bucle» del planificador. |
| **[scheduler.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes)** El número de subprocesos que el programador puede ejecutar en paralelo para programar DAGs. **De forma predeterminada:** use `(2 * number of vCPUs) - 1` | Puede usar esta opción para liberar recursos **reduciendo** el número de procesos que el programador ejecuta en paralelo para DAGs analizarlos. Recomendamos utilizar una cantidad baja si el análisis de los DAG afecta a la programación de tareas. **Debe especificar** un valor inferior al recuento de la CPU virtual (vCPU) de su entorno. Consulte los [límites](#best-practices-tuning-scheduler-limits) para obtener más información. |
------
### Límites
En esta sección, se describen los límites que debe tener en cuenta al ajustar los parámetros predeterminados del programador.
**scheduler.parsing\$1processes, scheduler.max\$1threads (solo para la versión 2)**
Se permiten dos hilos por vCPU en cada clase de entorno. Reserve al menos un hilo para el programador en cada clase de entorno. Si nota un retraso en la programación de las tareas, es posible que deba aumentar su [clase de entorno](environment-class.md). Por ejemplo, un entorno grande tendrá una instancia de contenedor de Fargate de 4 vCPU para el programador. Esto significa que hay un máximo de `7` hilos disponibles en total para que los utilicen otros procesos. Es decir, dos subprocesos multiplicados por cuatro vCPUs, menos uno para el propio programador. Tal como se muestra a continuación, el valor que especifique en `scheduler.max_threads` (solo para la versión 2) y en `scheduler.parsing_processes` no debe ser superior a la cantidad de hilos que tenga disponibles en una clase de entorno.
+ **mw1.small**: no debe destinarse más de `1` hilo al resto de procesos. El hilo restante debe reservarse para el programador.
+ **mw1.medium**: no deben destinarse más de `3` hilos al resto de procesos. El hilo restante debe reservarse para el programador.
+ **mw1.large**: no deben destinarse más de `7` hilos al resto de procesos. El hilo restante debe reservarse para el programador.
## Carpetas de los DAG
El programador de Apache Airflow escanea continuamente la DAGs carpeta de su entorno. en busca de cualquier archivo que contenga `plugins.zip`, o cualquier archivo Python (`.py`) que contenga en sus instrucciones de importación la palabra “airflow”. A continuación, todos los objetos DAG de Python resultantes se colocan en un archivo *DagBag*para que el planificador los procese y determine qué tareas, si las hay, deben programarse. El análisis de los archivos DAG se realiza independientemente de si los archivos contienen objetos DAG viables o no.
### Parameters
En esta sección se describen las opciones de configuración disponibles para la DAGs carpeta (Apache Airflow v2 y versiones posteriores) y sus casos de uso.
------
#### [ Apache Airflow v3 ]
| Configuración | Caso de uso |
| --- | --- |
| **[dag\$1processor.refresh\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#config-dag-processor-refresh-interval)** El número de segundos que debe escanearse la DAGs carpeta en busca de nuevos archivos. **Valor predeterminado:** 300 segundos | Puede utilizar esta opción para liberar recursos **aumentando** el número de segundos necesarios para analizar la DAGs carpeta. Se recomienda aumentar este valor si los tiempos de análisis son prolongados`total_parse_time metrics`, lo que puede deberse a la gran cantidad de archivos de la DAGs carpeta. |
| **[dag\$1processor.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-file-process-interval)** Cantidad de segundos que transcurren desde que el programador analiza un DAG hasta que se reflejan las actualizaciones del mismo. **Valor predeterminado:** 30 segundos | Esta opción puede utilizarse para liberar recursos **aumentando** la cantidad de segundos que el programador espera antes de analizar un DAG. Por ejemplo, si especifica un valor de `30`, el archivo DAG se analizará cada 30 segundos. Recomendamos mantener elevado dicho valor para reducir el uso de la CPU en su entorno. |
------
#### [ Apache Airflow v2 ]
| Configuración | Caso de uso |
| --- | --- |
| **[scheduler.dag\$1dir\$1list\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-dir-list-interval)** El número de segundos que debe escanearse la DAGs carpeta en busca de archivos nuevos. **Valor predeterminado:** 300 segundos | Puede utilizar esta opción para liberar recursos **aumentando** el número de segundos necesarios para analizar la DAGs carpeta. Se recomienda aumentar este valor si los tiempos de análisis son prolongados`total_parse_time metrics`, lo que puede deberse a la gran cantidad de archivos de la DAGs carpeta. |
| **[scheduler.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-file-process-interval)** Cantidad de segundos que transcurren desde que el programador analiza un DAG hasta que se reflejan las actualizaciones del mismo. **Valor predeterminado:** 30 segundos | Esta opción puede utilizarse para liberar recursos **aumentando** la cantidad de segundos que el programador espera antes de analizar un DAG. Por ejemplo, si especifica un valor de `30`, el archivo DAG se analizará cada 30 segundos. Recomendamos mantener elevado dicho valor para reducir el uso de la CPU en su entorno. |
------
## Archivos DAG
Como parte del bucle del programador de Apache Airflow, los archivos DAG individuales se analizan para extraer los objetos DAG en Python. En Apache Airflow v2 y versiones posteriores, el programador analiza simultáneamente un número máximo de [procesos de análisis](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes). Para que se vuelva a analizar el mismo archivo, deben transcurrir primero los segundos especificados en `scheduler.min_file_process_interval` (versión 2) o en `dag_processor.min_file_process_interval` (versión 3).
### Parameters
En esta sección, se describen las opciones de configuración disponibles para los archivos DAG de Apache Airflow (Apache Airflow v2 y versiones posteriores) y sus casos de uso.
------
#### [ Apache Airflow v3 ]
| Configuración | Caso de uso |
| --- | --- |
| **[dag\$1processor.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dag-file-processor-timeout)** El número de segundos antes de que se agote el *DagFileProcessor*tiempo de espera para procesar un archivo DAG. **Valor predeterminado:** 50 segundos | Puede utilizar esta opción para liberar recursos **aumentando** el tiempo que tarda en agotarse el *DagFileProcessor*tiempo de espera. Se recomienda aumentar este valor si se producen tiempos de espera en los registros de procesamiento del DAG que impidan cargarlos de forma viable DAGs . |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dagbag-import-timeout)** Cantidad segundos que transcurren antes de que se interrumpe la importación de un archivo en Python. **Valor predeterminado:** 30 segundos | Se puede usar esta opción para liberar recursos **aumentando** el tiempo que transcurre hasta que el programador interrumpe la importación de un archivo en Python para extraer los objetos DAG. Esta opción se procesa como parte del “bucle” del programador y debe incluir un valor inferior al especificado en `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)** El número mínimo de segundos tras los que se actualizan los serializados DAGs en la base de datos. **Predeterminado: 30** | Puede utilizar esta opción para liberar recursos **aumentando** el número de segundos tras los que se actualizan los serializados DAGs en la base de datos. Le recomendamos que aumente este valor si tiene un número grande de DAGs ellos o si es complejo DAGs. Al aumentar este valor, se reduce la carga del programador y la base de datos a medida que DAGs se serializan. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-fetch-interval)** El número de segundos en que se recupera un DAG serializado de la base de datos cuando ya está cargado en la. DagBag **Valor predeterminado**: 10 | Esta opción puede utilizarse para liberar recursos **aumentando** la cantidad de segundos que se tarda en volver a extraer un DAG serializado. El valor debe ser superior al valor especificado en `core.min_serialized_dag_update_interval` para reducir las tasas de “escritura” de la base de datos. Al aumentar este valor, se reduce la carga en el servidor web y la base de datos a medida que se serializan. DAGs |
------
#### [ Apache Airflow v2 ]
| Configuración | Caso de uso |
| --- | --- |
| **[core.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-file-processor-timeout)** El número de segundos antes de que se agote el *DagFileProcessor*tiempo de espera para procesar un archivo DAG. **Valor predeterminado:** 50 segundos | Puede utilizar esta opción para liberar recursos **aumentando** el tiempo que tarda en agotarse el *DagFileProcessor*tiempo de espera. Se recomienda aumentar este valor si se producen tiempos de espera en los registros de procesamiento del DAG que impidan cargarlos de forma viable DAGs . |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dagbag-import-timeout)** Cantidad segundos que transcurren antes de que se interrumpe la importación de un archivo en Python. **Valor predeterminado:** 30 segundos | Se puede usar esta opción para liberar recursos **aumentando** el tiempo que transcurre hasta que el programador interrumpe la importación de un archivo en Python para extraer los objetos DAG. Esta opción se procesa como parte del “bucle” del programador y debe incluir un valor inferior al especificado en `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)** El número mínimo de segundos tras los que se actualizan los serializados DAGs en la base de datos. **Predeterminado: 30** | Puede utilizar esta opción para liberar recursos **aumentando** el número de segundos tras los que se actualizan los serializados DAGs en la base de datos. Le recomendamos que aumente este valor si tiene un número grande de DAGs ellos o si es complejo DAGs. Al aumentar este valor, se reduce la carga del programador y la base de datos a medida que DAGs se serializan. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-fetch-interval)** El número de segundos en que se recupera un DAG serializado de la base de datos cuando ya está cargado en la. DagBag **Valor predeterminado**: 10 | Esta opción puede utilizarse para liberar recursos **aumentando** la cantidad de segundos que se tarda en volver a extraer un DAG serializado. El valor debe ser superior al valor especificado en `core.min_serialized_dag_update_interval` para reducir las tasas de “escritura” de la base de datos. Al aumentar este valor, se reduce la carga en el servidor web y la base de datos a medida que se serializan. DAGs |
------
## Tareas
Tanto el programador como los procesos de trabajo de Apache Airflow intervienen en la puesta de tareas en la cola y en su retirada de la misma. El programador toma las tareas analizadas que ya están a punto para ser programadas y modifica su estado de **Ninguno** a **Programado**. El ejecutor, que también se ejecuta en el contenedor del programador de Fargate, pone esas tareas en cola y cambia su estado a **En cola**. Cuando los procesos de trabajo tengan capacidad para ello, tomarán la tarea de la cola y cambiarán su estado a **En ejecución**, que posteriormente cambiará a **Correcto** o **Error** en función de si se ha logrado llevar a cabo la tarea correctamente o si algo ha fallado.
### Parameters
En esta sección se describen las opciones de configuración disponibles para las tareas de Apache Airflow y sus casos de uso.
Las opciones de configuración predeterminadas que Amazon MWAA anula están marcadas. *red*
------
#### [ Apache Airflow v3 ]
| Configuración | Caso de uso |
| --- | --- |
| **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Cantidad máxima de instancias de tareas que pueden tener el estado `Running`. **Valor predeterminado:** Se establece dinámicamente en función de `(maxWorkers * maxCeleryWorkers) / schedulers * 1.5`. | Esta opción puede utilizarse para liberar recursos **aumentando** la cantidad de instancias de tareas que se pueden ejecutar simultáneamente. El valor que se especifique debe ser igual al número de procesos de trabajo disponibles por la densidad de tareas de los procesos de trabajo. Recomendamos cambiar este valor únicamente cuando haya una gran cantidad de tareas atascadas en los estados de ejecución o de cola. |
| **[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 si Apache Airflow ejecuta tareas mediante la bifurcación del proceso principal o la creación de un nuevo proceso de Python. **Valor predeterminado**: `True` | Cuando este parámetro esté establecido en `True`, Apache Airflow reconocerá los cambios que realice en sus complementos como un nuevo proceso en Python creado para ejecutar tareas. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA anula la instalación base de Airflow para que esta opción escale procesos de trabajo como parte de su componente de escalado automático. **Valor predeterminado:** No corresponde | *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)** Simultaneidad de tareas de los procesos de trabajo. **Valores predeterminados:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/mwaa/latest/userguide/best-practices-tuning.html) | Se puede usar esta opción para liberar recursos **reduciendo** la simultaneidad `minimum` y `maximum` de tareas de los procesos de trabajo. Los trabajadores aceptan hasta las tareas `maximum` simultáneas configuradas, independientemente de si disponen de recursos suficientes para realizarlas. Si las tareas se programan sin que haya recursos suficientes, se producirá un error de inmediato. Recomendamos cambiar este valor en el caso de que las tareas consuman muchos recursos; reduzca los valores por debajo de los valores predeterminados para que haya una mayor capacidad por tarea. |
------
#### [ Apache Airflow v2 ]
| Configuración | Caso de uso |
| --- | --- |
| **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Cantidad máxima de instancias de tareas que pueden tener el estado `Running`. **Valor predeterminado:** Se establece dinámicamente en función de `(maxWorkers * maxCeleryWorkers) / schedulers * 1.5`. | Esta opción puede utilizarse para liberar recursos **aumentando** la cantidad de instancias de tareas que se pueden ejecutar simultáneamente. El valor que se especifique debe ser igual al número de procesos de trabajo disponibles por la densidad de tareas de los procesos de trabajo. Recomendamos cambiar este valor únicamente cuando haya una gran cantidad de tareas atascadas en los estados de ejecución o de cola. |
| **[core.dag\$1concurrency](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-concurrency)** Cantidad de instancias de tareas que se pueden ejecutar simultáneamente para cada DAG. **Predeterminado: 10000** | Esta opción puede utilizarse para liberar recursos **aumentando** la cantidad de instancias de tareas que pueden ejecutarse simultáneamente. Por ejemplo, si tiene cien tareas paralelas DAGs con diez y quiere que todas DAGs se ejecuten simultáneamente, puede calcular el paralelismo máximo como el número de trabajadores disponibles multiplicado por la densidad de tareas de los trabajadores dividido por el `celery.worker_concurrency` número de. 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 si Apache Airflow ejecuta tareas mediante la bifurcación del proceso principal o la creación de un nuevo proceso de Python. **Valor predeterminado**: `True` | Cuando este parámetro esté establecido en `True`, Apache Airflow reconocerá los cambios que realice en sus complementos como un nuevo proceso en Python creado para ejecutar tareas. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA anula la instalación base de Airflow para que esta opción escale procesos de trabajo como parte de su componente de escalado automático. **Valor predeterminado:** No corresponde | *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)** Simultaneidad de tareas de los procesos de trabajo. **Valores predeterminados:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/mwaa/latest/userguide/best-practices-tuning.html) | Se puede usar esta opción para liberar recursos **reduciendo** la simultaneidad `minimum` y `maximum` de tareas de los procesos de trabajo. Los trabajadores aceptan hasta las tareas `maximum` simultáneas configuradas, independientemente de si hay recursos suficientes para realizarlas. Si las tareas se programan sin que haya recursos suficientes, se producirá un error de inmediato. Recomendamos cambiar este valor en el caso de que las tareas consuman muchos recursos; reduzca los valores por debajo de los valores predeterminados para que haya una mayor capacidad por tarea. |
------
# Administración de las dependencias de Python en requirements.txt
En esta página, se describe cómo instalar y administrar las dependencias de Python en un archivo `requirements.txt` para entornos de Amazon Managed Workflows para Apache Airflow.
**Contents**
+ [Pruebas DAGs con la utilidad CLI Amazon MWAA](#best-practices-dependencies-cli-utility)
+ [Instalación de dependencias de Python mediante el formato de archivo de requisitos PyPi .org](#best-practices-dependencies-different-ways)
+ [Opción uno: dependencias de Python desde el Índice de paquetes de Python](#best-practices-dependencies-pip-extras)
+ [Opción dos: archivos wheels de Python (.whl)](#best-practices-dependencies-python-wheels)
+ [Uso del archivo `plugins.zip` en un bucket de Amazon S3](#best-practices-dependencies-python-wheels-s3)
+ [Uso de archivos WHL alojados en una URL](#best-practices-dependencies-python-wheels-url)
+ [Creación de archivos WHL a partir de DAG](#best-practices-dependencies-python-wheels-dag)
+ [Opción tres: dependencias de Python alojadas en un repositorio privado compatible con PyPi /PEP-503](#best-practices-dependencies-custom-auth-url)
+ [Habilitación de registros en la consola de Amazon MWAA](#best-practices-dependencies-troubleshooting-enable)
+ [Acceder a los registros en la consola de Logs CloudWatch](#best-practices-dependencies-troubleshooting-view)
+ [Visualización de los errores en la UI de Apache Airflow](#best-practices-dependencies-troubleshooting-aa)
+ [Inicio de sesión en Apache Airflow](#airflow-access-and-login)
+ [Ejemplos de escenarios de `requirements.txt`](#best-practices-dependencies-ex-mix-match)
## Pruebas DAGs con la utilidad CLI Amazon MWAA
+ La utilidad de la interfaz de la línea de comandos (CLI) replica entornos en Amazon Managed Workflows para Apache Airflow de forma local.
+ La CLI crea localmente una imagen de contenedor de Docker similar a una imagen de producción de Amazon MWAA. Puede usarlo para ejecutar un entorno local de Apache Airflow para desarrollar y probar DAGs complementos personalizados y dependencias antes de implementarlos en Amazon MWAA.
+ Para ejecutar la CLI, consulte [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)on GitHub.
## Instalación de dependencias de Python mediante el formato de archivo de requisitos PyPi .org
La siguiente sección describe las diferentes formas de instalar las dependencias de Python según el [formato de archivo de requisitos](https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format) de PyPi .org.
### Opción uno: dependencias de Python desde el Índice de paquetes de Python
La siguiente sección describe cómo especificar las dependencias de Python desde el [Python Package Index](https://pypi.org/) en un archivo `requirements.txt`.
------
#### [ Apache Airflow v3 ]
1. **Hacer una prueba local**. Añada bibliotecas adicionales de forma iterativa para encontrar la combinación adecuada de paquetes y sus versiones antes de crear un archivo `requirements.txt`. Para ejecutar la utilidad CLI Amazon MWAA, consulte en. [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images) GitHub
1. **Revise los extras del paquete Apache Airflow**. Para acceder a una lista de los paquetes instalados para Apache Airflow v3 en Amazon MWAA, consulte el sitio web. [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt) GitHub
1. **Añada instrucciones respecto a las restricciones.** Añada el archivo de restricciones para su entorno Apache Airflow v3 en la parte superior del archivo. `requirements.txt` Los archivos de restricciones de Apache Airflow especifican las versiones de proveedores disponibles en el momento de la publicación de Apache Airflow.
En el siguiente ejemplo, sustituya *\$1environment-version\$1* por el número de versión de su entorno y, *\$1Python-version\$1*, por la versión de Python compatible con su entorno.
Para obtener información sobre la versión de Python compatible con su entorno de Apache Airflow, consulte las [versiones de Apache Airflow](airflow-versions.md#airflow-versions-official).
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Si el archivo de restricciones determina que el paquete `xyz==1.0` no es compatible con otros paquetes de su entorno, `pip3 install` no podrá impedir que se instalen bibliotecas incompatibles en su entorno. Si se produce un error en la instalación de algún paquete, puede acceder a los registros de errores de cada componente de Apache Airflow (el programador, el equipo de trabajo y el servidor web) en el flujo de registros correspondiente en Logs. CloudWatch Para obtener más información sobre los tipos de registros, consulte [Acceder a los registros de Airflow en Amazon CloudWatch](monitoring-airflow.md).
1. **Paquetes de Apache Airflow.** Añada los [extras del paquete](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) y la versión (`==`). Esto ayuda a evitar que se instalen en su entorno paquetes del mismo nombre, pero de una versión diferente.
```
apache-airflow[package-extra]==2.5.1
```
1. **Bibliotecas Python**. Añada el nombre del paquete y la versión (`==`) al archivo `requirements.txt`. Esto ayuda a evitar que se aplique automáticamente una futura actualización de última hora de [PyPi.org](https://pypi.org).
```
library == version
```
**Example Boto3 y psycopg2-binary**
Este caso se proporciona como ejemplo. Las bibliotecas boto y psycopg2-binary vienen incluidas en la instalación base de Apache Airflow v3, por lo que no es necesario especificarlas en un archivo `requirements.txt`.
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Si se especifica un paquete sin una versión, Amazon MWAA instala la última versión del paquete desde .org. PyPi](https://pypi.org) Esta versión puede entrar en conflicto con otros paquetes de su `requirements.txt`.
------
#### [ Apache Airflow v2 ]
1. **Hacer una prueba local**. Añada bibliotecas adicionales de forma iterativa para encontrar la combinación adecuada de paquetes y sus versiones antes de crear un archivo `requirements.txt`. Para ejecutar la utilidad CLI Amazon MWAA, consulte en. [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images) GitHub
1. **Revise los extras del paquete Apache Airflow**. Para acceder a una lista de los paquetes instalados para Apache Airflow v2 en Amazon MWAA, visite el sitio web. [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt) GitHub
1. **Añada instrucciones respecto a las restricciones.** Añada el archivo de restricciones para su entorno Apache Airflow v2 en la parte superior del archivo `requirements.txt`. Los archivos de restricciones de Apache Airflow especifican las versiones de proveedores disponibles en el momento de la publicación de Apache Airflow.
A partir de la versión 2.7.2 de Apache Airflow, su archivo de requisitos debe incluir una instrucción `--constraint`. Si no proporciona ninguna restricción, Amazon MWAA especificará una para garantizar que los paquetes que figuran en sus requisitos sean compatibles con la versión de Apache Airflow que utilice.
En el siguiente ejemplo, sustituya *\$1environment-version\$1* por el número de versión de su entorno y, *\$1Python-version\$1*, por la versión de Python compatible con su entorno.
Para obtener información sobre la versión de Python compatible con su entorno de Apache Airflow, consulte las [versiones de Apache Airflow](airflow-versions.md#airflow-versions-official).
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Si el archivo de restricciones determina que el paquete `xyz==1.0` no es compatible con otros paquetes de su entorno, `pip3 install` no podrá impedir que se instalen bibliotecas incompatibles en su entorno. Si se produce un error en la instalación de algún paquete, puede acceder a los registros de errores de cada componente de Apache Airflow (el programador, el equipo de trabajo y el servidor web) en el flujo de registros correspondiente en Logs. CloudWatch Para obtener más información sobre los tipos de registros, consulte [Acceder a los registros de Airflow en Amazon CloudWatch](monitoring-airflow.md).
1. **Paquetes de Apache Airflow.** Añada los [extras del paquete](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) y la versión (`==`). Esto ayuda a evitar que se instalen en su entorno paquetes del mismo nombre, pero de una versión diferente.
```
apache-airflow[package-extra]==2.5.1
```
1. **Bibliotecas Python**. Añada el nombre del paquete y la versión (`==`) al archivo `requirements.txt`. Esto ayuda a evitar que se aplique automáticamente una futura actualización de última hora de [PyPi.org](https://pypi.org).
```
library == version
```
**Example Boto3 y psycopg2-binary**
Este caso se proporciona como ejemplo. Las bibliotecas boto y psycopg2-binary vienen incluidas en la instalación base de Apache Airflow v2, por lo que no es necesario especificarlas en un archivo `requirements.txt`.
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Si se especifica un paquete sin una versión, Amazon MWAA instala la última versión del paquete desde .org. PyPi](https://pypi.org) Esta versión puede entrar en conflicto con otros paquetes de su `requirements.txt`.
------
### Opción dos: archivos wheels de Python (.whl)
El formato wheel de Python es un tipo de paquete diseñado para enviar bibliotecas con artefactos compilados. Los paquetes wheel presentan varias ventajas si se utilizan como método para instalar dependencias en Amazon MWAA:
+ **Instalación más rápida**: los archivos WHL se copian en el contenedor como un único ZIP y se instalan de forma local, sin necesidad de descargarlos uno por uno.
+ **Menos conflictos**: se puede determinar con antelación la compatibilidad de las versiones de los paquetes. De esta manera, no es necesario que `pip` elabore de forma recurrente versiones compatibles.
+ **Mayor resiliencia**: si las bibliotecas se alojan externamente, es posible que los requisitos posteriores cambien con el tiempo, lo que provocará que las versiones sean incompatibles entre los contenedores de un entorno de Amazon MWAA. Al no depender de una fuente externa para las dependencias, todos los contenedores tienen las mismas bibliotecas, independientemente de cuándo se instancie cada contenedor.
Recomendamos seguir los métodos que se indican a continuación para instalar las dependencias de Python en su `requirements.txt` desde un archivo wheel de Python (`.whl`).
**Topics**
+ [Uso del archivo `plugins.zip` en un bucket de Amazon S3](#best-practices-dependencies-python-wheels-s3)
+ [Uso de archivos WHL alojados en una URL](#best-practices-dependencies-python-wheels-url)
+ [Creación de archivos WHL a partir de DAG](#best-practices-dependencies-python-wheels-dag)
#### Uso del archivo `plugins.zip` en un bucket de Amazon S3
El programador de Apache Airflow, los trabajadores y el servidor web (para Apache Airflow v2.2.2 y versiones posteriores) buscan complementos personalizados durante el inicio en el contenedor Fargate administrado AWS para su entorno en. `/usr/local/airflow/plugins/*` Este proceso comienza antes del `pip3 install -r requirements.txt` de Amazon MWAA para las dependencias de Python y del inicio del servicio Apache Airflow. Un `plugins.zip` archivo se puede utilizar para cualquier archivo que no desee que se modifique de forma continua durante la ejecución del entorno o para el que no desee conceder acceso a los usuarios que escriben. DAGs Por ejemplo, archivos wheel de la biblioteca Python, archivos PEM de certificados y archivos YAML de configuración.
En la siguiente sección se describe cómo instalar wheels del archivo `plugins.zip` de su bucket de Amazon S3.
1. **Descargue los archivos WHL necesarios**. Puede utilizarlos [https://pip.pypa.io/en/stable/cli/pip_download/](https://pip.pypa.io/en/stable/cli/pip_download/)con los que ya tiene `requirements.txt` en el Amazon MWAA [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)u otro contenedor de [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2) para resolver y descargar los archivos de rueda de Python necesarios.
```
pip3 download -r "$AIRFLOW_HOME/dags/requirements.txt" -d "$AIRFLOW_HOME/plugins"
cd "$AIRFLOW_HOME/plugins"
zip "$AIRFLOW_HOME/plugins.zip" *
```
1. **Especifique la ruta en su `requirements.txt`**. Especifique el directorio de complementos al principio de su archivo requirements.txt con [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 indique a `pip` que instale desde otras fuentes con [https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index](https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index), tal y como se muestra en el siguiente código:
```
--find-links /usr/local/airflow/plugins
--no-index
```
**Example Ejemplo de wheel en el archivo requirements.txt**
En el siguiente ejemplo, se supone que ha cargado el wheel en un archivo `plugins.zip` en la raíz de su bucket de Amazon S3. Por ejemplo:
```
--find-links /usr/local/airflow/plugins
--no-index
numpy
```
Amazon MWAA extrae el wheel `numpy-1.20.1-cp37-cp37m-manylinux1_x86_64.whl` de la carpeta de `plugins` y lo instala en su entorno.
#### Uso de archivos WHL alojados en una URL
En la siguiente sección se describe cómo instalar un archivo wheel alojado en una URL. La URL debe ser de acceso público o se debe poder acceder a ella desde la VPC de Amazon personalizada que especificó para su entorno de Amazon MWAA.
+ **Indique una URL**. Indique la URL en la que se encuentra el archivo wheel en su `requirements.txt`.
**Example archivo wheel en una URL pública**
En el siguiente ejemplo, se puede ver cómo se descarga un archivo wheel de un sitio web público.
```
--find-links https://files.pythonhosted.org/packages/
--no-index
```
Amazon MWAA obtiene el archivo wheel de la URL que había especificado y lo instala en su entorno.
**nota**
URLs no se puede acceder a ellos desde servidores web privados (requisitos de instalación en Amazon MWAA v2.2.2 y versiones posteriores).
#### Creación de archivos WHL a partir de DAG
Si dispone de un servidor web privado con Apache Airflow v2.2.2 o versiones posteriores y no puede instalar los requisitos porque su entorno no tiene acceso a repositorios externos, puede usar el siguiente DAG para tomar sus requisitos actuales de Amazon MWAA y empaquetarlos en 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}"
)
```
Después de ejecutar el DAG, utilice este nuevo archivo como su `plugins.zip` de Amazon MWAA. Si lo desea, puede empaquetarlo con otros complementos. A continuación, actualice su `requirements.txt` que comienza por `--find-links /usr/local/airflow/plugins` y `--no-index` sin agregar `--constraint`.
Este método le permitirá usar las mismas bibliotecas sin conexión.
### Opción tres: dependencias de Python alojadas en un repositorio privado compatible con PyPi /PEP-503
En la siguiente sección se describe cómo instalar un elemento adicional de Apache Airflow alojado en una URL privada con autenticación.
1. Añada su nombre de usuario y contraseña como [Opciones de configuración de Airflow](configuring-env-variables.md). Por ejemplo:
+ `foo.user` : `YOUR_USER_NAME`
+ `foo.pass` : `YOUR_PASSWORD`
1. Cree su archivo `requirements.txt`. Sustituya los marcadores de posición del ejemplo que sigue por su URL privada e introduzca el nombre de usuario y la contraseña que haya añadido como [Opciones de configuración de Airflow](configuring-env-variables.md). Por ejemplo:
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
```
1. En caso aplicable, añada las bibliotecas adicionales a su archivo `requirements.txt`. Por ejemplo:
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
my-private-package==1.2.3
```
## Habilitación de registros en la consola de Amazon MWAA
La [función de ejecución](mwaa-create-role.md) de su entorno Amazon MWAA necesita permiso para enviar registros a CloudWatch Logs. Para actualizar los permisos de un rol de ejecución, consulte [Rol de ejecución de Amazon MWAA](mwaa-create-role.md).
Puede habilitar los registros de Apache Airflow en los niveles `INFO`, `WARNING`, `ERROR` o `CRITICAL`. A elegir un nivel de registro, Amazon MWAA envía los registros correspondientes a ese nivel y a todos los niveles de gravedad superiores. Por ejemplo, si habilita los registros en el `INFO` nivel, Amazon MWAA envía `INFO` los registros y `WARNING``ERROR`, y los niveles de `CRITICAL` registro a CloudWatch Logs. Recomendamos habilitar los registros de Apache Airflow en el nivel `INFO` para que el programador pueda ver los registros recibidos para el archivo `requirements.txt`.
![\[En esta imagen, se muestra cómo habilitar los registros en el nivel INFO.\]](http://docs.aws.amazon.com/es_es/mwaa/latest/userguide/images/mwaa-console-logs-info.png)
## Acceder a los registros en la consola de Logs CloudWatch
Consulte los registros de Apache Airflow correspondientes al programador encargado de organizar sus flujos de trabajo y analizar su carpeta de `dags`. En los siguientes pasos se describe cómo abrir el grupo de registros del programador en la consola de Amazon MWAA y cómo acceder a los registros de Apache Airflow en la consola Logs. CloudWatch
**Para acceder a los registros de un `requirements.txt`**
1. Abra la página [Entornos](https://console.aws.amazon.com/mwaa/home#/environments) en la consola de Amazon MWAA.
1. Seleccione un entorno.
1. Elija el **Grupo de registro del programador de Airflow** en el panel de **Monitorización**.
1. Seleccione el registro `requirements_install_ip` en los **flujos de registro**.
1. Consulte la lista de paquetes que se hayan instalado en el entorno en `/usr/local/airflow/.local/bin`. Por ejemplo:
```
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. Consulte la lista de paquetes y compruebe si se produjo algún error en alguno de ellos durante la instalación. Si se produce un error, es posible que aparezca un error similar al siguiente:
```
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))
```
## Visualización de los errores en la UI de Apache Airflow
También puede comprobar su UI de Apache Airflow para averiguar si algún error puede estar relacionado con otro problema. El error más común que puede producirse con Apache Airflow en Amazon MWAA es el siguiente:
```
Broken DAG: No module named x
```
Si ve este error en la UI de Apache Airflow, es probable que falte una dependencia obligatoria en su archivo `requirements.txt`.
### Inicio de sesión en Apache Airflow
Necesita [Política de acceso a la interfaz de usuario de Apache Airflow: Amazon MWAAWeb ServerAccess](access-policies.md#web-ui-access) permisos de entrada AWS Identity and Access Management (IAM) para acceder a la interfaz de usuario de Apache Airflow. Cuenta de AWS
**Pasos para acceder a la interfaz de usuario de Apache Airflow**
1. Abra la página [Entornos](https://console.aws.amazon.com/mwaa/home#/environments) en la consola de Amazon MWAA.
1. Seleccione un entorno.
1. Elija **Abrir interfaz de usuario de Airflow**.
## Ejemplos de escenarios de `requirements.txt`
Puede mezclar y combinar diferentes formatos en su `requirements.txt`. En el siguiente ejemplo se utiliza una combinación de las distintas formas de instalar elementos adicionales.
**Example Extras en PyPi .org y en una URL pública**
Debe usar `--index-url` esta opción al especificar paquetes de PyPi .org, además de los paquetes en una URL pública, como un repositorio URLs personalizado compatible con PEP 503.
```
aws-batch == 0.6
phoenix-letter >= 0.3
--index-url http://dist.repoze.org/zope2/2.10/simple
zopelib
```