Panoramica di Direct Lake
Direct Lake è un'opzione di modalità di archiviazione per le tabelle in un modello semantico di Power BI archiviato in un'area di lavoro di Microsoft Fabric. È ottimizzato per grandi volumi di dati che possono essere caricati rapidamente in memoria dalle tabelle Delta, che archivia i dati in file Parquet in OneLake, ovvero l'unico archivio per tutti i dati di analisi. Dopo il caricamento in memoria, il modello semantico consente query ad alte prestazioni. Direct Lake elimina la necessità lenta e costosa di importare dati nel modello.
È possibile usare la modalità Di archiviazione Direct Lake per connettersi alle tabelle o alle viste di un singolo warehouse di fabric o infrastruttura. Entrambi gli elementi di Infrastruttura e i modelli semantici Direct Lake richiedono una licenza di capacità di Fabric.
In alcuni modi, un modello semantico Direct Lake è simile a un modello semantico di importazione. Questo perché i dati del modello vengono caricati in memoria dal motore VertiPaq per prestazioni di query veloci(tranne nel caso del fallback di DirectQuery, illustrato più avanti in questo articolo).
Tuttavia, un modello semantico Direct Lake differisce da un modello semantico di importazione in modo importante. Ciò è dovuto al fatto che un'operazione di aggiornamento per un modello semantico Direct Lake è concettualmente diversa da un'operazione di aggiornamento per un modello semantico di importazione. Per un modello semantico Direct Lake, un aggiornamento prevede un'operazione di frame (descritta più avanti in questo articolo), che può richiedere alcuni secondi. Si tratta di un'operazione a basso costo in cui il modello semantico analizza i metadati della versione più recente delle tabelle Delta e viene aggiornato per fare riferimento ai file più recenti in OneLake. Al contrario, per un modello semantico di importazione, un aggiornamento produce una copia dei dati, che può richiedere molto tempo e utilizzare risorse significative di origine dati e capacità (memoria e CPU).
Nota
L'aggiornamento incrementale per un modello semantico di importazione consente di ridurre il tempo di aggiornamento e l'uso delle risorse di capacità.
Quando è consigliabile usare la modalità di archiviazione Direct Lake?
Il caso d'uso principale per una modalità di archiviazione Direct Lake è in genere destinato ai progetti di analisi basati su IT che sfruttano le architetture incentrate sul lake. In questo scenario, si prevede di accumulare grandi volumi di dati in OneLake. Il caricamento rapido dei dati in memoria, operazioni di aggiornamento frequenti e veloci, uso efficiente delle risorse di capacità e prestazioni rapide delle query sono tutti importanti per questo caso d'uso.
Nota
I modelli semantici di importazione e DirectQuery sono ancora rilevanti in Fabric e rappresentano la scelta giusta del modello semantico per alcuni scenari. Ad esempio, la modalità di archiviazione di importazione spesso funziona bene per un analista self-service che necessita della libertà e dell'agilità per agire rapidamente e senza dipendenze dall'IT per aggiungere nuovi elementi di dati.
Inoltre, l'integrazione di OneLake scrive automaticamente i dati per le tabelle in modalità di archiviazione import in tabelle Delta in OneLake senza richiedere alcuna operazione di migrazione. Usando questa opzione, è possibile sfruttare molti dei vantaggi di Fabric resi disponibili per l'importazione di utenti di modelli semantici, ad esempio l'integrazione con lakehouse tramite collegamenti, query SQL, notebook e altro ancora. È consigliabile considerare questa opzione come un modo rapido per sfruttare i vantaggi di Fabric senza necessariamente o rielaborare immediatamente il data warehouse e/o il sistema di analisi esistente.
La modalità Direct Lake Storage è adatta anche per ridurre al minimo la latenza dei dati per rendere rapidamente disponibili i dati agli utenti aziendali. Se le tabelle Delta vengono modificate in modo intermittente (e presupponendo di aver già eseguito la preparazione dei dati nel data lake), è possibile dipendere dagli aggiornamenti automatici da riframeare in risposta a tali modifiche. In questo caso, le query inviate al modello semantico restituiranno i dati più recenti. Questa funzionalità funziona bene in collaborazione con la funzionalità di aggiornamento automatico delle pagine dei report di Power BI.
Tenere presente che Direct Lake dipende dalla preparazione dei dati eseguita nel data lake. La preparazione dei dati può essere eseguita usando vari strumenti, ad esempio processi Spark per fabric lakehouses, istruzioni DML T-SQL per fabric warehouse, flussi di dati, pipeline e altri. Questo approccio consente di garantire che la logica di preparazione dei dati venga eseguita il più basso possibile nell'architettura per ottimizzare la riutilizzabilità. Tuttavia, se l'autore del modello semantico non ha la possibilità di modificare l'elemento di origine, ad esempio, nel caso di un analista self-service che potrebbe non avere autorizzazioni di scrittura in un lakehouse gestito dall'IT, la modalità di archiviazione di importazione potrebbe essere una scelta migliore. Ciò è dovuto al fatto che supporta la preparazione dei dati usando Power Query, definito come parte del modello semantico.
Assicurarsi di prendere in considerazione la licenza di capacità di Fabric corrente e la protezione della capacità di Fabric quando si considera la modalità di archiviazione Direct Lake. Tenere inoltre conto delle considerazioni e delle limitazioni descritte più avanti in questo articolo.
Suggerimento
È consigliabile produrre un prototipo o un modello di verifica (POC) per determinare se un modello semantico Direct Lake è la soluzione giusta e ridurre i rischi.
Funzionamento di Direct Lake
In genere, le query inviate a un modello semantico Direct Lake vengono gestite da una cache in memoria delle colonne provenienti dalle tabelle Delta. L'archiviazione sottostante per una tabella Delta è uno o più file Parquet in OneLake. I file Parquet organizzano i dati in base alle colonne anziché alle righe. I modelli semantici caricano intere colonne da tabelle Delta in memoria perché sono richieste dalle query.
Un modello semantico Direct Lake può anche usare il fallback DirectQuery, che comporta il passaggio senza problemi alla modalità DirectQuery. Il fallback DirectQuery recupera i dati direttamente dall'endpoint di analisi SQL del lakehouse o del warehouse. Ad esempio, il fallback può verificarsi quando una tabella Delta contiene più righe di dati rispetto a quelle supportate dalla capacità di Fabric (descritta più avanti in questo articolo). In questo caso, un'operazione DirectQuery invia una query all'endpoint di analisi SQL. Le operazioni di fallback potrebbero comportare prestazioni delle query più lente.
Il diagramma seguente illustra il funzionamento di Direct Lake usando lo scenario di un utente che apre un report di Power BI.
Il diagramma illustra le azioni utente, i processi e le funzionalità seguenti.
| Articolo | Descrizione |
|---|---|
 |
