Direct Lake

La modalità Direct Lake è una funzionalità del modello semantico per l'analisi di volumi di dati molto grandi in Power BI. Direct Lake si basa sul caricamento di file in formato parquet direttamente da un data lake senza dover eseguire query su un endpoint lakehouse o warehouse e senza dover importare o duplicare i dati in un modello Power BI. Direct Lake è un percorso rapido per caricare i dati dal lake direttamente nel motore di Power BI, pronti per essere analizzati. Il diagramma seguente illustra il confronto tra le modalità di importazione classica e DirectQuery con la modalità Direct Lake.

In modalità DirectQuery, il motore di Power BI esegue una query sui dati nell'origine, che può essere lento, ma evita di dover copiare i dati come avviene con la modalità di importazione. Tutte le modifiche apportate all'origine dati vengono immediatamente riflesse nei risultati della query.

D'altra parte, con la modalità importazione le prestazioni possono essere migliori perché i dati vengono memorizzati nella cache e ottimizzati per le query di report DAX e MDX senza dover tradurre e passare SQL o altri tipi di query all'origine dati. Tuttavia, il motore di Power BI deve prima copiare tutti i nuovi dati nel modello nel corso dell'aggiornamento. Eventuali modifiche alla fonte vengono recepite solo con il successivo aggiornamento del modello.

La modalità Direct Lake elimina il requisito di importazione caricando i dati direttamente da OneLake. A differenza di DirectQuery, non è prevista la traduzione da DAX o MDX ad altri linguaggi di query o l'esecuzione di query su altri sistemi di database, con prestazioni simili alla modalità di importazione. Poiché non c'è un processo di importazione esplicito, è possibile rilevare le modifiche all'origine dei dati nel momento in cui si verificano, combinando i vantaggi di entrambe le modalità DirectQuery e di importazione ed evitandone gli svantaggi. La modalità Direct Lake può essere la scelta ideale per l'analisi di modelli di grandi dimensioni e di modelli con aggiornamenti frequenti nell'origine dati.

Direct Lake supporta anche sicurezza a livello di riga di Power BI e sicurezza a livello di oggetto in modo che gli utenti visualizzino solo i dati che sono autorizzati a visualizzare.

Prerequisiti

Direct Lake è supportato solo per gli SKU F di Microsoft Premium (P) e Microsoft Fabric (F).

Importante

Per i nuovi clienti, Direct Lake è supportato solo per gli SKU di Microsoft Fabric (F). I clienti esistenti possono continuare a usare Direct Lake con SKU Premium (P), ma è consigliabile passare a uno SKU di capacità dell'infrastruttura. Per altre informazioni sulle licenze di Power BI Premium, vedere l'annuncio delle licenze.

Lakehouse

Prima di usare Direct Lake, è necessario effettuare il provisioning di un lakehouse (o di un warehouse) con una o più tabelle Delta in un'area di lavoro ospitata in una capacità di Microsoft Fabric supportata. Il lakehouse è necessario perché fornisce il percorso di archiviazione per i file in formato parquet in OneLake.

Per informazioni su come effettuare il provisioning di un lakehouse, creare una tabella delta nel lakehouse e un modello di base per lakehouse, vedere Creare un lakehouse per Direct Lake.

Endpoint di analisi SQL e data warehouse

Nell'ambito del provisioning di un lakehouse, vengono creati e aggiornati un endpoint Analisi SQL per l'esecuzione di query SQL con tutte le tabelle aggiunte al lakehouse. Anche se la modalità Direct Lake non esegue query sull'endpoint Analisi SQL quando si caricano dati direttamente da OneLake, è necessario quando un modello Direct Lake deve eseguire facilmente il fallback alla modalità DirectQuery, ad esempio quando l'origine dati utilizza funzionalità specifiche come la sicurezza avanzata o le visualizzazioni che non possono essere lette tramite Direct Lake e devono utilizzare l’endpoint Analisi SQL. La modalità Direct Lake esegue periodicamente anche una query sull'endpoint Analisi SQL per ottenere informazioni correlate allo schema e alla sicurezza.

In alternativa a un lakehouse con endpoint Analisi SQL, è anche possibile effettuare il provisioning di un warehouse e aggiungere tabelle usando istruzioni SQL o pipeline di dati. La procedura per effettuare il provisioning di un data warehouse autonomo è quasi identica alla procedura per un lakehouse.

