Scegliere una modalità di archiviazione
La prima decisione di progettazione per qualsiasi modello semantico in Microsoft Fabric è la modalità di flusso dei dati nel modello. La modalità di archiviazione scelta influisce sulle prestazioni delle query, sull'aggiornamento dei dati e sulle funzionalità Fabric disponibili. In Fabric Direct Lake è l'impostazione predefinita e per la maggior parte dei carichi di lavoro è la scelta giusta.
Modalità Direct Lake
Direct Lake è la modalità di archiviazione predefinita per i modelli semantici creati in Microsoft Fabric. A differenza della modalità di importazione, Direct Lake non copia i dati nel modello. A differenza di DirectQuery, non converte le query in SQL di origine. Direct Lake legge invece le tabelle Delta direttamente da OneLake nella memoria, che combina la velocità dell'importazione all'aggiornamento di DirectQuery.
Quando un utente apre un report supportato da un modello semantico Direct Lake, il motore carica i dati delle colonne dai file Delta Parquet su richiesta. Non è necessario pianificare un aggiornamento, come si fa con la modalità importazione. Quando le tabelle Delta sottostanti vengono aggiornate, il modello riflette tali modifiche.
I modelli Direct Lake abilitano automaticamente il formato di archiviazione di modelli semantici di grandi dimensioni. Questa impostazione rimuove il limite di dimensioni del modello da 10 GB ed è un prerequisito sia per la scalabilità orizzontale delle query sia per l'accesso in lettura/scrittura dell'endpoint XMLA. Non è necessario abilitarlo manualmente per i modelli Direct Lake.
Opzioni di connessione Direct Lake
I modelli Direct Lake possono connettersi ai dati tramite due percorsi:
- Tabelle OneLake: il modello si connette direttamente alle tabelle Delta in un lakehouse o in un magazzino. Questo è il percorso più semplice e funziona bene quando i dati si trovano in un singolo archivio dati Fabric.
- Endpoint di analisi SQL: il modello si connette tramite l'endpoint SQL di un lakehouse o di un warehouse. Questo percorso consente l'accesso a viste, query tra database e funzionalità di sicurezza definite a livello SQL.
Scegliere tabelle OneLake quando i dati sono semplici e si trovano in un'unica posizione. Scegli l'endpoint di analisi SQL quando hai bisogno di viste, di join tra origini, o di sicurezza a livello di riga definita in SQL.
Comportamento di fallback
Alcune operazioni possono causare il fallback di un modello Direct Lake alla modalità DirectQuery. Calcoli DAX complessi, query che superano la memoria disponibile o alcune operazioni non supportate attivano questo fallback. Quando si verifica il fallback, la query viene eseguita sull'endpoint di analisi SQL anziché leggere direttamente i file Delta.
È possibile configurare il comportamento di fallback nelle impostazioni del modello semantico:
- Consenti fallback: le query che non possono essere eseguite in modalità Direct Lake eseguono automaticamente il fallback a DirectQuery. L'utente ottiene risultati, ma le prestazioni potrebbero diminuire.
- Non consentire il fallback: le query che non possono essere eseguite in modalità Direct Lake restituiscono un errore. Questa opzione applica prestazioni coerenti, ma richiede che tutte le query rimangano all'interno delle funzionalità di Direct Lake.
Per la maggior parte dei carichi di lavoro di produzione, iniziare con il fallback consentito e monitorare le query che lo attivano. Ottimizzare queste query o le strutture di dati per ridurre la frequenza di fallback nel tempo.
Modalità di importazione
La modalità di importazione copia i dati nel modello semantico e li archivia in un formato compresso in memoria. Le query vengono eseguite sulla copia locale, che rende l'importazione la modalità di archiviazione più veloce per le prestazioni delle query. Tuttavia, i dati sono aggiornati solo fino all'ultimo aggiornamento.
La modalità di importazione è la scelta giusta quando:
- L'origine dati non è Fabric (database locali, API di terze parti, file flat).
- Le prestazioni delle query sono la priorità principale e l'aggiornamento near-real-time non è necessario.
- Sono necessarie funzionalità non ancora supportate in Direct Lake.
Tip
Quando si usa la modalità importazione, connettersi alle viste anziché alle tabelle non elaborate, includere solo le colonne necessarie e usare i tipi di dati appropriati per ridurre le dimensioni del modello. Altre informazioni sulle tecniche per ridurre i dati caricati nei modelli di importazione.
Modalità DirectQuery
DirectQuery invia query direttamente all'origine dati in fase di query. Nessun dato viene archiviato nel modello, che rende DirectQuery adatto per scenari di dati in tempo reale e set di dati molto grandi che non possono essere importati.
Il compromesso è rappresentato dalle prestazioni. Ogni interazione del report genera una query sul sistema di origine. DirectQuery funziona meglio quando:
- I dati in tempo reale sono necessari e anche brevi ritardi di aggiornamento non sono accettabili.
- I volumi di dati di origine sono troppo grandi per l'importazione e l'origine dati non è Fabric.
- I requisiti di governance impongono che i dati rimangano all'origine.
Tip
Per altre informazioni, vedere Linee guida per il modello DirectQuery.
Modalità Composita
La modalità composita combina le modalità di archiviazione all'interno di un singolo modello. Alcune tabelle usano Import, mentre altre usano DirectQuery o Direct Lake. Ciò offre flessibilità per gli scenari in cui diverse tabelle hanno esigenze di prestazioni e aggiornamento diverse.
Ad esempio, una tabella dei fatti di grandi dimensioni potrebbe rimanere in Direct Lake, mentre una piccola tabella di riferimento proveniente da una fonte esterna potrebbe utilizzare Import. La modalità composita consente anche relazioni molti-a-molti tra tabelle di origini dati diverse.
Usare la modalità composita quando:
- Sono necessari dati provenienti sia da origini Fabric che non Fabric nello stesso modello.
- Alcune tabelle richiedono dati in tempo reale, mentre altri traggono vantaggio dalle prestazioni memorizzate nella cache.
- È necessario combinare le tabelle Direct Lake con le tabelle di importazione per l'analisi tra origini.
Scegliere la modalità di archiviazione corretta
La tabella seguente riepiloga quando scegliere ogni modalità:
| Modo | Ubicazione dei dati | Velocità delle query | Aggiornamento dei dati | Ideale per |
|---|---|---|---|---|
| Direct Lake | OneLake (tabelle Delta) | Veloce | Quasi in tempo reale | carichi di lavoro nativi di Fabric (impostazione predefinita) |
| Importa | Cache nel modello | Il più veloce | Dipendente dall'aggiornamento | Origini non-Fabric, massime prestazioni |
| DirectQuery | Sistema di origine | Dipende dal sistema di origine | Quasi in tempo reale | Requisiti in tempo reale, dati esterni molto grandi |
| Composita | Mixed | Variabile | Mixed | Scenari con fonti incrociate, requisiti ibridi |
La modalità di archiviazione influisce anche sul consumo di intelligenza artificiale. Quando Copilot o agenti dati eseguono query su un modello semantico, restituiscono risposte in base ai dati attualmente visualizzati dal modello. L'aggiornamento quasi in tempo reale di Direct Lake significa che le query di intelligenza artificiale restituiscono i risultati correnti senza attendere un aggiornamento pianificato. Per i modelli che servono sia gli utenti umani che l'intelligenza artificiale, la scelta della modalità di archiviazione influisce direttamente sulla qualità di entrambe le esperienze.
In Fabric iniziare con Direct Lake. Passare a un'altra modalità solo quando lo scenario specifico lo richiede.