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 di Power BI. Direct Lake è un percorso rapido per caricare i dati dal lake direttamente nel motore di Power BI, pronto per l'analisi. 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 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à di 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 durante l'aggiornamento. Tutte le modifiche apportate all'origine vengono prelevate solo con l'aggiornamento del modello successivo.

La modalità Direct Lake elimina il requisito di importazione caricando i dati direttamente da OneLake. A differenza di DirectQuery, non esiste alcuna conversione da DAX o MDX ad altri linguaggi di query o esecuzione di query in altri sistemi di database, ottenendo prestazioni simili alla modalità di importazione. Poiché non esiste un processo di importazione esplicito, è possibile prelevare le modifiche nell'origine dati man mano che si verificano, combinando i vantaggi delle modalità DirectQuery e di importazione evitandone gli svantaggi. La modalità Direct Lake può essere la scelta ideale per l'analisi di modelli e modelli di grandi dimensioni con aggiornamenti frequenti nell'origine dati.

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

Prerequisiti

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

Lakehouse

Prima di usare Direct Lake, è necessario effettuare il provisioning di una lakehouse (o di un magazzino) 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 nella lakehouse e creare un modello di base per la lakehouse, vedere Creare una lakehouse per Direct Lake.

Endpoint di analisi SQL e data warehouse

Nell'ambito del provisioning di un lakehouse, viene creato e aggiornato un endpoint di analisi SQL per le query SQL con tutte le tabelle aggiunte alla lakehouse. Anche se la modalità Direct Lake non esegue query sull'endpoint di 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 usa funzionalità specifiche come la sicurezza avanzata o le visualizzazioni che non possono essere lette tramite Direct Lake e devono usare l'endpoint di analisi SQL. La modalità Direct Lake esegue periodicamente query sull'endpoint di analisi SQL per ottenere informazioni correlate allo schema e alla sicurezza.

In alternativa a un lakehouse con endpoint di 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 una lakehouse.

Modello semantico di Power BI predefinito

I warehouse e gli endpoint di analisi SQL creano anche un modello semantico di Power BI predefinito 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. Vedere la documentazione predefinita del modello semantico 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 magazzino.

In 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 quindi selezionare Nuovo modello semantico di Power BI per creare un modello semantico di Power BI in modalità Direct Lake.

È quindi possibile 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 usando il menu di scelta rapida dall'area di lavoro per aprire il modello di dati.

Supporto per la scrittura di modelli con l'endpoint XMLA

I modelli Direct Lake supportano operazioni di scrittura tramite l'endpoint XMLA usando strumenti come SQL Server Management Studio (19.1 e versioni successive) e le versioni più recenti di strumenti di BUSINESS esterni, ad esempio Editor tabulare 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 eseguino il fallback 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à di 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. Selezionare 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 e quindi nell'impostazione Endpoint XMLA selezionare Lettura scrittura.

   

Tenere presente che l'impostazione endpoint XMLA si applica a tutte le aree di lavoro e a tutti i 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 mostrano le differenze seguenti:

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

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

• Le partizioni Direct Lake usano espressioni condivise per definire le origini dati. L'espressione punta all'endpoint di analisi SQL di un lakehouse o di un warehouse. Direct Lake usa l'endpoint di analisi SQL di Lakehouse per individuare le informazioni sullo schema e sulla 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 in un modello Direct Lake supera i limiti per lo SKU o usa funzionalità che non supportano la modalità Direct Lake, ad esempio le viste SQL in un warehouse, la query può eseguire il fallback alla modalità DirectQuery. In modalità DirectQuery le query usano SQL per recuperare i risultati dal warehouse o dall'endpoint di analisi SQL di un Lakehouse, che può influire sulle prestazioni delle query. È possibile disabilitare il fallback in modalità DirectQuery se si desidera elaborare query DAX solo 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 di query per un modello Direct Lake per identificare se e con quale frequenza si verificano i fallback. Per altre informazioni sulla modalità DirectQuery, vedere Modalità modello semantico in Power BI.

Le protezioni definiscono i limiti delle risorse per la modalità Direct Lake oltre la quale è necessario un fallback alla modalità DirectQuery per elaborare le query DAX. Per informazioni dettagliate su come determinare il numero di file Parquet e gruppi di righe per una tabella Delta, vedere le informazioni di riferimento sulle 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 in cui è possibile eseguire il paging. In effetti, non è un guardrail perché il 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 dei dati del modello dai dati di OneLake.

La tabella seguente elenca sia le protezioni delle risorse che la memoria massima:

1 - Se superato, le dimensioni massime del modello su disco/Onelake causano il fallback di tutte le query al modello in DirectQuery, a differenza di altre protezioni valutate per ogni query.

A seconda dello SKU dell'infrastruttura, si applicano anche limiti di capacità aggiuntivi e memoria massima per 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:

