Sia Workflows che Managed Service for Apache Airflow possono essere utilizzati per l'orchestrazione dei servizi per combinare i servizi per implementare la funzionalità dell'applicazione o eseguire l'elaborazione dei dati. Sebbene siano 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 Managed Airflow è il tipo di architettura che ogni prodotto è progettato per supportare.
Workflows orchestra più servizi basati su HTTP in un flusso di lavoro durevole e con stato. Ha una bassa latenza e può gestire un numero elevato di esecuzioni. Inoltre, è completamente serverless.
Workflows è ideale 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 di Workflows supportano anche sequenze semplici di operazioni in Google Cloud servizi come Cloud Storage e BigQuery.
Managed Airflow è progettato per orchestrare i flussi di lavoro basati sui dati (in particolare ETL/ELT). È basato sul progetto Apache Airflow, ma Managed Airflow è completamente gestito. Managed Airflow supporta le pipeline ovunque si trovino, inclusi on-premise o su più piattaforme cloud. Tutta la logica in Managed Airflow, inclusi attività e pianificazione, è espressa in Python come file di definizione del grafo diretto aciclico (DAG).
Managed Airflow è ideale per i carichi di lavoro in batch che possono gestire alcuni secondi di latenza tra le esecuzioni delle attività. Puoi utilizzare Managed Airflow 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 questo Google Cloud .
Confronto dettagliato delle funzionalità
| Funzionalità | Workflows | Managed Airflow |
|---|---|---|
| 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 di Airflow e sensori |
| Passaggio di dati tra i passaggi | 512 KB per le variabili | 48 KB1 per XCom |
| Trigger di esecuzione e pianificazione | gcloud CLI, Google Cloud console, API Workflows, librerie client Workflows, Cloud Scheduler | Pianificazioni di tipo cron nel file di definizione 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 fino a zero) | Provisioning effettuato |
| Modello di fatturazione | Basato sull'utilizzo (per passaggio eseguito) | Basato sulla capacità di cui è stato eseguito il provisioning |
| Funzionalità di elaborazione dei dati | No | Backfill, possibilità di eseguire di nuovo i DAG |
-
Codice sorgente per airflow.models.xcom. Documentazione di Apache Airflow. 2 agosto 2021. ↩