Modello semantico predefinito di Power BI

I warehouse e gli endpoint di analisi SQL creano anche un Modello semantico predefinito di Power BI in modalità Direct Lake. Questo modello semantico predefinito può essere modificato solo all'interno del warehouse o dell'endpoint di analisi SQL e presenta limitazioni aggiuntive. Si veda la documentazione Modello semantico predefinito di Power BI. Questa documentazione di Direct Lake riguarda i modelli semantici di Power BI non predefiniti in modalità Direct Lake.

Creare un modello semantico di Power BI in modalità Direct Lake

I modelli semantici di Power BI in modalità Direct Lake vengono creati nel lakehouse o nel warehouse.

Nel lakehouse fare clic su Nuovo modello semantico di Power BI per creare un modello semantico di Power BI in modalità Direct Lake.

Nell'endpoint di analisi di warehouse o SQL selezionare la barra multifunzione Report e poi Nuovo modello semantico di Power BI per creare un modello semantico di Power BI in modalità Direct Lake.

Successivamente si possono aggiungere relazioni, misure, gruppi di calcoli, stringhe di formato, sicurezza a livello di riga e così via, rinominare tabelle e colonne modificando il modello semantico nel browser. Modificare il modello semantico in un secondo momento utilizzando il menu di scelta rapida nell'area di lavoro per aprire il modello di dati.

Supporto per la scrittura di modelli con l'endpoint XMLA

I modelli Direct Lake supportano le operazioni di scrittura attraverso l'endpoint XMLA utilizzando strumenti come SQL Server Management Studio (versione 19.1 e successive) e le ultime versioni di strumenti di BI esterni come Tabular Editor e DAX studio. Operazioni di scrittura del modello tramite il supporto dell'endpoint XMLA:

• Personalizzazione, unione, scripting, debug e test dei metadati del modello Direct Lake.

• Controllo del codice sorgente e della versione, integrazione continua e distribuzione continua (CI/CD) con Azure DevOps e GitHub.

• Attività di automazione come l'aggiornamento e l'applicazione di modifiche ai modelli Direct Lake usando PowerShell e le API REST.

Le tabelle Direct Lake create con applicazioni XMLA inizialmente saranno in uno stato non elaborato fino a quando l'applicazione non rilascia un comando di aggiornamento. Le tabelle non elaborate tornano alla modalità DirectQuery. Quando si crea un nuovo modello semantico, assicurarsi di aggiornare il modello semantico per elaborare le tabelle.

Abilitare la lettura/scrittura XMLA

Prima di eseguire operazioni di scrittura sui modelli Direct Lake tramite l'endpoint XMLA, è necessario abilitare la lettura/scrittura XMLA per la capacità.

Per le capacità Valutazione di Fabric, l'utente della versione di valutazione dispone dei privilegi di amministratore necessari per abilitare la lettura/scrittura XMLA.

1. Nel portale di amministrazione selezionare Impostazioni capacità.

2. Seleziona la scheda Versione di valutazione.

3. Selezionare la capacità con Versione di valutazione e il nome utente nel nome della capacità.

4. Espandere Carichi di lavoro di Power BI, quindi nell'impostazione Endpoint XMLA, selezionare Lettura scrittura.

   

Nota bene: l'impostazione dell'endpoint XMLA si applica a tutte le aree di lavoro e ai modelli assegnati alla capacità.

Metadati del modello Direct Lake

Quando ci si connette a un modello Direct Lake autonomo tramite l'endpoint XMLA, i metadati sono simili a qualsiasi altro modello. Tuttavia, i modelli Direct Lake evidenziano le seguenti differenze:

• La proprietà compatibilityLevel dell'oggetto di database è 1604 o successiva.

• La proprietà Mode delle partizioni Direct Lake è impostata su directLake.

• Le partizioni Direct Lake usano espressioni condivise per definire le origini dati. L'espressione punta all'endpoint Analisi SQL di un lakehouse o di un warehouse. Direct Lake usa l'endpoint Analisi SQL del lakehouse per individuare lo schema e le informazioni di sicurezza, ma carica i dati direttamente dalle tabelle Delta, a meno che Direct Lake non debba eseguire il fallback alla modalità DirectQuery per qualsiasi motivo.

