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, con 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, 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).
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 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. Il lakehouse fornisce anche un punto di accesso per avviare la funzionalità di modellazione Web per creare un modello Direct Lake.
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 SQL
Nell'ambito del provisioning di un lakehouse, vengono creati e aggiornati un endpoint SQL per l'esecuzione di query SQL e un modello predefinito per la creazione di report con tutte le tabelle aggiunte alla lakehouse. Anche se la modalità Direct Lake non esegue query sull'endpoint 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. La modalità Direct Lake esegue anche una query sull'endpoint SQL per ottenere informazioni correlate allo schema e alla sicurezza.
Data warehouse
In alternativa a una lakehouse con l'endpoint 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.
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.
Si noti che 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 XMLA read-write
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.
Nel portale di Amministrazione selezionare Impostazioni capacità.
Fare clic sulla scheda Versione di valutazione .
Selezionare la capacità con Versione di valutazione e il nome utente nel nome della capacità.
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
compatibilityLevelproprietà dell'oggetto di database è 1604 o successiva.La
Modeproprietà delle partizioni Direct Lake è impostata sudirectLake.Le partizioni Direct Lake usano espressioni condivise per definire le origini dati. L'espressione punta all'endpoint SQL di una lakehouse o di un warehouse. Direct Lake usa l'endpoint SQL per individuare le informazioni di sicurezza e lo schema, 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 dall'endpoint SQL del lakehouse o warehouse, 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:
| SKU dell'infrastruttura | 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 superato, le dimensioni massime del modello su disco/Onelake causeranno 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();
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.
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 da lakehouse e warehouse eseguendo controlli delle autorizzazioni tramite l'endpoint T-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 T-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 edizione Standard LECT 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.
| Autorizzazioni di sicurezza di OneLake | Autorizzazioni SQL | Autorizzazioni valide |
|---|---|---|
| Consenti | None | Consenti |
| None | Consenti | Consenti |
| Consenti | Nega | Nega |
| None | Nega | Nega |
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.
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 non sono attualmente supportati.
Le relazioni DateTime non sono supportate nei modelli Direct Lake.
Le colonne calcolate e le tabelle calcolate non sono supportate.
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 incorporati 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
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per