dbt sta lasciando il magazzino. I tuoi Data Pipeline sono pronti?

Di Andrew Tan

L'esecuzione programmata che era sufficiente

Per la maggior parte dell'ultimo decennio, il workflow analitico era così:

Estrai i dati dalle tue fonti. Caricali in un data warehouse. Scrivi modelli SQL in dbt. Programma la loro esecuzione ogni poche ore. Costruisci dashboard sopra. Quando l'azienda chiede perché i numeri sembrano errati, controlli il badge di freschezza e scopri che il job è fallito sei ore fa.

Non era perfetto, ma era prevedibile. Il contratto tra analisi e ingegneria era chiaro: i modelli sono costruiti nel warehouse, su un programma, in SQL. dbt ha reso quel contratto elegante. Modelli controllati in versione, test automatizzati, grafici di dipendenza, documentazione generata dal codice. Per l'analisi batch, è stato un vero salto in avanti.

Poi l'azienda ha iniziato a chiedere dati più freschi. Non freschi del giorno dopo. Non freschi ogni ora. Freschi in tempo reale. Il tipo di freschezza in cui un cliente aggiorna il suo profilo e il motore di raccomandazione lo sa prima che se ne vada.

E improvvisamente, l'esecuzione programmata non è sufficiente.

Perché il successo di dbt ha creato un divario di runtime

L'intuizione fondamentale di dbt è stata separare la logica del modello dall'infrastruttura di esecuzione. Tu scrivi l'SQL. dbt gestisce il DAG, i test, la documentazione, la strategia di materializzazione. L'effettiva computazione avviene ovunque tu la punti — Snowflake, BigQuery, Redshift, Databricks. A dbt non importa. È un compilatore e orchestratore per modelli SQL, non un runtime.

Quella separazione era geniale per i carichi di lavoro batch. Significava che gli ingegneri analitici potevano possedere la logica di modellazione senza gestire cluster, strategie di partizionamento o ottimizzazione della memoria. Il warehouse gestiva tutto ciò. L'ingegnere analitico si concentrava sui semantici: cosa significa questo modello, come viene testato, chi dipende da esso.

Ma quella separazione assume qualcosa di importante: che il layer di esecuzione possa gestire il carico di lavoro che gli stai lanciando. E per i job batch programmati contro un warehouse moderno, è vero. Per l'elaborazione in tempo reale contro dati streaming, non lo è.

Il divario non è nell'SQL. L'SQL di dbt è ancora SQL. Il divario è in tutto ciò che accade tra l'evento e il risultato del modello:

• SLA di freschezza. Un modello dbt che gira ogni quindici minuti è ancora quindici minuti indietro. In un contesto di streaming, quindici minuti sono un job batch con un costume più piccolo.
• Eventi fuori ordine. I dati in streaming arrivano in ritardo, duplicati o fuori sequenza. Un modello SQL che assume input ordinato produce risultati errati senza avviso.
• Operazioni con stato. Funzioni di finestra, sessionizzazione, deduplicazione — queste necessitano di mantenere lo stato tra gli eventi. Le strategie di materializzazione di dbt (tabella, incrementale, effimero) non sono state progettate per la gestione dello stato in tempo di evento.
• Join operativi. Unire un flusso di ordini a una tabella di dimensioni che cambia lentamente in tempo reale è un problema diverso rispetto a unire due tabelle del warehouse su customer_id. La dimensione potrebbe cambiare a metà query. Il flusso non aspetta.

Questi non sono casi limite. Sono le caratteristiche distintive dell'elaborazione di flussi. E dbt, per design, delega tutti loro al layer di esecuzione.

Cosa stanno effettivamente vendendo i fornitori

Se sei stato a una conferenza sui dati nell'ultimo anno, hai visto il cambiamento nel marketing. Confluent sta spingendo la modellazione nativa dbt su Flink. Fivetran ha lanciato dbt Wizard con generazione di modelli assistita dall'AI. Snowflake ha annunciato Dynamic Tables, BigQuery ha Materialized Views, Databricks sta puntando tutto su Delta Live Tables.

