Azure Databricks nell’architettura DP-203

Azure Databricks è la piattaforma di analytics basata su Apache Spark offerta come servizio first-party su Azure. Nel percorso DP-203 rappresenta la scelta di riferimento per il processing distribuito su grandi volumi, sia in batch che in streaming, quando serve trasformare dati nel data lake e materializzarli in formato Delta Lake. Il cuore operativo è il workspace, l’ambiente collaborativo dove risiedono notebook, job, cluster, librerie e riferimenti al DBFS. I notebook supportano PySpark, Spark SQL, Scala e R e sono l’unità di sviluppo delle trasformazioni.

Cluster: all-purpose vs job cluster

La distinzione più ricorrente all’esame è quella tra i due tipi di cluster:

  • All-purpose cluster (interactive): creato manualmente, condiviso tra più utenti, resta acceso per sviluppo interattivo ed esplorazione nei notebook. È persistente e riavviabile, quindi comodo ma tendenzialmente più costoso se lasciato attivo.
  • Job cluster: creato automaticamente da un Databricks Job all’avvio dell’esecuzione e terminato al termine. È effimero, isolato e ottimizzato per i costi: la scelta corretta per pipeline pianificate in produzione.

Regola pratica d’esame: sviluppo/ad-hoc → all-purpose; workload schedulati e automatizzati → job cluster.

Pool e autoscaling

I pool (instance pool) mantengono un insieme di VM inattive e pronte all’uso: assegnando un cluster a un pool si riduce drasticamente il tempo di avvio e si contiene la latenza di scale-up, perché le istanze non vanno provisionate da zero. È il pattern giusto quando si vogliono job con start rapido e frequenti.

L’autoscaling consente al cluster di variare il numero di worker tra un minimo e un massimo in base al carico. Nei workload di streaming o con carico variabile si usa l’Enhanced Autoscaling (tipico di Delta Live Tables). Attenzione: autoscaling non elimina la spesa: agisce sui worker, non azzera il costo del driver.

Databricks Jobs e orchestrazione

I Databricks Jobs orchestrano l’esecuzione di uno o più task (notebook, script Python, JAR, query SQL, pipeline DLT) con dipendenze a grafo (DAG), scheduling, retry e alerting. Per pipeline complesse è comune orchestrare Databricks da Azure Data Factory o Synapse Pipelines tramite l’apposita activity, integrandolo nel flusso ELT complessivo. In produzione ogni Job dovrebbe puntare a un job cluster dedicato.

Unity Catalog per la governance

Unity Catalog è il layer di governance centralizzato: fornisce un metastore condiviso tra più workspace, gerarchia a tre livelli catalog → schema → table, controllo accessi granulare, data lineage e audit. È l’evoluzione rispetto all’Hive metastore legacy per workspace, e il punto di contatto con Microsoft Purview per il catalogo aziendale. All’esame: quando lo scenario chiede governance e sicurezza dei dati centralizzate su più workspace, la risposta è Unity Catalog.

Databricks vs Synapse Spark

DP-203 propone spesso la scelta tra Azure Databricks e i Spark pool di Azure Synapse Analytics. Entrambi eseguono Spark, ma:

  • Scegli Databricks quando servono Delta Lake e Delta Live Tables (DLT) nativi, MLflow, autoscaling avanzato, ecosistema maturo e performance ottimizzate (Photon).
  • Scegli Synapse Spark quando l’integrazione desiderata è l’ambiente unificato Synapse (SQL pool, pipeline, Synapse Studio) in un’unica esperienza.

Nota di contesto 2026: la strategia data platform Microsoft converge su Microsoft Fabric, ma per DP-203 restano centrali Databricks e Synapse.

Trappole tipiche d’esame

  • Scenario: pipeline notturna schedulata in produzione, minimizzare i costi → risposta giusta: job cluster (effimero), non un all-purpose sempre acceso.
  • Scenario: molti job brevi che devono partire velocemente → risposta giusta: instance pool per ridurre il tempo di avvio, non aumentare la dimensione fissa del cluster.
  • Scenario: governance e RBAC granulare su tabelle condivise tra più workspace → risposta giusta: Unity Catalog, non i permessi del singolo workspace o l’Hive metastore.
  • Scenario: servono Delta Lake e DLT nativi con ecosistema ML maturo → risposta giusta: Azure Databricks, non un Synapse Spark pool.
  • Trappola costo: il prezzo di Databricks è DBU + costo delle VM. Ridurre solo le DBU o abilitare l’autoscaling non elimina la spesa infrastrutturale delle macchine: il costo totale è la somma dei due, e i cluster all-purpose lasciati attivi continuano a fatturare entrambe le voci.