Workflows y Cloud Composer se pueden usar en la organización de servicios para combinar servicios con el objetivo de implementar la funcionalidad de la aplicación o realizar procesamiento de datos. Aunque son similares desde una perspectiva conceptual, están diseñadas para un conjunto diferente de casos prácticos. Esta página te ayuda a elegir el producto adecuado para tu caso de uso.
Diferencias clave
La diferencia principal entre Workflows y Cloud Composer es el tipo de arquitectura que admite cada producto.
Workflows organiza varios servicios basados en HTTP en un flujo de trabajo duradero y con estado. Tiene latencia baja y puede controlar una gran cantidad de ejecuciones. Además, es completamente sin servidores.
Workflows es excelente para encadenar microservicios, automatizar tareas de infraestructura como iniciar o detener una VM y realizar integraciones en sistemas externos. Los conectores de Workflows también admiten secuencias simples de operaciones en los servicios de Google Cloud, como Cloud Storage y BigQuery.
Cloud Composer está diseñado para organizar flujos de trabajo basados en datos (en particular, ETL/ELT). Se basa en el proyecto de 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 en la nube. Toda la lógica en Cloud Composer, incluidas las tareas y la programación, se expresa en Python como archivos de definición de grafo acíclico dirigido (DAG).
Cloud Composer es ideal para cargas de trabajo por lotes que pueden manejar unos 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. Existen más de 150 operadores solo para Google Cloud.
Comparación detallada de características
| Atributo | Workflows | Cloud Composer |
|---|---|---|
| Sintaxis | Sintaxis de Workflows en formato YAML o JSON | Python |
| Modelo de estado | Control de flujo imperativo | DAG declarativo con resolución de dependencia automática |
| Integraciones | Solicitudes HTTP y connectors | Operadores y sensores de Airflow |
| Cómo pasar datos entre pasos | 512 KB para variables | 48 KB1 para XCom |
| Activadores y programación de ejecución | gcloud CLI, la consola de Google Cloud, API de Workflows, bibliotecas cliente de Workflows, Cloud Scheduler | Programas similares a Cron en el archivo de definición del DAG, los sensores de Airflow |
| Patrones asíncronos |
|
Encuestas |
| Ejecución paralela | Ejecuciones simultáneas del mismo flujo de trabajo o dentro de un flujo de trabajo mediante pasos paralelos | Automático basado en dependencias |
| Latencia de ejecución | Milisegundos | Segundos |
| Basado en código abierto | No | Sí (Apache Airflow) |
| Escalamiento del modelo | Tecnología sin servidores (escala verticalmente según la demanda y reduce la escala a cero) | Aprovisionada |
| Modelo de facturación | Según el uso (por paso ejecutado) | Según la capacidad aprovisionada |
| Funciones de procesamiento de datos | No | Reabastecimientos, la capacidad de volver a ejecutar los DAG |
-
Código fuente de airflow.models.xcom. Documentación de Apache Airflow 2 de agosto de 2021. ↩