Real-Time: Databricks vs Microsoft Fabric o Spark vs Kusto Databricks o Microsoft Fabric per realizzare architetture per l’analisi dei dati in (Near) Real-Time ?

Una domanda che sorge spontanea quando pensiamo di realizzare un architettura per la gestione di dati in streaming su Microsoft Azure.

Stiamo assistendo all’evoluzione delle architetture dati moderne dove possiamo osservare una progressiva convergenza tra i paradigmi batch e streaming, guidata dalla necessità di ridurre il “Time-to-Insight” e abilitare processi decisionali istantanei. Nel panorama attuale, due piattaforme emergono come leader indiscussi in ambito Azure, proponendo tuttavia filosofie architetturali divergenti, Databricks si basa sul motore Apache Spark e l’architettura Lakehouse, Microsoft Fabric invece ci propone un ecosistema unificato SaaS basato su molteplici motori specializzati, tra cui spicca Kusto per la Real-Time Intelligence.

batch_and_streaming_processing

Databricks: Engine Spark e la Flessibilità Computazionale

Databricks si basa su Apache Spark Structured Streaming per la gestione dei processi Real-Time.

La modalità predominante in Spark è il Micro-batch (default). Il sistema accumula dati per un intervallo di trigger definito (es. 500ms), pianifica un job, elabora i dati e aggiorna i sink. Questo approccio garantisce un throughput elevatissimo e una semantica “exactly-once” robusta, poiché il sistema può tracciare gli offset di lettura e scrittura con precisione. Tuttavia, il micro-batch introduce intrinsecamente una latenza legata allo scheduling del job e alla gestione degli offset, che storicamente limitava la capacità di risposta a latenze sub-secondo.

Per superare questo limite, Databricks ci porta nel futuro, nel Data + AI Summit 2025 a San Francisco, ha annunciato la nuova modalità Real-Time Mode. Questa modalità abbandona il micro-batch tradizionale a favore di un’esecuzione continua e asincrona. Invece di lanciare job discreti, Spark lancia task a lunga esecuzione (long-running) che processano i dati non appena arrivano nel buffer di input. La gestione del checkpointing e dei commit avviene in modo asincrono, disaccoppiando l’I/O di persistenza dal flusso di elaborazione logica. Questo permette di ottenere latenze nell’ordine delle decine di millisecondi, rendendo Databricks competitivo anche per scenari di fraud detection.

Introducing Real-Time Mode

Microsoft Fabric: Engine Kusto e l’Indicizzazione

Microsoft Fabric adotta un approccio radicalmente diverso con il suo workload Real-Time Intelligence.

Il cuore è il motore Kusto (nato con Azure Data Explorer). Kusto non è un Engine di elaborazione general-purpose come Spark, ma un database analitico distribuito ottimizzato per l’append-only e le query ad alta concorrenza. La sua natura procedurale permette di costruire query complesse passo dopo passo. Per i dati in streaming, KQL offre una serie di primitive per analisi avanzate:

  • Time-Series Analysis: Funzioni come make-series permettono di regolarizzare dati temporali, creando serie continue pronte per l’analisi.

    Microsoft Fabric: Time Series Analysis

  • Pattern Recognition: Plugin come series_decompose_anomalies o series_periods_validate permettono di rilevare pattern stagionali o anomalie direttamente all’interno della query, sfruttando l’indicizzazione del motore per risposte istantanee.

    Microsoft Fabric: Anomaly Detection


Dagli Engine all’Architettura: Un Confronto tra Ecosistemi

Se il motore di calcolo è il cuore, l’architettura circostante è lo scheletro che sostiene la soluzione. Qui le differenze filosofiche tra le due piattaforme diventano evidenti.

Azure Databricks

Databricks Lakeflow

Databricks Lakeflow

Il controllo totale del Code-First in Databricks, l’approccio è engineering-centric. La piattaforma offre il massimo controllo granulare attraverso Databricks Lakeflow (e Delta Tables), permettendo di orchestrare pipeline di streaming complesse scrivendo codice nativo in Python o SQL. La gestione dei flussi streaming viene semplificata con il framework lakeflow:

  • Ingestion e Trasformazioni: Sfruttando la potenza di Spark Structured Streaming, i dati vengono elaborati e raffinati, inoltre utilizzando la sintassi dichiarativa di Spark Declarative Pipelines snelliamo il codice e lo irrobustiamo sfruttando una gestione automatica dei checkpoint.

    from pyspark import pipelines as dp
    
    # create a streaming table
    @dp.table
    def customers_bronze():
      return (
        spark.readStream.format("cloudFiles")
        .option("cloudFiles.format", "json")
        .option("cloudFiles.inferColumnTypes", "true")
        .load("/Volumes/path/to/files")
      )
    
  • Storage e Governance: I dati saranno salvati nelle Delta Tables all’interno del Unity Catalog, che funge da layer unificato di governance.

Streaming tables

Microsoft Fabric

Microsoft Fabric: Real-Time HUB

Microsoft Fabric: Real-Time HUB

La semplicità del SaaS integrato Fabric risponde con una filosofia Low-Code/No-Code orientata alla “Real-Time Intelligence”. Qui l’obiettivo è ridurre drasticamente il Time-to-Insight. Il flusso è lineare e gestito con diversi componenti:

  1. Ingestion: Eventstreams per catturare i dati alla fonte con la possibilità di applicare filtri e trasformazioni.
  2. Storage e Analisi: I dati vengono veicolati in un Eventhouse basato su KQL Database. A differenza delle Delta Tables, questo storage è ottimizzato specificamente per query su serie temporali e log ad alta frequenza.
  3. Visualizzazione: Il cerchio si chiude con le Real-Time Dashboards, che permette di visualizzare i dati dopo l’ingestione, bypassando la latenza tipica del refresh dei dataset.

Quindi, quale piattaforma scegliere?

Non esiste una risposta universale, né un vincitore assoluto. La scelta tra Databricks e Microsoft Fabric dipende dall’equilibrio tra la granularità del controllo che desideri e la semplicità di gestione di cui hai bisogno. Per facilitare questa decisione, ho sintetizzato il confronto in due framework visivi:

  1. Una Matrice delle Caratteristiche, per analizzare le differenze tecniche pure.
  2. Una Matrice dei Casi d’Uso, per identificare quale strumento si adatta meglio allo scenario di business specifico.
Matrice delle Caratteristiche

Matrice delle Caratteristiche

Matrice dei Casi d’Uso

Matrice dei Casi d’Uso

Considerazioni Finali

Mi diverte immaginare Databricks come il motore da Formula 1 da assemblare per vincere gare di ingegneria complessa (ETL e azioni a bassissima latenza), Fabric ti consegna un’auto sportiva con il pilota automatico, pronta per portarti dal dato grezzo alla dashboard in tempo record. Voi cosa ne pensate ? Approfondiamo il tema nei commenti.