Progettare la piattaforma di data integration e analytics

Nell’esame AZ-305 lo scenario tipico ti fornisce volumi, latenza richiesta, skillset del team e budget, e ti chiede di comporre un’architettura analitica coerente. Il segreto non è conoscere ogni servizio, ma sapere quando fermarti su uno e quando combinarne più di uno, evitando sovrapposizioni costose. Il framework mentale è quello dell’Azure Well-Architected Framework: bilanciare Cost Optimization, Operational Excellence, Performance Efficiency e Reliability.

Orchestrazione e movimento dati: Azure Data Factory

Azure Data Factory (ADF) è il servizio di riferimento per orchestrazione ELT/ETL e ingestione. I suoi punti di forza:

  • Copy activity con oltre 100 connettori verso sorgenti on-premises (via Self-hosted Integration Runtime) e SaaS.
  • Mapping Data Flow per trasformazioni visuali senza codice (esegue su cluster Spark gestiti).
  • Trigger scheduled, tumbling window ed event-based.

ADF eccelle nell’ingestione batch pianificata e nel movimento verso una landing zone. Non è però una piattaforma di calcolo per big data: le trasformazioni pesanti vanno delegate a Spark.

Data warehousing e lakehouse unificato: Synapse / Fabric

Azure Synapse Analytics unifica in un’unica workspace: Dedicated SQL Pool (MPP data warehouse per query T-SQL su volumi TB/PB), Serverless SQL Pool (query on-demand direttamente sul data lake, pay-per-TB scansionato) e Spark Pool. È la scelta quando il team ha skillset SQL forte e serve un enterprise data warehouse con modellazione a stella. Nota di scenario: per nuovi progetti Microsoft posiziona sempre più Microsoft Fabric come evoluzione SaaS; in AZ-305 Synapse resta la risposta canonica per il DW, ma riconosci Fabric come direzione strategica.

Big data e ML: Azure Databricks

Azure Databricks è la piattaforma Spark/Delta Lake ottimizzata per data engineering avanzato, machine learning e data science. Raccomandala quando:

  • il team ha competenze Python/Scala/notebook e workflow ML (MLflow, feature engineering);
  • servono trasformazioni complesse e collaborative su data lake con Delta Lake (ACID, time travel);
  • vuoi separare compute effimero e storage con autoscaling granulare.

Batch vs streaming: dove entra Event Hubs

Il discriminante progettuale è la latenza:

  • Batch (minuti/ore): ADF orchestrazione + Synapse/Databricks per il calcolo.
  • Streaming / near-real-time (secondi): Azure Event Hubs come punto di ingestione ad alto throughput (milioni di eventi/sec), spesso con Kafka endpoint compatibile. A valle: Stream Analytics (SQL-like, serverless, ottimo per aggregazioni a finestra) oppure Spark Structured Streaming su Databricks per logiche complesse. Event Hubs Capture scrive automaticamente in Data Lake/Blob in formato Avro, alimentando anche il percorso batch (architettura Lambda/Kappa).

La zona di landing/curated: il pilastro spesso dimenticato

Un design maturo definisce esplicitamente le zone su Azure Data Lake Storage Gen2 (con hierarchical namespace):

  • Bronze/Raw (landing): dati immutabili così come ingeriti.
  • Silver/Curated: puliti, deduplicati, conformati.
  • Gold: aggregati business-ready per il DW o Power BI.

Omettere questa medallion architecture è un anti-pattern che porta a pipeline fragili e ri-elaborazioni costose.

Griglia decisionale rapida

  • Solo orchestrare/spostare dati, poca trasformazione → ADF.
  • DW SQL enterprise, team T-SQL, BI classico → Synapse Dedicated SQL Pool.
  • Query esplorative ad-hoc sul lake senza infrastruttura → Serverless SQL Pool.
  • ML, data engineering Python, Delta collaborativo → Databricks.
  • Ingestione eventi ad alto volume, latenza secondi → Event Hubs (+ Stream Analytics o Structured Streaming).

Trappole tipiche d’esame

  • Requisito: minimizzare i costi di data movement tra regioni → Colloca compute e storage nella stessa region, usa Event Hubs Capture o Serverless SQL Pool per interrogare il lake in place, evitando copy activity ridondanti. Il costo del data egress cross-region è la voce sottovalutata più frequente.
  • Requisito: query occasionali su Parquet nel data lake senza gestire cluster → Raccomanda Synapse Serverless SQL Pool (pay-per-query), NON un Dedicated SQL Pool (che paga il compute anche a riposo) né Databricks.
  • Requisito: team di data scientist con notebook Python e modelli ML → Azure Databricks con MLflow, non Synapse SQL Pool. Lo skillset è il discriminante decisivo quando latenza e volumi sono simili.
  • Requisito: dashboard near-real-time da telemetria IoT ad alto throughput → Event Hubs → Stream Analytics → Power BI, non una pipeline ADF batch (che introduce latenza di minuti/ore).
  • Requisito: orchestrare più step eterogenei (copy, Databricks notebook, stored procedure) con dipendenze → Usa ADF/Synapse Pipelines come orchestratore che invoca Databricks, evitando di duplicare la logica di scheduling dentro i notebook (sovrapposizione di responsabilità e governance frammentata).