Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 archiviate in OneLake, ovvero l'archivio singolo per tutti i dati di analisi. Dopo il caricamento in memoria, il modello semantico abilita l'analisi interattiva ad alte prestazioni.
Direct Lake è ideale per i modelli semantici che si connettono a grandi Fabric lakehouses, Fabric warehouses e altre origini con tabelle Delta, soprattutto quando replicare l'intero volume di dati in un modello di Importazione è difficile o impossibile. Le query Direct Lake vengono, come la modalità Import, elaborate dal motore di interrogazione VertiPaq, mentre DirectQuery federate le query all'origine dati sottostante. Ciò significa che le query Direct Lake, ad esempio la modalità di importazione, normalmente hanno prestazioni superiori a DirectQuery.
Tuttavia, un Direct Lake differisce da una modalità di importazione in modo importante: un'operazione di aggiornamento per un modello semantico Direct Lake è concettualmente diversa da un'operazione di aggiornamento per un modello semantico di importazione. La modalità di importazione replica i dati e crea un'intera copia memorizzata nella cache dei dati per il modello semantico, mentre un aggiornamento Direct Lake copia solo i metadati (noti come frame, descritti più avanti in questo articolo), che possono richiedere alcuni secondi. L'aggiornamento di Direct Lake è un'operazione a basso costo che analizza i metadati della versione più recente delle tabelle Delta e viene aggiornata per fare riferimento ai file più recenti in OneLake. Al contrario, per un aggiornamento di importazione viene creata una copia dei dati, che può richiedere molto tempo e utilizzare risorse significative di origine dati e capacità (memoria e CPU). Direct Lake sposta la preparazione dei dati in OneLake e in questo modo usa l'intera gamma di tecnologie fabric per la preparazione dei dati, tra cui processi Spark, istruzioni DML T-SQL, flussi di dati, pipeline e altro ancora.
La modalità Direct Lake Storage offre i vantaggi principali seguenti:
- Analogamente alla modalità di importazione, le query Direct Lake vengono elaborate dal motore VertiPaq e pertanto offrono prestazioni di query paragonabili alla modalità di importazione senza il sovraccarico di gestione dei cicli di aggiornamento dei dati per caricare l'intero volume di dati.
- Usa gli investimenti di Fabric esistenti integrando facilmente con grandi lakehouse, magazzini e altre origini fabric con tabelle Delta. Ad esempio, Direct Lake è una scelta ideale per il livello di analisi gold nell'architettura del lakehouse medallion.
- Ottimizza il ritorno sugli investimenti (ROI) perché i volumi di dati analizzati possono superare i limiti massimi di memoria della capacità, poiché solo i dati necessari per rispondere a una query vengono caricati in memoria.
- Riduce al minimo le latenze dei dati sincronizzando rapidamente e automaticamente un modello semantico con le relative origini, rendendo disponibili nuovi dati agli utenti aziendali senza pianificazioni di aggiornamento.
Quando è consigliabile usare la modalità di archiviazione Direct Lake?
Il caso d'uso principale per la modalità di archiviazione Direct Lake è generalmente per progetti di analisi gestiti dall'IT che utilizzano architetture incentrate sui data lake. In questi scenari, si prevede di accumulare volumi elevati 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 alcuno sforzo di migrazione, il che consente di sfruttare molti dei vantaggi di Fabric resi disponibili per gli utenti di modelli semantici Import, come l'integrazione con lakehouse tramite collegamenti, query SQL, notebook e altro ancora. È consigliabile usare questa opzione come modo rapido per sfruttare i vantaggi di Fabric senza necessariamente o riprogettare immediatamente il data warehouse esistente e/o il sistema di analisi.
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, che consentono di garantire che la logica di preparazione dei dati venga eseguita a monte 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, l'aumento del modello con le tabelle in modalità di archiviazione di importazione potrebbe essere una scelta ottimale, poiché la modalità importazione supporta la preparazione dei dati tramite Power Query, definito come parte del modello semantico.
Quando si considera la modalità di archiviazione Direct Lake, assicurarsi di prendere in considerazione la tua attuale licenza di capacità di Fabric e le protezioni per la 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.
Concetti chiave e terminologia
Questo articolo presuppone familiarità con i concetti seguenti:
- Gli utenti interagiscono con gli oggetti visivi nei report di Power BI, che generano query DAX nel modello semantico.
-
Modalità di archiviazione: il modello semantico elabora le query DAX in modo diverso a seconda della modalità di archiviazione usata. Per esempio:
- Le modalità di importazione e archiviazione Direct Lake usano il motore VertiPaq per elaborare le query DAX e restituire i risultati al report e all'utente di Power BI.
- DirectQuery, d'altra parte, converte le query DAX nella sintassi di query dell'origine dati (in genere una forma di SQL) e le esegue la federazione nel database sottostante. I processori di query del database di origine spesso non sono orientati alle query di tipo BI, aggregate e pertanto comportano prestazioni più lente e una riduzione dell'interattività dell'utente rispetto alle modalità Import e Direct Lake.
La modalità di archiviazione è una proprietà di una tabella nel modello semantico. Quando un modello semantico include tabelle con modalità di archiviazione diverse, viene definita modello composito. Per altre informazioni sulle modalità di archiviazione, vedere Modalità del modello semantico nel servizio Power BI.
La modalità Direct Lake può usare due metodi di accesso diversi:
- Direct Lake on OneLake non dipende dagli endpoint SQL e può utilizzare dati di qualsiasi origine dati di Fabric che contengano tabelle Delta. Direct Lake su OneLake non passa alla modalità DirectQuery.
Nota
Direct Lake su OneLake è attualmente disponibile in anteprima pubblica.
- Direct Lake negli endpoint SQL usa l'endpoint SQL di un lakehouse di Fabric o di un warehouse per l'individuazione delle tavole Delta e i controlli delle autorizzazioni. Direct Lake negli endpoint SQL può eseguire il fallback alla modalità DirectQuery quando non può caricare i dati direttamente da una tabella Delta, ad esempio quando l'origine dati è una vista SQL o quando warehouse usa sicurezza a livello di riga (RLS) basata su SQL. Direct Lake negli endpoint SQL è disponibile a livello generale e completamente supportato nell'ambiente di produzione.
Confronto tra le modalità di archiviazione
La tabella seguente confronta la modalità di archiviazione Direct Lake con le modalità di archiviazione Import e DirectQuery.
| Capacità | Direct Lake su OneLake | Implementazione di Direct Lake sugli endpoint SQL | Importazione | DirectQuery |
|---|---|---|---|---|
| Licenze | Abbonamento alla capacità del tessuto solo per SKU | 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 | Tabelle di qualsiasi origine dati di Fabric supportata da tabelle Delta | Solo tabelle o viste di tipo lakehouse o di magazzino | Qualsiasi connettore | Qualsiasi connettore che supporta la modalità DirectQuery |
| Collegarsi alle visualizzazioni degli endpoint di SQL Analytics | NO | Sì, ma eseguirà automaticamente il fallback alla modalità DirectQuery | Sì | Sì |
| Modelli compositi | Numero 1 | Numero 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ì | Sì | Non applicabile | Sì |
| Tabelle calcolate | Sì, ma i calcoli non possono fare riferimento a colonne di tabelle in modalità Direct Lake. | 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 | Sì, ma i calcoli non possono fare riferimento a colonne di tabelle in modalità Direct Lake. | NO | Sì | Sì |
| Tabelle ibride | NO | NO | Sì | Sì |
| Modello di partizioni della tabella | No. Tuttavia, il partizionamento può essere eseguito a livello di tabella Delta | 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 | NO | Sì: sono supportate le tabelle di aggregazione di importazione nelle tabelle DirectQuery | Sì |
| Sicurezza a livello di oggetto dell'endpoint di analisi SQL o sicurezza a livello di colonna | NO | Sì, ma potrebbe generare errori quando viene negata l'autorizzazione | Sì, ma è necessario 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 per l'endpoint delle analisi SQL | NO | Sì, ma le query passeranno alla modalità DirectQuery. | Sì – ma è necessario duplicare le autorizzazioni con il modello di 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ì, ma è consigliabile usare una connessione cloud di identità fissa | Sì | Sì |
| Sicurezza a livello di oggetto del modello semantico | Sì | Sì | Sì | Sì |
| Volumi di dati di grandi dimensioni senza requisiti di aggiornamento | Sì | Sì | NO | Sì |
| Ridurre la latenza dei dati | Sì: quando gli aggiornamenti automatici sono abilitati o la riframmentazione a livello di codice | Sì: quando gli aggiornamenti automatici sono abilitati o la riframmentazione a livello di codice | NO | Sì |
| Power BI Incorporato | Sì 2 | Sì 2 | Sì | Sì |
1 Quando si usa Direct Lake negli endpoint SQL, 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.
2 Richiede un token di incorporazione V2. Se si usa un principale del servizio, si deve usare una connessione cloud a identità fissa .
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.
Direct Lake in OneLake non è associato all'endpoint SQL, offrendo un'integrazione più stretta con le funzionalità di OneLake, ad esempio la sicurezza di OneLake e piani di query DAX più efficienti perché, ad esempio, il controllo della sicurezza basata su SQL non è obbligatorio. Il fallback directQuery non è supportato da Direct Lake in OneLake.
Con Direct Lake sugli endpoint SQL, una query DAX potrebbe 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 si verifica quando viene rilevata la sicurezza basata su SQL nell'endpoint SQL. 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.
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 diventano 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 per rimuoverla (espulsa) dalla memoria. I motivi per cui le colonne potrebbero essere rimosse includono:
- Il modello o la tabella è stata aggiornata dopo un aggiornamento della tabella Delta alla fonte (vedere Framing nella sezione successiva).
- Nessuna query ha utilizzato 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à di elaborazione. Per ulteriori informazioni sulle protezioni delle risorse e sui limiti massimi di memoria, consultare le "protezioni e limitazioni della capacità di Fabric" 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 framing, i segmenti delle colonne della tabella residente e i dizionari potrebbero essere rimossi dalla memoria se i dati sottostanti sono stati modificati e il momento dell'aggiornamento diventa il nuovo punto di riferimento per tutti i futuri eventi di transcodifica. A partire da questo punto, le query Direct Lake considerano solo i dati nelle tabelle Delta al momento dell'operazione di framing 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 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 di inquadramento consente di ridurre il carico di aggiornamento e di migliorare le prestazioni delle interrogazioni. 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 altre informazioni, vedere Aggiornare 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 l'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
Quando si usa Direct Lake negli endpoint SQL, una query inviata a un modello semantico Direct Lake può eseguire il fallback alla modalità DirectQuery , nel qual caso la tabella non funziona più in modalità Direct Lake. 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.
Quando si verifica il fallback directQuery, una query non usa più la modalità Direct Lake. Una query non può sfruttare la modalità Direct Lake 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 non può sfruttare la modalità Direct Lake quando una tabella Delta supera i limiti di 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 . Questa impostazione si applica solo a Direct Lake sugli endpoint SQL. Direct Lake in OneLake non supporta il fallback di DirectQuery. Per ulteriori informazioni, fare riferimento a Impostare la proprietà del comportamento Direct Lake.
Autorizzazioni di sicurezza e accesso ai dati
Per impostazione predefinita, Direct Lake usa l'accesso Single Sign-On (SSO), il che significa che l'identità che esegue query sul modello semantico (spesso un utente del report) deve essere autorizzata ad accedere ai dati. In alternativa, è possibile associare un modello Direct Lake a una connessione cloud condivisibile (SCC) per fornire un'identità fissa e disabilitare l'accesso SSO. In questo caso, solo l'identità fissa richiede l'accesso in lettura ai dati nell'origine.
Autorizzazioni degli elementi della struttura.
I modelli semantici Direct Lake rispettano un modello di sicurezza a più livelli. Eseguono controlli delle autorizzazioni per determinare se l'identità che tenta di accedere ai dati dispone delle autorizzazioni di accesso ai dati necessarie nell'elemento dati di origine e nel modello semantico. Le autorizzazioni possono essere assegnate direttamente o acquisite in modo implicito usando i ruoli dell'area di lavoro in Microsoft Fabric.
È importante sapere che Direct Lake in OneLake e Direct Lake sugli endpoint SQL eseguono controlli delle autorizzazioni in modo diverso.
- Direct Lake in OneLake richiede le autorizzazioni Read e ReadAll sul lakehouse/magazzino per accedere alle tabelle Delta.
- Direct Lake negli endpoint SQL richiede le autorizzazioni Read e ReadData nel lakehouse/warehouse per accedere ai dati dall'endpoint di analisi SQL.
Nota
Direct Lake in OneLake richiede che gli utenti dispongano dell'autorizzazione per leggere le tabelle Delta in OneLake e non necessariamente l'endpoint SQL. In questo modo viene applicata una progettazione centralizzata della sicurezza in cui OneLake è l'unica origine del controllo di accesso.
Direct Lake negli endpoint SQL richiede invece che gli utenti abbiano accesso in lettura all'endpoint SQL e non necessariamente alle tabelle Delta in OneLake. Questo perché Fabric concede le autorizzazioni necessarie al modello semantico per leggere le tabelle Delta e i file Parquet associati (per caricare i dati delle colonne in memoria). Il modello semantico dispone inoltre delle autorizzazioni necessarie per leggere periodicamente l'endpoint di analisi SQL per eseguire controlli delle autorizzazioni per determinare i dati a cui l'utente che esegue query (o l'identità fissa) può accedere.
Autorizzazioni del modello semantico
Oltre alle autorizzazioni per gli elementi di Fabric, è necessario concedere autorizzazioni agli utenti in modo che possano usare o gestire il modello semantico Direct Lake. In breve, gli utenti del report necessitano dell'autorizzazione lettura e i creatori di report necessitano di un'autorizzazione creazione aggiuntiva. Le autorizzazioni del modello semantico possono essere assegnate direttamente o acquisite in modo implicito usando i ruoli dell'area di lavoro. Per gestire le impostazioni del modello semantico (per l'aggiornamento e altre configurazioni), è necessario essere il proprietario del modello semantico .
Requisiti relativi alle autorizzazioni
Si considerino gli scenari e i requisiti di autorizzazione seguenti.
| Sceneggiatura | Autorizzazioni necessarie | Commenti |
|---|---|---|
| Gli utenti possono visualizzare i report | Concedere l'autorizzazione Lettura per i report e l'autorizzazione Lettura per il modello semantico. Se il modello semantico usa Direct Lake negli endpoint SQL e la connessione cloud utilizza SSO, assegnare almeno le autorizzazioni Read e ReadData per il lakehouse o il warehouse. Se il modello semantico utilizza Direct Lake su OneLake e la connessione cloud utilizza SSO, concedere almeno i permessi Read e ReadAll per le tabelle Delta su OneLake. |
I report non devono appartenere alla stessa area di lavoro del modello semantico. Per altre informazioni, vedere Strategia per gli utenti di sola lettura. |
| Gli utenti possono creare report | Concedere l'autorizzazione di compilazione per il modello semantico. Se il modello semantico utilizza Direct Lake nel contesto degli endpoint SQL e la connessione cloud utilizza l'accesso SSO, concedere almeno le autorizzazioni Read e ReadData per il lakehouse o il warehouse. Se il modello semantico utilizza Direct Lake su OneLake e la connessione cloud utilizza SSO, concedere almeno i permessi Read e ReadAll per le tabelle Delta su OneLake. |
Per altre informazioni, vedere Strategia per gli autori di contenuti. |
| Gli utenti possono visualizzare i report, ma viene negata l'esecuzione di query sulle tabelle lakehouse, endpoint di analisi SQL o Delta in OneLake | Concedere l'autorizzazione Lettura per i report e l'autorizzazione Lettura per il modello semantico. Non concedere agli utenti alcuna autorizzazione per le tabelle lakehouse, warehouse o Delta. |
Adatto solo quando il modello Direct Lake usa un'identità fissa tramite una connessione cloud con SSO disabilitato. |
| Gestire il modello semantico, incluse le impostazioni di aggiornamento | Richiede la proprietà del modello semantico. | Per altre informazioni, vedere Proprietà del modello semantico. |
Importante
È consigliabile testare sempre accuratamente le autorizzazioni prima di rilasciare il modello semantico e i report nell'ambiente di produzione.
Per altre informazioni, vedere Autorizzazioni del modello semantico.
Requisiti di capacità del tessuto
I modelli semantici Direct Lake richiedono una licenza di capacità di 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). Microsoft sta consolidando le opzioni di acquisto e ritirando gli SKU di Power BI Premium per capacità. I clienti nuovi ed esistenti dovrebbero invece prendere in considerazione l'acquisto di sottoscrizioni di capacità di Fabric (F SKUs).
Per altre informazioni, vedere Aggiornamento importante per le licenze Power BI Premium e Power BI Premium.
| SKU del tessuto | 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, 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é superarne non comporta il ritorno alla modalità DirectQuery; tuttavia, può avere un impatto sulle prestazioni se la quantità di dati è sufficientemente grande da causare un eccessivo scambio di pagina dei dati del modello dai dati di OneLake.
Se superata, la dimensione massima del modello su disco/OneLake causa che tutte le query al modello semantico passino alla modalità DirectQuery. Tutti gli altri guardrail presentati nella tabella vengono valutati per ogni query. È quindi importante ottimizzare le tabelle Delta e il modello semantico Direct Lake per evitare di dover aumentare inutilmente le prestazioni verso uno SKU di Fabric superiore.
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 capacità e le funzionalità dei modelli semantici Direct Lake sono in rapida evoluzione. Assicurarsi di tornare periodicamente per esaminare l'elenco più recente di considerazioni e limitazioni.
| Considerazioni/limitazioni | Direct Lake su OneLake | Direct Lake in SQL (endpoint di analisi) |
|---|---|---|
| Quando l'endpoint di analisi SQL applica la sicurezza a livello di riga, le query DAX vengono elaborate in modo diverso a seconda del tipo di modalità Direct Lake usata. Quando si utilizza Direct Lake su OneLake, le query avranno successo e non verrà applicata la RLS basata su SQL. Direct Lake in OneLake richiede che l'utente abbia accesso ai file, dato che OneLake non applica la sicurezza a livello di riga basata su SQL. |
Le interrogazioni avranno esito positivo. | Sì, a meno che il fallback non sia disabilitato nel qual caso le query avranno esito negativo. |
| Se una tabella nel modello semantico si basa su una vista SQL (non materializzata), le query DAX vengono elaborate in modo diverso a seconda del tipo di modalità Direct Lake usata. Negli endpoint SQL, Direct Lake passerà a DirectQuery in questo caso. Non è supportato creare una tabella Direct Lake in OneLake basata su una vista SQL non materializzata. È possibile utilizzare invece una vista materializzata del lakehouse poiché vengono create le tabelle Delta. In alternativa, usare una modalità di archiviazione diversa, ad esempio Import o DirectLake per le tabelle basate su viste SQL non materializzate. |
Non applicabile | Sì, a meno che il fallback non sia disabilitato nel qual caso le query avranno esito negativo. |
| La modellazione composita non è attualmente supportata, il che 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 gruppi di calcolo, parametri di simulazione e parametri di campo). | Non supportato | Non supportato |
| 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. | Non supportato | Non supportato |
| 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. | Non supportato | Non supportato |
| Le relazioni tra tabelle richiedono che i tipi di dati delle colonne correlate corrispondano. | Sì | Sì |
| 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. | Sì | Sì |
| Intelligenza automatica di data/ora in Power BI Desktop per creare relazioni usando solo la parte data di una colonna datetime. Nota: è supportato contrassegnare la propria tabella delle date come tabella delle date e creare relazioni tramite colonne di date. | Sostenuto | Non supportato |
| La lunghezza dei valori di colonna stringa è limitata a 32.764 caratteri Unicode. | Sì | Sì |
| I valori a virgola mobile non numerici, ad esempio NaN (non un numero), non sono supportati. | Sì | Sì |
| La pubblicazione sul Web da Power BI tramite un'entità servizio è supportata solo quando si usa un'identità fissa per il modello semantico Direct Lake. | Sì | Sì |
| 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. | Sì | Sì |
| Nel portale di Fabric la scheda Direct Lake nella cronologia degli aggiornamenti elenca gli errori di aggiornamento correlati a Direct Lake. Le operazioni di aggiornamento riuscite (frame) non vengono in genere elencate a meno che lo stato dell'aggiornamento non venga modificato, ad esempio da nessuna esecuzione precedente o da un errore di aggiornamento per l'esito positivo dell'aggiornamento o l'esito positivo dell'aggiornamento con avviso. | Sì | Sì |
| La capacità dello SKU di Fabric determina la memoria massima disponibile per il modello semantico Direct Lake. Quando viene superato il limite, le query al modello semantico potrebbero risultare più lente a causa di un paging eccessivo dei dati del modello. | Sì | Sì |
| La creazione di un modello semantico Direct Lake in uno spazio di lavoro situato in una regione diversa da quella dello spazio 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 verso le tabelle prima di creare il modello semantico. Per trovare l'area in cui ci si trova, vedere trovare l'area principale di Fabric. | Sì | Sì |
| L'incorporamento dei report richiede un token di incorporamento V2. | Sì | Non supportato |
| Profili del principale del servizio per l'autenticazione. | Non supportato | Non supportato |
| I modelli semantici Direct Lake di Power BI possono essere creati e interrogati dalle entità servizio, e l'appartenenza ai ruoli visualizzatore con le entità servizio è supportata, ma i modelli semantici Direct Lake predefiniti su lakehouse/warehouse non supportano questo scenario. | Sì | Sì |
| Le scorciatoie in una Lakehouse possono essere usate come origini dati per le tabelle del modello semantico. | Non supportato durante l'anteprima pubblica | Sostenuto |
| Creare modelli Direct Lake nelle aree di lavoro personali (Area di lavoro personale). | Non supportato | Non supportato |
| Regole della pipeline di distribuzione per riassociare l'origine dati. | Non supportato | Sostenuto |