Eventstream nel workload Real-Time Intelligence

Eventstream è il componente di Microsoft Fabric Real-Time Intelligence che permette di ingerire, trasformare e instradare flussi di eventi senza scrivere codice, tramite un canvas visuale drag-and-drop. Lavora sul modello event-driven: gli eventi entrano da una o più sorgenti, attraversano un grafo di operatori di elaborazione e vengono scritti su una o più destinazioni. È il tassello che collega la telemetria in tempo reale al resto di Fabric (Eventhouse, Lakehouse, Data Activator).

Sorgenti supportate

Un eventstream può leggere da più tipi di source, tra cui:

  • Azure Event Hubs — la sorgente classica per streaming ad alto throughput; richiede consumer group e connection/authentication.
  • Azure IoT Hub — telemetria da dispositivi, con gestione della device identity.
  • Sample data — dataset simulati (es. yellow taxi, stock market) utili per prototipare e per gli scenari d’esame.
  • Custom endpoint (custom app) — un endpoint gestito che espone protocolli Event Hub / Kafka / AMQP, così un’applicazione può pubblicare eventi direttamente nell’eventstream.

Sono inoltre disponibili connettori CDC (Change Data Capture) per sorgenti come Azure SQL DB, PostgreSQL, Cosmos DB, per trasformare le modifiche a livello di riga in uno stream.

Trasformazioni no-code in streaming

Nella modalità Edit l’eventstream espone operatori che si applicano continuamente al flusso:

  • Filter — scarta o mantiene eventi in base a condizioni.
  • Aggregate — calcoli su tumbling/hopping/sliding window (SUM, AVG, COUNT su finestre temporali).
  • Join — correla due stream su una chiave entro una finestra temporale.
  • Expand — “esplode” un array annidato in più righe.
  • Operatori di supporto: Manage fields, Union, Group by, Derived column.

Il punto architetturale ASSOCIATE è capire che queste trasformazioni sono stateful e temporali: una aggregazione richiede sempre una window definition, perché su uno stream infinito non esiste un “totale” senza una finestra.

Destinazioni

  • Eventhouse / KQL database — destinazione primaria per l’analisi real-time; i dati diventano immediatamente interrogabili in KQL. Supporta ingestion diretta (bypassa gli operatori, latenza minima) oppure post-trasformazione.
  • Lakehouse — scrive in formato Delta per l’analisi batch e l’integrazione con notebook Spark / semantic model.
  • Data Activator (Activator) — instrada gli eventi verso regole di alerting e automazione (trigger su soglie, azioni verso Teams, email, Power Automate).
  • Ulteriori destinazioni: Derived stream, Custom endpoint, Stream riutilizzabile a valle.

Scegliere il motore streaming

DP-700 verifica spesso quale engine usare per uno scenario:

  • Eventstream — quando serve ingestione e routing no-code, con trasformazioni semplici e integrazione nativa con Eventhouse/Activator. È la scelta di default per pipeline real-time senza sviluppo.
  • KQL (update policy / materialized view nell’Eventhouse) — quando la trasformazione va fatta dopo l’ingestion, sui dati già dentro Eventhouse, con logica analitica ricca (parsing, enrichment, aggregazioni continue lato query engine).
  • Spark Structured Streaming (notebook su Lakehouse) — quando serve logica complessa/custom in codice (PySpark/Scala), machine learning inline, join con tabelle Delta di grandi dimensioni o output verso Delta con controllo fine su checkpoint e trigger.

Regola pratica: no-code + routing → Eventstream; analisi KQL sui dati caldi → Eventhouse; codice custom / ML / Delta pesante → Spark.

La trappola della destinazione Lakehouse

Anche se l’eventstream è “streaming”, la destinazione Lakehouse scrive i dati in Delta tramite micro-batch: gli eventi vengono bufferizzati e materializzati in tabelle Delta a intervalli. Questo introduce una latenza dell’ordine dei minuti, non millisecondi. Quindi il Lakehouse è ideale per analisi near-real-time e batch, non per dashboard o alert a latenza minima. Per il vero real-time la destinazione corretta è Eventhouse/KQL (o Data Activator per l’alerting immediato).

Trappole tipiche d’esame

  • “Serve latenza sub-secondo e query KQL immediate sulla telemetria” → destinazione Eventhouse/KQL database, non Lakehouse (il Lakehouse micro-batcha in Delta con latenza di minuti).
  • “Aggregare eventi ogni 5 minuti senza scrivere codice” → operatore Aggregate con tumbling window dentro Eventstream, non un notebook Spark.
  • “Attivare un alert su Teams quando la temperatura supera una soglia” → destinazione Data Activator, non una query pianificata.
  • “Join in streaming con logica ML custom e output su tabelle Delta grandi” → Spark Structured Streaming, perché Eventstream no-code non copre logica arbitraria/ML.
  • “Un’app deve pubblicare eventi direttamente in Fabric” → source Custom endpoint (app) con protocollo Event Hub/Kafka/AMQP, non un file upload né IoT Hub.