Ecco un esempio di query XMLA in SSMS:

Per altre informazioni sul supporto degli strumenti tramite l'endpoint XMLA, vedere Connettività del modello semantico con l'endpoint XMLA.

Fallback

I modelli semantici di Power BI in modalità Direct Lake leggono tabelle delta direttamente da OneLake. Tuttavia, se una query DAX su un modello Direct Lake supera i limiti della SKU o utilizza funzioni che non supportano la modalità Direct Lake, come le visualizzazioni SQL in un warehouse, la query può tornare alla modalità DirectQuery. In modalità DirectQuery le query utilizzano SQL per recuperare i risultati dal warehouse o dall'endpoint Analisi SQL di un lakehouse, cosa che può influire sulle prestazioni delle query. È possibile disabilitare il fallback in modalità DirectQuery se si vogliono elaborare solo query DAX in modalità Direct Lake pura. Se non è necessario eseguire il fallback in DirectQuery, è consigliabile disabilitare il fallback. Può anche essere utile quando si analizza l'elaborazione delle query per un modello Direct Lake per identificare se e quanto spesso si verificano i fallback. Per altre informazioni sulla modalità DirectQuery, vedere modalità del modello semantico in Power BI.

I Guardrail definiscono i limiti delle risorse per la modalità Direct Lake oltre i quali è necessario un fallback alla modalità DirectQuery per l’elaborazione delle query DAX. Per informazioni dettagliate su come determinare il numero di file parquet e gruppi di righe per una tabella delta, vedere il Riferimento alle proprietà della tabella Delta.

Per i modelli semantici Direct Lake, Max memory rappresenta il limite massimo di risorse di memoria per la quantità di dati di cui è possibile eseguire il paging. In effetti, non si tratta di un guardrail, perché il suo superamento non causa un fallback a DirectQuery; tuttavia, può avere un impatto sulle prestazioni se la quantità di dati è sufficientemente grande da causare il paging in entrata e in uscita dei dati del modello dai dati di OneLake.

La tabella seguente elenca sia i guardrail delle risorse che Max Memory:

SKU di Fabric	File parquet per tabella	Gruppi di righe per tabella	Righe per tabella (milioni)	Dimensioni massime del modello su disco/OneLake1 (GB)	Memoria massima (GB)
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: se superate, le dimensioni massime del modello su disco/Onelake causano il ritorno di tutte le query al modello a DirectQuery, a differenza di altri guardrail valutati per ogni query.

A seconda dell'infrastruttura o dello SKU di Power BI, si applicano anche dei limiti aggiuntivi Unità di capacità e Memoria massima per ogni query ai modelli Direct Lake. Per altre informazioni, vedere Capacità e SKU.

Comportamento di fallback

I modelli Direct Lake includono la proprietà DirectLakeBehavior, che include tre opzioni:

Automatica: (impostazione predefinita) Specifica che le query tornano alla modalità DirectQuery se i dati non possono essere caricati in memoria in modo efficace.

DirectLakeOnly: specifica che tutte le query utilizzano esclusivamente la modalità Direct Lake. Il ritorno alla modalità DirectQuery è disabilitato. Se i dati non possono essere caricati in memoria, viene recepito un errore. Usare questa impostazione per stabilire se le query DAX non riescono a caricare i dati in memoria, forzando la restituzione di un errore.

DirectQueryOnly: specifica che tutte le query utilizzano esclusivamente la modalità DirectQuery. Usare questa impostazione per testare le prestazioni di fallback.

La proprietà DirectLakeBehavior può essere configurata tramite TOM (Tabular Object Model) o TMSL (Tabular Model Scripting Language).

L’esempio seguente specifica che tutte le query utilizzano esclusivamente la modalità Direct Lake:

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Può essere impostata anche quando si modifica il modello semantico nel browser, nelle proprietà del modello semantico. Selezionare Modello semantico nella scheda Modello del riquadro Dati.

Analisi dell’elaborazione di query

Per determinare se le query DAX di un oggetto visivo del report nell'origine dati offrono prestazioni ottimali tramite la modalità Direct Lake oppure tornando alla modalità DirectQuery, è possibile usare Analizzatore prestazioni in Power BI Desktop, SQL Server Profiler o altri strumenti di terze parti per analizzare le query. Per altre informazioni, vedere Analizzare l'elaborazione delle query per i modelli Direct Lake.

