Eventhouse: il motore per la telemetria in Real-Time Intelligence

In Microsoft Fabric, l’Eventhouse è l’artefatto di Real-Time Intelligence progettato per ospitare uno o più KQL database ottimizzati per dati time-series, log ed eventi ad alto volume. A differenza di un Lakehouse o di un Warehouse, è pensato per ingestione continua a bassa latenza (streaming da Eventstream, IoT, log applicativi) e per query analitiche su miliardi di righe append-only. Un singolo Eventhouse condivide il compute tra i suoi KQL database, così più workload correlati beneficiano dell’elasticità e del caching senza provisioning separato.

Caching hot/cold e retention policy

Ogni tabella KQL è governata da due policy che, come scelta architetturale, vanno dimensionate insieme:

  • Caching policy (hot cache): quanti giorni di dati restano su SSD locale per query in millisecondi. Estenderla migliora le performance ma aumenta il compute consumato.
  • Retention policy: per quanto tempo i dati restano interrogabili prima dell’eliminazione. La hot cache è sempre minore o uguale alla retention.

Scenario tipico: interroghi di continuo gli ultimi 7 giorni ma devi conservarne 365 per compliance. Imposti hot cache = 7d, retention = 365d: i dati oltre 7 giorni scivolano in cold storage (query più lente ma comunque disponibili). Non serve un secondo store per lo storico.

Disponibilità in OneLake (Delta) e cross-engine

Attivando la OneLake availability, l’Eventhouse proietta le tabelle in OneLake come Delta Parquet. Questo abilita il cross-engine: notebook Spark, query T-SQL su Warehouse e Power BI Direct Lake leggono gli stessi dati senza copie manuali. È una proiezione logica adiacente al motore Kusto, non un secondo carico ETL da gestire.

KQL per l’analisi in tempo reale

KQL (Kusto Query Language) è un linguaggio a pipeline: si parte dalla tabella e si concatenano operatori con |. È read-optimized e progettato per l’esplorazione veloce della telemetria.

Operatori fondamentali

  • where — filtro (equivalente al WHERE SQL), da mettere il prima possibile per ridurre i dati scansionati.
  • summarize — aggregazione con by per il raggruppamento (count(), avg(), percentile()).
  • bin() — discretizza il tempo in finestre (time-window), es. bucket da 5 minuti.
  • make-series — genera serie temporali regolari con riempimento dei gap, ideale per anomaly detection e forecasting.
Telemetry
| where Timestamp > ago(1h) and Level == "Error"
| summarize Errori = count() by bin(Timestamp, 5m), Service
| render timechart

Per una serie continua da dare in pasto a funzioni come series_decompose_anomalies():

Telemetry
| make-series Reqs = count() default=0
    on Timestamp from ago(24h) to now() step 15m by Service

Quando KQL batte T-SQL o Spark

  • Telemetria e log ad alto volume: KQL scansiona time-series con hot cache in millisecondi, dove Spark paga overhead di startup del cluster.
  • Latenza near-real-time: dashboard Real-Time e alert su dati appena ingeriti — KQL non richiede un job batch.
  • Analisi time-series native: make-series, funzioni di serie e anomaly detection sono built-in, non librerie da importare.

Usi invece T-SQL/Warehouse per join transazionali complessi e modelli star, e Spark per trasformazioni pesanti, ML training e data engineering batch.

Trappole tipiche d’esame

  • Scenario: devi aggiornare/correggere record esistenti con frequenza (UPDATE/DELETE transazionali). → Risposta giusta: l’Eventhouse/KQL è ottimizzato per append e query di telemetria, non per update transazionali; scegli un Warehouse o Lakehouse per quel workload.
  • Scenario: interroghi spesso solo gli ultimi giorni ma devi conservare lo storico per un anno. → Configura hot cache breve (es. 7d) e retention lunga (es. 365d), non aumentare la hot cache all’intera retention (spreco di compute).
  • Scenario: un notebook Spark e Power BI devono leggere gli stessi dati dell’Eventhouse senza duplicarli. → Abilita la OneLake availability: i dati diventano Delta Parquet leggibili cross-engine, non serve un pipeline di copia.
  • Scenario: dashboard che deve mostrare metriche su eventi appena arrivati con latenza minima. → Usa un KQL database in Eventhouse con Real-Time Dashboard, non un job Spark batch schedulato.
  • Scenario: serve una serie temporale regolare con i buchi riempiti a zero per anomaly detection. → Usa make-series (non summarize by bin(), che lascia i gap vuoti).