Flujo de trabajo administrado por Amazon para Apache Airflow (Amazon MWAA) es un servicio administrado que le permite utilizar una versión familiar Flujo de aire Apache entorno con escalabilidad, disponibilidad y seguridad mejoradas para mejorar y escalar los flujos de trabajo de su negocio sin la carga operativa de administrar la infraestructura subyacente.

Hoy anunciamos la disponibilidad de los entornos Apache Airflow versión 2.7.2 y la compatibilidad con operadores diferibles en Amazon MWAA. En esta publicación, proporcionamos una descripción general de operadores diferibles y desencadenantes, que incluye un tutorial de un ejemplo que muestra cómo usarlos. También profundizamos en algunas de las nuevas características y capacidades de Apache Airflow y en cómo puede configurar o actualizar su entorno Amazon MWAA a la versión 2.7.2.

Operadores diferibles y desencadenantes

Los operadores y sensores estándar ocupan continuamente un puesto de trabajador de Airflow, independientemente de si están activos o inactivos. Por ejemplo, incluso mientras se espera que un sistema externo complete un trabajo, se consume un espacio de trabajador. El siguiente diagrama de Gantt, que representa una Gráfico acíclico dirigido (DAG), muestra este escenario a través de múltiples Desplazamiento al rojo de Amazon operaciones.

Puede ver el tiempo que cada tarea pasa inactiva mientras espera que se cree, se tome una instantánea y se ponga en pausa el clúster de Redshift. Con la introducción de operadores diferibles en Apache Airflow 2.2, el proceso de sondeo se puede descargar para garantizar la utilización eficiente del espacio de trabajo. Un operador diferible puede suspenderse y reanudarse una vez que se completa el trabajo externo, en lugar de ocupar continuamente un puesto de trabajador. Esto minimiza las tareas en cola y conduce a una utilización más eficiente de los recursos dentro de su entorno Amazon MWAA. La siguiente figura muestra un diagrama simplificado que describe el flujo del proceso.

Después de que una tarea ha aplazado su ejecución, libera el espacio de trabajo y asigna la verificación de finalización a una pequeña porción de código asincrónico llamado detonante. El disparador se ejecuta en un proceso principal llamado disparador, un servicio que ejecuta un asíncio bucle de eventos. El activador tiene la capacidad de ejecutar activadores en paralelo a escala y de indicar que las tareas se reanuden cuando se cumpla una condición.

La Paquete de proveedor de Amazon para Apache Airflow ha agregado activadores para servicios populares de AWS como Pegamento AWS y EMR de Amazon. En entornos Amazon MWAA que ejecutan Apache Airflow v2.7.2, usted se encarga de la administración y operación del servicio de activación. Si prefiere no utilizar el servicio de activación, puede cambiar la configuración mwaa.triggerer_enabled. Además, puede definir cuántos activadores puede ejecutar cada activador en paralelo utilizando el parámetro de configuración triggerer.default_capacity. Este parámetro tiene valores predeterminados basados ​​en su clase de entorno de Amazon MWAA. Referirse a Referencia de configuración en la Guía del usuario para obtener valores de configuración detallados.

Cuándo utilizar operadores diferibles

Los operadores diferibles son particularmente útiles para tareas que envían trabajos a sistemas externos a un entorno de Amazon MWAA, como Amazon EMR, AWS Glue y Amazon SageMakeru otros sensores esperando que ocurra un evento específico. Estas tareas pueden tardar de minutos a horas en completarse y son principalmente operadores inactivos, lo que los convierte en buenos candidatos para ser reemplazados por sus versiones diferibles. Algunos casos de uso adicionales incluyen:

• Operaciones basadas en sistemas de archivos.
• Operaciones de bases de datos con consultas de larga duración.

Uso de operadores diferibles en Amazon MWAA

Para utilizar operadores aplazables en Amazon MWAA, asegúrese de ejecutar Apache Airflow versión 2.7 o superior en su entorno de Amazon MWAA y de que los operadores o sensores de sus DAG admitan el aplazamiento. Los operadores del paquete de proveedores de Amazon exponen un deferrable parámetro que puede establecer en True para ejecutar el operador en modo asíncrono. Por ejemplo, puedes usar S3KeySensor en modo asincrónico de la siguiente manera:

