Tanto los flujos de trabajo como Cloud Composer se pueden usar para la orquestación de servicios con el fin de combinar servicios para implementar la funcionalidad de la aplicación o realizar el procesamiento de datos. Aunque sean similares desde una perspectiva conceptual, cada uno está diseñado para diferentes casos de uso. En esta página, encontrarás ayuda para elegir el producto correcto para tu caso de uso.
Diferencias clave
La diferencia principal entre Workflows y Cloud Composer es el tipo de arquitectura que cada producto está diseñado para admitir.
Workflows organiza varios servicios basados en HTTP en un flujo de trabajo duradero y con estado. Tiene latencia baja y puede manejar una gran cantidad de ejecuciones. También es completamente sin servidores.
Los flujos de trabajo son ideales para encadenar microservicios, automatizar tareas de infraestructura, como iniciar o detener una VM, y realizar integraciones con sistemas externos. Los conectores de flujos de trabajo también admiten secuencias simples de operaciones en Google Cloud servicios como Cloud Storage y BigQuery.
Cloud Composer está diseñado para organizar flujos de trabajo basados en datos (en particular, ETL/ELT). Se compila en el proyecto Apache Airflow, pero Cloud Composer está completamente administrado. Cloud Composer admite tus canalizaciones dondequiera que estén, ya sea de forma local o en varias plataformas de nube. Toda la lógica de Cloud Composer, incluidas las tareas y la programación, se expresa en Python como archivos de definición de grafos acíclicos dirigidos (DAG).
Cloud Composer es mejor para cargas de trabajo por lotes que pueden manejar algunos segundos de latencia entre ejecuciones de tareas. Puedes usar Cloud Composer para organizar servicios en tus canalizaciones de datos, como activar un trabajo en BigQuery o iniciar una canalización de Dataflow. Puedes usar operadores preexistentes para comunicarte con varios servicios, y hay más de 150 operadores solo para Google Cloud .
Comparación detallada de características
| Función | Workflows | Cloud Composer |
|---|---|---|
| Sintaxis | Sintaxis de flujos de trabajo en formato YAML o JSON | Python |
| Modelo de estado | Control de flujo imperativo | DAG declarativo con resolución de dependencias automática |
| Integraciones | Solicitudes HTTP y conectores | Operadores y sensores de Airflow |
| Cómo pasar datos entre pasos | 512 KB para variables | 48 KB1 para XCom |
| Activadores y programación de ejecuciones | CLI de gcloud, Google Cloud console, API de Workflows, bibliotecas cliente de Workflows, Programador de Cloud | Programaciones similares a Cron en el archivo de definición del DAG, sensores de Airflow |
| Patrones asíncronos |
|
Encuestas |
| Ejecución en paralelo | Ejecuciones simultáneas del mismo flujo de trabajo o dentro de un flujo de trabajo con pasos en paralelo | Automático según las dependencias |
| Latencia de ejecución | Milisegundos | Segundos |
| Basado en código abierto | No | Sí (Apache Airflow) |
| Modelo de escalamiento | Sin servidores (aumenta la escala hasta la demanda y disminuye hasta cero) | Aprovisionado |
| Modelo de facturación | Según el uso (por paso ejecutado) | Según la capacidad aprovisionada |
| Funciones de procesamiento de datos | No | Reabastecimientos, capacidad para volver a ejecutar DAG |
-
Código fuente de airflow.models.xcom. Documentación de Apache Airflow. 2 de agosto de 2021 ↩