Architettura di analisi in tempo reale: livelli, pattern e compromessi

Architettura di analisi in tempo reale: livelli, pattern e compromessi

Un’architettura di analisi in tempo reale trasferisce continuamente gli eventi dal luogo in cui si verificano a quello in cui qualcuno può intervenire, invece di attendere un processo notturno. In pratica, comprende quattro livelli: acquisizione, elaborazione dei flussi, un archivio per la distribuzione dei dati e un livello di fruizione, come dashboard, API o avvisi. La parte difficile raramente consiste nello scegliere gli strumenti. Consiste nel decidere quanto debba essere realmente aggiornata ogni risposta e nel pagare solo per quel livello di aggiornamento.

Questa guida illustra i livelli, i pattern Lambda e Kappa, le decisioni di progettazione che causano problemi in produzione e un approccio per dimensionare correttamente la soluzione. È pensata per i responsabili aziendali, operativi e tecnologici che sponsorizzeranno o valuteranno questo tipo di sistema, non solo per gli ingegneri che lo realizzeranno.

Punti chiave

• Un’architettura di streaming ha quattro livelli: acquisizione, elaborazione, distribuzione e fruizione. La latenza si accumula in tutti questi livelli, quindi la misuri dall’inizio alla fine.
• Parta dalla decisione, non dalla tecnologia. Un controllo antifrode e una dashboard dell’inventario richiedono livelli di aggiornamento molto diversi, e la curva dei costi è ripida.
• Kappa (un’unica pipeline di streaming) è adatto alla maggior parte dei nuovi progetti. Lambda (elaborazione batch più streaming) giustifica il costo aggiuntivo solo quando devono coesistere due standard di accuratezza.
• I dati in ritardo, la contropressione, le modifiche allo schema e la governance sono ciò che compromette i sistemi dopo il lancio. Progetti per gestirli fin dal primo giorno.
• Un dimensionamento corretto è migliore del massimalismo. Molti team hanno bisogno di minuti, non di millisecondi.

Indice

• Che cos’è un’architettura di analisi in tempo reale
• I quattro livelli e il modo in cui i dati li attraversano
• Streaming e batch: che cosa cambia davvero
• Lambda e Kappa: quale pattern è adatto
• Le decisioni di progettazione che determinano la solidità della soluzione
• Un percorso dimensionato correttamente dall’idea alla produzione
• Come aiuta Ridiculous Engineering
• Domande frequenti
• Fonti

Che cos’è un’architettura di analisi in tempo reale

I sistemi batch raccolgono i dati, attendono un processo pianificato e pubblicano i risultati ore dopo. Un sistema in tempo reale tratta i dati come un flusso continuo: ogni evento viene acquisito, elaborato e reso interrogabile entro pochi secondi o meno. Le indicazioni di AWS Well-Architected per l’analisi descrivono i componenti fondamentali di una progettazione di streaming come origini dati, acquisizione del flusso e produttori (ad esempio, change data capture o Kafka Connect), archiviazione del flusso (ad esempio, Kafka o Kinesis), elaborazione del flusso (ad esempio, Flink o Spark) e destinazioni a valle, come illustrato nella sua architettura di riferimento per lo streaming.

Questo elenco è una checklist utile per la prima sessione alla lavagna. Se una proposta di un fornitore omette una di queste caselle, chieda dove risiede quella responsabilità.

“Tempo reale” è prima di tutto un termine aziendale, non tecnico

Non tutto deve essere disponibile in millisecondi. Un controllo antifrode sui pagamenti potrebbe richiedere una risposta in molto meno di un secondo. Una visualizzazione dell’inventario di magazzino può essere perfettamente utile anche se si aggiorna ogni pochi minuti. Un report dirigenziale settimanale potrebbe non richiedere affatto lo streaming.

Prima di qualsiasi diagramma dell’architettura, annoti per ogni caso d’uso:

1. La decisione o l’azione supportata dai dati.
2. Chi o che cosa intraprende quell’azione (una persona, un’applicazione, una regola automatizzata).
3. Quanto possono essere obsoleti i dati prima che la decisione peggiori.
4. Quanto costa una risposta errata o incompleta.

Queste quattro risposte definiscono il Suo budget di latenza. Tutto ciò che segue è progettato per rispettarlo, e non per essere più restrittivo.

