Import, DirectQuery e Direct Lake: quando scegliere quale
Questa è la decisione più importante di tutto Power BI. Tre modalità di connessione, tre filosofie diverse. Sbagliare significa report lenti, dati stantii o costi alle stelle. Ti do un metodo per decidere in 30 secondi.
- ⏱ Tempo stimato: ~25 min + esercitazioni
- 🎯 Prerequisiti: L1.1, L2.1
- 🛠 Software: nessuno (concettuale)
Import — i dati 'dentro' il modello (default storico)
Import mode: al refresh, Power BI copia i dati dalla sorgente dentro il modello, comprimendoli con il motore in-memory VertiPaq. Quando l'utente apre il report e interagisce con un visual, il calcolo avviene in memoria sul motore Power BI, non sulla sorgente.
- Pro: velocissimo (millisecondi), interattività fluida, indipendente dalla sorgente.
- Pro: nessun carico sulla sorgente durante l'uso del report.
- Contro: i dati sono "fotografati al momento del refresh" — freschezza = ultimo refresh.
- Contro: limite dataset (10 GB su Pro/PPU, fino a centinaia di GB su capacità Fabric).
- Contro: richiede pianificazione refresh (8/giorno su Pro, 48 su PPU/F-SKU).
.pbix.DirectQuery — query live alla sorgente
DirectQuery: i dati non vengono copiati. Ogni volta che l'utente interagisce con un visual, Power BI genera una query SQL (o equivalente) e la manda live alla sorgente. La sorgente risponde, Power BI mostra.
- Pro: dati sempre freschi (al secondo, se la sorgente è viva).
- Pro: niente limiti di dimensione dataset.
- Pro: nessun refresh schedulato (la "freschezza" è gratuita).
- Contro: ogni click sull'utente = una query alla sorgente → performance dipendono dalla sorgente.
- Contro: alcune funzioni DAX non funzionano o sono limitate.
- Contro: carico costante sulla sorgente (può servire scaling).
Direct Lake — la modalità Fabric che cambia le regole (GA)
Direct Lake è la modalità nata in Fabric. Legge direttamente le tabelle Delta/Parquet da OneLake senza copiarle e senza fare query live alla sorgente. Il motore VertiPaq carica le colonne on-demand al primo uso, poi tiene tutto in memoria.
Combina i due mondi:
- Velocità di Import — usa VertiPaq in memoria una volta caricato.
- Freschezza di DirectQuery — se la tabella Delta viene aggiornata, Direct Lake la rilegge senza refresh schedulato.
- Zero copia — niente storage duplicato, niente refresh ETL.
- Capacità Fabric F-SKU (non Pro/PPU).
- Dati in OneLake in formato Delta (tabelle Lakehouse o shortcut).
- Modello semantico creato dentro Fabric (non un .pbix Import).
I modelli compositi (Import + DirectQuery, oppure Direct Lake + Import)
Puoi mescolare. Esempi:
- Composite Import + DirectQuery: le tabelle dimensione (Prodotti, Clienti, Date) in Import per velocità; la tabella fatti (Vendite con miliardi di righe) in DirectQuery per non duplicare lo storage.
- Composite Direct Lake + Import: il fatto live da Lakehouse via Direct Lake; tabelle dimensione importate (es. da Excel o sistema separato).
Tabella decisionale — quale scegliere
| Aspetto | Quando | Modalità consigliata |
|---|---|---|
| Dataset ≤ 1 GB, refresh notturno sufficiente | Sempre | Import |
| Dati che cambiano ogni minuto, devo vedere in tempo reale | Sempre | DirectQuery (o Direct Lake) |
| Decine di GB di dati, capacità Fabric disponibile, dati in Delta su OneLake | Sempre | Direct Lake |
| SQL piccolo, pochi utenti, dati semi-statici | Sempre | Import |
| 500 utenti, dashboard interattivi, sorgente non sopporta carico | Sempre | Import (o Direct Lake) |
| Dimensioni piccole + fatto enorme che non vuoi duplicare | Composite | Import + DirectQuery |
| Stack Fabric moderno con Lakehouse, voglio "best of both" | Composite | Direct Lake + Import |
Cose che non funzionano in DirectQuery
DirectQuery impone vincoli che è importante conoscere prima di scegliere:
- Funzioni DAX "complesse" che richiedono iterazione sull'intero dataset (alcune time intelligence avanzate, calcoli su intero virtual table) sono limitate o lente.
- Quick measures e alcune funzioni AI non disponibili.
- Power Query in DirectQuery ha step limitati: non puoi fare unpivot, merge complessi, alcune trasformazioni — perché devono essere "translatable" in SQL.
- Calcoli misure devono fare query folding giù alla sorgente: se rompi il folding (es. step custom in M), la performance crolla.
Esercitazioni
Match scenario → modalità
Per ognuno indica modalità consigliata e perché in 1 frase:
- Dashboard finanza con dati ERP mensili (vendite, costi, P&L).
- Monitor real-time di traffico web (eventi al secondo) per il team marketing.
- Report su miliardi di righe di transazioni in un Lakehouse Fabric.
- Report su 10k clienti per un piccolo CRM (Pro license, niente F-SKU).
- Dashboard ops con scorte di magazzino + vendite real-time.
Vero o falso
- Import copia i dati nel
.pbix. - DirectQuery richiede refresh schedulato.
- Direct Lake legge tabelle Delta da OneLake senza copiarle.
- Direct Lake è disponibile anche con licenza Pro.
- VertiPaq comprime i dati nel modello Import.
Troubleshooting — il report DirectQuery è lentissimo
Hai un report DirectQuery su Snowflake. Un visual a barre con 10 categorie impiega 12 secondi ad apparire. Cosa controlli, in ordine, per diagnosticare?
Stack scelto, giustificalo
Sei chiamato in un'azienda manifatturiera. Hanno: 2 anni di vendite (15 GB in SQL), anagrafica clienti (50k righe in Excel), uno stream IoT da 200 sensori in tempo reale (Azure Event Hub → Lakehouse Fabric). Vogliono un cruscotto unico per il management. Quale architettura Power BI proponi e con quali modalità?
Quick check finale
Quale modalità copia i dati dentro il modello al refresh?
Che cosa richiede Direct Lake?
Hai finito la Lezione 2.2 ✓
Hai in tasca la decisione architetturale più importante di Power BI. Nella 2.3 torniamo concreti: carichiamo Excel, CSV e SQL passo-passo.