Il messaggio è coerente: puoi mantenere il tuo workflow dbt e semplicemente... renderlo in tempo reale. L'SQL rimane lo stesso. Il DAG rimane lo stesso. L'unica cosa che cambia è la velocità.

Questo è approssimativamente mezzo vero.

Sì, puoi eseguire SQL su dati in streaming. Flink SQL, Spark Structured Streaming e una lista crescente di processori di flussi supportano la sintassi SQL che sembra familiare. Sì, puoi controllare in versione quei file SQL e costruire DAG. Alcuni strumenti supportano persino test e documentazione in stile dbt.

Quello che non ti dicono è che l'altra metà del problema — la metà del runtime — non scompare. Cambia solo forma.

Quando passi da batch programmato a streaming continuo, erediti un nuovo set di preoccupazioni che dbt non ha mai dovuto risolvere:

L'SQL potrebbe sembrare lo stesso. Ma il sistema che lo esegue sta risolvendo un insieme di problemi completamente diverso.

La questione della proprietà che nessuno vuole affrontare

Ecco dove diventa organizzativo. dbt ha creato un confine chiaro: gli ingegneri analitici possiedono i modelli, gli ingegneri della piattaforma possiedono il warehouse. Quando un modello fallisce, di solito è un problema di SQL o di qualità dei dati. Quando il warehouse è lento, è un problema della piattaforma. La separazione delle preoccupazioni si mappa perfettamente a una separazione dei team.

Lo streaming rompe quel confine.

Quando una pipeline in tempo reale fallisce, è un problema di SQL o un problema di infrastruttura? Se gli eventi arrivano fuori ordine, l'ingegnere analitico riscrive la logica della finestra o l'ingegnere della piattaforma riconfigura le impostazioni del watermark del processore di flusso? Se un evento in ritardo corrompe una vista materializzata, chi lo risolve — la persona che ha scritto l'SQL o la persona che gestisce il checkpointing?

Ho visto team gestire questo in tre modi, e solo uno di essi funziona:

Opzione 1: Gli ingegneri analitici imparano l'elaborazione di flussi. Diventano esperti in checkpointing, backpressure, tempo di evento vs. tempo di elaborazione e semantica esattamente una volta. Questo funziona per piccoli team con persone senior. Non scala.

Opzione 2: Gli ingegneri della piattaforma possiedono tutto ciò che è a valle di Kafka. Gli ingegneri analitici scrivono specifiche SQL e il team della piattaforma le implementa in Flink o Spark. Questo preserva la separazione ma crea uno strato di traduzione. Le specifiche SQL sono ambigue sul comportamento in tempo di evento. Il team della piattaforma fa delle assunzioni. Quelle assunzioni diventano bug sei mesi dopo.

Opzione 3: Separare la logica di modellazione dalla responsabilità del runtime. Gli ingegneri analitici possiedono ciò che il modello significa — la logica aziendale, i test, i semantici. Gli ingegneri della piattaforma possiedono come viene eseguito — il motore di esecuzione, il backend di stato, il recupero dai fallimenti. Entrambi i lati concordano su un contratto: il modello si aspetta input ordinato entro un ritardo limitato e il runtime garantisce quel contratto o fornisce un errore chiaro.

Questa terza opzione è più difficile da impostare. Richiede che entrambi i team concordino su interfacce e modalità di fallimento in anticipo. Ma è l'unica che scala senza trasformare i tuoi ingegneri analitici in specialisti di sistemi distribuiti o il tuo team della piattaforma in lettori di mente.

Cosa richiede realmente "dbt in tempo reale"

Se il tuo team è serio riguardo al trasferimento di modelli in stile dbt in pipeline in tempo reale, ecco cosa ti serve realmente — non ciò che è nel deck di marketing:

Un runtime che comprende il tempo di evento. Non solo il tempo di elaborazione. Il tempo di evento. La differenza tra "quando è arrivato" e "quando è successo" è la differenza tra risultati corretti e risultati sottilmente errati che sembrano a posto su una dashboard.

