Di Andrew Tan
Lo stack di orchestrazione tipico di un team di dati si evolve in passi ragionevoli. Si inizia con Airflow. Va bene. Il team lo conosce. I DAG vengono eseguiti secondo programma. Dopo cinque anni, Airflow esegue 300 DAG e tutti hanno paura di toccare l'immagine di base.
Poi hai bisogno di qualcosa di moderno. Una nuova assunzione spinge per Prefect — è nativo in Python, l'esperienza dello sviluppatore è migliore e l'interfaccia utente è più pulita. Quindi inizi nuovi progetti in Prefect e lasci quelli vecchi in Airflow.
Poi arriva un team di ML. Vogliono Dagster perché il pensiero centrato sugli asset e il tracciamento della lineage si adattano al loro lavoro con il feature store. Ragionevole. Aggiungi Dagster.
Nessuno ha preso una decisione sbagliata. Ogni strumento era la scelta giusta nel contesto. Ma ora il team sta pagando per tre scheduler, tre set di worker, tre dashboard di monitoraggio e tre modelli mentali. Quando i dati fluiscono da Airflow a Dagster prima di passare a una chiamata API orchestrata da Prefect, la lineage si interrompe. Puoi vedere ogni passaggio in isolamento. Non puoi vedere l'intera catena.
Questa è la tassa di orchestrazione. Ed è quasi universale nelle aziende che costruiscono infrastrutture dati da più di due anni.
Come si manifesta la tassa
Il conto nascosto appare in tre luoghi che la maggior parte dei team non misura.
La giuntura di coordinamento. Quando il Pipeline A (Airflow) deve attivare il Pipeline B (Dagster), come lo fa? Di solito: un file drop, un flag nel database, una chiamata API o — più comune — un messaggio Slack tra gli umani che possiedono ciascun sistema. Quell'"integrazione" ora è portante. Quando si rompe, fallisce silenziosamente. Lo scopri tre ore dopo quando il pipeline di Dagster è stato eseguito sui dati di ieri.
Alcuni team finiscono con un intero ingegnere dedicato a mantenere ciò che internamente chiamano "il livello di colla". È un ruolo a tempo pieno che scrive script Python per far sembrare che tre strumenti di orchestrazione siano uno solo.
Il labirinto di debug. Un problema di qualità dei dati emerge nello strumento BI. Il numero è sbagliato. Dove è andato storto? Inizi dai log di Airflow. Il DAG è riuscito. Controlli Prefect — il flusso di eventi è riuscito. Controlli Dagster — gli asset sono stati materializzati. Da qualche parte nel passaggio tra i sistemi, qualcosa è andato storto e non c'è una visione unificata di ciò che è successo.
Il MTTR (tempo medio di risoluzione) per i fallimenti cross-sistema è costantemente 3-5 volte superiore rispetto ai fallimenti di un singolo sistema nei team che tracciano questo. Il costo del debug è il pezzo nascosto più grande.
Il pedaggio del cambio di contesto. Lo scheduler di Airflow pensa in espressioni cron e dipendenze dei task. Dagster pensa in asset e politiche di freschezza. Prefect pensa in flussi e deployment. Ognuno ha il proprio modello di autenticazione, la propria gestione dei segreti, il proprio modo di gestire i retry. Gli ingegneri diventano fluenti in tutti e tre — il che significa che non sono esperti in nessuno di essi, e ogni transizione di strumento costa un sovraccarico cognitivo che non appare in nessun tracciatore di sprint.
La situazione di Kestra
Questo è il motivo per cui il marketing di Kestra risuona. La loro proposta — "puoi eseguire Airflow, Spark, dbt e script personalizzati, tutto da un unico orchestratore" — affronta direttamente la frustrazione multi-strumento.
Ma c'è una differenza tra un'unica interfaccia e un'unica fonte di verità. Kestra può avvolgere i tuoi strumenti esistenti. È utile. Non riduce effettivamente il problema della coordinazione distribuita. Hai aggiunto un altro strumento sopra tre strumenti.
La proliferazione dell'orchestrazione non è un problema di interfaccia utente. È un problema di proprietà del flusso di dati. Chi possiede l'evento che attiva la catena? Chi possiede lo schema dei dati che passa tra i sistemi? Chi è responsabile quando il passaggio tra il passaggio 2 e il passaggio 3 fallisce?
Un nuovo livello di orchestrazione in cima non risponde a queste domande. Aggiunge solo un altro sistema da guardare quando fai il debug alle 2 del mattino.
Cosa aiuta realmente
Siamo diretti su ciò che funziona rispetto a ciò che sposta solo il problema.
Funziona: consolidare attorno a un modello, in modo aggressivo. Scegli lo strumento che gestisce bene l'80% del tuo carico di lavoro attuale, migra tutto ciò che puoi e vivi con l'attrito di spostare i lavori legacy. È doloroso per sei mesi. Dopo di che, hai un modello di scheduling, un set di worker, un posto dove guardare quando le cose falliscono. I team che fanno questo riportano costantemente una riduzione del 40-60% nel tempo di risposta agli incidenti entro un anno.
Funziona: trattare i passaggi inter-sistema come dati di prima classe. Se devi eseguire più strumenti per motivi legittimi (ad esempio, i pipeline di ML beneficiano realmente del modello di asset di Dagster), rendi ogni passaggio un trasferimento di dati esplicito e monitorato. Non un file drop. Non un flag nel database che qualcuno ha aggiunto a una tabella quattro anni fa. Uno schema definito, con osservabilità, con retry, con allerta. La colla diventa parte del design del tuo sistema piuttosto che un incidente di esso.
Non funziona: aggiungere osservabilità sopra la frammentazione. Un'altra dashboard che mostra lo stato di tutti e tre i sistemi non risolve il problema della coordinazione — rende solo il fallimento distribuito visibile in più luoghi. Hai bisogno di meno cose da osservare, non di strumenti migliori per osservare più cose.
Non funziona: teatro della migrazione. "Stiamo migrando a Dagster nei prossimi 18 mesi" non è un piano. È una dichiarazione che il dolore non è ancora abbastanza grave da fare il lavoro reale. Fino a quando non ritiri effettivamente il vecchio strumento, stai solo aggiungendo superficie di integrazione mentre pianifichi.
Il pezzo batch/streaming
Un vero motivo per cui i team eseguono più strumenti di orchestrazione è che batch e streaming hanno realmente requisiti diversi. Airflow pianifica i lavori. Kafka elabora i flussi. Paradigmi diversi, strumenti diversi — e se stai cercando di servire entrambi nella stessa piattaforma dati, finisci con due sistemi di gestione dei workflow separati.
Vale la pena nominarlo direttamente: una piattaforma che gestisce sia batch che streaming all'interno dello stesso modello di deployment, stessa definizione di workflow e stessi strumenti operativi significa che lo stesso team che esegue l'ETL notturno può gestire l'elaborazione degli eventi in tempo reale. Non perché qualcuno stia reinventando Airflow o Kafka, ma perché la divisione tra "programmato" e "guidato dagli eventi" non dovrebbe richiedere due specialità ingegneristiche separate e due sistemi di monitoraggio separati.
L'obiettivo non è sostituire tutto ciò che hai. È smettere di pagare la tassa.
La vera domanda
La conversazione di solito si riduce alla stessa domanda: "È davvero un problema che vale la pena risolvere, o è solo la natura della costruzione di sistemi di dati?"
Giusto. Ogni azienda ha debito tecnico. Non ogni debito vale la pena di essere ripagato.
Ecco un modo semplice per pensarci: se il tuo turno di reperibilità include "controllare tutti e tre gli scheduler" come passaggio in ogni runbook, stai pagando la tassa di orchestrazione ogni settimana. Se un nuovo ingegnere dei dati ha bisogno di un mese per diventare produttivo perché deve imparare i modelli mentali di più strumenti, la stai pagando a ogni assunzione. Se il tuo processo di debug richiede di incrociare i riferimenti di tre diversi sistemi di log, la stai pagando a ogni incidente.
Somma tutto. Poi decidi.
Se stai affrontando la proliferazione dell'orchestrazione e vuoi capire quale potrebbe essere un percorso verso la consolidazione — specialmente quando gestisci sia carichi di lavoro batch che real-time — contattaci. Possiamo esaminare il tuo setup specifico e darti un quadro onesto di ciò che vale la pena cambiare e cosa no.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che real-time su larga scala.