Di Andrew Tan
La costosa verità sui moderni data stack
Passa abbastanza tempo con i team delle piattaforme dati e sentirai la stessa storia. Un'azienda costruisce il proprio "modern data stack" — data warehouse, processing layer, orchestrator — e tutto sembra pulito sul diagramma dell'architettura. Poi il conto del data warehouse inizia a salire. I job di ingestion falliscono più spesso di quanto previsto. E ogni volta che qualcosa si rompe, ci vuole mezza giornata per capire se il problema è nel load, nel reshape, nell'orchestrator o nel data warehouse stesso.
Ad un certo punto, qualcuno nel team dice ad alta voce la parte che tutti pensavano: "Credo che abbiamo costruito uno strumento di integrazione molto costoso per sbaglio."
Di solito ha ragione.
L'errore di categoria
Un data warehouse è un motore di query e storage. È ottimizzato per una cosa: rispondere rapidamente a domande analitiche su grandi dataset.
Una data pipeline è un runtime di movimento ed elaborazione. È ottimizzato per qualcosa di diverso: portare i dati da dove si trovano a dove devono essere, nella forma giusta, al momento giusto, in modo affidabile.
Sono lavori diversi. Ma nell'ultimo decennio abbiamo silenziosamente chiesto al data warehouse di farli entrambi.
È iniziato in modo innocuo. I data warehouse sono diventati più bravi a caricare dati. Poi hanno ottenuto stored procedures. Poi dbt ha trasformato SQL in un processing layer. Poi gli orchestrator hanno iniziato a triggerare query del data warehouse per spostare dati tra tabelle. E prima che qualcuno lo nominasse, il data warehouse era diventato lo strato di integrazione predefinito.
Il risultato è prevedibile. Il data warehouse è eccellente per l'analisi. È mediocre per l'integrazione. E quando lo costringi a fare integrazione su larga scala, lo paghi in tre valute: costo, affidabilità e fragilità architetturale.
Cosa va storto quando il data warehouse diventa la pipeline
Il conto del compute diventa una sorpresa
Il compute del data warehouse è tariffato per query analitiche. Gli analisti eseguono poche query grandi, aspettano i risultati e vanno a prendere decisioni. Il compute è a raffiche e a ritmo umano.
I workload di integrazione non sono così. Girano continuamente o su schedule stretti. Spostano milioni di righe. Eseguono le stesse conversioni ripetutamente. Non si fermano per lasciare agli umani il tempo di leggere le dashboard.
Quando esegui questo tipo di workload all'interno di un data warehouse, il contatore gira in modo diverso. È comune che una "semplice" sincronizzazione oraria consumi più crediti dell'intero workload analitico. Non perché il data warehouse sia cattivo, ma perché è il motore sbagliato per il lavoro.
I fallimenti diventano opachi
Una data pipeline ha un lavoro chiaro: prendere dati da A, trasformarli, consegnarli a B. Quando fallisce, vuoi sapere quale step è fallito e perché.
Quando il data warehouse è la pipeline, il fallimento è distribuito tra più strati. Il load era lento perché il data warehouse era sovraccarico? L'orchestrator ha perso la connessione? La query di reshape ha raggiunto un timeout? I dati sono sbagliati a causa della sorgente, della conversione o di una modifica al piano di esecuzione del data warehouse?
Il debug diventa archeologia. Scavi nella cronologia delle query, nei log dell'orchestrator e nelle metriche del data warehouse, cercando di ricostruire cosa sia effettivamente successo. Gli strumenti ci sono tutti. La chiarezza no.
La latency è quello che decide il data warehouse
Se la tua data pipeline è una serie di query del data warehouse, la tua latency è limitata dallo scheduling del data warehouse. Una query attende in coda. Viene compilata. Viene eseguita. Forse viene preemptata. Forse scala. Forse no.
Per l'analisi batch, va bene. A nessuno importa se un report notturno finisce alle 3:00 o alle 3:15.
Per i casi d'uso operativi, non va bene. Fraud detection, aggiornamenti di inventario, dashboard rivolte al cliente — questi hanno bisogno di minuti o secondi, non del tempo di coda del data warehouse. Quando il data warehouse è la tua data pipeline, erediti il suo ritmo. E il suo ritmo è progettato per gli analisti, non per le operazioni.
Il lock-in si approfondisce
Più logica di integrazione vive dentro il data warehouse, più diventa difficile uscirne. Le tue riscritture sono in dialetti SQL specifici del data warehouse. La tua orchestration è legata alle sessioni del data warehouse. Le tue regole di qualità dei dati girano come query del data warehouse. Anche la tua visibilità sui costi ha la forma del data warehouse.
Non è una cospirazione. È semplicemente ciò che succede quando un tool diventa responsabile di troppi lavori. Il costo di migrazione cresce finché sembra più facile restare infelici che andarsene.
Com'è fatta una separazione pulita
La soluzione non è buttare via il data warehouse. Il data warehouse è bravo in ciò che fa. La soluzione è lasciarlo fare ciò che fa e smettere di chiedergli tutto il resto.
In pratica, questo di solito significa due piattaforme, non una:
Runtime di integrazione e orchestrazione
Qui è dove i dati si muovono, vengono riformattati, validati e instradati verso i giusti consumatori. Pianifica anche le data pipeline, ritenta i fallimenti, impone le dipendenze e triggera il lavoro a valle — sia dentro la piattaforma che in sistemi esterni. Girano su un motore progettato per il flusso continuo di dati, non per la latency delle query.
Data warehouse
Qui è dove i dati vengono memorizzati e interrogati. Riceve dati puliti e pronti per l'interrogazione dallo strato di integrazione. Non si preoccupa di come i dati ci sono arrivati, quando arriverà il prossimo load o cosa fare se un job fallisce. Si limita a rispondere alle domande.
Logicamente, puoi ancora pensare all'integrazione e all'orchestrazione come a preoccupazioni separate. Operativamente, spesso appartengono allo stesso runtime. Una data pipeline che può spostare dati ma non può pianificarsi da sola, ritentare o triggerare lo step successivo è solo a metà utile. Le migliori piattaforme combinano entrambe.
Quando queste preoccupazioni sono separate dal data warehouse, ogni strumento diventa più semplice. Lo strato di integrazione è ottimizzato per throughput e affidabilità. L'orchestrator è ottimizzato per la gestione delle dipendenze e il ripristino dai fallimenti. Il data warehouse è ottimizzato per le prestazioni delle query.
Soprattutto, i problemi restano nel loro ambito. Quando l'ingestion fallisce, guardi all'integration runtime. Quando un report è sbagliato, guardi al data warehouse. Quando un job non gira, guardi all'orchestrator — che, in una configurazione pulita, fa parte dello stesso runtime che muove i dati.
Quando il data warehouse come pipeline va bene davvero
Non voglio esagerare. Per alcuni team, il pattern warehouse-as-pipeline funziona bene.
Se sei piccolo, i tuoi volumi di dati sono bassi, il tuo reshape è semplice e i tuoi requisiti di latency sono "domani va bene", tenere tutto in un unico posto è un tradeoff ragionevole. La semplicità operativa vale più della purezza architetturale.
I problemi iniziano quando il pattern continua a scalare oltre il suo limite naturale. Un team che lo supera di solito lo sa. I conti diventano strani. I fallimenti diventano misteriosi. L'idea di aggiungere un caso d'uso real-time diventa un progetto di mesi invece di una modifica di configurazione.
La domanda non è se il pattern sia cattivo. La domanda è se sia ancora il pattern giusto per dove sei ora.
Il percorso di migrazione che nessuno intraprende
La maggior parte dei team immagina questa separazione come un progetto di rip-and-replace. Non deve essere così.
L'approccio migliore è estrarre prima lo strato di movimento. Scegli una sorgente dati. Invece di caricarla direttamente nel data warehouse e poi riformattarla lì, spostala prima attraverso un integration runtime dedicato. Puliscila. Validala. Poi scrivi i dati puliti nel data warehouse.
Il data warehouse non cambia molto. Gli analisti continuano a interrogare le stesse tabelle. Ma ora quelle tabelle sono alimentate da una data pipeline progettata per alimentare tabelle.
Una volta spostata una sorgente, il pattern si ripete. Sorgente per sorgente. Data pipeline per data pipeline. Col tempo, il data warehouse smette di essere l'hub di integrazione e diventa ciò che era destinato a essere: l'hub analitico.
I team che hanno successo non iniziano con la data pipeline più difficile. Iniziano con una noiosa. Le data pipeline noiose ti insegnano il pattern senza il rischio. Le data pipeline difficili diventano più facili una volta che il pattern è in atto.
Dove si colloca layline.io
Sarò diretto: questa è la scommessa architetturale dietro layline.io.
Abbiamo costruito una piattaforma di data processing che gestisce lo strato di integration e orchestration — sia batch che streaming — senza fare fare il lavoro pesante al data warehouse. Le data pipeline muovono i dati, li riformattano, li validano e li consegnano. Pianificano anche se stesse, ritentano in caso di fallimento, impongono dipendenze e triggerano Workflow a valle dentro layline o in sistemi esterni.
Il data warehouse memorizza i dati e li interroga. Ogni tool fa il proprio lavoro.
Poiché layline.io gestisce sia batch che streaming nello stesso runtime, non finisci con un tool per i tuoi load orari e un altro per i tuoi eventi in tempo reale. Stessi Workflow. Stessa osservabilità. Stesso team. E poiché l'orchestrazione è integrata, non hai bisogno di un orchestrator separato sopra, che coordini tra layline.io e tutto il resto.
Questo non è un pitch per tutti. Se la tua configurazione warehouse-as-pipeline funziona e i tuoi conti sono ragionevoli, non hai bisogno di noi. Ma se stai fissando un conto del data warehouse triplicato e ti chiedi come una "semplice" sincronizzazione sia diventata così costosa, la separazione che stiamo descrivendo è probabilmente ciò che stai cercando davvero.
La domanda da fare al tuo team
Scegli i tuoi tre workload del data warehouse più costosi. Non le query analitiche più grandi — quelli che girano tutto il giorno, spostando e riformattando dati.
Chiedi: questi workload stanno rispondendo a domande di business, o stanno semplicemente portando i dati in una forma in cui possono rispondere a domande di business?
Se la risposta è la seconda, hai del lavoro di integrazione che gira in un motore analitico. Non è un difetto morale. È un'architettura molto comune. Ma è anche molto risolvibile.
Il data warehouse è uno strumento potente. Non è semplicemente l'unico strumento.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, che costruisce infrastrutture di data processing enterprise in grado di gestire carichi di lavoro sia batch che in tempo reale su larga scala.
