Di Andrew Tan
Ero a una conferenza l'anno scorso quando un architetto di dati — Fortune 500, grande team, budget serio — mi ha preso da parte e mi ha raccontato una storia che ho sentito troppe volte ormai.
Hanno impiegato 14 mesi per migrare a Kafka. Assunto un nuovo team. Creato una nuova infrastruttura. Costruito un intero nuovo turno di reperibilità. Tutto il necessario.
Sei mesi dopo il lancio, hanno silenziosamente riportato metà dei pipeline al batch.
Kafka non si è rotto. Ha funzionato bene. Il problema era più banale di così: nessuno utilizzava i dati in tempo reale. I dashboard venivano ancora controllati alle 9 del mattino. I report venivano ancora eseguiti settimanalmente. I modelli di Machine Learning venivano ancora riaddestrati durante la notte. Avevano costruito un'auto di Formula 1 per andare al supermercato.
La Conferenza Che Ha Lanciato Mille Migrazioni
Ecco come di solito inizia. Qualcuno del team guarda una conferenza — probabilmente a velocità 2x su YouTube — dove un ingegnere FAANG descrive il loro pipeline in tempo reale. Miliardi di eventi al secondo. Latenza sotto il millisecondo. Dashboard che si aggiornano come nel Matrix.
Quell'ingegnere torna in ufficio ispirato. "Dovremmo farlo." Il team annuisce. Il CTO ama la parola "real-time" nella roadmap trimestrale. Nasce un'epica su Jira.
Quello che nessuno chiede: qualcuno in questo edificio ha davvero bisogno di dati più veloci di quanto li stia ottenendo oggi?
Non "sarebbe bello." Non "sembra più moderno." Una persona specifica, che prende una decisione specifica, ottiene risultati misurabilmente peggiori perché i dati hanno un'ora di ritardo invece di un secondo?
Nove volte su dieci, la risposta onesta è no. E l'unica volta che è sì, di solito è un solo pipeline — non l'intera piattaforma.
La Lista della Spesa
Prima di migrare qualsiasi cosa, fai una lista. Sono serio — apri un foglio di calcolo. Per ogni pipeline, rispondi a tre domande:
Chi consuma questi dati? Un nome. Un team. Un sistema. Se non puoi nominare il consumatore, il pipeline potrebbe non aver bisogno di esistere affatto, figuriamoci in tempo reale.
Cosa ne fanno e quando? Se la risposta è "controllano un dashboard ogni mattina" o "alimenta un report il venerdì," lo streaming non cambierà il risultato. Stai solo rendendo l'impianto idraulico più costoso per la stessa acqua.
Cosa si rompe se questi dati sono in ritardo di 1 ora? 1 giorno? Questa è l'unica domanda che effettivamente separa il batch dallo streaming. Se la risposta a entrambe è "niente, davvero," hai un carico di lavoro batch travestito da streaming.
La maggior parte dei team scopre che l'80% dei loro pipeline va benissimo come batch. Il restante 20% è dove le cose diventano interessanti.
Dove la Velocità Conta Davvero
Alcuni dati si deteriorano davvero. Come il latte, non il vino.
Rilevamento delle frodi è l'esempio ovvio. Una transazione con carta di credito segnalata cinque minuti dopo il fatto non è rilevamento delle frodi — è notifica di frode. I soldi sono già andati. Se il tuo pipeline di frode funziona in batch, stai scrivendo lettere di scuse invece di bloccare le porte.
La nostra soluzione di rilevamento delle frodi gestisce la valutazione in tempo reale con latenza sotto i 100 ms.
Allarmi operativi — se il tuo sensore IoT ti dice che una turbina si sta surriscaldando, quell'informazione ha una durata misurata in secondi. Un lavoro batch orario qui non è solo lento. È negligente.
Prezzi e inventario in mercati competitivi. Se il tuo concorrente aggiorna i prezzi ogni 30 secondi e tu aggiorni ogni 6 ore, non stai competendo. Stai spettando.
Flussi di eventi multi-consumatore dove l'economia si compone. Un argomento Kafka che alimenta tre sistemi a valle può essere più economico di tre lavori batch separati che estraggono dallo stesso database. Lo streaming si guadagna qui non attraverso la velocità, ma attraverso l'eleganza dell'architettura.
Il modello: in ogni caso, c'è un costo specifico e misurabile per il ritardo. Non una sensazione vaga. Un numero.
I Costi Che Nessuno Mette nell'Epica di Jira
L'infrastruttura di streaming ha un modello di pricing che sembra ottimo sulla slide del fornitore e terribile sui risultati effettivi del Q3.
Funziona 24/7. Il tuo lavoro batch funziona per 4 ore e dorme. Il tuo lavoro di streaming funziona tutto il giorno, tutta la notte, nei weekend, nei giorni festivi. Anche se il volume totale dei dati è identico, il conto del calcolo non lo è. Un team che conosco è passato da un setup batch di $2,000/mese a uno di streaming di $11,000/mese — elaborando gli stessi dati, consegnandoli nello stesso posto, consumati alla stessa cadenza.
Il debug passa dall'archeologia alla fisica quantistica. Quando un lavoro batch fallisce, ottieni un trace dello stack, un record errato e un chiaro percorso di riesecuzione. Quando un lavoro di streaming produce un output errato, potrebbe non "fallire" affatto. Alimenta semplicemente silenziosamente spazzatura a valle finché qualcuno non nota che il dashboard delle entrate sembra strano tre giorni dopo.
I cambiamenti di schema diventano una negoziazione diplomatica. Nel batch, versioni il tuo codice, testi sui dati storici e pubblichi. Nello streaming, cambiare un campo significa coordinare ogni produttore e consumatore simultaneamente su un sistema live. Se sbagli l'ordine, stai debugando la corruzione dei dati alle 2 del mattino.
La tassa di reperibilità è reale. Lag del consumatore, skew delle partizioni, failover dei broker — questi non sono casi limite rari, sono il martedì. Se il tuo team è già sovraccarico, lo streaming non risolve il problema. Lo moltiplica.
Un Framework Che Aiuta Davvero
Ecco cosa consiglierei. Ci vogliono circa due ore con le persone giuste nella stanza.
Passo 1: Nomina le decisioni. Per ogni pipeline, identifica la decisione aziendale specifica che supporta. Non "analisi" — la decisione effettiva. "Approva o rifiuta questa transazione." "Riordina questo SKU." "Avvisa la squadra di manutenzione." Se non puoi nominarla, il batch va bene.
Passo 2: Cronometra le decisioni. Quanto spesso viene presa quella decisione? Ogni secondo? Ogni ora? Ogni lunedì? Abbina la cadenza del pipeline alla cadenza della decisione. Una consegna sotto il secondo per una decisione giornaliera è uno spreco.
Passo 3: Valuta il ritardo. Quanto costa un ritardo di un'ora, in dollari? Questa è la domanda più difficile e più importante. Se la risposta è "non lo sappiamo" o "probabilmente nulla," non hai un caso d'uso per lo streaming. Hai un desiderio di streaming.
Passo 4: Inizia con uno. Scegli il pipeline con il costo di ritardo più chiaro. Migralo. Eseguilo insieme alla versione batch per un ciclo completo. Confronta. Risolvi ciò che si rompe. Poi decidi se espandere.
I team che fanno bene questo processo di solito finiscono con 2-3 pipeline di streaming e 15 batch. I team che saltano questo processo finiscono con 18 pipeline di streaming, un team operativo esausto e una silenziosa migrazione di ritorno al batch sei mesi dopo.
Non È Un'Alternativa
Ecco cosa la maggior parte dei fornitori di streaming non ti dirà: le migliori architetture di dati sono noiose. Non sono tutte-streaming o tutte-batch. Sono un mix, scelto pipeline per pipeline, in base a ciò che i dati devono effettivamente fare.
Batch per i report. Batch per l'addestramento di Machine Learning. Batch per qualsiasi cosa dove "giornaliero" è abbastanza veloce e la semplicità ti fa risparmiare $8,000 al mese in costi operativi.
Streaming per le frodi. Streaming per gli allarmi operativi. Streaming per i pochi pipeline dove il ritardo ha un segno di dollaro allegato.
Questo è esattamente il motivo per cui abbiamo costruito layline.io nel modo in cui l'abbiamo fatto. Gestisce sia batch che streaming nella stessa piattaforma — stessi Workflow, stessi strumenti, stesso team. Non devi scegliere un mondo e abbandonare l'altro. Inizi con ciò che hai, aggiungi il tempo reale dove ne vale la pena e mantieni il batch dove ha senso. Nessuna sostituzione totale. Nessun aut aut.
Il diagramma dell'architettura non vincerà nessuna conferenza. Ma il team va a casa alle 17 e il turno di reperibilità dorme davvero tutta la notte.
Questo è il tipo di noia che scala.
Se stai valutando quali pipeline appartengono al tempo reale e quali sono perfettamente adatti al batch, layline.io ti consente di eseguire entrambi su una singola piattaforma — così puoi convalidare il caso aziendale prima di impegnare l'infrastruttura. Parla con noi della tua architettura specifica.
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.
