airflow
Apache Airflow 2.10.3
Apache Airflow (o simplemente Airflow) es una plataforma para crear, programar y monitorear flujos de trabajo mediante programación.
Cuando los flujos de trabajo se definen como código, se vuelven más fáciles de mantener, versionables, comprobables y colaborativos.
Utilice Airflow para crear flujos de trabajo como gráficos acíclicos dirigidos (DAG) de tareas. El programador Airflow ejecuta sus tareas en una variedad de trabajadores mientras sigue las dependencias especificadas. Las ricas utilidades de línea de comandos facilitan la realización de cirugías complejas en DAG. La rica interfaz de usuario facilita la visualización de canalizaciones que se ejecutan en producción, monitorea el progreso y soluciona problemas cuando es necesario.
Tabla de contenido
Airflow funciona mejor con flujos de trabajo que son en su mayoría estáticos y cambian lentamente. Cuando la estructura del DAG es similar de una ejecución a otra, aclara la unidad de trabajo y la continuidad. Otros proyectos similares incluyen Luigi, Oozie y Azkaban.
Airflow se usa comúnmente para procesar datos, pero tiene la opinión de que, idealmente, las tareas deberían ser idempotentes (es decir, los resultados de la tarea serán los mismos y no crearán datos duplicados en un sistema de destino) y no deberían pasar grandes cantidades de datos. de una tarea a la siguiente (aunque las tareas pueden pasar metadatos utilizando la función XCom de Airflow). Para tareas de gran volumen y uso intensivo de datos, una mejor práctica es delegar en servicios externos especializados en ese tipo de trabajo.
Airflow no es una solución de transmisión, pero a menudo se usa para procesar datos en tiempo real, extrayendo datos de las transmisiones en lotes.
Apache Airflow se prueba con:
| Versión principal (desarrollador) | Versión estable (2.10.3) | |
|---|---|---|
| Pitón | 3.9, 3.10, 3.11, 3.12 | 3.8, 3.9, 3.10, 3.11, 3.12 |
| Plataforma | AMD64/ARM64(*) | AMD64/ARM64(*) |
| Kubernetes | 1,28, 1,29, 1,30, 1,31 | 1,27, 1,28, 1,29, 1,30 |
| PostgreSQL | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 |
| mysql | 8.0, 8.4, Innovación | 8.0, 8.4, Innovación |
| SQLite | 3.15.0+ | 3.15.0+ |
* Experimentales
Nota : MariaDB no está probado ni recomendado.
Nota : SQLite se utiliza en las pruebas de Airflow. No lo utilice en producción. Recomendamos utilizar la última versión estable de SQLite para el desarrollo local.
Nota : Actualmente, Airflow se puede ejecutar en sistemas operativos compatibles con POSIX. Para el desarrollo, se prueba periódicamente en distribuciones de Linux bastante modernas y en versiones recientes de macOS. En Windows, puede ejecutarlo a través de WSL2 (Subsistema de Windows para Linux 2) o mediante contenedores de Linux. El trabajo para agregar compatibilidad con Windows se rastrea a través del número 10388, pero no es una alta prioridad. Sólo debe utilizar distribuciones basadas en Linux como entorno de ejecución de "Producción", ya que este es el único entorno compatible. La única distribución que se utiliza en nuestras pruebas de CI y que se utiliza en la imagen de DockerHub administrada por la comunidad es Debian Bookworm .
Visite la documentación oficial del sitio web de Airflow (última versión estable ) para obtener ayuda con la instalación de Airflow, cómo comenzar o seguir un tutorial más completo.
Nota: Si está buscando documentación para la rama principal (la última rama de desarrollo): puede encontrarla en s.apache.org/airflow-docs.
Para obtener más información sobre las propuestas de mejora del flujo de aire (AIP), visite Airflow Wiki.
La documentación para proyectos dependientes, como paquetes de proveedores, imagen de Docker y Helm Chart, la encontrará en el índice de documentación.
Publicamos Apache Airflow como paquete apache-airflow en PyPI. Sin embargo, instalarlo a veces puede ser complicado porque Airflow es tanto una biblioteca como una aplicación. Las bibliotecas suelen mantener abiertas sus dependencias y las aplicaciones suelen fijarlas, pero no debemos hacer ninguna de las dos cosas al mismo tiempo. Decidimos mantener nuestras dependencias lo más abiertas posible (en pyproject.toml ) para que los usuarios puedan instalar diferentes versiones de bibliotecas si es necesario. Esto significa que pip install apache-airflow no funcionará de vez en cuando o producirá una instalación de Airflow inutilizable.
Sin embargo, para tener una instalación repetible, mantenemos un conjunto de archivos de restricciones "que se sabe que funcionan" en las ramas orphan constraints-main y constraints-2-0 . Mantenemos esos archivos de restricciones "que se sabe que funcionan" por separado para cada versión principal/menor de Python. Puede usarlos como archivos de restricciones al instalar Airflow desde PyPI. Tenga en cuenta que debe especificar la etiqueta/versión/rama de Airflow y las versiones de Python correctas en la URL.
Nota: Actualmente, solo se admite oficialmente la instalación
pip.
Si bien es posible instalar Airflow con herramientas como Poetry o pip-tools, no comparten el mismo flujo de trabajo que pip , especialmente cuando se trata de gestión de restricciones versus requisitos. Actualmente no se admite la instalación a través de Poetry o pip-tools .
Existen problemas conocidos con bazel que pueden generar dependencias circulares al usarlo para instalar Airflow. Cambie a pip si encuentra tales problemas. La comunidad Bazel trabaja para solucionar el problema en this PR <https://github.com/bazelbuild/rules_python/pull/1166> _ por lo que es posible que las versiones más nuevas de bazel lo solucionen.
Si desea instalar Airflow usando esas herramientas, debe usar los archivos de restricciones y convertirlos al formato y flujo de trabajo apropiados que requiere su herramienta.
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "Para obtener información sobre la instalación de paquetes de proveedores, consulte proveedores.
Apache Airflow es un proyecto de Apache Software Foundation (ASF) y nuestro código fuente oficial publica:
Siguiendo las reglas de la ASF, los paquetes fuente publicados deben ser suficientes para que un usuario pueda crear y probar la versión, siempre que tenga acceso a la plataforma y las herramientas adecuadas.
Hay otras formas de instalar y utilizar Airflow. Esos son métodos "convenientes": no son "lanzamientos oficiales" como lo establece la ASF Release Policy , pero pueden ser utilizados por usuarios que no quieran crear el software ellos mismos.
Estas son, en el orden de las formas más comunes en que las personas instalan Airflow:
pip estándardocker , úselas en Kubernetes, Helm Charts, docker-compose , docker swarm , etc. Puede leer más sobre el uso, la personalización y la extensión de las imágenes en los documentos más recientes y obtener detalles sobre los aspectos internos. en el documento de imágenes.Todos esos artefactos no son lanzamientos oficiales, pero se preparan utilizando fuentes publicadas oficialmente. Algunos de esos artefactos son de "desarrollo" o "prelanzamiento" y están claramente marcados como tales siguiendo la Política de ASF.
DAG : descripción general de todos los DAG en su entorno.
Cuadrícula : representación de cuadrícula de un DAG que abarca el tiempo.
Gráfico : visualización de las dependencias de un DAG y su estado actual para una ejecución específica.
Duración de la tarea : tiempo total dedicado a diferentes tareas a lo largo del tiempo.
Gantt : Duración y superposición de un DAG.
Código : forma rápida de ver el código fuente de un DAG.
A partir de Airflow 2.0.0, admitimos un enfoque estricto de SemVer para todos los paquetes publicados.
Hay algunas reglas específicas que acordamos que definen los detalles del control de versiones de los diferentes paquetes:
google 4.1.0 y amazon 3.0.3 se pueden instalar felizmente con Airflow 2.1.2 . Si existen límites de dependencias cruzadas entre proveedores y paquetes de Airflow, están presentes en los proveedores como limitaciones install_requires . Nuestro objetivo es mantener la compatibilidad de los proveedores con todas las versiones de Airflow 2 publicadas anteriormente, pero a veces habrá cambios importantes que podrían hacer que algunos o todos los proveedores tengan especificada una versión mínima de Airflow.Ciclo de vida de la versión de Apache Airflow:
| Versión | Parche actual/menor | Estado | Primer lanzamiento | Soporte limitado | EOL/Terminado |
|---|---|---|---|---|---|
| 2 | 2.10.3 | Apoyado | 17 de diciembre de 2020 | Por determinar | Por determinar |
| 1.10 | 1.10.15 | fin de vida | 27 de agosto de 2018 | 17 de diciembre de 2020 | 17 de junio de 2021 |
| 1.9 | 1.9.0 | fin de vida | 03 de enero de 2018 | 27 de agosto de 2018 | 27 de agosto de 2018 |
| 1.8 | 1.8.2 | fin de vida | 19 de marzo de 2017 | 03 de enero de 2018 | 03 de enero de 2018 |
| 1.7 | 1.7.1.2 | fin de vida | 28 de marzo de 2016 | 19 de marzo de 2017 | 19 de marzo de 2017 |
Las versiones de soporte limitado solo serán compatibles con seguridad y corrección de errores críticos. Las versiones EOL no recibirán correcciones ni soporte. Siempre recomendamos que todos los usuarios ejecuten la última versión menor disponible para cualquier versión principal que esté en uso. Recomendamos encarecidamente actualizar a la última versión principal de Airflow lo antes posible y antes de la fecha EOL.
A partir de Airflow 2.0, aceptamos ciertas reglas que seguimos para la compatibilidad con Python y Kubernetes. Se basan en el calendario de lanzamiento oficial de Python y Kubernetes, muy bien resumido en la Guía del desarrollador de Python y la política de sesgo de versión de Kubernetes.
Dejaremos de admitir las versiones de Python y Kubernetes cuando lleguen al EOL. A excepción de Kubernetes, una versión sigue siendo compatible con Airflow si dos proveedores importantes de la nube aún la brindan. Dejamos de admitir esas versiones EOL en principal justo después de la fecha EOL, y se elimina efectivamente cuando lanzamos la primera nueva versión MENOR (o MAYOR si no hay una nueva versión MENOR) de Airflow. Por ejemplo, para Python 3.9 significa que dejaremos de admitir el soporte principal justo después del 27.06.2023, y la primera versión PRINCIPAL o MENOR de Airflow lanzada después no lo tendrá.
Admitimos una nueva versión de Python/Kubernetes en main después de su lanzamiento oficial, tan pronto como los hacemos funcionar en nuestro canal de CI (lo que puede no ser inmediato debido a que las dependencias se ponen al día con las nuevas versiones de Python en su mayoría), lanzamos nuevas imágenes. /soporte en Airflow según la configuración de CI en funcionamiento.
Esta política es de mejor esfuerzo, lo que significa que puede haber situaciones en las que podríamos cancelar el soporte antes si las circunstancias lo requieren.
La comunidad Airflow proporciona imágenes de contenedores convenientemente empaquetadas que se publican cada vez que publicamos una versión de Apache Airflow. Esas imágenes contienen:
La versión de la imagen del sistema operativo base es la versión estable de Debian. Airflow admite el uso de todas las versiones estables activas actualmente, tan pronto como todas las dependencias de Airflow admitan la construcción y configuremos el canal de CI para compilar y probar la versión del sistema operativo. Aproximadamente 6 meses antes del final del soporte regular de una versión estable anterior del sistema operativo, Airflow cambia las imágenes publicadas para usar la última versión compatible del sistema operativo.
Por ejemplo, el cambio de Debian Bullseye a Debian Bookworm se implementó antes del lanzamiento 2.8.0 en octubre de 2023 y Debian Bookworm será la única opción admitida a partir de Airflow 2.10.0.
Los usuarios seguirán pudiendo crear sus imágenes utilizando versiones estables de Debian hasta que finalice el soporte regular y la creación y verificación de las imágenes se realice en nuestro CI, pero no se ejecutaron pruebas unitarias utilizando esta imagen en la rama main .
Airflow tiene muchas dependencias (directas y transitivas, además Airflow es ambas: biblioteca y aplicación), por lo tanto, nuestras políticas de dependencias deben incluir ambas: estabilidad de la instalación de la aplicación, pero también capacidad de instalar versiones más nuevas de las dependencias para aquellos usuarios que desarrollan. DAG. Desarrollamos un enfoque en el que se utilizan constraints para garantizar que el flujo de aire se pueda instalar de forma repetible, sin limitar a nuestros usuarios a actualizar la mayoría de las dependencias. Como resultado, decidimos no aumentar la versión de las dependencias de Airflow de forma predeterminada, a menos que tengamos buenas razones para creer que es necesario limitarlas debido a la importancia de la dependencia, así como al riesgo que implica actualizar una dependencia específica. También elevamos las dependencias que sabemos que causan problemas.
Nuestro mecanismo de restricción se encarga de encontrar y actualizar automáticamente todas las dependencias que no están en el límite superior (siempre que pasen todas las pruebas). Nuestras main fallas de compilación indicarán en caso de que haya versiones de dependencias que rompan nuestras pruebas, lo que indicará que debemos vincularlas en sentido superior o que debemos corregir nuestro código/pruebas para tener en cuenta los cambios ascendentes de esas dependencias.
Siempre que establezcamos un límite superior para dicha dependencia, siempre debemos comentar por qué lo hacemos; es decir, debemos tener una buena razón por la cual la dependencia tiene un límite superior. Y también debemos mencionar cuál es la condición para quitar la encuadernación.
Esas dependencias se mantienen en pyproject.toml .
Hay pocas dependencias que decidimos que son lo suficientemente importantes como para establecer un límite superior de forma predeterminada, ya que se sabe que siguen un esquema de versiones predecible, y sabemos que es muy probable que las nuevas versiones de ellas traigan cambios importantes. Nos comprometemos a revisar e intentar actualizar periódicamente las versiones más recientes de las dependencias a medida que se publican, pero este es un proceso manual.
Las dependencias importantes son:
SQLAlchemy : límite superior a una versión MENOR específica (se sabe que SQLAlchemy elimina obsolescencias e introduce cambios importantes, especialmente porque el soporte para diferentes bases de datos varía y cambia a distintas velocidades)Alembic : es importante manejar nuestras migraciones de manera predecible y eficiente. Está desarrollado junto con SQLAlchemy. Nuestra experiencia con Alembic es que es muy estable en la versión MENOR.Flask : utilizamos Flask como columna vertebral de nuestra interfaz de usuario web y API. Sabemos que es muy probable que la versión principal de Flask introduzca cambios importantes, por lo que tiene sentido limitarla a la versión PRINCIPAL.werkzeug : se sabe que la biblioteca causa problemas en las nuevas versiones. Está estrechamente vinculado con las bibliotecas de Flask y deberíamos actualizarlas juntos.celery : El apio es un componente crucial de Airflow, como se utiliza para CeleryExecutor (y similares). Apio sigue a SemVer, por lo que debemos limitarlo a la siguiente versión PRINCIPAL. Además, cuando actualicemos la versión superior de la biblioteca, debemos asegurarnos de que la versión mínima de Airflow de Celery Provider esté actualizada.kubernetes : Kubernetes es un componente crucial de Airflow, ya que se utiliza para KubernetesExecutor (y similares). La biblioteca Python de Kubernetes sigue a SemVer, por lo que debemos limitarla a la siguiente versión PRINCIPAL. Además, cuando aumentamos la versión superior de la biblioteca, debemos asegurarnos de que la versión mínima de Airflow del proveedor de Kubernetes esté actualizada.La parte principal de Airflow es Airflow Core, pero el poder de Airflow también proviene de una serie de proveedores que amplían la funcionalidad principal y se lanzan por separado, incluso si los mantenemos (por ahora) en el mismo monorepo por conveniencia. Puede leer más sobre los proveedores en la documentación de Proveedores. También hemos implementado un conjunto de políticas para mantener y liberar proveedores administrados por la comunidad, así como el enfoque para proveedores comunitarios frente a proveedores externos en el documento de proveedores.
Esos extras y dependencias providers se mantienen en provider.yaml de cada proveedor.
De forma predeterminada, no debemos limitar las dependencias de los proveedores; sin embargo, el mantenedor de cada proveedor podría decidir agregar límites adicionales (y justificarlos con comentarios).
¿Quieres ayudar a construir Apache Airflow? Consulte nuestra guía para contribuyentes para obtener una descripción general completa de cómo contribuir, incluidas instrucciones de configuración, estándares de codificación y pautas de solicitud de extracción.
Si no puedes esperar para contribuir y quieres comenzar lo antes posible, ¡consulta el inicio rápido de contribuciones aquí!
Las imágenes oficiales de Docker (contenedor) para Apache Airflow se describen en imágenes.
+1s tanto de los miembros del PMC como de los comprometidos se consideran un voto vinculante. Conocemos alrededor de 500 organizaciones que utilizan Apache Airflow (pero probablemente haya muchas más) en la naturaleza.
Si utiliza Airflow, no dude en hacer un PR para agregar su organización a la lista.
Airflow es trabajo de la comunidad, pero los responsables/mantenedores principales son responsables de revisar y fusionar los RP, así como de dirigir las conversaciones en torno a las solicitudes de nuevas funciones. Si desea convertirse en mantenedor, revise los requisitos del confirmador de Apache Airflow.
A menudo verá un problema asignado a un hito específico con la versión de Airflow, o un PR que se fusiona con la rama principal y es posible que se pregunte en qué versión se lanzarán los PR fusionados o en qué versión se solucionarán los problemas. en. La respuesta a esto es la de siempre: depende de varios escenarios. La respuesta es diferente para los RP y los Issues.
Para agregar un poco de contexto, seguimos el esquema de versiones de Semver como se describe en Proceso de lanzamiento de Airflow. Se explican más detalles en detalle en este archivo README en el capítulo sobre versiones semánticas, pero en resumen, tenemos versiones MAJOR.MINOR.PATCH de Airflow.
MAJOR se incrementa en caso de cambios importantesMINOR se incrementa cuando se agregan nuevas funcionesPATCH se incrementa cuando solo hay correcciones de errores y cambios solo en documentos Generalmente lanzamos versiones MINOR de Airflow desde una rama que lleva el nombre de la versión MENOR. Por ejemplo, las versiones 2.7.* se publican desde la rama v2-7-stable , 2.8.* se publican desde la rama v2-8-stable , etc.
La mayor parte del tiempo en nuestro ciclo de lanzamiento, cuando la rama para la siguiente rama MINOR aún no se ha creado, todos los RP fusionados con main (a menos que se reviertan) encontrarán su camino a la próxima versión MINOR . Por ejemplo, si la última versión es 2.7.3 y la rama v2-8-stable aún no se ha creado, la próxima versión MINOR es 2.8.0 y todos los PR fusionados con main se publicarán en 2.8.0 . Sin embargo, algunos PR (correcciones de errores y cambios solo en documentos) cuando se fusionan, se pueden seleccionar en la rama MINOR actual y publicar en la próxima versión PATCHLEVEL . Por ejemplo, si 2.8.1 ya se lanzó y estamos trabajando en 2.9.0dev , marcar un PR con el hito 2.8.2 significa que se seleccionará para la rama v2-8-test y se lanzará en 2.8.2rc1 . y finalmente en 2.8.2 .
Cuando nos preparamos para la próxima versión MINOR , cortamos las nuevas ramas v2-*-test y v2-*-stable y preparamos las versiones alpha y beta para la próxima versión MINOR , los PR fusionados con la principal aún se publicarán en la próxima versión MINOR . hasta que se corte la versión rc . Esto sucede porque las ramas v2-*-test y v2-*-stable se reestablecen sobre la principal cuando se preparan las próximas versiones beta y rc . Por ejemplo, cuando eliminamos la versión 2.10.0beta1 , todo lo que se haya fusionado con main antes de que se lance 2.10.0rc1 llegará a 2.10.0rc1.
Luego, una vez que preparamos el primer candidato RC para la versión MENOR, dejamos de mover las ramas v2-*-test y v2-*-stable y los PR fusionados con main se publicarán en la próxima versión MINOR . Sin embargo, algunos PR (correcciones de errores y cambios solo en documentos) cuando se fusionan, pueden seleccionarse en la rama MINOR actual y publicarse en la próxima versión PATCHLEVEL , por ejemplo, cuando la última versión lanzada de la rama v2-10-stable es 2.10.0rc1 , algunos de los PR de main pueden ser marcados como hitos 2.10.0 por los confirmadores, el administrador de lanzamiento intentará seleccionarlos en la rama de lanzamiento. Si tienen éxito, se lanzarán en 2.10.0rc2 y posteriormente en 2.10.0 . Esto también se aplica a las versiones posteriores PATCHLEVEL . Cuando, por ejemplo, 2.10.1 ya se haya lanzado, marcar un PR con el hito 2.10.2 significará que se seleccionará para la rama v2-10-stable y se lanzará en 2.10.2rc1 y, finalmente, en 2.10.2 .
La decisión final sobre la selección la toma el administrador de lanzamiento.
Marcar problemas con un hito es un poco diferente. Los mantenedores generalmente no marcan los problemas con un hito, normalmente solo se marcan en los RP. Si el PR vinculado al problema (y "solucionarlo") se fusiona y publica en una versión específica siguiendo el proceso descrito anteriormente, el problema se cerrará automáticamente, no se establecerá ningún hito para el problema, debe verificar el PR que Se solucionó el problema para ver en qué versión se lanzó.
Sin embargo, a veces los mantenedores marcan los problemas con hitos específicos, lo que significa que es importante convertirse en un candidato para echar un vistazo al problema cuando se esté preparando el lanzamiento. Dado que este es un proyecto de código abierto, donde básicamente todos los contribuyentes ofrecen su tiempo como voluntarios, no hay garantía de que un problema específico se solucione en una versión específica. No queremos retener el lanzamiento porque algún problema no se solucionó, por lo que, en tal caso, el administrador de lanzamiento reasignará dichos problemas no solucionados al siguiente hito en caso de que no se solucionen a tiempo para el lanzamiento actual. Por lo tanto, el hito del problema es más una intención de examinarlo que una promesa de que se solucionará en la versión.
Puede encontrar más contexto y preguntas frecuentes sobre la versión del nivel de parche en el documento Qué incluye la próxima versión en la carpeta dev del repositorio.
¡Sí! Asegúrese de cumplir con las políticas de marcas registradas de la Fundación Apache y el Libro de marcas de Apache Airflow. Los logotipos más actualizados se encuentran en este repositorio y en el sitio web de Apache Software Foundation.
La infraestructura de CI para Apache Airflow ha sido patrocinada por:
