Sia i workflow sia Cloud Composer possono essere utilizzati per l'orchestrazione dei servizi al fine di combinare i servizi per implementare la funzionalità dell'applicazione o eseguire l'elaborazione dei dati. Sebbene concettualmente simili, ognuno è progettato 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 che ciascun prodotto è progettato per supportare.
Workflows orchestra più servizi basati su HTTP in un flusso di lavoro duraturo e con stato. Ha una bassa latenza e può gestire un numero elevato di esecuzioni. Inoltre, è completamente serverless.
I flussi di lavoro sono ideali per collegare microservizi, automatizzare attività di infrastruttura come l'avvio o l'arresto di una VM e integrare con sistemi esterni. I connettori di Workflows supportano anche sequenze semplici di operazioni in Google Cloud servizi 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, anche on-premise o su più piattaforme cloud. Tutta la logica di Cloud Composer, incluse le attività e la pianificazione, viene espressa in Python come file di definizione di grafici diretti aciclici (DAG).
Cloud Composer è ideale per i carichi di lavoro batch che possono gestire alcuni secondi di latenza tra le esecuzioni delle attività. Puoi utilizzare Cloud Composer per orchestrare i servizi nelle pipeline di dati, ad esempio attivare un job in BigQuery o avviare una pipeline Dataflow. Puoi utilizzare gli operatori preesistenti per comunicare con vari servizi e sono disponibili oltre 150 operatori solo per Google Cloud .
Confronto dettagliato delle funzionalità
| Funzionalità | Workflow | Cloud Composer |
|---|---|---|
| Sintassi | Sintassi di Workflows in formato YAML o JSON | Python |
| Modello di stato | Controllo del flusso imperativo | DAG dichiarativo con risoluzione automatica delle dipendenze |
| Integrazioni | Richieste HTTP e connettori | Operatori e sensori di Airflow |
| Trasferimento di dati tra i vari passaggi | 512 KB per le variabili | 48 KB1 per XCom |
| Trigger di esecuzione e pianificazione | Interfaccia a riga di comando gcloud, console Google Cloud, API Workflows, librerie client Workflows, Cloud Scheduler | Pianificazioni simili a cron nel file di definizione del DAG, Sensori Airflow |
| Pattern asincroni |
|
Sondaggi |
| Esecuzione parallela | Esecuzioni simultanee dello stesso flusso di lavoro o all'interno di un flusso di lavoro utilizzando passaggi paralleli | Automatica in base alle dipendenze |
| Latenza di esecuzione | Millisecondi | Secondi |
| Basato su open source | No | Sì (Apache Airflow) |
| Modello di scalabilità | Serverless (scala in base alla domanda e si riduce a zero) | Provisioning effettuato |
| Modello di fatturazione | In base all'utilizzo (per passaggio eseguito) | In base alla capacità sottoposta a provisioning |
| Funzionalità di elaborazione dei dati | No | Backfill, possibilità di rieseguire i DAG |
-
Codice sorgente per airflow.models.xcom. Documentazione di Apache Airflow. 2 agosto 2021. ↩