Automatic : (impostazione predefinita) Specifica che le query eseguono il fallback alla modalità DirectQuery se i dati non possono essere caricati in modo efficiente nella memoria.

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

DirectQueryOnly : specifica che tutte le query usano solo 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 usano solo la modalità Direct Lake:

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

Questa impostazione 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 .

Analizzare l'elaborazione delle query

Per determinare se le query DAX di un oggetto visivo del report nell'origine dati offrono prestazioni ottimali usando la modalità Direct Lake o il fallback 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 questo comportamento disabilitando Mantenere aggiornati i dati Direct Lake nelle impostazioni del modello.

È possibile disabilitare se, ad esempio, è necessario consentire il completamento dei processi di preparazione dei dati prima di esporre i nuovi dati ai consumer del modello. Se disabilitato, è 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 aggiornamento richiamato dall'utente successivo viene completato senza errori.

Single Sign-On (SSO) abilitato per impostazione predefinita

Per impostazione predefinita, i modelli Direct Lake si basano su Microsoft Entra Single Sign-On (SSO) per accedere alle origini dati fabric Lakehouse e Warehouse 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 dati esplicita perché Lakehouse o Warehouse è direttamente accessibile e SSO elimina la necessità di credenziali di connessione archiviate.

È anche possibile associare in modo esplicito l'origine dati Lakehouse o Warehouse a una connessione cloud condivisibile (SCC) nei casi in cui si desidera usare le credenziali archiviate e quindi disabilitare l'accesso SSO per tale connessione all'origine dati. Per associare in modo esplicito 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, quindi seguire la procedura per specificare un nome di connessione. Selezionare quindi OAuth 2.0 come metodo di autenticazione per la nuova connessione, immettere le credenziali desiderate e deselezionare la casella di controllo Single Sign-On, quindi 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 viene associato automaticamente al PCC corrispondente in modo che le impostazioni di connessione già definite per l'origine dati vengano applicate immediatamente. È necessario confermare la configurazione della connessione dei modelli Direct Lake per assicurarsi che i modelli accedano alle origini dati di Fabric con le impostazioni corrette.

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

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 supportato dai lakehouse e dai warehouse eseguendo controlli delle autorizzazioni tramite l'endpoint di analisi SQL per determinare se l'identità che tenta di accedere ai dati dispone delle autorizzazioni di accesso ai dati necessarie. Per impostazione predefinita, i modelli Direct Lake usano l'accesso Single Sign-On (SSO), quindi le autorizzazioni valide dell'utente interattivo determinano se l'utente è autorizzato o negato l'accesso 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 di analisi SQL restituisce Consentito o Negato al modello Direct Lake in base alla combinazione di autorizzazioni SQL e sicurezza di OneLake.

Ad esempio, un amministratore del warehouse può concedere a un utente le autorizzazioni SELECT per una tabella in modo che l'utente possa leggere da tale tabella anche se l'utente non dispone di autorizzazioni di sicurezza OneLake. L'utente è stato autorizzato a livello di lakehouse/warehouse. Viceversa, un amministratore del 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 l'utente dispone delle autorizzazioni di lettura per la sicurezza di OneLake. L'istruzione DENY sovraruole qualsiasi autorizzazione di sicurezza o SQL concessa a OneLake. Fare riferimento alla tabella seguente per le autorizzazioni valide che un utente può disporre di qualsiasi combinazione di autorizzazioni SQL e sicurezza di OneLake.

Problemi noti e limitazioni

• Per impostazione predefinita, solo le tabelle nel modello semantico derivato dalle tabelle in un Lakehouse o Warehouse supportano la modalità Direct Lake. Anche se le tabelle nel modello possono essere derivate dalle viste SQL in Lakehouse o Warehouse, le query che usano tali tabelle eseguiranno il fallback alla modalità DirectQuery.

• Le tabelle del modello semantico Direct Lake possono essere derivate solo da tabelle e viste da un singolo lakehouse o warehouse. Una singola lakehouse può includere collegamenti aggiunti da altre lakehouse.

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

• Le tabelle Direct Lake non possono attualmente essere combinate con altri tipi di tabella, ad esempio Import, DirectQuery o Dual, nello 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 calcolate e le tabelle calcolate non sono supportate. Sono supportati gruppi di calcolo e parametri di campo.

• Alcuni tipi di dati potrebbero non essere supportati, ad esempio decimali e tipi money ad alta precisione.

• 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 chiave primaria 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' (Not A Number) non è supportato nei modelli Direct Lake.

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

• La convalida è limitata per i modelli Direct Lake. Le selezioni utente vengono considerate corrette e nessuna query convaliderà la cardinalità e le selezioni di filtri incrociati 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 attualmente 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 il lakehouse nell'area di lavoro di Microsoft Fabric. Per altre informazioni, vedere Creare una lakehouse per Direct Lake.

Contenuto correlato

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