wait_for_source_data = S3KeySensor (
task_id="WaitForSourceData",
bucket_name="source_bucket_name",
bucket_key = "object_key",
aws_conn_id="aws_default",
deferrable=True
)

También puede utilizar varios operadores diferibles prediseñados disponibles en otros paquetes de proveedores, como Copo de nieve y Databricks.

Siga el código de muestra completo en el Repositorio GitHub comprender cómo trabajan juntos los operadores diferibles. Estará construyendo y orquestando la canalización de datos ilustrada en la siguiente figura.

El oleoducto consta de tres etapas:

• Un S3KeySensor que espera a que se cargue un conjunto de datos Servicio de almacenamiento simple de Amazon (Amazon S3)
• Un rastreador de AWS Glue para clasificar objetos en el conjunto de datos y guardar esquemas en el catálogo de datos de AWS Glue
• Un trabajo de AWS Glue que utiliza los metadatos del catálogo de datos para desnormalizar el conjunto de datos de origen, crear tablas del catálogo de datos basadas en datos filtrados y escribir los datos resultantes en Amazon S3 en archivos Apache Parquet independientes.

Tareas de configuración y desmontaje

Es común crear flujos de trabajo que requieren recursos efímeros, por ejemplo, un depósito S3 para almacenar temporalmente datos, bases de datos y conjuntos de datos correspondientes para ejecutar controles de calidad, o un clúster de cómputo para entrenar un modelo en una canalización de orquestación de aprendizaje automático (ML). Debe tener estos recursos configurados correctamente antes de ejecutar las tareas de trabajo y, después de ejecutarlas, asegurarse de que estén desactivados. Hacer esto manualmente es complejo. Puede provocar una mala legibilidad y mantenibilidad de sus DAG y dejar los recursos en funcionamiento constantemente, lo que aumenta los costos. Con la compatibilidad de Amazon MWAA con Apache Airflow versión 2.7.2, puede utilizar dos nuevos tipos de tareas para admitir este escenario: tareas de configuración y desmontaje.

Las tareas de configuración y desmontaje garantizan que los recursos necesarios para una tarea de trabajo se configuren antes de que la tarea comience a ejecutarse y luego se retiren una vez finalizada, incluso si la tarea de trabajo falla. Cualquier tarea se puede configurar como tarea de instalación o desmontaje. Una vez configurados, tienen visibilidad especial en la interfaz de usuario de Airflow y también un comportamiento especial. El siguiente gráfico describe un proceso simple de verificación de la calidad de los datos mediante tareas de configuración y desmontaje.

Una opción para marcar setup_db_instance y teardown_db_instance como tareas de instalación y desmontaje es utilizar el as_teardown() método en la tarea de desmontaje en la declaración de la cadena de dependencias. Tenga en cuenta que el método recibe la tarea de configuración como parámetro:

setup_db_instance >> column_quality_check >> row_count_quality_check >> teardown_db_instance.as_teardown(setups=setup_db_instance)

Otra opción es usar @setup y @teardown decoradores:

from airflow.decorators import setup @setup
def setup_db_instance():
...
return "Resources fully setup" setup_db_instance()

Después de configurar las tareas, la vista de gráfico muestra sus tareas de configuración con una flecha hacia arriba y sus tareas de desmontaje con una flecha hacia abajo. Están conectados por una línea de puntos que representa el flujo de trabajo de instalación y desmontaje. Cualquier tarea entre las tareas de configuración y desmontaje (como column_quality_check y row_count_quality_check) están en el alcance del flujo de trabajo. Este arreglo implica el siguiente comportamiento:

• Si te aclaras column_quality_check or row_count_quality_check, Tanto setup_db_instance y teardown_db_instance será borrado
• If setup_db_instance se ejecuta exitosamente y column_quality_check y row_count_quality_check han completado, independientemente de si tuvieron éxito o no, teardown_db_instance correrá
• If setup_db_instance falla o se omite, entonces teardown_db_instance fallará o se saltará
• If teardown_db_instance falla, de forma predeterminada, Airflow ignora su estado para evaluar si la ejecución de la tubería fue exitosa

Tenga en cuenta que al crear flujos de trabajo de configuración y desmontaje, puede haber más de un conjunto de tareas de configuración y desmontaje, y pueden ser paralelas y anidadas. Ni las tareas de configuración ni de desmontaje están limitadas en número, ni tampoco las tareas de los trabajadores que puede incluir en el alcance del flujo de trabajo.

