Cos'è un DAG in una pipeline dati?

Un DAG (Directed Acyclic Graph, grafo diretto aciclico) è la struttura con cui un orchestratore di pipeline dati rappresenta un flusso di lavoro: un insieme di nodi, ciascuno un task, collegati da archi direzionali che codificano una dipendenza, un task deve completarsi prima che il successivo parta. La proprietà che dà il nome alla struttura è l'assenza di cicli: nessun task può dipendere, direttamente o attraverso una catena di altri task, da se stesso. Se quel percorso esistesse, il grafo chiederebbe di eseguire A prima di B e B prima di A, una condizione che nessun motore di scheduling può risolvere e che va quindi esclusa per costruzione, non gestita a runtime. Il DAG è il modello concettuale sottostante a strumenti come Apache Airflow, Dagster e Prefect, ma non è legato a nessuno di loro: la stessa struttura descrive dipendenze di build software, i grafi di derivazione dei sistemi di versionamento e reti bayesiane. Qui interessa l'applicazione specifica all'orchestrazione di pipeline dati e ML.

Perché non basta uno script sequenziale

Uno script che esegue i passaggi in fila, uno dopo l'altro, funziona finché la pipeline resta piccola. Chi valuta se serve un vero orchestratore o basta lo script accumulato negli anni si trova davanti a tre numeri, tutti derivati dalla stessa proprietà del grafo delle dipendenze. Il primo è quante ore si perdono aspettando in sequenza task che potrebbero girare in parallelo, perché un motore che legge il grafo li lancia insieme quando non dipendono l'uno dall'altro: su una pipeline con decine di fonti indipendenti è la differenza tra ore e minuti. Il secondo è quanto costa il recovery dopo un fallimento: lo script sequenziale spesso ricomincia tutto da capo, mentre un orchestratore che conosce il grafo rilancia solo il task caduto e ciò che dipende da lui. Il terzo è quanto tempo si passa a capire cosa ha causato cosa: il grafo rende esplicito chi blocca chi, invece di lasciare un generico "la pipeline è lenta" da investigare a mano. Messi in fila, sono i tre numeri che dicono se lo script che gira da anni è ancora sostenibile o è già un debito tecnico silenzioso.

Un esempio enterprise

Una pipeline che consolida dati da CRM, gestionale ed e-commerce in un'unica trasformazione per il reporting settimanale è il caso tipico. Ognuna delle tre estrazioni è un nodo indipendente dagli altri due, e la trasformazione che le unisce è un nodo a valle che dipende da tutte e tre. Con un DAG, se l'estrazione dal gestionale fallisce per una manutenzione del fornitore, le estrazioni da CRM ed e-commerce proseguono comunque: solo il nodo caduto e la trasformazione finale restano in attesa, non l'intera pipeline. Con uno script sequenziale, lo stesso guasto blocca anche i due flussi che non avevano nessun problema, semplicemente perché erano scritti dopo nell'ordine del file.

Perché conta per chi decide

Il DAG è il criterio con cui valutare la maturità di una piattaforma dati indipendentemente dallo strumento scelto: se le pipeline sono ancora script incatenati a mano o cron job che si sperano in ordine, un errore in una fonte minore può fermare la produzione di un report critico senza una ragione tecnica reale. Adottare un modello a grafo non richiede necessariamente di cambiare orchestratore; richiede di riconoscere quali task dipendono davvero da quali altri, cosa che spesso in una pipeline cresciuta per accumulo nessuno ha mai scritto esplicitamente. Per chi valuta un investimento in DataOps, questo è anche il punto in cui si misura il costo reale di un incidente: minuti su un solo task, o ore sull'intera pipeline.