Condividi tramite

Gestire modelli semantici Direct Lake

  • Articolo

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, è possibile configurare l'individuazione dei dati per consentire agli autori di report di leggere i metadati, aiutandoli così a individuare i dati nell'hub dati OneLake e richiederne l'accesso. È anche possibile approvare (certificato o promosso) il modello semantico per comunicare che rappresenta dati di qualità adatti all'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 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 SCC e condividerli con i creatori destinatari per la 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 principale del servizio.

Nota

È supportata solo l'autenticazione di Microsoft Entra. Di conseguenza, 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).

Principale del 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 tramite la rotazione di segreti e 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.

Accesso singolo

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 esegua anche 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, verrà utilizzata l'identità dell'utente che esegue la query sul modello, qualora le query tornino alla 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 impone 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 a subset di dati, se possibile, applicare la sicurezza a livello di riga (RLS) esclusivamente a livello del modello semantico. In questo modo, gli utenti trarranno vantaggio dalle query in memoria ad alte prestazioni.
  • Se possibile, evitare l'uso di OLS e CLS perché ciò 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 sicurezza a livello di riga (RLS), 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 del sistema Fabric.

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, gli utilizzatori di report necessitano dell'autorizzazione di 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 utilizza l'accesso SSO, concedere almeno l'autorizzazione di lettura per il deposito dati o il magazzino.		 I report non devono appartenere alla stessa area di lavoro del modello semantico. Per ulteriori informazioni, vedere Strategia per utenti di sola lettura.
Gli utenti possono creare report • Concedere l'autorizzazione per il modello semantico.
• Se la connessione cloud usa l'accesso SSO, concedere almeno autorizzazione read per il lakehouse o il warehouse.		 Per altre informazioni, vedere strategia di 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 autorizzazioni di lettura 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 risulta in un'operazione di framing . È possibile attivare un'operazione di aggiornamento:

  • Manualmente, eseguendo un aggiornamento su richiesta nel portale Fabric oppure eseguendo il comando TMSL (Tabular Model Scripting Language) Refresh da uno script in SQL Server Management Studio (SSMS), o utilizzando uno strumento di terze parti che si connette tramite l'endpoint XMLA.
  • Automaticamente, configurando una pianificazione dell'aggiornamento nel portale Fabric.
  • Automaticamente, quando vengono rilevate modifiche nelle tabelle Delta sottostanti. Per altre informazioni, vedere Aggiornamenti automatici (descritto di seguito).
  • A livello di codice, attivando un aggiornamento usando 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 Mantenere aggiornati i dati di Direct Lake che esegue gli aggiornamenti automatici delle tabelle Direct Lake. È abilitato 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 Fabric, 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 framing è sempre specifica solo per le tabelle dove le modifiche dei dati sono rilevate.

È 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 perché 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 a livello di codice l'invio di una query al modello semantico. Un modo pratico per inviare una query consiste nell'usare 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, causando la loro limitazione o il loro declassamento.

Imposta la proprietà di comportamento di Direct Lake

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

  • Automatic: (impostazione predefinita) Le query passano alla modalità DirectQuery se i dati necessari non possono essere caricati in modo efficiente nella memoria.
  • DirectLakeOnly: tutte le query usano solo la modalità di archiviazione Direct Lake. Il fallback alla modalità DirectQuery è disabilitato. Se i dati non possono essere caricati in memoria, viene restituito 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 oppure usando TOM (Tabular Object Model) o TMSL (Tabular Model Scripting Language).

Consiglio

È consigliabile disabilitare il fallback directQuery quando si desidera elaborare le query solo in modalità Direct Lake Storage. Si raccomanda di disabilitare il fallback quando non si desidera ricorrere al 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 di 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.

L'analizzatore delle prestazioni

È possibile usare Performance Analyzer 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 DirectQuery, 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 Performance Analyzer.

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 Analyze by using 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.

Azure Log Analytics

È possibile usare di 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 Azure Monitor, che Power BI utilizza per salvare i log delle attività.

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

Contenuto correlato