Il modello semantico è il punto in cui l’architettura Fabric incontra il report. La scelta dello storage mode decide latenza dei dati, tempo di risposta e consumo di capacity: nell’esame DP-600 è uno degli argomenti con più domande a scenario.
I tre storage mode a confronto
| Aspetto | Import | DirectQuery | Direct Lake |
|---|---|---|---|
| Dove stanno i dati | Copia compressa in VertiPaq | Solo alla fonte | File Delta/Parquet in OneLake |
| Latenza dei dati | Pari all’ultimo refresh | Tempo reale | Quasi tempo reale (dopo il framing) |
| Tempo di query | Ottimo | Dipende dalla fonte + traduzione SQL | Paragonabile a Import |
| Memoria | Alta (dataset intero residente) | Minima | Caricamento a colonne on demand |
| Trasformazioni | Power Query completo | Power Query limitato (folding) | Nessuna trasformazione nel modello |
Import duplica i dati: veloce ma con finestra di refresh e footprint di memoria. DirectQuery non duplica nulla ma traduce ogni visual in SQL sulla fonte, pagando latenza a ogni interazione.
Direct Lake è la terza via: il motore VertiPaq legge direttamente i file Parquet delle tabelle Delta su OneLake, senza copia e senza tradurre in SQL. Le colonne effettivamente usate da un visual vengono caricate e transcodificate in memoria on demand nel formato in-memory di Analysis Services, poi restano in cache finché serve. Il risultato è la velocità di Import con la freschezza tipica di DirectQuery.
Perché il formato conta: V-Order
Fabric scrive le tabelle Delta con ottimizzazione V-Order, un riordino dei dati dentro il Parquet allineato alla compressione VertiPaq. Tabelle V-Ordered si transcodificano molto più rapidamente. Su tabelle scritte da processi esterni o molto frammentate, esegui OPTIMIZE (compattazione dei file) e VACUUM (pulizia dei file storici) prima di puntarci un modello Direct Lake.
Prerequisiti e vincoli
Per usare Direct Lake devi rispettare tutte queste condizioni:
- Workspace ospitato su Fabric capacity (SKU F o Premium P). Su Pro/PPU non è disponibile.
- Le tabelle devono essere tabelle Delta in un lakehouse o in un warehouse Fabric, esposte via SQL analytics endpoint (o via OneLake, nella variante Direct Lake on OneLake).
- Nessuna trasformazione Power Query nel modello: niente merge, colonne calcolate M, unpivot. La modellazione va fatta a monte (notebook, dataflow, vista o tabella nel warehouse).
- Nessun modello composito che mescoli Direct Lake con altre origini nella stessa tabella.
- Le viste del SQL analytics endpoint non sono tabelle Delta: attivano il fallback.
- Le relazioni devono poggiare su colonne dello stesso tipo; misure DAX sì, colonne calcolate DAX con limiti.
Quando una query supera i guardrail della SKU (righe per tabella, numero di file Parquet, cardinalità), il modello può ricadere in DirectQuery sull’endpoint SQL. Il comportamento si governa con la proprietà di fallback: Automatic, DirectQuery only, oppure Direct Lake only (che fa fallire la query invece di degradare in silenzio: utile in test per scoprire le regressioni).
Framing e reframe
Il modello Direct Lake non “vede” continuamente il Delta log: ne fotografa una versione specifica. Questa operazione si chiama framing e produce uno snapshot dei metadati che indica quali file Parquet leggere.
Il flusso è:
- Una pipeline o un notebook scrive nuove righe nella tabella Delta → nasce una nuova versione nel Delta log.
- Finché il modello non riesegue il framing, continua a puntare ai file della versione precedente: il report mostra dati vecchi anche se il lakehouse è già aggiornato.
- Il reframe (l’operazione di “refresh” del modello semantico Direct Lake, che non copia dati ma aggiorna i puntatori) allinea il modello alla versione corrente e invalida le colonne in cache, che verranno ricaricate al primo accesso.
Di default esiste un aggiornamento automatico del modello sui cambi dell’endpoint, ma in scenari controllati si disattiva e si accoda il reframe alla fine della pipeline di ingestion, così il report non mostra mai un carico a metà. Nota il costo nascosto: subito dopo un reframe la cache è fredda, quindi la prima query paga di nuovo la transcodifica.
Trappole tipiche d’esame
- Scenario: un report Direct Lake mostra dati vecchi anche se la pipeline ha appena caricato il lakehouse. → Risposta: il modello non ha ancora eseguito il framing/reframe; accoda un refresh del modello semantico alla fine della pipeline.
- Scenario: serve unire una tabella Delta del lakehouse con un file Excel su SharePoint nello stesso modello. → Risposta: Direct Lake non ammette modelli compositi con altre origini: usa Import, oppure porta prima il file dentro il lakehouse.
- Scenario: le performance del modello Direct Lake sono improvvisamente peggiorate. → Risposta: è avvenuto il fallback a DirectQuery per superamento dei guardrail o per l’uso di una vista anziché una tabella Delta; verifica con
Direct Lake only. - Scenario: requisito di trasformare e pulire i dati dentro il modello semantico. → Risposta: incompatibile con Direct Lake: sposta la logica a monte in notebook/warehouse, oppure scegli Import.
- Scenario: tabella Delta scritta da un processo esterno, transcodifica lenta e molti file piccoli. → Risposta: esegui OPTIMIZE con V-Order e VACUUM sulla tabella prima di usarla in Direct Lake.
- Scenario: il workspace è su licenza Pro e si chiede Direct Lake. → Risposta: non disponibile; serve una Fabric capacity (F/P SKU).