Condividi tramite


Gestire modelli semantici Direct Lake

Questo articolo descrive gli argomenti di progettazione relativi alla gestione dei modelli semantici Direct Lake.

Attività successive alla pubblicazione

Dopo aver pubblicato un modello semantico Direct Lake pronto per la creazione di report, è necessario completare immediatamente alcune attività successive alla pubblicazione. Queste attività possono anche essere modificate in qualsiasi momento durante il ciclo di vita del modello semantico.

Facoltativamente, è anche possibile configurare l'individuazione dei dati per consentire agli autori di report di leggere i metadati, aiutandoli a individuare i dati nell'hub dati OneLake e richiedere l'accesso. È anche possibile approvare (certificato o alzato di livello) il modello semantico per comunicare che rappresenta i dati di qualità adatti per l'uso.

Configurare la connessione cloud

Un modello semantico Direct Lake usa una connessione cloud per connettersi all'endpoint di analisi SQL. Consente l'accesso ai dati di origine, ovvero i file Parquet in OneLake (modalità di archiviazione Direct Lake, che comporta il caricamento dei dati delle colonne in memoria) o l'endpoint di analisi SQL (quando le query eseguono il fallback alla modalità DirectQuery).

Connessione cloud predefinita

Quando si crea un modello semantico Direct Lake, viene usata la connessione cloud predefinita. Sfrutta l'accesso Single Sign-On (SSO), il che significa che l'identità che esegue query sul modello semantico (spesso un utente del report) viene usata per eseguire query sui dati dell'endpoint di analisi SQL.

Connessione cloud condivisibile

Facoltativamente, è possibile creare una connessione cloud condivisibile in modo che le connessioni all'origine dati possano essere stabilite con un'identità fissa. Può aiutare i clienti aziendali a proteggere gli archivi dati aziendali. Il reparto IT può gestire le credenziali, creare controller di dominio e condividerli con gli autori destinati alla gestione centralizzata degli accessi.

Per configurare un'identità fissa, vedere Specificare un'identità fissa per un modello semantico Direct Lake.

Autenticazione

L'identità fissa può eseguire l'autenticazione usando OAuth 2.0 o entità servizio.

Nota

È supportata solo l'autenticazione di Microsoft Entra. Pertanto, l'autenticazione di base non è supportata per i modelli semantici Direct Lake.

OAuth 2.0

Quando si usa OAuth 2.0, è possibile eseguire l'autenticazione con un account utente di Microsoft Entra. L'account utente deve disporre dell'autorizzazione per eseguire query sulle tabelle e le viste degli endpoint di analisi SQL e i metadati dello schema.

