Il fallback a DirectQuery è il meccanismo con cui un semantic model in modalità Direct Lake rinuncia a leggere i file Parquet in OneLake e reindirizza la query al SQL analytics endpoint. Il risultato resta corretto, ma le prestazioni crollano: si perde la scansione in-memory VertiPaq e si paga la latenza di un motore SQL distribuito. Per DP-600 devi saper riconoscere quando accade, come accorgertene e come impedirlo.

Perché scatta il fallback

I trigger si dividono in tre famiglie.

1. Guardrail di capacità superati. Ogni SKU Fabric impone limiti su righe per tabella e memoria del modello. Se una tabella supera il numero massimo di righe consentito per lo SKU, o se il modello non entra nella memoria disponibile, il motore degrada a DirectQuery. I guardrail crescono con lo SKU: un F2 ha soglie molto più basse di un F64, e i tenant Power BI Premium P-SKU seguono la mappatura equivalente. La regola pratica d’esame: modello troppo grande per lo SKU → fallback, e la contromisura diretta è salire di SKU o ridurre il volume.

2. Oggetti non supportati dal formato Direct Lake. Direct Lake può leggere solo tabelle Delta con statistiche V-Order valide. Non sono supportati in modalità Direct Lake:

  • View SQL (incluse le view del SQL analytics endpoint) — sempre lette in DirectQuery
  • Tipi di dato non mappabili al motore VertiPaq
  • Tabelle Delta con troppi file Parquet o senza V-Order

3. Sicurezza definita a valle. Se sulla tabella o view esiste RLS o OLS definita sul SQL analytics endpoint (o data masking a livello SQL), la query deve passare per il motore SQL per applicarla: fallback garantito. La RLS definita nel semantic model con espressioni DAX, invece, non causa fallback.

Le tre modalità di DirectLakeBehavior

La proprietà DirectLakeBehavior si imposta sul semantic model (Tabular Editor, TMDL, o l’impostazione nelle proprietà del modello in Fabric).

Valore Comportamento Quando usarlo
Automatic (default) Usa Direct Lake quando possibile, degrada silenziosamente a DirectQuery se un trigger scatta Produzione, quando la continuità del servizio conta più della prevedibilità
DirectLakeOnly Se Direct Lake non è utilizzabile, la query fallisce con errore invece di degradare Diagnosi, test di regressione, e scenari dove una query lenta è peggio di una query fallita
DirectQueryOnly Forza sempre DirectQuery, ignorando Direct Lake Confronto di baseline, o quando servono view SQL/RLS a valle su tutto il modello

Il punto operativo che l’esame ama: DirectLakeOnly è lo strumento di troubleshooting. In Automatic il fallback è invisibile e l’utente segnala solo “il report è lento”. Impostando DirectLakeOnly, i visual che dipendono da tabelle problematiche generano un errore esplicito che identifica immediatamente il colpevole.

Rilevare il fallback

  • Performance Analyzer in Power BI Desktop: registra la durata delle query DAX e mostra le Direct query emesse. Se compaiono query SQL dove ti aspettavi Direct Lake, sei in fallback.
  • Monitoring hub di Fabric: espone la cronologia delle query del semantic model e delle attività di capacità.
  • Query log / SQL analytics endpoint queryinsights: le viste queryinsights.exec_requests_history mostrano le query SQL arrivate all’endpoint; traffico inatteso qui equivale a fallback.
  • Metriche di capacità (Fabric Capacity Metrics app): picchi di CU sull’operazione di query SQL invece che sulla lettura Direct Lake.

Contromisure

  1. OPTIMIZE sulla tabella Delta: compatta i file Parquet piccoli in file più grandi, riducendo il numero di rowgroup e il costo di transcodifica.
  2. V-Order: assicurati che sia abilitato in scrittura (default nelle pipeline Fabric, ma disattivabile via spark.sql.parquet.vorder.enabled). Senza V-Order la lettura Direct Lake è inefficiente o non applicabile.
  3. VACUUM per rimuovere i file obsoleti che gonfiano il log delle transazioni.
  4. Ridurre le colonne importate nel modello: Direct Lake carica in memoria solo le colonne effettivamente usate, ma rimuovere colonne ad alta cardinalità inutili riduce drasticamente il footprint.
  5. Sostituire le view SQL con tabelle Delta materializzate (via notebook o dataflow) quando servono in Direct Lake.
  6. Spostare la RLS dal SQL analytics endpoint al semantic model in DAX.
  7. Aumentare lo SKU quando i guardrail di righe/memoria sono il vero limite e i dati non si possono ridurre.

Trappole tipiche d’esame

  • Scenario: il report Direct Lake è improvvisamente lento dopo che un collega ha aggiunto la RLS sul SQL analytics endpoint → Risposta: la RLS a livello SQL forza il fallback; ridefinisci la sicurezza come RLS DAX nel semantic model.
  • Scenario: devi dimostrare che una tabella specifica causa fallback, senza ipotesi → Risposta: imposta DirectLakeBehavior = DirectLakeOnly e osserva quali visual falliscono. Non DirectQueryOnly (forza il comportamento opposto) e non Automatic (nasconde il problema).
  • Scenario: la tabella dei fatti è alimentata da microbatch e ha migliaia di file Parquet minuscoli → Risposta: esegui OPTIMIZE (e VACUUM), non un aumento di SKU.
  • Scenario: una tabella del modello punta a una view creata sul SQL analytics endpoint → Risposta: le view non sono mai servite in Direct Lake; materializzale come tabella Delta.
  • Scenario: la tabella supera il limite di righe dello SKU F-corrente e il business non accetta filtri sui dati → Risposta: unica leva reale è l’upgrade di SKU (o partizionamento del modello), non OPTIMIZE.