OneLake è un data lake che archivia i dati di analisi in formato Parquet. Questo formato di file è ottimizzato per l'archiviazione dei dati per i modelli semantici Direct Lake. |
 |
In un'area di lavoro che si trova in una capacità infrastruttura è presente un lakehouse o un warehouse di infrastruttura. Lakehouse ha un endpoint di analisi SQL, che offre un'esperienza basata su SQL per l'esecuzione di query. Le tabelle (o le viste) forniscono un mezzo per eseguire query sulle tabelle Delta in OneLake usando Transact-SQL (T-SQL). |
 |
Un modello semantico Direct Lake esiste in un'area di lavoro infrastruttura. Si connette a tabelle o viste nel lakehouse o nel magazzino. |
 |
Un utente apre un report di Power BI. |
 |
Il report di Power BI invia query DAX (Data Analysis Expressions) al modello semantico Direct Lake. |
 |
Quando possibile (e necessario), il modello semantico carica le colonne in memoria direttamente dai file Parquet archiviati in OneLake. Le query ottengono prestazioni in memoria, molto veloci. |
 |
Il modello semantico restituisce i risultati della query. |
 |
Il report di Power BI esegue il rendering degli oggetti visivi. |
 |
In determinate circostanze, ad esempio quando il modello semantico supera le protezioni della capacità, le query del modello semantico eseguono automaticamente il fallback alla modalità DirectQuery. In questa modalità, le query vengono inviate all'endpoint di analisi SQL del lakehouse o del warehouse. |
 |
