Padroneggiare l'architettura Lakehouse: Bronze, Silver e Gold in Microsoft Fabric

By Mirko Peters · 2026-08-28

Bentornato sul blog di approfondimento del podcast! Nel nostro ultimo episodio ci siamo immersi a fondo nelle realtà pratiche dell'ingegneria del machine learning all'interno di Micro…

Automatically translated with AI from the original post. Read the English original

Bentornati sul blog di accompagnamento al podcast! Nel nostro ultimo episodio abbiamo approfondito le problematiche pratiche dell'ingegneria del machine learning nell'ecosistema Microsoft. Se non l'avete ancora ascoltato, non perdete Build Machine Learning Models in Microsoft Fabric. Oggi approfondiamo questi concetti e vediamo come strutturare i dati con un'architettura medallion all'interno di un Lakehouse di Microsoft Fabric, che costituisce la base indispensabile di un'operazione di machine learning di successo e scalabile.

Costruire modelli di machine learning pronti per la produzione non significa solo scegliere l'algoritmo giusto o ottimizzare gli iperparametri. Nella maggior parte dei casi, il successo dei modelli predittivi dipende da qualità dei dati, pipeline riproducibili e governance solida. Vediamo insieme come padroneggiare l'architettura Lakehouse con Microsoft Fabric.

Architettura in sintesi

Quando si progetta una piattaforma end-to-end per dati e machine learning in Microsoft Fabric, è fondamentale capire il flusso dei dati. Tutto parte da OneLake, che funge da livello di archiviazione unificato. Da qui i dati confluiscono in un Lakehouse, dove passano attraverso le tabelle Delta bronze, silver e gold.

Per il calcolo, i Notebook di Fabric offrono ai data scientist uno stack per data science preconfigurato, basato su Spark, Python e R. Il tracciamento degli esperimenti è gestito in modo naturale tramite le esecuzioni MLflow integrate, che registrano metriche, parametri e artefatti senza richiedere server di tracciamento esterni. Una volta addestrati, i modelli passano nel registro unificato, con versionamento, approvazioni e piena lineage dei dati. Infine, i modelli vengono distribuiti tramite processi batch gestiti o endpoint HTTP in tempo reale, alimentando consumer come Power BI, Power Apps e client API personalizzati.

Lakehouse: domare gli input, mantenere il controllo

La filosofia di fondo di un Lakehouse è unire la flessibilità di un data lake con l'affidabilità di un data warehouse. Per far funzionare tutto questo in modo efficace, è necessario strutturare i dati in livelli distinti.

Organizza le tabelle per livelli

• Bronze: è il livello di ingestione grezza. I dati arrivano qui secondo il principio schema-on-read e restano immutabili per audit e rielaborazioni.
• Silver: in questo livello i dati vengono puliti, tipizzati e uniti. I PII sono ridotti al minimo e vengono applicati i controlli di qualità iniziali.
• Gold: il livello gold contiene aggregati pronti per le feature, costruiti su contratti di dati chiari e documentati, che i modelli di machine learning possono consumare direttamente.

Accesso in base alle esigenze

Utilizza il controllo degli accessi basato sui ruoli a livello di area di lavoro insieme alle liste di controllo degli accessi a livello di tabella. Concedi ai data scientist l'accesso in lettura alle tabelle silver e gold, limitando la scrittura specificamente alle tabelle delle feature e alle directory sperimentali.

Barriere di controllo della qualità dei dati

Implementa vincoli rigorosi per valori non nulli, intervalli di valori e integrità referenziale. Quando le righe non superano questi controlli, indirizzale direttamente a una tabella _quarantine, così le pipeline a valle non falliscono in silenzio né acquisiscono dati corrotti.

Feature store leggero

Tratta le feature riutilizzabili come tabelle gold, ad esempio feat_customer_rolling_90d, e affiancale a un data dictionary in YAML, così il team sa esattamente che cosa rappresenta ciascuna feature.