I quattro livelli e il modo in cui i dati li attraversano

1. Acquisizione: catturare e memorizzare nel buffer

Gli eventi provengono da database applicativi, clic degli utenti, sistemi di pagamento, sensori IoT, log e API di terze parti. L'acquisizione li cattura in modo affidabile e li colloca in un luogo durevole. Due approcci comuni:

• Pubblicazione degli eventi dalle applicazioni. L'applicazione emette un evento aziendale («ordine effettuato») in un flusso. La semantica è chiara, ma sono necessarie modifiche al codice dell'applicazione.
• Change Data Capture (CDC). Un connettore legge il log delle modifiche del database e pubblica ogni inserimento o aggiornamento. È meno invasivo per i sistemi legacy, motivo per cui ricorre così spesso nei progetti di modernizzazione.

Il buffer è importante quanto l'acquisizione. Una piattaforma di streaming funziona come un log distribuito, in sola aggiunta, in cui gli eventi vengono conservati per un periodo configurabile, da ore a mesi o persino a tempo indeterminato, e rimangono disponibili per essere letti da qualsiasi consumer, come descrive una guida di settore sulle applicazioni di analisi in tempo reale La conservazione è ciò che consente di riprodurre la cronologia dopo la correzione di un bug o di aggiungere in seguito un nuovo consumer senza toccare il sistema di origine. Per una prospettiva ingegneristica più approfondita su questo livello, la nostra guida pratica allo streaming degli eventi con Kafka illustra topic, partizioni e garanzie di consegna.

2. Elaborazione: convalidare, arricchire, aggregare

Il livello di elaborazione trasforma gli eventi grezzi in qualcosa di utile: li convalida, li associa ai dati di riferimento, calcola totali progressivi, rileva schemi o li valuta con un modello. Le indicazioni di Microsoft sulla scelta di una tecnologia per l'elaborazione dei flussi sottolineano che la decisione dipende spesso dal fatto che sia necessaria un'elaborazione con stato o senza stato e dal fatto che servano finestre temporali, a blocchi (fisse e non sovrapposte) oppure scorrevoli (sovrapposte), per le aggregazioni basate sul tempo.

In termini semplici:

• Senza stato le operazioni (filtro, analisi sintattica, trasformazioni semplici) sono economiche e facili da scalare.
• Con stato le operazioni («numero di accessi non riusciti per utente negli ultimi cinque minuti») devono conservare informazioni, con ripercussioni su memoria, ripristino e costi.
• Le finestre definiscono «gli ultimi cinque minuti» e sono all'origine della maggior parte delle sorprese relative alla correttezza.

3. Distribuzione: un archivio progettato per la domanda

I dati elaborati vengono depositati in un archivio scelto in base al modo in cui verranno interrogati. Non esiste un'unica risposta corretta:

Per il caso delle ricerche, lo scenario di riferimento di Microsoft per un lakehouse quasi in tempo reale denormalizza i dati in un archivio NoSQL come Azure Cosmos DB per supportare risposte API nell'ordine di pochi millisecondi. Per il caso del lakehouse, lo stesso scenario utilizza Delta Lake, che offre semantica ACID e un'elaborazione unificata di streaming e batch su un data lake.

Il principio progettuale: strutturare i dati in funzione di chi li legge. Preaggregare e denormalizzare in fase di scrittura è ciò che rende rapide le letture.

4. Consumo: dashboard, API, avvisi e modelli

È qui che l’azienda vede il valore e dove i requisiti di latenza variano maggiormente. Una schermata operativa in tempo reale, una metrica visibile ai clienti all’interno del prodotto, un avviso inviato al responsabile di turno e un flusso di dati per un modello di machine learning leggono tutti dal livello di serving in modo diverso. Pianificate prima i consumer e procedete a ritroso.

Un dashboard di cui nessuno si fida o che nessuno comprende rende inutile l’intera pipeline. Chi legge i dati in tempo reale deve anche saperli interpretare; per questo alcune organizzazioni affiancano al lancio di una piattaforma un corso di formazione sull’analisi web per gli analisti e i responsabili che utilizzeranno quotidianamente i dashboard. La nostra guida a analisi self-service approfondisce ulteriormente come far funzionare quest’ultimo passaggio.

La latenza è la somma di ogni fase

