O Workflows e o Cloud Composer podem ser usados na orquestração de serviços para combinar serviços e implementar a funcionalidade do aplicativo ou realizar o processamento de dados. Embora semelhantes, eles foram projetados para diferentes grupos de casos de uso. Nesta página, você encontra informações úteis para escolher o produto certo para seu caso de uso.
Principais diferenças
A principal diferença entre o Workflows e o Cloud Composer é o tipo de arquitetura compatível com cada produto.
O Workflows orquestra vários serviços baseados em HTTP em um fluxo de trabalho durável e com estado. Ele tem baixa latência e pode processar um grande número de execuções. Ele também não tem servidor.
O Workflows é ótimo para encadear microsserviços, automatizar tarefas de infraestrutura, como iniciar ou interromper uma VM e integrar com sistemas externos. Os conectores do Workflows também são compatíveis com sequências simples de operações em serviços do Google Cloud, como o Cloud Storage e o BigQuery.
O Cloud Composer foi projetado para orquestrar fluxos de trabalho baseados em dados (especialmente ETL/ELT). Ele é criado no projeto do Apache Airflow, mas o Cloud Composer é totalmente gerenciado. O Cloud Composer é compatível com seus pipelines onde quer que eles estejam, incluindo no local ou em várias plataformas em nuvem. Toda a lógica do Cloud Composer, incluindo tarefas e programação, é em Python no formato de arquivos de definição acíclico dirigido (DAG, na sigla em inglês).
O Cloud Composer é ideal para cargas de trabalho em lote que podem processar alguns segundos de latência entre as execuções de tarefas. Use o Cloud Composer para orquestrar serviços nos pipelines de dados, como acionar um job no BigQuery ou iniciar um pipeline do Dataflow. É possível usar operadores pré-existentes para se comunicar com vários serviços, e há mais de 150 operadores apenas para o Google Cloud.
Comparação detalhada dos recursos
| Engenharia de | Fluxos de trabalho | Cloud Composer |
|---|---|---|
| Sintaxe | Sintaxe dos fluxos de trabalho no formato YAML ou JSON | Python |
| Modelo de estado | Controle do fluxo imperativo | DAG declarativo com resolução de dependência automática |
| Integrações | Solicitações HTTP e connectors | Operadores e sensores do Airflow |
| Como transmitir dados entre etapas | 512 KB para variáveis | 48 KB1 para XCom |
| Gatilhos e programação de execução | CLI gcloud, console do Google Cloud, API Workflows, bibliotecas de cliente Workflows, Cloud Scheduler | Programações em estilo Cron no arquivo de definição do DAG, sensores do Airflow |
| Padrões assíncronos |
|
Enquetes |
| Execução paralela | Execuções simultâneas do mesmo fluxo de trabalho ou dentro de um fluxo de trabalho usando etapas paralelas. | Automático com base em dependências |
| Latência de execução | Milissegundos | Segundos |
| Baseado em código aberto | Não | Sim (Apache Airflow) |
| Modelo de escalonamento | Sem servidor (escalonamento vertical para demanda e até zero) | Aprovisionado |
| Modelo de faturamento | Baseado no uso (por etapa executada) | Baseado na capacidade provisionada |
| Recursos de processamento de dados | Não | Preenchimentos, capacidade de executar DAGs novamente |
-
Código-fonte de airflow.models.xcom. Documentação do Apache Airflow (em inglês). 2 de agosto de 2021. ↩