Notebook senza fatica

La programmazione collaborativa può diventare rapidamente caotica se gli sviluppatori usano ambienti diversi. Fabric fornisce kernel preinstallati, tra cui pandas, PySpark, scikit-learn e PyTorch, che garantiscono a tutti di partire dalla stessa base.

Adotta una struttura di progetto ordinata, separando i notebook esplorativi, gli script di feature engineering, le routine di addestramento dei modelli e i file di configurazione. Affida la riproducibilità al codice invece che ai clic manuali nell'interfaccia. Leggi dal Lakehouse tramite Spark SQL, scrivi le feature finali come tabelle Delta e popola sempre tabelle campione più piccole per lo sviluppo, così il team può iterare rapidamente senza attendere query su dataset completi.

Traccia tutto con MLflow (integrato)

Il tracciamento manuale degli esperimenti sui modelli porta a risultati non replicabili. Sfruttando l'integrazione nativa di MLflow in Fabric, garantisci la confrontabilità tra un'esecuzione e l'altra, un controllo completo e rollback senza fatica quando un modello appena distribuito non rende come previsto.

Registra tutti gli iperparametri, le metriche di valutazione e gli artefatti dei modelli addestrati direttamente negli script di addestramento. Assicurati di etichettare le esecuzioni con metadati contestuali, come la finestra dei dati, le versioni dei set di funzionalità e gli hash dei commit del codice, fissando le tabelle di addestramento a specifiche versioni snapshot di Delta.

Registro, approvazioni e lineage

Passare un modello dalla sperimentazione alla produzione non dovrebbe mai essere un gioco di supposizioni. Promuovi le esecuzioni migliori a un Registered Model usando il controllo di versione semantico, ad esempio 1.0.0. Implementa un processo di approvazione in due passaggi che richieda il benestare sia del data science owner sia del business owner. Infine, acquisisci metadati completi della model card che descrivano lo scopo del modello, l'ambito dei dati, le note sull'equità e gli obiettivi di livello di servizio per il monitoraggio.

Opzioni di servizio (scegli in base al carico di lavoro)

Batch scoring (economico e affidabile)

Per i carichi di lavoro che non richiedono risposte istantanee, sotto il secondo, il batch scoring è la soluzione ideale. Usa processi pianificati di Fabric o notebook per leggere i modelli di produzione dal registro, applicarli a set di dati batch e scrivere le previsioni di nuovo nel Lakehouse.

Endpoint in tempo reale (applicazioni interattive)

Quando gli utenti hanno bisogno di un feedback immediato, ad esempio per la convalida di un modulo o per il calcolo del rischio al clic, distribuisci il modello registrato come endpoint in tempo reale gestito direttamente dall'interfaccia utente di Fabric. Esponi un contratto JSON prevedibile e collegalo in modo sicuro a Power Apps o ad applicazioni esterne.

Monitoraggio e riaddestramento

Distribuire un modello è solo metà del lavoro. Devi monitorare continuamente il data drift confrontando le distribuzioni delle funzionalità in tempo reale con la baseline di addestramento, usando la divergenza di Kullback-Leibler o le soglie della Population Stability Index. Tieni traccia delle metriche di salute operativa, tra cui latenza degli endpoint, tassi di errore e costi per mille punteggi. Automatizza le pipeline di riaddestramento combinando trigger temporali e avvisi di drift basati su eventi, così da garantire che i modelli restino accurati nel tempo.

Sicurezza e conformità

Mantenere la sicurezza è fondamentale quando si gestiscono dati aziendali. Applica il principio del privilegio minimo concedendo ai data scientist l'accesso in lettura ai livelli silver e gold, limitando le autorizzazioni di scrittura alle cartelle designate per le funzionalità e per gli esperimenti. Usa identità gestite e Azure Key Vault per l'archiviazione di tutte le credenziali, assicurandoti che nessun segreto finisca mai hardcoded nei notebook. Riduci l'esposizione dei dati personali applicando hashing o tokenizzazione alle informazioni sensibili già nel livello silver, così che non si propaghino mai nei tuoi feature store.

