Il pattern medallion in Microsoft Fabric

L’architettura medallion organizza il flusso dati in tre layer progressivi di qualità e affidabilità, tipicamente materializzati come schemi o tabelle Delta Lake dentro un Lakehouse di Microsoft Fabric. L’idea centrale è che ogni layer abbia una responsabilità precisa e che i dati diventino via via più puliti, conformati e pronti al consumo man mano che risalgono la catena.

  • Bronze (raw): ingestione dei dati “as-is” dalle sorgenti, con minime o nulle trasformazioni. Si preserva il formato originale, si aggiungono metadati tecnici (timestamp di ingest, nome file/sorgente) e si mantiene la storicità. È la zona di replay: se una logica a valle è sbagliata, si può rigenerare tutto dal bronze senza tornare alle sorgenti.
  • Silver (validato e conformato): qui avvengono pulizia, deduplica, gestione dei null, casting dei tipi, applicazione dello schema e denormalizzazione/conforming tra sorgenti diverse. È il livello dove i dati diventano affidabili e riusabili da più consumatori.
  • Gold (aggregato per il consumo): modelli dimensionali, aggregazioni, KPI e tabelle pensate per report Power BI, semantic model o data science. Ottimizzato per la lettura, non per la flessibilità.

L’implementazione tipica in Fabric usa i notebook Spark, con una cella o un notebook per transizione di layer, orchestrati da un Data Pipeline o da un job schedulato.

Trasformazioni con PySpark e Spark SQL

Fabric espone lo stesso motore attraverso due interfacce intercambiabili: la PySpark DataFrame API e Spark SQL. Scegli in base al task, non per abitudine: SQL è spesso più leggibile per join e aggregazioni, l’API DataFrame è più potente per logiche procedurali, funzioni custom e pipeline parametriche.

Da bronze a silver: pulizia e conforming

Il passaggio silver concentra la qualità: rimozione duplicati, normalizzazione di formati, filtraggio di record invalidi e unione di sorgenti eterogenee.

silver = (bronze
    .dropDuplicates(["order_id"])
    .filter(col("amount") > 0)
    .withColumn("order_date", to_date("order_ts"))
)

Qui si applica lo schema atteso e si denormalizza arricchendo i fatti con attributi delle dimensioni (join su lookup), così i consumatori a valle non devono ricostruire ogni volta le stesse relazioni.

Da silver a gold: group by e aggregazioni

Il gold produce le metriche di business. In Spark SQL:

SELECT product_id, DATE_TRUNC('month', order_date) AS mese,
       SUM(amount) AS ricavo, COUNT(*) AS ordini
FROM silver_orders GROUP BY product_id, DATE_TRUNC('month', order_date)

La scrittura avviene sempre in formato Delta, con saveAsTable o write.format("delta").mode(...), così da abilitare ACID, time travel e MERGE.

Best practice

  • Idempotenza: ogni notebook deve poter essere rieseguito senza duplicare o corrompere i dati. Prediligi overwrite per snapshot completi o MERGE (upsert su chiave) per carichi incrementali, evitando append cieco che accumula duplicati a ogni run.
  • Partizionamento sensato: partiziona su colonne a bassa cardinalità e usate nei filtri (es. data), non su chiavi ad alta cardinalità come order_id. Un partizionamento sbagliato genera cartelle innumerevoli e degrada tutto.
  • Small files problem: molti file Delta piccoli affossano le performance di lettura. Usa OPTIMIZE (bin-compaction) e V-Order, controlla il numero di partizioni con repartition/coalesce prima della scrittura e valuta il liquid clustering dove disponibile.

Trappole tipiche d’esame

  • Scenario: devi rigenerare i dati dopo aver scoperto un bug nella logica di trasformazione, senza reinterrogare le sorgenti operative → mantieni il bronze immutabile e raw; il replay parte da lì, mai dal silver.
  • Scenario: aggregazioni pesanti per Power BI mescolate con la pulizia dei dati nello stesso notebook silver → separa le responsabilità: pulizia/conforming nel silver, aggregazioni nel gold. Mescolare i layer compromette qualità e riusabilità.
  • Scenario: un carico incrementale notturno duplica le righe a ogni esecuzione → sostituisci l’append con un MERGE idempotente sulla chiave di business.
  • Scenario: query Power BI lente su una tabella gold con migliaia di micro-file → esegui OPTIMIZE + V-Order e rivedi il partizionamento; è il classico small files problem.
  • Scenario: si propone di far leggere ai data scientist direttamente il bronze per “risparmiare tempo” → sbagliato: saltare il silver significa esporre dati non validati né conformati; il silver è il livello riusabile e affidabile.