Comparativa entre orquestadores Airflow y Argo Workflow
Airflow
Con los flujos de trabajo de airflow puedes realizar la recopilación de datos de otras fuentes, procesamiento, carga y creación de reportería.
En cuanto a la ejecución de tareas estas pueden ser paralelizadas teniendo en cuenta varios parámetros de configuración paralelismo, tareas por DAG, ejecuciones por DAG, Timeouts, ETC. para lograr un escalado y paralelismo estable son varias decenas de parámetros que se deben configurar teniendo en cuenta el tipo de carga de trabajo y los límites de hardware disponibles
Las recomendaciones de la cantidad máxima de DAG por cluster de Airflow, según algunos proveedores cloud es de no más de 1000 DAG totales con un total de 400 tareas concurrentes.
Características
- open source: Airflow es una plataforma de código abierto y está disponible de forma gratuita para todo el mundo. Cuenta con una gran comunidad de usuarios activos que facilita a los desarrolladores el acceso a los recursos.
- Integración dinámica: Airflow utiliza el lenguaje de programación Python para escribir flujos de trabajo como DAGs. Esto permite que Airflow se integre con varios operadores, ganchos y conectores para generar pipelines dinámicos. También puede desplegarse fácilmente en plataformas cloud como Amazon AWS, Microsoft Azure, Google Cloud, etc.
- Personalización: Airflow soporta la personalización, y permite a los usuarios diseñar sus propios operadores, ejecutores y ganchos personalizados. También puede ampliar las bibliotecas según sus necesidades para que se ajuste al nivel de abstracción deseado.
- Interfaz de usuario enriquecida: La interfaz de usuario (UI) de Airflow ayuda a supervisar y gestionar flujos de trabajo complejos. Utiliza plantillas Jinja para crear pipelines y además facilita el seguimiento de las tareas en curso.
- Escalabilidad: Airflow es altamente escalable y está diseñado para soportar múltiples flujos de trabajo dependientes simultáneamente
Argo Workflow
Argo workflow es un motor de flujo de trabajo de código abierto para orquestar tareas en Kubernetes, permitiendo crear y ejecutar flujos de trabajo avanzados en su clúster de Kubernetes.
Argo Workflows está construido sobre Kubernetes, y cada tarea se ejecuta como un pod de Kubernetes independiente.
Muchas organizaciones de renombre en la industria utilizan Argo Workflows para ML (Machine Learning), ETL (Extract, Transform, Load), Procesamiento de Datos y Pipelines CI/CD.
Argo es básicamente una extensión de Kubernetes y permite a las organizaciones definir sus tareas como DAGs utilizando YAML.
Argo viene con un archivo de flujo de trabajo nativo para auditoría, flujos de trabajo programados, y una API REST con todas las funciones.
En cuanto a la ejecución de tareas estas pueden ser paralelizadas teniendo en cuenta 2 dos puntos el controlador y el cluster de kubernetes, siendo muy importante los límites de kubernetes ya que cada tarea será un pod, resultando como recomendación no exceder la cantidad de 10.000 ejecuciones concurrente.
Características
- Open source: Argo también es totalmente de código abierto y es un proyecto en incubación en Cloud Native Computing Foundation (CNCF). Está disponible de forma gratuita para todo el mundo.
- Integraciones nativas: Argo viene con soporte nativo de artefactos para descargar, transportar y subir tus archivos durante el tiempo de ejecución. Soporta cualquier repositorio de artefactos compatible con S3 como AWS, GCS, Alibaba Cloud OSS, HTTP, Git, Raw y Minio.
- Escalabilidad: Argo Workflows cuenta con robustos mecanismos de reintento para una alta fiabilidad y es altamente escalable. Es capaz de gestionar miles de pods y flujos de trabajo en paralelo.
- Personalización: Argo es altamente personalizable y soporta plantillas y compostabilidad para crear y reutilizar flujos de trabajo
- Potente interfaz de usuario: Argo viene con una interfaz de usuario (UI) con todas las funciones que es fácil de usar. La interfaz de usuario de Argo Workflows también es compatible con Argo Events. Cuenta con widgets incrustados y un nuevo visor de registros de flujos de trabajo.
Diferencias clave
Lenguaje
Tanto Airflow como Argo permiten definir sus flujos de trabajo como DAGs, pero hay algunas diferencias en el funcionamiento de ambas plataformas que pueden ser críticas a la hora de elegir la más adecuada para sus necesidades.
El primer diferenciador clave de Argo Workflow frente a Airflow es el lenguaje de programación utilizado para definir los DAGs. Airflow permite a las organizaciones definir sus flujos de trabajo como DAGs en Python.
Argo también permite a las organizaciones definir sus flujos de trabajo como DAGs, pero a diferencia de Airflow, las definiciones se escriben en YAML.
Por otro lado Argo ejecuta cada tarea como un “pod” de Kubernetes.
Sin embargo, los flujos de trabajo que suelen ser complejos se expresan con mayor claridad de una forma declarativa o sea en formato YAML.
Scheduling
Airflow destaca en la ejecución de tareas programadas, y cuenta con un planificador tolerante a fallos que es capaz de reconocer cuándo una tarea programada no fue ejecutada.
Uno de los puntos débiles es que el scheduler de Airflow puede tardar hasta 5 minutos en volver a escanear un archivo DAG en busca de actualizaciones y en ejecutar el bucle de estado para programar nuevas tareas. Por lo tanto, no es el más apropiado para la programación de baja latencia.
Argo también es bastante bueno en la ejecución de tareas programadas, tiene la capacidad de asegurar que la ejecución continúe ante algunas interrupciones de su scheduler utilizando el parámetro “startingDeadlineSeconds” que especifica el tiempo máximo después de la última ejecución exitosa.
Por ejemplo, si un flujo de trabajo se ejecuta cada minuto y se ejecutó por última vez a las 12:05:00, debido a que el controlador falló entre las 12:05:55 y las 12:06:05.
Entonces se perdería la oportunidad de ejecución en el tiempo esperado de 12:06:00. Sin embargo, usando “startingDeadlineSeconds” podrá extender ese tiempo permitiendo la correcta ejecución del flujo de trabajo
Una de las ventajas de argo es que admite otros servicio de scheduler como por ejemplo cloud scheduler, ya que argo cuenta con una API rest la cual le permite recibir peticiones.
Uno de los puntos fuertes es que el scheduler Argo recibe eventos de Kubernetes y es capaz de responder inmediatamente a nuevos flujos de trabajo y cambios de estado, lo que lo convierte en una opción ideal para la programación de baja latencia
Escalabilidad
Airflow admite la escalabilidad horizontal y es capaz de ejecutar varios schedulers simultáneamente. En lo que respecta a las tareas, Airflow se basa en un grupo dedicado de workers para ejecutarlas. Así, el máximo paralelismo de tareas es igual al número de nodos
Argo ejecuta cada tarea como un pod de Kubernetes independiente y, por tanto, es capaz de gestionar miles de pods y flujos de trabajo en paralelo. A diferencia de Airflow, el paralelismo de un flujo de trabajo no está limitado por un número fijo de trabajadores en Argo. Por lo tanto, es el más adecuado para trabajos con dependencias de secuencia y pasos paralelos.
Flujos de trabajo compatibles
Los DAG de Airflow son estáticos y, una vez definidos, no tienen la capacidad de añadir o modificar pasos durante el tiempo de ejecución. Airflow ejecuta los DAG sólo con un scheduler, por lo que sistemas externos no pueden iniciar la ejecución flujo de trabajo, actualmente se pueden ejecutar externamente con una API en versión beta que representa un alto riesgo de dañar la operación.
Además, Airflow asume que todos los DAGs son autocontenidos y por lo tanto no tiene un mecanismo de primera clase para pasar parámetros en tiempo de ejecución a los DAG
Mientras tanto en Argo los DAG pueden crearse dinámicamente para cada ejecución del flujo de trabajo. Puede asignar tareas sobre listas de resultados generadas dinámicamente para procesar elementos en paralelo.
Además Argo permite pasar parámetros de entrada y salida a nivel de tarea, y parámetros de entrada a nivel de flujo de trabajo
Interacción con los recursos de Kubernetes
Airflow tiene un operador de Kubernetes que puede ser utilizado para ejecutar pods como parte de un flujo de trabajo. Sin embargo, no tiene ningún soporte para crear otros recursos.
Argo está construido sobre Kubernetes, y cada tarea se ejecuta como un “pod” de Kubernetes independiente. Argo tiene la capacidad de manejar objetos nativos de kubernetes lo que facilita realizar operaciones CRUD en objetos de Kubernetes como pods y despliegues.
Resumen
| Característica | Argo Workflow | Airflow |
|---|---|---|
|
Lenguaje de definición de flujos de trabajo
|
YAML |
Python |
|
Scheduler tolerante a fallos |
SI |
SI |
|
scheduler de baja latencia
|
SI |
NO |
|
Alto grado de paralelismo
|
SI |
NO |
|
Flujos de trabajo dinámicos |
SI |
NO |
|
Flujos de trabajo basados en eventos
|
SI |
NO |
|
Flujos de trabajo parametrizados |
SI |
NO |
|
Interacción con Kubernetes
|
SI |
NO |
Conclusión
De acuerdo con este análisis comparativo entre Argo vs Airflow, debes haber notado que ambas herramientas tienen diferentes enfoques y puntos fuertes. Por lo tanto, no existe una forma para decidir qué herramienta es la mejor. La elección depende en gran medida de su caso de uso, requisitos y entorno de ejecución.
Tanto Argo como Airflow le permiten definir sus tareas como DAG, pero Argo permite ejecutar cada unos de las tareas del dag dentro de un pod, permitiendo ejecutar cualquier lenguaje de programación de forma nativa dentro de un contenedor con las dependencias que necesites para ejecutarlas
Para ayudarte, podemos definir un ejemplo práctico donde utilizaremos Argo Workflow para un pipeline poly lenguajes, primero debemos definir un flujos de trabajo de N pasos los cuales serán importados por el DAG. Claramente este caso sería realizado con Argo Workflow.
Describiendo un poco cada etapa serían las siguientes:
- Parsear los argumentos de entrada en formato YAML (utilizando Python)
- Realizar el procesamiento y transformación de datos desde BigQuery (utilizando Spark / Scala)
- Realizar el envío de los datos a una API REST (utilizando Java)
Cómo comentario adicional si tienes experiencia en Kubernetes se recomienda usar Argo.
Si sus desarrolladores se sienten más cómodos escribiendo definiciones de DAG en Python que en YAML, pueden considerar usar Airflow.