L’analitica su larga scala non nasce da un singolo prodotto, ma dall’orchestrazione di più servizi che spostano i dati dalle sorgenti operative fino ai report consultati dal business. Questo modello prende il nome di modern data warehouse e rappresenta il punto di riferimento architetturale per DP-900: capire quale componente fa cosa è più importante di conoscere i dettagli di configurazione.

Le fasi dell’architettura

Un’architettura di analitica moderna si articola in quattro fasi logiche, spesso rappresentate come un flusso da sinistra a destra.

1. Ingestione (data ingestion)

È la fase di raccolta dei dati dalle sorgenti: database applicativi, file, API, dispositivi IoT, log. Su Azure il servizio di orchestrazione tipico è Azure Data Factory (o le pipeline di Microsoft Fabric), che coordina il movimento e la copia dei dati senza scrivere codice infrastrutturale. L’ingestione può essere pianificata (a intervalli) o event-driven (al verificarsi di un evento).

2. Storage nel data lake

I dati grezzi, in qualsiasi formato (strutturati, semi-strutturati, non strutturati), vengono depositati in un data lake, tipicamente Azure Data Lake Storage Gen2. Il data lake è economico, altamente scalabile e conserva i dati nel loro formato originale (schema-on-read): non impone una struttura al momento della scrittura. In Microsoft Fabric questo storage unificato è chiamato OneLake.

3. Elaborazione e trasformazione

I dati grezzi vengono puliti, aggregati e trasformati in un formato pronto per l’analisi. Qui si applica il modello ELT (Extract, Load, Transform): prima si caricano i dati nel lake, poi li si trasforma sfruttando la potenza di calcolo distribuita. Motori tipici sono Apache Spark (notebook), i flussi di dati e le query SQL su larga scala.

4. Data warehouse e serving

I dati raffinati confluiscono in un data warehouse: un archivio centralizzato, ottimizzato per query analitiche su grandi volumi. Su Azure il riferimento è il warehouse di Microsoft Fabric (evoluzione di Azure Synapse Analytics). Da qui i dati vengono “serviti” agli strumenti di reporting e visualizzazione, primo fra tutti Power BI.

Concetti di data warehousing

Un data warehouse si distingue da un database operativo per la sua natura analitica (OLAP) anziché transazionale (OLTP):

  • OLTP (Online Transaction Processing): tante scritture piccole e veloci, dati normalizzati, supporta le applicazioni (es. inserire un ordine).
  • OLAP (Online Analytical Processing): letture aggregate su enormi volumi storici, dati denormalizzati, supporta le decisioni (es. analizzare le vendite di 5 anni).

Il data warehouse organizza i dati in schemi dimensionali (star schema): tabelle dei fatti (le misure numeriche, come importi e quantità) collegate a tabelle delle dimensioni (il contesto: tempo, cliente, prodotto, area geografica).

Batch vs elaborazione in tempo reale

La distinzione tra i due paradigmi di elaborazione è un punto di partenza fondamentale.

  • Batch processing: i dati vengono raccolti in gruppi e processati a intervalli. Alta latenza (minuti/ore), ma throughput elevato ed efficiente sui grandi volumi storici. È il cuore del modern data warehouse. Esempio: consolidare le vendite della giornata ogni notte.
  • Stream processing (real-time): ogni evento viene elaborato appena arriva, con latenza di secondi o millisecondi. Servizi tipici: Azure Stream Analytics, Azure Event Hubs, l’esperienza Real-Time Intelligence di Microsoft Fabric. Esempio: monitorare sensori o rilevare frodi in tempo reale.

Molte architetture combinano entrambi gli approcci (pattern lambda), servendo sia dati storici sia flussi live nello stesso ambiente analitico.

Trappole tipiche d’esame

  • Scenario: devi archiviare grandi quantità di dati grezzi in qualsiasi formato, a basso costo, prima di trasformarli → risposta: un data lake (Azure Data Lake Storage Gen2 / OneLake), non un data warehouse relazionale.
  • Scenario: devi orchestrare lo spostamento e la copia dei dati dalle sorgenti al lake senza scrivere codice → risposta: Azure Data Factory (o le pipeline di Microsoft Fabric).
  • Scenario: devi elaborare dati aggregati su grandi volumi storici, dove una latenza di ore è accettabile → risposta: batch processing, non stream processing.
  • Scenario: devi reagire in millisecondi a eventi in arrivo da dispositivi IoT → risposta: stream processing con Azure Stream Analytics / Event Hubs.
  • Scenario: serve un archivio ottimizzato per query analitiche (OLAP) su dati modellati a fatti e dimensioni → risposta: un data warehouse, non un database OLTP.
  • Scenario: devi creare report e dashboard interattivi per il business → risposta: Power BI come livello di serving/visualizzazione.