Siga el código de muestra completo en el Repositorio GitHub para comprender cómo funcionan las tareas de configuración y desmontaje.

Cuándo utilizar tareas de configuración y desmontaje

Las tareas de configuración y desmontaje son útiles para mejorar la confiabilidad y la rentabilidad de los DAG, garantizando que los recursos necesarios se creen y eliminen en el momento adecuado. También pueden ayudar a simplificar los DAG complejos dividiéndolos en tareas más pequeñas y manejables, lo que mejora la capacidad de mantenimiento. Algunos casos de uso incluyen:

• Procesamiento de datos basado en computación efímera, como Nube informática elástica de Amazon (Amazon EC2) flotas de instancias o clústeres de EMR
• Canalizaciones de entrenamiento o ajuste de modelos de ML
• Extraiga, transforme y cargue trabajos (ETL) utilizando almacenes de datos efímeros externos para compartir datos entre tareas de Airflow.

Con la compatibilidad de Amazon MWAA con Apache Airflow versión 2.7.2, puede comenzar a utilizar tareas de configuración y desmontaje para mejorar sus canalizaciones a partir de hoy. Para obtener más información sobre las tareas de configuración y desmontaje, consulte la Documentación de flujo de aire de Apache.

Caché de secretos

Para reflejar los cambios en sus DAG y tareas, el programador Apache Airflow analiza sus archivos DAG continuamente, cada 30 segundos de forma predeterminada. Si tiene variables o conexiones como código de nivel superior (código fuera de los métodos de ejecución del operador), se genera una solicitud cada vez que se analiza el archivo DAG, lo que afecta la velocidad de análisis y genera un rendimiento subóptimo en el procesamiento del archivo DAG. Si está ejecutando a escala, tiene el potencial de afectar el rendimiento y la escalabilidad de Airflow a medida que aumenta la cantidad de comunicación de red y la carga en la base de datos del metastore. Si está utilizando un backend de secretos alternativo, como Director de secretos de AWS, cada análisis de DAG es una nueva solicitud para ese servicio, lo que aumenta los costos.

Con la compatibilidad de Amazon MWAA con Apache Airflow versión 2.7.2, puede utilizar la caché de secretos para variables y conexiones. Airflow almacenará en caché las variables y conexiones localmente para que se pueda acceder a ellas más rápido durante el análisis de DAG, sin tener que recuperarlas del backend secreto, las variables de entorno o la base de datos de metadatos. El siguiente diagrama describe el proceso.

Habilitar el almacenamiento en caché ayudará a reducir el tiempo de análisis de DAG, especialmente si se utilizan variables y conexiones en el código de nivel superior (lo cual no es una mejor práctica). Con la introducción de una caché de secretos, se reduce la frecuencia de las llamadas API al backend, lo que a su vez reduce el costo general asociado con el acceso al backend. Sin embargo, al igual que otras implementaciones de almacenamiento en caché, una caché de secretos puede ofrecer valores obsoletos hasta que expire el tiempo de vida (TTL).

Cuándo utilizar la función de caché de secretos

Debería considerar utilizar la función de caché de secretos para mejorar el rendimiento y la confiabilidad, y reducir los costos operativos de sus tareas de Airflow. Esto es particularmente útil si su DAG recupera con frecuencia variables o conexiones en el código Python de nivel superior.

Cómo utilizar la función de caché de secretos en Amazon MWAA

Para habilitar el caché de secretos, puede configurar el secrets.use_cache parámetro de configuración del entorno en True. Una vez habilitado, Airflow almacenará automáticamente en caché los secretos cuando se acceda a ellos. La caché solo se utilizará durante el análisis de archivos DAG y no durante el tiempo de ejecución de DAG.

También puede controlar el TTL de los valores almacenados para los cuales el caché se considera válido utilizando el parámetro de configuración del entorno. secrets.cache_ttl_seconds, cuyo valor predeterminado es 15 minutos.

Filtros en ejecución o fallidos y página Actividad del clúster

Identificar DAG en estado fallido puede resultar un desafío para instancias grandes de Airflow. Por lo general, se encuentra desplazándose por páginas en busca de fallas que solucionar. Con los entornos Apache Airflow versión 2.7.2 en Amazon MWAA, ahora puede filtrar los DAG que se están ejecutando actualmente y los DAG con ejecuciones de DAG fallidas. Como puede ver en la siguiente captura de pantalla, dos pestañas de estado, Correr y Fallidos, se agregaron a la interfaz de usuario.