Gestione dello stato esplicita. Finestratura, deduplicazione e sessionizzazione richiedono tutte uno stato. Quello stato deve essere checkpointato, recuperabile e interrogabile per il debugging. Se non puoi ispezionare ciò che il sistema pensava alle 14:47 di martedì scorso, non puoi risolvere un incidente in produzione.

Evoluzione dello schema con incisività. Aggiungere una colonna è facile. Gestire un cambiamento di tipo, un rinominare o uno spostamento semantico nel significato di una colonna è difficile. La tua pipeline deve rilevare questi cambiamenti, decidere se sono sicuri e adattarsi o fermarsi con un errore chiaro.

Riproduzione e riempimento come operazioni di prima classe. Nel batch, riprocessare significa rieseguire un job. Nello streaming, significa riavvolgere un log e riprodurre eventi attraverso la stessa logica. Se la tua pipeline in tempo reale non può riprodurre esattamente, non puoi recuperare dai bug, non puoi testare i cambiamenti contro i dati storici e non puoi dimostrare la conformità.

Visibilità dei costi per carico di lavoro. I costi batch sono facili da ragionare: questo job ha elaborato questa quantità di dati e ha impiegato questo tempo. I costi di streaming sono continui: il job è sempre in esecuzione, sempre consumando risorse, e il costo non si correla chiaramente con l'output aziendale. Hai bisogno di telemetria che colleghi la spesa dell'infrastruttura al comportamento della pipeline.

Nessuna di queste sono funzionalità SQL. Sono funzionalità di runtime. E sono la differenza tra una demo che gira per dieci minuti e un sistema che gira per dieci mesi.

Il pitch onesto

dbt ha cambiato il modo in cui lavorano i team di analisi. Ha portato pratiche di ingegneria del software — controllo di versione, test, documentazione — a una disciplina che ne aveva disperatamente bisogno. Quel contributo è reale e duraturo.

Ma dbt è stato costruito per un mondo in cui i dati si muovono in batch, i warehouse sono il centro di gravità e "fresco" significa "aggiornato quest'ora". L'industria si sta muovendo verso un mondo in cui i dati si muovono continuamente, i modelli sono applicati in volo e "fresco" significa "aggiornato questo millisecondo".

Questo non rende dbt obsoleto. Rende dbt incompleto per un insieme crescente di casi d'uso.

I fornitori che vendono "dbt in tempo reale" stanno rispondendo a una domanda reale. Ma ciò che stanno vendendo è di solito un'interfaccia SQL su un processore di flussi, non una soluzione ai problemi di runtime che l'elaborazione di flussi introduce. L'SQL è la parte facile. La gestione dello stato, il recupero dai fallimenti, l'evoluzione dello schema e l'osservabilità operativa sono le parti difficili. E quelle parti difficili non scompaiono solo perché l'SQL sembra familiare.

Se stai valutando uno di questi strumenti, non chiedere "Può eseguire i miei modelli dbt più velocemente?" Chiedi "Cosa succede quando un nodo si riavvia a metà finestra?" "Come faccio a riprodurre i dati di martedì scorso attraverso un modello che ho cambiato ieri?" "Cosa fa il sistema quando lo schema cambia alle 2 del mattino?"

Le risposte a queste domande ti diranno se stai acquistando uno strumento batch più veloce o un vero runtime di streaming.

Dove ci inseriamo

In layline.io, abbiamo costruito un runtime che gestisce sia batch che streaming nella stessa pipeline. Non due sistemi separati con una patina SQL su ciascuno. Un sistema in cui lo stesso team può costruire carichi di warehouse programmati e elaborazione di eventi in tempo reale senza cambiare strumenti, contesti o modelli mentali.

Gli ingegneri analitici mantengono la proprietà dei semantici del modello. Il team della piattaforma mantiene la proprietà dell'infrastruttura di esecuzione. Ma entrambi i lati lavorano nello stesso ambiente, con la stessa osservabilità e le stesse garanzie su riproduzione, recupero dello stato ed evoluzione dello schema.

dbt ha insegnato all'industria che la logica di modellazione merita rigore. Stiamo costruendo su quell'idea — e aggiungendo il rigore del runtime che i dati in tempo reale richiedono.

Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che in tempo reale su larga scala.