È allettante fare un benchmark del motore di elaborazione e considerare il lavoro concluso. Tuttavia, la latenza end-to-end è il totale di acquisizione, transito di rete, buffering, elaborazione, scrittura nell’archivio, tempo di esecuzione delle query e aggiornamento del dashboard. Strumentate ogni passaggio con timestamp fin dal primo giorno. Quando uno stakeholder dice «il dashboard sembra lento», dovete sapere quale fase ha assorbito quei secondi.

Streaming e batch: che cosa cambia davvero

Al di là dell’aggiornamento dei dati, i due modelli comportano compromessi ingegneristici diversi. Le ricerche sull’argomento sottolineano che i motori di streaming devono gestire compromessi tra latenza e throughput: confermare i messaggi uno alla volta per garantire la consegna aggiunge overhead ed è meno efficiente dell’elaborazione in batch, secondo l’analisi IEEE di Jimmy Lin sulle architetture Lambda e Kappa.

Questo ha conseguenze pratiche per la pianificazione:

• Lo streaming costa più per record rispetto al batch quando viene eseguito ininterrottamente. Se un aggiornamento ogni ora è sufficiente per prendere la decisione, il batch è la scelta più corretta.
• Lo streaming impone di gestire aspetti che il batch nasconde: eventi fuori ordine, consegne duplicate e risultati parziali.
• Le attività operative cambiano. Un job notturno che non riesce può essere eseguito di nuovo al mattino. Un flusso che si blocca alle 2 di notte è un incidente.

Un approccio ibrido è normale. Molte aziende trasmettono in streaming il 10% dei dati che alimenta decisioni sensibili al fattore tempo e gestiscono il resto in batch.

Lambda e Kappa: quale modello è adatto

Questi due nomi emergono in quasi ogni revisione architetturale, quindi vale la pena essere precisi.

Lambda è stata proposta da Nathan Marz intorno al 2011. Esegue fianco a fianco un livello batch e un livello real-time transitorio, con un livello di fusione che combina i relativi risultati. Il livello batch fornisce alla fine risposte accurate e complete. Il livello speed fornisce subito risposte approssimative.

Kappa è stata proposta da Jay Kreps in un post del 2014. Utilizza un unico motore di stream processing per tutti i dati ed evita la complessità della doppia pipeline di Lambda. I dati storici vengono rielaborati riproducendo il log attraverso lo stesso codice. Entrambe le descrizioni provengono dal documento di Lin.

Il compromesso reale

La logica duplicata è il vero costo di Lambda. Quando due codebase calcolano i “ricavi”, prima o poi non coincideranno e qualcuno passerà una settimana a capire perché.

La nostra raccomandazione per la maggior parte dei nuovi sistemi: iniziare con un approccio Kappa. Conservate un log degli eventi duraturo, scrivete la logica una sola volta e riproducetela quando dovete correggere la cronologia. Aggiungete un percorso batch separato solo quando avete un motivo documentato, ad esempio il requisito che la fatturazione sia esatta mentre un dashboard operativo tolleri piccoli errori. Le moderne tabelle lakehouse che gestiscono streaming e batch sugli stessi dati riducono ulteriormente il divario, perché offrono un unico livello di archiviazione con due modalità di lettura.

Decisioni progettuali che determinano la solidità della soluzione

Il diagramma appare uguale in tutti i progetti. Le differenze che contano sono riportate di seguito.

Dati in ritardo e fuori ordine

Gli eventi non arrivano nell'ordine in cui si sono verificati. I dispositivi mobili vanno offline, le reti accumulano ritardi e i sistemi a monte riprovano. I processori di stream gestiscono questo problema con watermark: una stima mobile dell'avanzamento del tempo degli eventi, utilizzata per decidere quando una finestra è sufficientemente completa da essere pubblicata.

Il compromesso è diretto. Un watermark ravvicinato pubblica rapidamente i risultati, ma perde o gestisce in modo errato gli eventi tardivi. Uno più permissivo attende più a lungo, migliorando la completezza ma aumentando il ritardo e lo stato che il sistema deve mantenere. Scegliete il valore in base al ritardo osservato nei vostri dati effettivi, non in base a un valore predefinito. Decidete poi esplicitamente cosa accade agli eventi che arrivano dopo la chiusura della finestra: scartarli, instradarli verso un percorso di correzione o aggiornare il risultato.