Refresh

Per impostazione predefinita, le modifiche ai dati in OneLake vengono riflesse automaticamente in un modello Direct Lake. È possibile modificare tale comportamento disabilitando Mantenere aggiornati i dati Direct Lake nelle impostazioni del modello.

È possibile effettuare la disabilitazione nel caso, ad esempio, sia necessario consentire il completamento dei processi di preparazione dei dati prima di esporre i nuovi dati ai consumer del modello. Una volta effettuata la disabilitazione, è possibile richiamare l'aggiornamento manualmente o usando le API di aggiornamento. Richiamare un aggiornamento per un modello Direct Lake è un'operazione a basso costo, in cui il modello analizza i metadati della versione più recente della tabella Delta Lake e viene aggiornato per fare riferimento ai file più recenti in OneLake.

Si noti che Power BI può sospendere gli aggiornamenti automatici delle tabelle Direct Lake se si verifica un errore irreversibile durante l'aggiornamento, quindi assicurarsi che il modello semantico possa essere aggiornato correttamente. Power BI riprende automaticamente gli aggiornamenti automatici quando un successivo aggiornamento richiesto dall'utente viene completato senza errori.

Funzionalità Single Sign-On (SSO) abilitata per impostazione predefinita

Per impostazione predefinita, i modelli Direct Lake si basano su Microsoft Entra Single Sign-On (SSO) per accedere alle origini dati dei lakehouse e warehouse di Fabric e usare l'identità dell'utente che attualmente interagisce con il modello. È possibile controllare la configurazione nelle impostazioni del modello Direct Lake espandendo la sezione Gateway e connessioni cloud, come illustrato nello screenshot seguente. Il modello Direct Lake non richiede una connessione esplicita ai dati, poiché il Lakehouse o Warehouse sono direttamente accessibili, e SSO elimina la necessità di memorizzare le credenziali di connessione.

È anche possibile vincolare esplicitamente l'origine dati Lakehouse o Warehouse a una connessione condivisibile nel cloud (SCC) nel caso in cui si vogliano usare le credenziali memorizzate, disabilitando così SSO per quella connessione all'origine dati. Per vincolare esplicitamente l'origine dati, selezionare la casella di riepilogo Mapping a: nella sezione Connessioni gateway e cloud. È anche possibile creare una nuova connessione selezionando Crea una connessione, seguendo poi la procedura per specificare un nome di connessione. Successivamente, selezionare OAuth 2.0 come metodo di autenticazione per la nuova connessione, immettere le credenziali desiderate e deselezionare la casella di controllo Single Sign-On, poi associare l'origine dati Lakehouse o Warehouse alla nuova connessione SCC appena creata.

La configurazione della connessione Predefinito: Single Sign-On (Entra ID) semplifica la configurazione del modello Direct Lake, tuttavia, se si dispone già di una connessione cloud personale (PCC) all'origine dati Lakehouse o Warehouse, il modello Direct Lake si associa automaticamente alla PCC corrispondente, in modo da applicare immediatamente le impostazioni di connessione già definite per l'origine dati. È necessario confermare la configurazione delle connessioni dei modelli Direct Lake per assicurarsi che i modelli accedano alle origini dati Fabric con le impostazioni corrette.

I modelli semantici possono usare la configurazione di connessione Predefinito: Single Sign-On (Entra ID) per Lakehouses e Warehouse di Fabric in modalità Direct Lake, Importa e DirectQuery. Tutte le altre origini dati richiedono connessioni dati definite esplicitamente.

Sicurezza dell'accesso ai dati a più livelli

I modelli Direct Lake creati su lakehouse e warehouse rispettano il modello di sicurezza a più livelli da essi supportato eseguendo controlli delle autorizzazioni tramite l'endpoint Analisi SQL al fine di determinare se l'identità che tenta di accedere ai dati dispone delle necessarie autorizzazioni di accesso ai dati. Per impostazione predefinita, i modelli Direct Lake usano Single Sign-On (SSO), quindi le autorizzazioni valide dell'utente interattivo determinano se l'utente è autorizzato o meno ad accedere ai dati. Se il modello Direct Lake è configurato per l'uso di un'identità fissa, l'autorizzazione effettiva dell'identità fissa determina se gli utenti che interagiscono con il modello semantico possono accedere ai dati. L'endpoint Analisi SQL restituisce Consentito o Negato al modello Direct Lake in base alla combinazione di autorizzazioni di sicurezza di OneLake e di SQL.

