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 archiviano i dati in file Parquet in OneLake, che è l'archivio unico per tutti i dati analitici. 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 Fabric lakehouse o Fabric warehouse. Sia gli elementi di Fabric sia 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 di fallback 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 comporta un'operazione di framing (descritta più avanti in questo articolo), che può richiedere alcuni secondi per essere completata. 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 può aiutare a ridurre i tempi 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 è solitamente per i progetti analitici guidati dall'IT che utilizzano architetture incentrate sul data 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, 'integrazione di OneLake scrive automaticamente i dati per le tabelle in modalità di archiviazione di importazione in tabelle Delta in OneLake senza richiedere alcuna operazione di migrazione. Usando questa opzione, è possibile sfruttare molti dei vantaggi di Fabric resi disponibili per gli utenti che importano modelli semantici, come l'integrazione con i 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 che sia già stata eseguita la preparazione dei dati nel data lake), è possibile dipendere da aggiornamenti automatici per riframeare in risposta a tali modifiche. In questo caso, le query inviate al modello semantico restituiscono i dati più recenti. Questa funzionalità funziona bene in collaborazione con la funzionalità di aggiornamento automatico della pagina di dei report 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, se un analista self-service non dispone delle 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.
Quando si prende in considerazione la modalità di archiviazione Direct Lake, assicurati di considerare la licenza di capacità di Fabric corrente e i limiti di capacità di Fabric . Tenere inoltre conto delle considerazioni e delle limitazioni , descritte più avanti in questo articolo.
Consiglio
È 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 è costituita da 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 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 potrebbe verificarsi quando una tabella Delta contiene più righe di dati rispetto a quelle supportate dalla capacità di Fabric (descritto 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, i processi e le funzionalità utente 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 uno spazio di lavoro che utilizza la capacità Fabric è presente un lakehouse o un warehouse Fabric. 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 è presente in un'area di lavoro Fabric. 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 raggiungono prestazioni in memoria che sono 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 i guardrail della capacità, le query del modello semantico ritornano automaticamente in 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 eseguono a loro volta interrogazioni 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 di Direct Lake caricano i dati da OneLake solo quando vengono interpellate per la prima volta le colonne. Il processo di caricamento dei dati su richiesta da OneLake è noto come transcodifica.
Quando il modello semantico riceve una query DAX (Espressioni Multidimensionali—MDX), innanzitutto determina quali colonne sono necessarie per produrre il risultato della query. È necessaria qualsiasi colonna usata 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 è significativamente 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 veloce, ma può dipendere da fattori come la cardinalità dei dati archiviati nelle colonne.
Le colonne caricate in memoria sono quindi risiedono 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 per rimuoverla (espulsa) dalla memoria. I motivi per cui le colonne potrebbero essere rimosse includono:
- Il modello o la tabella è stata aggiornata successivamente a un refresh della tabella Delta nell'origine (vedere Framing 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 Fabric determina la memoria disponibile massima per ogni modello semantico Direct Lake nella capacità. Per altre informazioni sulle protezioni delle risorse e sui limiti massimi di memoria, vedere fabric capacity guardrails and limitations (Guardrail e limitazioni della capacità di Fabric) più avanti in questo articolo.
Inquadratura
Framing fornisce ai proprietari del modello un controllo puntuale 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 framing, i segmenti e i dizionari delle colonne della tabella residente potrebbero essere rimossi dalla memoria se i dati sottostanti sono stati modificati e il punto nel tempo dell'aggiornamento diventa la nuova base di riferimento 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 interrogate per restituire dati in base allo stato della tabella Delta al momento dell'operazione di inquadratura più recente. Tale ora non è necessariamente lo stato più recente delle tabelle Delta.
Si noti che il modello semantico analizza il log Delta di ogni tabella Delta durante il frame per eliminare solo i segmenti di colonna interessati e ricaricare i dati appena aggiunti durante la transcodifica. Un'ottimizzazione importante è che i dizionari in genere non verranno eliminati quando il frame incrementale diventa effettivo e i nuovi valori vengono aggiunti ai dizionari esistenti. Questo approccio incrementale consente di ridurre il carico di aggiornamento e di migliorare le prestazioni delle query. Nel caso ideale, quando una tabella Delta non ha ricevuto aggiornamenti, non è necessario ricaricare le colonne già residenti in memoria e le query mostrano un impatto molto inferiore sulle prestazioni dopo il frame, perché il frame incrementale consente essenzialmente al modello semantico di aggiornare parti sostanziali dei dati in memoria esistenti.
Il diagramma seguente illustra il funzionamento delle operazioni di frame Direct Lake.
Il diagramma illustra i processi e le funzionalità seguenti.
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 ulteriori informazioni, vedere Aggiornamento dei modelli semantici di Direct Lake.
Per ulteriori informazioni sul versionamento e sull'organizzazione 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. È abilitato 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.
Consiglio
È possibile configurare aggiornamento pagina automatico nei report di Power BI. Si tratta di una funzionalità che aggiorna automaticamente una pagina del report specifica, a condizione che il report sia connesso 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ò passare 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 ricorre sempre a un'azione di fallback quando il modello semantico interroga una vista nell'endpoint di analisi SQL o una tabella che applica la sicurezza a livello di riga (RLS)nell'endpoint di analisi SQL.
Inoltre, una query potrebbe ritornare 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 ulteriori informazioni, vedere Configurare la proprietà di comportamento di Direct Lake.
Protezioni e limitazioni della capacità del tessuto
I modelli semantici Direct Lake richiedono una licenza di capacità Fabric. Sono inoltre presenti limiti di capacità e restrizioni applicabili al vostro abbonamento alla capacità di Fabric (SKU), come mostrato 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 della capacità di Fabric (SKU F).
Per ulteriori informazioni, consultare Importante aggiornamento in arrivo per le licenze di Power BI Premium e Power BI Premium.
| SKU della rete | 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 | Illimitato | 25 |
| F128/P2 | 5,000 | 5,000 | 3,000 | Illimitato | 50 |
| F256/P3 | 5,000 | 5,000 | 6,000 | Illimitato | 100 |
| F512/P4 | 10.000 | 10.000 | 12,000 | Illimitato | 200 |
| F1024/P5 | 10.000 | 10.000 | 24,000 | Illimitato | 400 |
| F2048 | 10.000 | 10.000 | 24,000 | Illimitato | 400 |
1 Per i modelli semantici Direct Lake, memoria massima rappresenta il limite superiore delle risorse di memoria per la quantità di dati che può essere caricata in memoria. Per questo motivo, non è una barriera di protezione, perché il superamento non comporta una ricaduta in modalità DirectQuery; tuttavia, può avere un impatto sulle prestazioni se la quantità di dati è sufficientemente grande da causare un eccessivo paging dei dati del modello da quelli di OneLake.
Se superato, la dimensione massima del modello su disco/OneLake fa sì che tutte le query al modello semantico eseguino il fallback alla modalità DirectQuery. Tutti gli altri guardrail presentati nella tabella vengono valutati per ogni query. È quindi importante ottimizzare le tabelle Delta e 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, 'unità di capacità e 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 capacità 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 quella tabella del modello passeranno sempre 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 dei casi speciali, inclusi i gruppi di calcolo , parametri di simulazionee i parametri dei campi ).
- Le colonne calcolate e le tabelle calcolate che fanno riferimento a colonne o tabelle in modalità Direct Lake Storage non sono supportate. i gruppi di calcolo, i parametri di simulazionee i parametri di campo, che creano implicitamente tabelle calcolate, e le tabelle calcolate che non fanno riferimento a colonne o tabelle Direct Lake, sono supportate.
- 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 hanno esito negativo se vengono rilevati valori duplicati in una colonna a un lato.
- L'intelligenza automatica per data e ora in Power BI Desktop non è supportata. È supportato contrassegnare la tabella delle date personalizzata come tabella delle date.
- La lunghezza dei valori di colonna stringa è limitata a 32.764 caratteri Unicode.
- Il valore a virgola mobile NaN (non un numero) non è supportato.
- Pubblicare sul Web da Power BI utilizzando un'entità servizio è supportato solo quando si utilizza un'identità fissa per il modello semantico Direct Lake.
- Nell'esperienza di modellazione Web , la convalida è limitata per i modelli semantici Direct Lake. Si presume che le selezioni dell'utente siano corrette e non vengano eseguite query per convalidare la cardinalità o le selezioni di filtri incrociati per le relazioni, né per la colonna data selezionata in una tabella delle date 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 (inquadramento) non sono elencate.
- Lo SKU di Fabric determina la memoria massima disponibile per ogni modello semantico Direct Lake della 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 regione e creare scorciatoie alle tabelle prima di creare il modello semantico. Per individuare la regione in cui ti trovi, consulta la tua regione domestica di Fabric.
- È possibile creare e visualizzare un modello semantico Direct Lake personalizzato usando un'identità dell'entità servizio, ma il modello semantico Direct Lake predefinito non supporta le entità servizio. Assicurarsi che l'autenticazione dell'entità servizio sia abilitata per le API REST di Fabric nel tenant. Concedere all'entità servizio le autorizzazioni di Collaboratore o superiore all'area di lavoro del modello semantico Direct Lake.
- L'incorporazione dei report richiede un token di incorporazione V2.
- Direct Lake non supporta i profili degli agenti di servizio per l'autenticazione.
- I modelli semantici personalizzati Direct Lake creati dal principale del servizio e dal visualizzatore con principale del servizio sono supportati; tuttavia, i modelli semantici Direct Lake di default non sono supportati.
Confronto con altre modalità di archiviazione
La tabella seguente confronta la modalità di archiviazione Direct Lake con le modalità di archiviazione Import e DirectQuery.
| Capacità | Direct Lake | Importazione | DirectQuery |
|---|---|---|---|
| Licenze | Abbonamento alla capacità del tessuto solo per SKU | 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) |
| Fonte dati | Solo tabelle di tipo lakehouse o di magazzino (o viste) | Qualsiasi connettore | Qualsiasi connettore che supporta la modalità DirectQuery |
| Connettersi alle visualizzazioni degli endpoint di SQL Analytics | Sì, ma eseguirà automaticamente il fallback alla modalità DirectQuery | Sì | Sì |
| Modelli compositi | Nessun 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 |
| Autenticazione singola (Single Sign-On, SSO) | Sì | Non applicabile | Sì |
| Tabelle calcolate | No: ad eccezione dei gruppi di calcolo , parametri di simulazionee 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 modello di tabella | No, tuttavia il partizionamento può essere eseguito a livello della tabella Delta. | Sì: creato automaticamente dall'aggiornamento incrementale o creato manualmente usando 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 è necessario duplicare le autorizzazioni con la sicurezza degli oggetti del modello semantico. | Sì, ma le query potrebbero generare errori quando viene negata l'autorizzazione |
| Sicurezza a livello di riga per l'endpoint delle 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 è fortemente consigliato usare un'identità fissa per la connessione cloud | 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 programmatica, tuttavia, la preparazione dei dati deve essere eseguita a monte prima. | No | Sì |
| Power BI Embedded | Sì 2 | Sì | Sì |
1 Non è possibile combinare tabelle in modalità Archiviazione Direct Lake 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.
2 richiede un token di incorporamento V2. Se si usa un principale del servizio, si deve usare una connessione cloud a identità fissa .