Una domanda apparentemente banale separa due modi di lavorare con i dati: stai orchestrando job o stai orchestrando dati? Il team di Dagster ha inquadrato questa differenza in un modello di maturità dell’orchestrazione che descrive bene un’evoluzione che molte organizzazioni attraversano senza nominarla.
Job-centrico vs asset-aware
I sistemi di orchestrazione tradizionali rispondono a domande sui job: quando gira questo task? è fallito? quanto ha impiegato? Sono domande legittime, ma incomplete. Chi fa data engineering ha bisogno di risposte sui dati: questo dataset è aggiornato? chi dipende da lui? è affidabile?
Il salto è dal job-centrico all’asset-aware. In un sistema asset-aware ogni dataset, ogni modello, ogni output è un cittadino di prima classe: il sistema sa cosa produce ogni pipeline, non solo quando viene eseguita. La pipeline diventa un mezzo; l’asset di dati diventa il fine.
Perché è un cambio di prospettiva, non solo di tool
Adottare un approccio asset-aware non è una semplice scelta di strumento. Cambia il modo in cui si ragiona su tre temi chiave. La governance: sapere cosa esiste e chi lo usa. L’osservabilità: monitorare la freschezza e la qualità degli asset, non solo lo stato dei job. La fiducia: poter rispondere con certezza alla domanda "posso usare questo dato?".
Quando la transizione conta
Spesso il limite del modello job-centrico non si vede finché non si scala. Con poche pipeline va tutto bene; con decine di dataset interdipendenti e più team che li consumano, la mancanza di una visione orientata agli asset diventa un costo: incidenti difficili da diagnosticare, dipendenze invisibili, dati di cui nessuno si fida del tutto.
Il modello di maturità di Dagster è utile proprio come specchio: aiuta a capire a che punto si è e dove conviene investire. E ricorda un principio sano — alla fine non ci interessano i task che girano, ci interessano i dati che producono.
Hai qualcosa da aggiungere? Unisciti alla discussione.