L'uso di un account utente specifico non è una procedura consigliata. Ciò è dovuto al fatto che le query del modello semantico avranno esito negativo se la modifica della password o l'account utente verrà eliminato ( ad esempio quando un dipendente lascia l'organizzazione).

Entità servizio

L'autenticazione con un'entità servizio è la procedura consigliata perché non dipende da un account utente specifico. L'entità di sicurezza deve disporre dell'autorizzazione per eseguire query sulle tabelle e le viste degli endpoint di analisi SQL e i metadati dello schema.

Per garantire la continuità, le credenziali dell'entità servizio possono essere gestite dalla rotazione di segreti/certificati.

Nota

Le impostazioni del tenant di Fabric devono consentire le entità servizio e l'entità servizio deve appartenere a un gruppo di sicurezza dichiarato.

Single Sign-On

Quando si crea una connessione cloud condivisibile, la casella di controllo Single Sign-On è deselezionata per impostazione predefinita. Questa è la configurazione corretta quando si usa un'identità fissa.

È possibile abilitare l'accesso Single Sign-On quando si vuole che l'identità che esegue query sul modello semantico per eseguire query sull'endpoint di analisi SQL. In questa configurazione, il modello semantico Direct Lake userà l'identità fissa per aggiornare il modello e l'identità utente per eseguire query sui dati.

Quando si usa un'identità fissa, è pratica comune disabilitare l'accesso SSO in modo che l'identità fissa venga usata sia per gli aggiornamenti che per le query, ma non è necessario eseguire questa operazione.

Di seguito sono riportate le procedure consigliate relative alle connessioni cloud:

  • Quando tutti gli utenti possono accedere ai dati e avere l'autorizzazione per farlo, non è necessario creare una connessione cloud condivisa. È invece possibile usare le impostazioni di connessione cloud predefinite. In questo caso, l'identità dell'utente che esegue query sul modello verrà usata in modalità DirectQuery.
  • Creare una connessione cloud condivisa quando si vuole usare un'identità fissa per eseguire query sui dati di origine. Ciò potrebbe essere dovuto al fatto che agli utenti che eseguono query sul modello semantico non viene concessa l'autorizzazione per leggere il lakehouse o il magazzino. Questo approccio è particolarmente rilevante quando il modello semantico applica la sicurezza a livello di riga.
  • Se si usa un'identità fissa, usare l'opzione Entità servizio perché è più sicura e affidabile. Questo perché non si basa su un singolo account utente o sulle relative autorizzazioni e non richiede manutenzione (e interruzione) se modifica la password o lascia l'organizzazione.
  • Se utenti diversi devono essere limitati all'accesso solo ai subset di dati, se possibile, applicare la sicurezza a livello di riga solo a livello di modello semantico. In questo modo, gli utenti trarranno vantaggio dalle query in memoria ad alte prestazioni.
  • Se possibile, evitare OLS e CLS perché genera errori negli oggetti visivi del report. Gli errori possono creare confusione o preoccupazione per gli utenti. Per le colonne riepilogabili, è consigliabile creare misure che restituiscono BLANK in determinate condizioni anziché CLS (se possibile).

Gestire l'appartenenza ai ruoli di sicurezza

Se il modello semantico Direct Lake applica la sicurezza a livello di riga, potrebbe essere necessario gestire i membri assegnati ai ruoli di sicurezza. Per altre informazioni, vedere Gestire la sicurezza nel modello.

Impostare le autorizzazioni per gli elementi dell'infrastruttura

I modelli semantici Direct Lake rispettano un modello di sicurezza a più livelli. Eseguono 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.

È necessario concedere autorizzazioni agli utenti in modo che possano usare o gestire il modello semantico Direct Lake. In breve, i consumer di report necessitano dell'autorizzazione lettura e gli autori di report necessitano dell'autorizzazione di compilazione . Le autorizzazioni del modello semantico possono essere assegnate direttamente o acquisite in modo implicito tramite 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.

A seconda della connessione cloud configurata e se gli utenti devono eseguire query sul lakehouse o sull'endpoint di analisi SQL del warehouse, potrebbe essere necessario concedere altre autorizzazioni (descritte nella tabella in questa sezione).

Nota

In particolare, gli utenti non richiedono mai l'autorizzazione per leggere i dati 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.

Si considerino gli scenari e i requisiti di autorizzazione seguenti.

Scenario 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 la connessione cloud usa l'accesso SSO, concedere almeno l'autorizzazione di lettura per il lakehouse o il magazzino.
I report non devono appartenere alla stessa area di lavoro del modello semantico. Per altre informazioni, vedere Strategia per i consumer di sola lettura.
Gli utenti possono creare report • Concedere l'autorizzazione di compilazione per il modello semantico.
• Se la connessione cloud usa l'accesso SSO, concedere almeno l'autorizzazione di lettura per il lakehouse o il magazzino.
Per altre informazioni, vedere Strategia per gli autori di contenuti.
Gli utenti possono eseguire query sul modello semantico, ma viene negata l'esecuzione di query sull'endpoint lakehouse o di analisi SQL • Non concedere alcuna autorizzazione per il lakehouse o il magazzino. Adatto solo quando la connessione cloud usa un'identità fissa.
Gli utenti possono eseguire query sul modello semantico e sull'endpoint di analisi SQL, ma viene negata l'esecuzione di query sul lakehouse • Concedere le autorizzazioni Read e ReadData per il lakehouse o il magazzino. Importante: le query inviate all'endpoint di analisi SQL ignorano le autorizzazioni di accesso ai dati applicate dal modello semantico.
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.

Aggiornare i modelli semantici Direct Lake

Un aggiornamento di un modello semantico Direct Lake comporta un'operazione di frame . È possibile attivare un'operazione di aggiornamento:

  • Manualmente, eseguendo un aggiornamento su richiesta nel portale di Fabric o eseguendo il comando TMSL (Tabular Model Scripting Language) da uno script in SQL Server Management Studio (SSMS) o usando uno strumento di terze parti che si connette tramite l'endpoint XMLA.
  • Impostando automaticamente una pianificazione degli aggiornamenti nel portale di Fabric.
  • Automaticamente, quando vengono rilevate modifiche nelle tabelle Delta sottostanti. Per altre informazioni, vedere Aggiornamenti automatici (descritti di seguito).
  • A livello di codice, attivando un aggiornamento tramite l'API REST di Power BI o TOM. È possibile attivare un aggiornamento a livello di codice come passaggio finale di un processo di estrazione, trasformazione e caricamento (ETL).

Aggiornamenti automatici

È disponibile un'impostazione a livello di modello semantico denominata Mantieni aggiornati i dati di Direct Lake che esegue gli aggiornamenti automatici delle tabelle Direct Lake. È abilitata per impostazione predefinita. Garantisce che le modifiche ai dati in OneLake vengano riflesse automaticamente nel modello semantico Direct Lake. L'impostazione è disponibile nel portale di Infrastruttura, nella sezione Aggiorna delle impostazioni del modello semantico.

Quando l'impostazione è abilitata, il modello semantico esegue un'operazione di frame ogni volta che vengono rilevate modifiche ai dati nelle tabelle Delta sottostanti. L'operazione di frame è sempre specifica solo per le tabelle in cui vengono rilevati i dati.

È consigliabile lasciare attiva l'impostazione, soprattutto quando si dispone di un modello semantico di piccole o medie dimensioni. È particolarmente utile quando si hanno requisiti di creazione di report a bassa latenza e le tabelle Delta vengono modificate regolarmente.

In alcune situazioni, potrebbe essere necessario disabilitare gli aggiornamenti automatici. Ad esempio, potrebbe essere necessario consentire il completamento dei processi di preparazione dei dati o il processo ETL prima di esporre i nuovi dati ai consumer del modello semantico. Se disabilitato, è possibile attivare un aggiornamento usando un metodo programmatico (descritto in precedenza).

Nota

Power BI sospende gli aggiornamenti automatici quando si verifica un errore non ripristinabile durante l'aggiornamento. Un errore non ripristinabile può verificarsi, ad esempio, quando un aggiornamento non riesce dopo diversi tentativi. Assicurarsi quindi che il modello semantico possa essere aggiornato correttamente. Power BI riprende automaticamente gli aggiornamenti automatici quando un aggiornamento su richiesta successivo viene completato senza errori.

Scaldare la cache

Un'operazione di aggiornamento del modello semantico Direct Lake potrebbe rimuovere tutte le colonne residenti dalla memoria. Ciò significa che le prime query dopo un aggiornamento di un modello semantico Direct Lake potrebbero riscontrare un certo ritardo quando le colonne vengono caricate in memoria. I ritardi possono essere evidenti solo quando si dispone di volumi di dati estremamente elevati.

Per evitare tali ritardi, prendere in considerazione il riscaldamento della cache inviando una query al modello semantico a livello di codice. Un modo pratico per inviare una query consiste nell'usare il collegamento semantico. Questa operazione deve essere eseguita immediatamente al termine dell'operazione di aggiornamento.

Importante

Il riscaldamento della cache potrebbe avere senso solo quando i ritardi sono inaccettabili. Prestare attenzione a non caricare inutilmente i dati in memoria che potrebbero mettere pressione su altri carichi di lavoro di capacità, causando la limitazione o la deprioritizzazione.

Impostare la proprietà comportamento Direct Lake

È possibile controllare il fallback dei modelli semantici Direct Lake impostandone la DirectLakeBehavior proprietà. Può essere impostato su:

  • Automatico: (impostazione predefinita) Le query eseguono il fallback alla modalità DirectQuery se i dati necessari non possono essere caricati in modo efficiente nella memoria.
  • DirectLakeOnly: tutte le query usano solo la modalità Direct Lake Storage. Il fallback alla modalità DirectQuery è disabilitato. Se i dati non possono essere caricati in memoria, viene recepito un errore.
  • DirectQueryOnly: tutte le query usano solo la modalità DirectQuery. Usare questa impostazione per testare le prestazioni di fallback, in cui, ad esempio, è possibile osservare le prestazioni delle query nei report connessi.

È possibile impostare la proprietà nell'esperienza di modellazione Web o tramite TABULAR Object Model (TOM) o TMSL (Tabular Model Scripting Language).

Suggerimento

È consigliabile disabilitare il fallback directQuery quando si desidera elaborare le query solo in modalità Direct Lake Storage. È consigliabile disabilitare il fallback quando non si vuole eseguire il fallback in DirectQuery. Può essere utile anche quando si vuole analizzare l'elaborazione delle query per un modello semantico Direct Lake per identificare se e con quale frequenza si verifica il fallback.

Monitorare i modelli semantici Direct Lake

È possibile monitorare un modello semantico Direct Lake per determinare le prestazioni delle query DAX visive del report o per determinare quando esegue il fallback alla modalità DirectQuery.

È possibile usare analizzatore prestazioni, SQL Server Profiler, Azure Log Analytics o uno strumento open source, come DAX Studio.

Analizzatore prestazioni

È possibile usare analizzatore prestazioni in Power BI Desktop per registrare il tempo di elaborazione necessario per aggiornare gli elementi del report avviati in seguito a qualsiasi interazione dell'utente che comporta l'esecuzione di una query. Se i risultati del monitoraggio mostrano una metrica di query diretta, significa che le query DAX sono state elaborate in modalità DirectQuery. In assenza di tale metrica, le query DAX sono state elaborate in modalità Direct Lake.

Per altre informazioni, vedere Analizzare usando analizzatore prestazioni.

SQL Server Profiler

È possibile usare SQL Server Profiler per recuperare i dettagli sulle prestazioni delle query tracciando gli eventi di query. Viene installato con SQL Server Management Studio (SSMS). Prima di iniziare, assicurarsi di avere installato la versione più recente di SSMS.

Per altre informazioni, vedere Analizzare con SQL Server Profiler.

Importante

In generale, la modalità Direct Lake Storage offre prestazioni di query veloci, a meno che non sia necessario un fallback alla modalità DirectQuery. Poiché il fallback alla modalità DirectQuery può influire sulle prestazioni delle query, è importante analizzare l'elaborazione delle query per un modello semantico Direct Lake per identificare se, con quale frequenza e perché si verificano i fallback.

Log Analytics di Azure

È possibile usare Azure Log Analytics per raccogliere, analizzare e agire sui dati di telemetria associati a un modello semantico Direct Lake. Si tratta di un servizio all'interno di Monitoraggio di Azure, che Power BI usa per salvare i log attività.

Per altre informazioni, vedere Uso di Azure Log Analytics in Power BI.