Sia Workflows che Cloud Composer possono essere utilizzati per l'orchestrazione dei servizi in modo da combinare i servizi al fine di implementare le funzionalità dell'applicazione o eseguire l'elaborazione dei dati. Sebbene siano concettualmente simili, ognuna è progettata per un insieme diverso di casi d'uso. Questa pagina ti aiuta a scegliere il prodotto giusto per il tuo caso d'uso.
Differenze principali
La differenza principale tra Workflows e Cloud Composer è il tipo di architettura per cui ciascun prodotto è progettato.
Workflows orchestra più servizi basati su HTTP in un flusso di lavoro duraturo e stateful. Ha una bassa latenza ed è in grado di gestire un numero elevato di esecuzioni. Inoltre, è completamente serverless.
Workflows è ottimo per concatenare i microservizi, automatizzare le attività dell'infrastruttura come l'avvio o l'arresto di una VM e l'integrazione con sistemi esterni. I connettori Workflows supportano anche semplici sequenze di operazioni nei servizi Google Cloud come Cloud Storage e BigQuery.
Cloud Composer è progettato per orchestrare i flussi di lavoro basati sui dati (in particolare ETL/ELT). È basato sul progetto Apache Airflow, ma Cloud Composer è completamente gestito. Cloud Composer supporta le tue pipeline ovunque si trovino, on-premise o su più piattaforme cloud. Tutta la logica in Cloud Composer, incluse attività e pianificazione, è espressa in Python come file di definizione del grafo diretto aciclico (DAG).
Cloud Composer è la soluzione migliore per carichi di lavoro batch in grado di gestire pochi secondi di latenza tra le esecuzioni delle attività. Puoi utilizzare Cloud Composer per orchestrare i servizi nelle tue pipeline di dati, ad esempio per attivare un job in BigQuery o avviare una pipeline Dataflow. Puoi utilizzare operatori preesistenti per comunicare con vari servizi e ci sono oltre 150 operatori solo per Google Cloud.
Confronto dettagliato delle funzionalità
| Selezione delle | Workflows | Cloud Composer |
|---|---|---|
| Sintassi | Sintassi di Workflows in formato YAML o JSON | Python |
| Modello statale | Controllo del flusso imperativo | DAG dichiarativa con risoluzione automatica delle dipendenze |
| Integrazioni | Richieste HTTP e connectors | Operatori e sensori Airflow |
| Passaggio dei dati tra i passaggi | 512 kB per le variabili | 48 kB1 per XCom |
| Trigger di esecuzione e pianificazione | gcloud CLI, console Google Cloud, API Workflows, librerie client di Workflows, Cloud Scheduler | Pianificazioni di tipo cronologico nel file di definizione dei DAG, Airflow Sensors |
| Pattern asincroni |
|
Sondaggi |
| Esecuzione in parallelo | Esecuzioni simultanee dello stesso flusso di lavoro o all'interno di un flusso di lavoro utilizzando passi paralleli | Automatica in base alle dipendenze |
| Latenza di esecuzione | Millisecondi | Secondi |
| Basato sull'open source | No | Sì (Apache Airflow) |
| Modello di scalabilità | Serverless (scalabilità verticale fino alla domanda e fino a zero) | Provisioning effettuato |
| Modello di fatturazione | In base all'utilizzo (per passaggio eseguito) | In base alla capacità sottoposta a provisioning |
| Funzionalità di trattamento dati | No | Backfill, possibilità di eseguire nuovamente i DAG |
-
Codice sorgente per airflow.models.xcom. Documentazione di Apache Airflow. 2 agosto 2021.↩