Cosa misurare (dimostra subito il valore)

Per dimostrare rapidamente il valore delle tue iniziative di machine learning, concentrati sulle metriche giuste. Misura la capacità del modello con AUC e precision-at-k per le classifiche, monitora l'impatto sul business tramite l'incremento dei ricavi o la riduzione dei tassi di abbandono, controlla la velocità dalla prontezza dei dati al deployment in produzione e valuta l'affidabilità dell'infrastruttura e l'efficienza dei costi per mille previsioni.

Piano di rollout in 14 giorni

Se vuoi passare da zero a un deployment di Fabric pronto per la produzione in tempi rapidi, segui questo piano strutturato di due settimane:

• Giorno 1–2: pulizia del Lakehouse, struttura bronze/silver/gold, ACL e controlli di qualità.
• Giorno 3: impostazione dei notebook, helper per i dati e tabelle di esempio per lo sviluppo.
• Giorno 4–5: set di funzionalità v1, addestramento del modello di riferimento e logging con MLflow.
• Giorno 6: suite di valutazione, creazione della model card e registrazione del modello (v0.1).
• Giorno 7: creazione del processo di batch scoring e integrazione con la dashboard di Power BI.
• Giorno 8: MVP di monitoraggio, controlli di drift e logging operativo.
• Giorno 9: implementazione del flusso di approvazione e promozione in produzione.
• Giorno 10: configurazione dell'endpoint in tempo reale, throttling e logging delle richieste (se applicabile).
• Giorno 11–12: A/B testing, backtesting e definizione dei KPI di business.
• Giorno 13: governance dei costi, limiti di autoscaling e piano di canary deployment.
• Giorno 14: documentazione del runbook, passaggio di consegne al team e pianificazione del backlog.

Errori comuni (e soluzioni rapide)

Anche i team esperti incontrano ostacoli. Evita la "roulette dei notebook" bloccando i tuoi ambienti sui kernel standard di Fabric. Non testare solo su campioni ridotti che si rompono quando passi ai dataset completi. Previeni i "modelli fantasma" in produzione applicando rigorosamente i flussi di promozione nel registro. Tieni sotto controllo i costi cloud usando per impostazione predefinita l'elaborazione batch dove possibile e mettendo in cache le feature derivate.

Snippet utili

Per darti una mano con il tuo prossimo progetto, ecco un breve snippet che mostra come leggere una versione specifica di una tabella Delta:

sales_v = spark.read.option("versionAsOf", 123).table("lakehouse.gold.sales_txn")

Se vuoi estrarre l'importanza delle feature con scikit-learn e registrarla direttamente in MLflow, usa questo approccio:

import pandas as pd
fi = pd.Series(clf.feature_importances_, index=feature_cols).sort_values(ascending=False)
mlflow.log_artifact(fi.head(30).to_frame("importance").to_csv("fi.csv", index=True))

E per calcolare il Population Stability Index (PSI) per il rilevamento del drift:

import numpy as np
def psi(expected, actual, bins=10):
    e, b = np.histogram(expected, bins=bins, range=(np.min(expected), np.max(expected)))
    a, _ = np.histogram(actual,   bins=b,     range=(np.min(expected), np.max(expected)))
    e = np.clip(e / e.sum(), 1e-6, None); a = np.clip(a / a.sum(), 1e-6, None)
    return np.sum((a - e) * np.log(a / e))

Se ti va, scrivi nei commenti i nomi delle tue tabelle Lakehouse attuali e un caso d'uso target, come churn dei clienti, lead scoring o previsione della domanda, oppure contattami direttamente. Ti aiuterò a definire un set minimo di feature, la scelta del modello di base e il collegamento esatto batch o in tempo reale, così da portare in produzione il tuo primo deployment di Microsoft Fabric in tempi rapidi!