Backpressure e durabilità

Cosa accade quando un archivio a valle rallenta? Senza un piano, la risposta è la perdita di dati o un guasto a cascata. Una buona pipeline memorizza temporaneamente i dati nel log duraturo, rallenta i produttori o aumenta i consumatori e avvisa qualcuno, invece di eliminare i record senza segnalarlo. Chiedete al vostro team di dimostrarlo rallentando deliberatamente un consumatore in un ambiente di test.

Garanzie di consegna

“Exactly once” è l'obiettivo per tutto ciò che riguarda aspetti finanziari o l'inventario, ma è una proprietà dell'intera pipeline, non di un singolo componente. Quando non può essere garantito dall'inizio alla fine, progettate scritture idempotenti, in modo che la riproduzione di un evento non lo conteggi due volte.

Modifiche allo schema e qualità dei dati

I produttori modificano i formati degli eventi, di solito senza preavviso. Utilizzate un registro degli schemi, convalidate i dati all'acquisizione e inviate i record non validi a uno stream di quarantena con un avviso, invece di permettere che contaminino le tabelle a valle. La stessa disciplina applicata ai rilasci delle applicazioni vale anche qui: il nostro approfondimento su CI/CD per le pipeline di dati mostra come i controlli dello schema vincolati alle pull request intercettino le modifiche incompatibili prima che raggiungano la produzione.

Sicurezza e governance

Lo streaming non vi esonera dalla governance. Anzi, aumenta la posta in gioco, poiché i dati si spostano più velocemente di quanto possa fare una revisione manuale. Considerate il controllo degli accessi, la crittografia, la conservazione, la provenienza e la titolarità dello schema come parti dell'architettura, in particolare in contesti regolamentati come sanità, finanza e pubblica amministrazione, dove la governance deve operare allo stesso ritmo dei dati. Stabilite chi è responsabile di ogni tipo di evento, chi può leggerlo e per quanto tempo viene conservato prima che fluisca il primo evento.

Portate l'intelligenza ai margini quando consente di risparmiare

Per telecamere, sensori e macchine che producono grandi volumi di dati, filtrate i dati ed eseguite localmente l'inferenza, inviando a monte solo aggregati o eccezioni. Questo riduce la larghezza di banda e la spesa per il cloud e accorcia i tempi di risposta per le azioni locali.

Un percorso adeguato dalle idee alla produzione

La maggior parte dei progetti in tempo reale falliti non aveva scelto la tecnologia sbagliata. Aveva cercato di trasmettere tutto in streaming contemporaneamente. Una sequenza efficace è la seguente:

1. Scegliete una decisione. Ad esempio, segnalare gli ordini bloccati entro due minuti oppure mostrare i livelli delle scorte in tempo reale per ogni magazzino. Definite il budget di latenza e il costo di una risposta errata.
2. Mappate le origini. Quali sistemi contengono gli eventi? Potete pubblicarli o vi serve il CDC? Quali di questi sistemi sono abbastanza datati da rendere difficile questa operazione?
3. Costruite il vertical slice più essenziale. Una fonte, un job di elaborazione, un archivio di servizio e un consumatore, con strumentazione per misurare i tempi dall'inizio alla fine.
4. Aggiungete i percorsi di errore. Dati in ritardo, riproduzione, quarantena, avvisi e un runbook per lo stream bloccato.
5. Misurate il risultato. La decisione è migliorata? Meno esaurimenti delle scorte, blocchi antifrode più rapidi, tempi di risposta più brevi? Se il numero non cambia, fermatevi prima di aumentare la scala.
6. Espandete con criterio. Aggiungete fonti e consumatori uno alla volta, riutilizzando la piattaforma.

Il caso aziendale alla base di questo approccio è trattato nella nostra panoramica di perché i dati in tempo reale cambiano il modo in cui operano le aziende. In breve: il vantaggio deriva da decisioni più rapide, non dalla tecnologia di streaming in sé.

Sviluppare, acquistare o combinare