Ad esempio, un amministratore warehouse può concedere a un utente le autorizzazioni SELECT per una tabella in modo che l'utente possa leggere da tale tabella anche se non dispone di autorizzazioni di sicurezza OneLake. L'utente è stato autorizzato a livello di lakehouse/warehouse. Viceversa, un amministratore warehouse può anche NEGARE l'accesso in lettura a una tabella da parte di un utente. L'utente non sarà quindi in grado di leggere da tale tabella anche se dispone delle autorizzazioni di lettura per la sicurezza di OneLake. L'istruzione DENY sovrascrive qualsiasi autorizzazione di sicurezza OneLake o di SQL concessa a OneLake. Fare riferimento alla seguente tabella per le autorizzazioni effettive che un utente può avere con qualsiasi combinazione di autorizzazioni di sicurezza OneLake e SQL.

Autorizzazioni di sicurezza OneLake	Autorizzazioni SQL	Autorizzazioni valide
Consenti	None	Consenti
None	Consenti	Consenti
Consenti	Nega	Nega
None	Nega	Nega

Problemi noti e limitazioni

• Per motivi di progettazione, solo le tabelle del modello semantico derivate da tabelle di un Lakehouse o di un Warehouse supportano la modalità Direct Lake. Anche se le tabelle del modello possono essere derivate da viste SQL in Lakehouse o Warehouse, le query che utilizzano queste tabelle passano alla modalità DirectQuery.

• Le tabelle del modello semantico Direct Lake possono essere derivate solo da tabelle e viste di un singolo Lakehouse o Warehouse. Un singolo Lakehouse può includere collegamenti rapidi aggiunti da altri Lakehouse.

• Le query che usano la sicurezza a livello di riga sulle tabelle del data warehouse (endpoint di analisi SQL del lakehouse compreso) eseguiranno il fallback alla modalità DirectQuery.

• Al momento, le tabelle Direct Lake non possono essere combinate con altri tipi di tabella, ad esempio Import, DirectQuery o Dual, all’interno dello stesso modello. I modelli compositi nei modelli semantici di Power BI possono usare modelli semantici di Power BI in modalità Di archiviazione Direct Lake come origine.

• Le relazioni DateTime non sono supportate nei modelli Direct Lake. Le relazioni di data sono supportate.

• Le colonne e le tabelle calcolate non sono ancora supportate. Sono supportati i gruppi di calcolo e i parametri di campo.

• Alcuni tipi di dati potrebbero non essere supportati, come i decimali ad alta precisione e i tipi di valute.

• Le tabelle Direct Lake non supportano tipi di colonna di tabella Delta complessi. 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 chiave coincidano. Le colonne delle chiavi primarie devono contenere valori univoci. Le query DAX avranno esito negativo se vengono rilevati valori di chiave primaria duplicati.

• La lunghezza dei valori di colonna stringa è limitata a 32.764 caratteri Unicode.

• Il valore “a virgola mobile ‘NaN” (Non un numero) non è supportato nei modelli Direct Lake.

• Gli scenari Power BI incorporati che si basano su entità incorporate non sono ancora supportati.

• La convalida è limitata per i modelli Direct Lake. Le selezioni dell'utente sono ritenute corrette e nessuna query convaliderà le selezioni di cardinalità e di filtro incrociato per le relazioni o per la colonna data selezionata in una tabella data.

• La scheda Direct Lake nella cronologia aggiornamenti elenca solo gli errori di aggiornamento correlati a Direct Lake. Gli aggiornamenti riusciti vengono correntemente omessi.

Operazioni preliminari

Il modo migliore per iniziare a usare una soluzione Direct Lake nell'organizzazione consiste nel creare una lakehouse, crearvi una tabella delta e quindi creare un modello semantico di base per lakehouse nell'area di lavoro di Microsoft Fabric. Per altre informazioni, vedere Creare un lakehouse per Direct Lake.

Contenuto correlato

• Creare un lakehouse per Direct Lake
• Analizzare l'elaborazione delle query per i modelli semantici Direct Lake.