Otra ventaja de los entornos Amazon MWAA que utilizan Apache Airflow versión 2.7.2 es el nuevo Actividad del clúster página para monitoreo a nivel ambiental.

La Actividad del clúster La página recopila datos útiles para monitorear las métricas históricas y en vivo de su clúster. En la sección superior de la página, obtiene métricas en vivo sobre la cantidad de DAG listos para programar, los 5 DAG de mayor duración, las ranuras utilizadas en diferentes grupos y el estado de los componentes (metabase de datos, programador y activador). La siguiente captura de pantalla muestra un ejemplo de esta página.

La sección inferior del Actividad del clúster La página incluye métricas históricas de ejecuciones de DAG y estados de instancias de tareas.

Configure un nuevo entorno Apache Airflow v2.7.2 en Amazon MWAA

La configuración de un nuevo entorno Apache Airflow versión 2.7.2 en Amazon MWAA no solo proporciona nuevas características, sino que también aprovecha Python 3.11 y Amazon Linux 2023 (AL2023), que ofrece seguridad mejorada, herramientas modernas y compatibilidad con las últimas bibliotecas y funciones de Python. Puedes iniciar el establecer en su cuenta y región preferida usando el Consola de administración de AWS, API o Interfaz de línea de comandos de AWS (AWS CLI). Si está adoptando infraestructura como código (IaC), puede automatizar la configuración usando Formación en la nube de AWS, el Kit de desarrollo en la nube de AWS (AWS CDK) o scripts de Terraform.

Tras la creación exitosa de un entorno Apache Airflow versión 2.7.2 en Amazon MWAA, ciertos paquetes se instalan automáticamente en los nodos programador y trabajador. Para obtener una lista completa de los paquetes instalados y sus versiones, consulte esta documentación de MWAA. Puede instalar paquetes adicionales utilizando un archivo de requisitos. A partir de Apache Airflow versión 2.7.2, su archivo de requisitos debe incluir un --constraints declaración. Si no proporciona una restricción, Amazon MWAA le especificará una para garantizar que los paquetes enumerados en sus requisitos sean compatibles con la versión de Apache Airflow que está utilizando.

Actualice desde versiones anteriores de Apache Airflow a Apache Airflow v2.7.2

Aproveche estas capacidades más recientes actualizando sus entornos anteriores basados ​​en Apache Airflow v2.x a la versión 2.7.2 mediante actualizaciones de versión locales. Para obtener más información sobre las actualizaciones de versiones locales, consulte Actualización de la versión de Apache Airflow or Presentación de actualizaciones de versiones locales con Amazon MWAA.

Conclusión

En esta publicación, analizamos los operadores diferibles junto con algunos cambios significativos introducidos en Apache Airflow versión 2.7.2, como la página Actividad del clúster en la interfaz de usuario, el caché para variables y conexiones, y cómo puede comenzar a usarlos en Amazon MWAA. .

Para obtener detalles adicionales y ejemplos de códigos en Amazon MWAA, visite el Guía del usuario de Amazon MWAA y del Ejemplos de repositorio de GitHub de Amazon MWAA.

Apache, Apache Airflow y Airflow son marcas comerciales registradas o marcas comerciales de Apache Software Foundation en los Estados Unidos y / o en otros países.

Acerca de los autores

Manasi Bhutada es un arquitecto de soluciones ISV con sede en los Países Bajos. Ayuda a los clientes a diseñar e implementar soluciones bien diseñadas en AWS que aborden sus problemas comerciales. Le apasiona el análisis de datos y las redes. Más allá del trabajo, le gusta experimentar con la comida, jugar pickleball y sumergirse en divertidos juegos de mesa.

Hernán García es arquitecto senior de soluciones en AWS con sede en los Países Bajos. Trabaja en la industria de servicios financieros apoyando a las empresas en su adopción de la nube. Le apasionan las tecnologías sin servidor, la seguridad y el cumplimiento. Le gusta pasar tiempo con familiares y amigos y probar nuevos platos de diferentes cocinas.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/big-data/introducing-amazon-mwaa-support-for-apache-airflow-version-2-7-2-and-deferrable-operators/