I servizi cloud gestiti riducono il lavoro operativo, ma aumentano il vincolo verso il fornitore e i costi ricorrenti. I motori open source offrono controllo, ma richiedono persone che li gestiscano. Il codice personalizzato sviluppato attorno a una di queste soluzioni è ciò che racchiude la logica aziendale e le differenze competitive. La combinazione giusta dipende dalle dimensioni del team, dai requisiti di conformità e dal numero di sistemi da collegare. Diffidate di qualsiasi approccio che non sappia spiegare cosa succede alle 2 di notte quando qualcosa si guasta.

Come Ridiculous Engineering aiuta

Progettiamo e realizziamo i componenti che si collocano tra il problema aziendale e un sistema funzionante: acquisizione di eventi da fonti legacy e moderne, pipeline di elaborazione, sistemi di archiviazione per la distribuzione dei dati, dashboard e applicazioni che vi si basano. Il nostro lavoro di analisi dei dati e business intelligence parte dalla decisione che desiderate migliorare e dalla latenza realmente necessaria, quindi dimensiona l'architettura di conseguenza. Quando il destinatario è un'applicazione o un flusso di lavoro, il nostro team di sviluppo software personalizzato realizza quella parte con gli stessi ingegneri senior, mentre il nostro lavoro di sviluppo dell'IA e automazione si occupa di modelli e azioni automatizzate alimentati da dati in tempo reale. Il prezzo dipende dall'ambito del progetto, quindi il passo successivo consiste nel discutere il vostro caso d'uso e preparare un preventivo.

Domande frequenti

Qual è la differenza tra analisi in tempo reale e analisi in streaming?

Nell'uso quotidiano, i termini si sovrappongono. Lo streaming descrive la tecnica: l'elaborazione continua degli eventi man mano che arrivano. Il tempo reale descrive il risultato: dati abbastanza aggiornati da consentire un'azione entro un intervallo temporale definito da voi. È possibile trasmettere i dati in streaming e fornire comunque risultati ogni pochi minuti, il che spesso è tutto ciò di cui l'azienda ha bisogno.

Devo scegliere Lambda o Kappa?

Per la maggior parte dei sistemi nuovi, iniziate con Kappa: un'unica pipeline di streaming, logica scritta una sola volta e rielaborazione dello storico riproducendo un log persistente. Scegliete Lambda solo quando due utilizzatori necessitano di garanzie di accuratezza diverse, ad esempio dati di fatturazione esatti insieme a una dashboard live con una certa tolleranza. Valutate questa scelta rispetto al costo di mantenere due percorsi di codice.

Quanto deve essere veloce il mio sistema?

Partite dalla decisione e procedete a ritroso. Un controllo antifrode può richiedere risposte in meno di un secondo, mentre una dashboard delle scorte o delle vendite può essere aggiornata senza problemi ogni pochi minuti. Ogni riduzione della latenza aumenta i costi e l'impegno operativo, quindi definite l'obiettivo in base al valore della decisione, non a ciò che gli strumenti sono in grado di fare.

Abbiamo bisogno di Kafka?

Non sempre. La funzionalità importante è un log degli eventi persistente e riproducibile, e Kafka è un modo comune per ottenerla. Se i volumi sono contenuti e le fonti sono poche, può essere sufficiente un servizio di streaming gestito o persino l'elaborazione frequente in micro-batch. La nostra guida a Kafka per ingegneri può aiutarvi a valutarlo.

Cosa si guasta più spesso dopo il lancio?

Le cause più comuni sono le modifiche allo schema a monte, gli eventi in ritardo o duplicati e i sistemi di archiviazione a valle lenti, che creano backpressure. La convalida durante l'acquisizione, le scritture idempotenti, un percorso di quarantena per i record non validi e gli avvisi sulla latenza risolvono la maggior parte di questi problemi.

Fonti

• Architettura di riferimento, Data Analytics Lens (AWS Well-Architected)
• Scegliere una tecnologia di stream processing (Microsoft Learn)
• Elaborazione di dati lakehouse quasi in tempo reale (Microsoft Learn)
• Lambda e Kappa (Jimmy Lin, IEEE 2017)
• Creare applicazioni di analisi in tempo reale
• Corso di formazione sull'analisi web

Consigliato

• Dati in tempo reale: una svolta per le aziende
• Data Mesh e Data Fabric: scegliere l’architettura giusta
• Progettazione di un livello semantico pronto per la produzione: una guida pratica
• Stack di dati moderno: una roadmap pratica per chi prende decisioni