Le query DirectQuery inviate all'endpoint di analisi SQL a loro volta eseguono query sulle tabelle Delta in OneLake. Per questo motivo, le prestazioni delle query potrebbero essere più lente rispetto alle query in memoria. |
Le sezioni seguenti descrivono concetti e funzionalità di Direct Lake, tra cui caricamento di colonne, frame, aggiornamenti automatici e fallback di DirectQuery.
Caricamento di colonne (transcodifica)
I modelli semantici Direct Lake caricano i dati solo da OneLake come e quando vengono eseguite query per la prima volta sulle colonne. Il processo di caricamento dei dati su richiesta da OneLake è noto come transcodifica.
Quando il modello semantico riceve una query DAX (o MDX), determina innanzitutto quali colonne sono necessarie per produrre un risultato della query. Le colonne necessarie includono tutte le colonne che vengono usate direttamente dalla query e anche le colonne richieste da relazioni e misure. In genere, il numero di colonne necessarie per produrre un risultato della query è molto inferiore al numero di colonne definite nel modello semantico.
Dopo aver compreso quali colonne sono necessarie, il modello semantico determina quali colonne sono già in memoria. Se le colonne necessarie per la query non sono in memoria, il modello semantico carica tutti i dati per tali colonne da OneLake. Il caricamento dei dati delle colonne è in genere un'operazione molto veloce, ma può dipendere da fattori quali la cardinalità dei dati archiviati nelle colonne.
Le colonne caricate in memoria sono quindi residenti in memoria. Le query future che coinvolgono solo le colonne residenti non devono caricare più colonne in memoria.
Una colonna rimane residente finché non c'è motivo di rimuoverla (rimossa) dalla memoria. I motivi per cui le colonne potrebbero essere rimosse includono:
- Il modello o la tabella è stata aggiornata (vedere Frame nella sezione successiva).
- Nessuna query ha usato la colonna per un certo periodo di tempo.
- Altri motivi di gestione della memoria, tra cui la pressione della memoria nella capacità dovuta ad altre operazioni simultanee.
La scelta dello SKU di Infrastruttura determina la memoria massima disponibile per ogni modello semantico Direct Lake sulla capacità. Per altre informazioni sulle protezioni delle risorse e sui limiti massimi di memoria, vedere Guardrail e limitazioni della capacità dell'infrastruttura più avanti in questo articolo.
Inquadratura
Il frame fornisce ai proprietari del modello il controllo temporizzato sui dati caricati nel modello semantico. Il frame è un'operazione Direct Lake attivata da un aggiornamento di un modello semantico e nella maggior parte dei casi il completamento richiede solo pochi secondi. Questo perché è un'operazione a basso costo in cui il modello semantico analizza i metadati della versione più recente delle tabelle Delta Lake e viene aggiornato per fare riferimento ai file Parquet più recenti in OneLake.
Quando si verifica il frame, le colonne residenti potrebbero essere rimosse dalla memoria e il punto nel tempo dell'aggiornamento diventa la nuova baseline per tutti gli eventi di transcodifica futuri. Da questo punto, le query Direct Lake considerano solo i dati nelle tabelle Delta al momento dell'operazione di frame più recente. Per questo motivo, le tabelle Direct Lake vengono sottoposte a query per restituire dati in base allo stato della tabella Delta al punto dell'operazione di frame più recente. Tale ora non è necessariamente lo stato più recente delle tabelle Delta.
Il diagramma seguente illustra il funzionamento delle operazioni di frame Direct Lake.
Il diagramma illustra i processi e le funzionalità seguenti.
| Articolo | Descrizione |
|---|---|
|
Un modello semantico esiste in un'area di lavoro infrastruttura. |
|
Le operazioni di frame vengono eseguite periodicamente e impostano la linea di base per tutti gli eventi di transcodifica futuri. Le operazioni di frame possono essere eseguite automaticamente, manualmente, in base alla pianificazione o a livello di codice. |
|
OneLake archivia i metadati e i file Parquet, rappresentati come tabelle Delta. |
|
L'ultima operazione di frame include i file Parquet correlati alle tabelle Delta e in particolare i file Parquet aggiunti prima dell'ultima operazione di frame. |
|
Un'operazione di frame successiva include i file Parquet aggiunti dopo l'ultima operazione di frame. |
|
Le colonne residenti nel modello semantico Direct Lake potrebbero essere rimosse dalla memoria e il punto nel tempo dell'aggiornamento diventa la nuova baseline per tutti gli eventi di transcodifica futuri. |
|
Le successive modifiche ai dati, rappresentate dai nuovi file Parquet, non sono visibili fino a quando non si verifica l'operazione di frame successiva. |
Non è sempre consigliabile disporre di dati che rappresentano lo stato più recente di una tabella Delta quando viene eseguita un'operazione di transcodifica. Si consideri che il frame consente di fornire risultati di query coerenti in ambienti in cui i dati nelle tabelle Delta sono temporanei. I dati possono essere temporanei per diversi motivi, ad esempio quando si verificano processi di estrazione, trasformazione e caricamento (ETL) a esecuzione prolungata.
L'aggiornamento per un modello semantico Direct Lake può essere eseguito manualmente, automaticamente o a livello di codice. Per altre informazioni, vedere Aggiornare i modelli semantici Direct Lake.
Per altre informazioni sul controllo delle versioni e sul frame delle tabelle Delta, vedere Informazioni sull'archiviazione per i modelli semantici Direct Lake.
Aggiornamenti automatici
È disponibile un'impostazione a livello di modello semantico per aggiornare automaticamente le tabelle Direct Lake. È abilitata per impostazione predefinita. Garantisce che le modifiche ai dati in OneLake vengano riflesse automaticamente nel modello semantico Direct Lake. È consigliabile disabilitare gli aggiornamenti automatici quando si desidera controllare le modifiche dei dati in base al frame, come illustrato nella sezione precedente. Per altre informazioni, vedere Gestire modelli semantici Direct Lake.
Suggerimento
È possibile configurare l'aggiornamento pagina automatico nei report di Power BI. Si tratta di una funzionalità che aggiorna automaticamente una pagina del report specifica che il report si connette a un modello semantico Direct Lake (o ad altri tipi di modello semantico).
Fallback di DirectQuery
Una query inviata a un modello semantico Direct Lake può eseguire il fallback alla modalità DirectQuery. In questo caso, recupera i dati direttamente dall'endpoint di analisi SQL del lakehouse o del warehouse. Tali query restituiscono sempre i dati più recenti perché non sono vincolati al momento dell'ultima operazione di frame.
Una query esegue sempre il fallback quando il modello semantico esegue query su una vista nell'endpoint di analisi SQL o una tabella nell'endpoint di analisi SQL che applica la sicurezza a livello di riga.
Inoltre, una query potrebbe eseguire il fallback quando il modello semantico supera le protezioni della capacità.
Importante
Se possibile, è consigliabile progettare sempre la soluzione, o ridimensionare la capacità, per evitare il fallback di DirectQuery. Questo perché potrebbe comportare un rallentamento delle prestazioni delle query.
È possibile controllare il fallback dei modelli semantici Direct Lake impostando la relativa proprietà DirectLakeBehavior . Per altre informazioni, vedere Impostare la proprietà del comportamento direct Lake.
Protezioni e limitazioni della capacità dell'infrastruttura
I modelli semantici Direct Lake richiedono una licenza di capacità di Fabric. Esistono anche protezioni di capacità e limitazioni applicabili alla sottoscrizione della capacità di Infrastruttura (SKU), come illustrato nella tabella seguente.
Importante
La prima colonna della tabella seguente include anche le sottoscrizioni della capacità Power BI Premium (SKU P). Tenere presente che Microsoft sta consolidando le opzioni di acquisto e ritirando gli SKU di Power BI Premium per capacità. I clienti nuovi ed esistenti devono invece prendere in considerazione l'acquisto di sottoscrizioni con capacità Fabric (SKU F).
Per altre informazioni, vedere Aggiornamento importante per le licenze Power BI Premium e Power BI Premium.
| Fabric SKU | File parquet per tabella | Gruppi di righe per tabella | Righe per tabella (milioni) | Dimensioni massime del modello su disco/OneLake (GB) | Memoria massima (GB) 1 |
|---|---|---|---|---|---|
| F2 | 1.000 | 1,000 | 300 | 10 | 3 |
| F4 | 1.000 | 1,000 | 300 | 10 | 3 |
| F8 | 1.000 | 1,000 | 300 | 10 | 3 |
| F16 | 1.000 | 1,000 | 300 | 20 | 5 |
| F32 | 1.000 | 1,000 | 300 | 40 | 10 |
| F64/FT1/P1 | 5,000 | 5,000 | 1.500 | Nessun limite | 25 |
| F128/P2 | 5,000 | 5,000 | 3,000 | Nessun limite | 50 |
| F256/P3 | 5,000 | 5,000 | 6.000 | Nessun limite | 100 |
| F512/P4 | 10,000 | 10,000 | 12,000 | Nessun limite | 200 |
| F1024/P5 | 10,000 | 10,000 | 24,000 | Nessun limite | 400 |
| F2048 | 10,000 | 10,000 | 24,000 | Nessun limite | 400 |
1 Per i modelli semantici Direct Lake, Max Memory rappresenta il limite massimo di risorse di memoria per la quantità di dati in cui è possibile eseguire il paging. Per questo motivo, non è un guardrail perché il superamento non comporta un fallback in modalità DirectQuery; Tuttavia, può avere un impatto sulle prestazioni se la quantità di dati è sufficientemente grande da causare un paging eccessivo dei dati del modello dai dati di OneLake.
Se superato, le dimensioni massime del modello su disco/OneLake causeranno il fallback di tutte le query al modello semantico alla modalità DirectQuery. Tutte le altre protezioni presentate nella tabella vengono valutate per ogni query. È quindi importante ottimizzare le tabelle Delta e il modello semantico Direct Lake per evitare di dover aumentare inutilmente le prestazioni fino a uno SKU di Infrastruttura superiore (con conseguente aumento dei costi).
Inoltre, le unità di capacità e i limiti di memoria massima per query si applicano ai modelli semantici Direct Lake. Per altre informazioni, vedere Capacità e SKU.
Considerazioni e limitazioni
I modelli semantici Direct Lake presentano alcune considerazioni e limitazioni.
Nota
Le funzionalità e le funzionalità dei modelli semantici Direct Lake sono in continua evoluzione. Assicurarsi di tornare periodicamente per esaminare l'elenco più recente di considerazioni e limitazioni.
- Quando una tabella del modello semantico Direct Lake si connette a una tabella nell'endpoint di analisi SQL che applica la sicurezza a livello di riga, le query che coinvolgono tale tabella del modello eseguiranno sempre il fallback alla modalità DirectQuery. Le prestazioni delle query potrebbero risultare più lente.
- Quando una tabella del modello semantico Direct Lake si connette a una vista nell'endpoint di analisi SQL, le query che coinvolgono tale tabella del modello eseguiranno sempre il fallback alla modalità DirectQuery. Le prestazioni delle query potrebbero risultare più lente.
- La modellazione composita non è supportata. Ciò significa che le tabelle del modello semantico Direct Lake non possono essere combinate con le tabelle in altre modalità di archiviazione, ad esempio Import, DirectQuery o Dual (ad eccezione di casi speciali, inclusi i gruppi di calcolo, i parametri di simulazione e i parametri di campo).
- Le colonne calcolate e le tabelle calcolate che fanno riferimento a colonne o tabelle in modalità Direct Lake Storage non sono supportate. Sono supportati gruppi di calcolo, parametri di simulazione e parametri di campo, che creano in modo implicito tabelle calcolate e tabelle calcolate che non fanno riferimento a colonne o tabelle Direct Lake.
- Le tabelle in modalità Direct Lake Storage non supportano tipi di colonne di tabella Delta complesse. Anche i tipi semantici binari e GUID non sono supportati. È necessario convertire questi tipi di dati in stringhe o in altri tipi di dati supportati.
- Le relazioni tra tabelle richiedono che i tipi di dati delle colonne correlate corrispondano.
- Le colonne a un lato delle relazioni devono contenere valori univoci. Le query avranno esito negativo se vengono rilevati valori duplicati in una colonna a un lato.
- L'intelligenza automatica dei dati/ora in Power BI Desktop non è supportata. Contrassegnare la tabella data personalizzata come tabella data è supportata.
- La lunghezza dei valori di colonna stringa è limitata a 32.764 caratteri Unicode.
- Il valore a virgola mobile NaN (non un numero) non è supportato.
- Gli scenari di incorporamento che usano lo scenario Per l'utilizzo dei clienti non sono supportati.
- La pubblicazione sul Web da Power BI è supportata solo quando si usa un'identità fissa per il modello semantico Direct Lake.
- Nell'esperienza di modellazione Web la convalida è limitata per i modelli semantici Direct Lake. Si presuppone che le selezioni utente siano corrette e non vengano eseguite query per convalidare la cardinalità o le selezioni tra filtri per le relazioni o per la colonna data selezionata in una tabella data contrassegnata.
- Nel portale di Fabric la scheda Direct Lake nella cronologia degli aggiornamenti elenca solo gli errori di aggiornamento correlati a Direct Lake. Le operazioni di aggiornamento riuscite (frame) non sono elencate.
- Lo SKU di Infrastruttura determina la memoria massima disponibile per ogni modello semantico Direct Lake per la capacità. Quando viene superato il limite, le query al modello semantico potrebbero risultare più lente a causa di un paging eccessivo dei dati del modello.
- La creazione di un modello semantico Direct Lake in un'area di lavoro in un'area diversa dell'area di lavoro dell'origine dati non è supportata. Ad esempio, se lakehouse si trova negli Stati Uniti centro-occidentali, è possibile creare modelli semantici solo da questa Lakehouse nella stessa area. Una soluzione alternativa consiste nel creare una lakehouse nell'area di lavoro dell'altra area di lavoro e collegamenti alle tabelle prima di creare il modello semantico. Per trovare l'area in cui ci si trova, vedere trovare l'area principale di Fabric.
Confronto con altre modalità di archiviazione
La tabella seguente confronta la modalità di archiviazione Direct Lake con le modalità di archiviazione Import e DirectQuery.
| Funzionalità | Direct Lake | Importa | DirectQuery |
|---|---|---|---|
| Licenze | Solo SKU (Fabric Capacity Subscription) | Qualsiasi licenza di Fabric o Power BI (incluse le licenze gratuite di Microsoft Fabric) | Qualsiasi licenza di Fabric o Power BI (incluse le licenze gratuite di Microsoft Fabric) |
| Origine dati | Solo tabelle lakehouse o warehouse (o viste) | Qualsiasi connettore | Qualsiasi connettore che supporta la modalità DirectQuery |
| Connettersi alle viste degli endpoint di analisi SQL | Sì, ma eseguirà automaticamente il fallback alla modalità DirectQuery | Sì | Sì |
| Modelli compositi | No 1 | Sì: può essere combinato con le tabelle in modalità DirectQuery o Dual Storage | Sì: può essere combinato con le tabelle in modalità importazione o doppia archiviazione |
| Single sign-on (SSO) | Sì | Non applicabile | Sì |
| Tabelle calcolate | No: ad eccezione dei gruppi di calcolo, dei parametri di simulazione e dei parametri di campo, che creano in modo implicito tabelle calcolate | Sì | No: le tabelle calcolate usano la modalità di archiviazione import anche quando fanno riferimento ad altre tabelle in modalità DirectQuery |
| Colonne calcolate | No | Sì | Sì |
| Tabelle ibride | No | Sì | Sì |
| Partizioni di tabella del modello | No. Tuttavia , il partizionamento può essere eseguito a livello di tabella Delta | Sì: creato automaticamente dall'aggiornamento incrementale o creato manualmente tramite l'endpoint XMLA | No |
| Aggregazioni definite dall'utente | No | Sì | Sì |
| Sicurezza a livello di oggetto dell'endpoint di analisi SQL o sicurezza a livello di colonna | Sì, ma le query eseguiranno il fallback alla modalità DirectQuery e potrebbero generare errori quando viene negata l'autorizzazione | Sì, ma deve duplicare le autorizzazioni con la sicurezza a livello di oggetto del modello semantico | Sì, ma le query potrebbero generare errori quando viene negata l'autorizzazione |
| Sicurezza a livello di riga dell'endpoint di analisi SQL | Sì, ma le query eseguiranno il fallback alla modalità DirectQuery | Sì, ma deve duplicare le autorizzazioni con la sicurezza a livello di riga del modello semantico | Sì |
| Sicurezza a livello di riga del modello semantico | Sì, ma è consigliabile usare una connessione cloud di identità fissa | Sì | Sì |
| Sicurezza a livello di oggetto del modello semantico | Sì | Sì | Sì |
| Volumi di dati di grandi dimensioni senza requisiti di aggiornamento | Sì | Meno adatto: potrebbe essere necessaria una dimensione di capacità maggiore per l'esecuzione di query e l'aggiornamento | Sì |
| Ridurre la latenza dei dati | Sì: quando gli aggiornamenti automatici sono abilitati o la riframmentazione a livello di codice; tuttavia, la preparazione dei dati deve essere eseguita prima upstream | No | Sì |
1 Non è possibile combinare tabelle in modalità Direct Lake Storage con tabelle in modalità DirectQuery o dual storage nello stesso modello semantico. Tuttavia, è possibile usare Power BI Desktop per creare un modello composito in un modello semantico Direct Lake e quindi estenderlo con nuove tabelle (usando la modalità di importazione, DirectQuery o archiviazione doppia) o calcoli. Per altre informazioni, vedere Creare un modello composito in un modello semantico.