Condividi tramite

Sviluppare modelli semantici Direct Lake

  • Articolo

Questo articolo descrive gli argomenti di progettazione relativi allo sviluppo di modelli semantici Direct Lake.

Creare il modello

Usare il portale infrastruttura per creare un modello semantico Direct Lake in un'area di lavoro. Si tratta di un processo semplice che prevede la selezione delle tabelle da un singolo lakehouse o magazzino da aggiungere al modello semantico.

È quindi possibile usare l'esperienza di modellazione Web per sviluppare ulteriormente il modello semantico. Questa esperienza consente di creare relazioni tra tabelle, creare misure e gruppi di calcolo, contrassegnare le tabelle delle date e impostare le proprietà per il modello e i relativi oggetti (ad esempio i formati di colonna). È anche possibile configurare la sicurezza a livello di riga del modello definendo ruoli e regole e aggiungendo membri (account utente Microsoft Entra o gruppi di sicurezza) a tali ruoli.

In alternativa, è possibile continuare lo sviluppo del modello usando uno strumento conforme a XMLA, ad esempio SQL Server Management Studio (SSMS) (versione 19.1 o successiva) o strumenti della community open source. Per altre informazioni, vedere Supporto per la scrittura di modelli con l'endpoint XMLA più avanti in questo articolo.

Suggerimento

Per informazioni su come creare una lakehouse, una tabella Delta e un modello semantico Direct Lake di base, completare questa esercitazione.

Tabelle del modello

Le tabelle del modello sono basate su una tabella o una vista dell'endpoint di analisi SQL. Tuttavia, evitare di usare le visualizzazioni quando possibile. Ciò è dovuto al fatto che le query a una tabella modello basate su una vista eseguiranno sempre il fallback alla modalità DirectQuery, con conseguente rallentamento delle prestazioni delle query.

Le tabelle devono includere colonne per il filtro, il raggruppamento, l'ordinamento e il riepilogo, oltre alle colonne che supportano le relazioni tra modelli. Anche se le colonne non necessarie non influiscono sulle prestazioni delle query del modello semantico (perché non verranno caricate in memoria), comportano dimensioni di archiviazione maggiori in OneLake e richiedono più risorse di calcolo per caricare e gestire.

Avviso

L'uso di colonne che applicano DDM (Dynamic Data Masking) nei modelli semantici Direct Lake non è supportato.

Per informazioni su come selezionare le tabelle da includere nel modello semantico Direct Lake, vedere Modificare le tabelle per i modelli semantici Direct Lake.

Per altre informazioni sulle colonne da includere nelle tabelle del modello semantico, vedere Informazioni sull'archiviazione per i modelli semantici Direct Lake.

Applicare le regole di accesso ai dati

Quando si hanno requisiti per distribuire subset di dati del modello a utenti diversi, è possibile applicare regole di accesso ai dati. Le regole vengono applicate configurando la sicurezza a livello di oggetto e/o la sicurezza a livello di riga (RLS) nell'endpoint di analisi SQL o nel modello semantico.

Nota

L'argomento relativo all'applicazione delle regole di accesso ai dati è diverso, ma correlato, all'impostazione delle autorizzazioni per consumer, creatori e utenti che gestiranno il modello semantico (e gli elementi di Fabric correlati). Per altre informazioni sull'impostazione delle autorizzazioni, vedere Gestire modelli semantici Direct Lake.

Protezione a livello di oggetto (OLS)

OLS implica la limitazione dell'accesso all'individuazione e all'esecuzione di query su oggetti o colonne. Ad esempio, è possibile usare OLS per limitare gli utenti che possono accedere alla Salary colonna dalla Employee tabella.

Per un endpoint di analisi SQL, è possibile configurare OLS per controllare l'accesso agli oggetti endpoint, ad esempio tabelle o viste, e sicurezza a livello di colonna (CLS) per controllare l'accesso alle colonne della tabella degli endpoint.

Per un modello semantico, è possibile configurare OLS per controllare l'accesso alle tabelle o alle colonne del modello. Per configurare OLS, è necessario usare strumenti open source della community come l'editor tabulare.

Sicurezza a livello di riga

La sicurezza a livello di riga implica la limitazione dell'accesso ai subset di dati nelle tabelle. Ad esempio, è possibile usare la sicurezza a livello di riga per assicurarsi che i venditori possano accedere solo ai dati di vendita per i clienti nella propria area di vendita.

Per un endpoint di analisi SQL, è possibile configurare la sicurezza a livello di riga per controllare l'accesso alle righe in una tabella endpoint.

Importante

Quando una query usa qualsiasi tabella con sicurezza a livello di riga nell'endpoint di analisi SQL, eseguirà il fallback alla modalità DirectQuery. Le prestazioni delle query potrebbero risultare più lente.

Per un modello semantico, è possibile configurare la sicurezza a livello di riga per controllare l'accesso alle righe nelle tabelle del modello. La sicurezza a livello di riga può essere configurata nell'esperienza di modellazione Web o usando uno strumento di terze parti.

Modalità di valutazione delle query

Il motivo per sviluppare modelli semantici Direct Lake è ottenere query ad alte prestazioni su grandi volumi di dati in OneLake. Pertanto, è necessario cercare di progettare una soluzione che ottimizza le probabilità di query in memoria.

I passaggi seguenti approssimano il modo in cui vengono valutate le query e se hanno esito negativo. I vantaggi della modalità Direct Lake Storage sono possibili solo quando si ottiene il quinto passaggio.

  1. Se la query contiene una tabella o una colonna limitata dal modello semantico OLS, viene restituito un risultato di errore (l'oggetto visivo del report non riuscirà a eseguire il rendering).
  2. Se la query contiene una colonna limitata da CLS dell'endpoint di analisi SQL (o la tabella viene negata), viene restituito un risultato di errore (l'oggetto visivo del report non riuscirà a eseguire il rendering).
    1. Se la connessione cloud usa SSO (impostazione predefinita), CLS viene determinato dal livello di accesso del consumer del report.
    2. Se la connessione cloud usa un'identità fissa, CLS viene determinato dal livello di accesso dell'identità fissa.
  3. Se la query contiene una tabella nell'endpoint di analisi SQL che applica la sicurezza a livello di riga o viene usata una vista, la query esegue il fallback alla modalità DirectQuery.
    1. Se la connessione cloud usa l'accesso SSO (impostazione predefinita), la sicurezza a livello di riga è determinata dal livello di accesso del consumer del report.
    2. Se la connessione cloud usa un'identità fissa, la sicurezza a livello di riga viene determinata dal livello di accesso dell'identità fissa.
  4. Se la query supera le protezioni della capacità, torna alla modalità DirectQuery.
  5. In caso contrario, la query viene soddisfatta dalla cache in memoria. I dati delle colonne vengono caricati in memoria come e quando sono necessari.

Autorizzazioni per gli elementi di origine

L'account usato per accedere ai dati è uno dei seguenti.

  • Se la connessione cloud usa l'accesso SSO (impostazione predefinita), è l'utente del report.
  • Se la connessione cloud usa un'identità fissa, si tratta dell'identità fissa.

L'account deve disporre almeno delle autorizzazioni Read e ReadData per l'elemento di origine (lakehouse o warehouse). Le autorizzazioni degli elementi possono essere ereditate dai ruoli dell'area di lavoro o assegnate in modo esplicito per l'elemento, come descritto in questo articolo.

Supponendo che questo requisito sia soddisfatto, Fabric concede l'accesso necessario al modello semantico per leggere le tabelle Delta e i file Parquet associati (per caricare i dati delle colonne in memoria) e le regole di accesso ai dati possono essere applicate.

Opzioni delle regole di accesso ai dati

È possibile configurare le regole di accesso ai dati in:

  • Solo il modello semantico.
  • Solo l'endpoint di analisi SQL.
  • Sia nel modello semantico che nell'endpoint di analisi SQL.

Regole nel modello semantico

Se è necessario applicare le regole di accesso ai dati, è necessario farlo nel modello semantico ogni volta che è possibile. Ciò è dovuto al fatto che la sicurezza a livello di riga applicata dal modello semantico viene ottenuta filtrando la cache in memoria dei dati per ottenere query con prestazioni elevate.

È anche un approccio appropriato quando ai consumer di report non viene concessa l'autorizzazione per eseguire query sul lakehouse o sul magazzino.

In entrambi i casi, è consigliabile che la connessione cloud usi un'identità fissa anziché l'accesso SSO. SSO implica che gli utenti finali possono accedere direttamente all'endpoint di analisi SQL e potrebbero quindi ignorare le regole di sicurezza nel modello semantico.

Importante

Le autorizzazioni degli elementi del modello semantico possono essere impostate in modo esplicito tramite le app Power BI o acquisite in modo implicito tramite i ruoli dell'area di lavoro.

In particolare, le regole di accesso ai dati del modello semantico non vengono applicate per gli utenti che dispongono dell'autorizzazione di scrittura per il modello semantico. Viceversa, le regole di accesso ai dati si applicano agli utenti assegnati al ruolo dell'area di lavoro Visualizzatore . Tuttavia, gli utenti assegnati al ruolo dell'area di lavoro Amministratore, Membro o Collaboratore dispongono implicitamente dell'autorizzazione di scrittura per il modello semantico e pertanto le regole di accesso ai dati non vengono applicate. Per altre informazioni, vedere Ruoli nelle aree di lavoro.

Regole nell'endpoint di analisi SQL

È appropriato applicare le regole di accesso ai dati nell'endpoint di analisi SQL quando la connessione cloud del modello semantico usa l'accesso Single Sign-On (SSO). Ciò avviene perché l'identità dell'utente viene delegata per eseguire una query sull'endpoint di analisi SQL, assicurando che le query restituisca solo i dati a cui l'utente può accedere. È anche opportuno applicare regole di accesso ai dati a questo livello quando gli utenti eseguiranno una query direttamente sull'endpoint di analisi SQL per altri carichi di lavoro, ad esempio per creare un report impaginato di Power BI o esportare i dati.

In particolare, una query del modello semantico eseguirà il fallback alla modalità DirectQuery quando include qualsiasi tabella che applica la sicurezza a livello di riga nell'endpoint di analisi SQL. Di conseguenza, il modello semantico potrebbe non memorizzare mai nella cache i dati in memoria per ottenere query con prestazioni elevate.

Regole a entrambi i livelli

Le regole di accesso ai dati possono essere applicate a entrambi i livelli. Tuttavia, questo approccio comporta un sovraccarico di gestione e complessità aggiuntivo. In questo caso, è consigliabile che la connessione cloud usi un'identità fissa anziché l'accesso SSO.

Confronto tra le opzioni delle regole di accesso ai dati

Nella tabella seguente vengono confrontate le opzioni di configurazione dell'accesso ai dati.

Applicare le regole di accesso ai dati a Commento
Solo modello semantico Usare questa opzione quando agli utenti non vengono concesse autorizzazioni per l'elemento per eseguire query sul lakehouse o sul magazzino. Configurare la connessione cloud per l'uso di un'identità fissa. È possibile ottenere prestazioni elevate delle query dalla cache in memoria.
Solo endpoint di analisi SQL Usare questa opzione quando gli utenti devono accedere ai dati dal warehouse o dal modello semantico e con regole di accesso ai dati coerenti. Verificare che l'accesso Single Sign-On sia abilitato per la connessione cloud. Le prestazioni delle query potrebbero risultare lente.
Lakehouse o warehouse e modello semantico Questa opzione comporta un sovraccarico di gestione aggiuntivo. Configurare la connessione cloud per l'uso di un'identità fissa.

Di seguito sono riportate le procedure consigliate relative all'applicazione delle regole di accesso ai dati:

  • Se utenti diversi devono essere limitati a subset di dati, ogni volta che è 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. In questo caso, è consigliabile che la connessione cloud usi un'identità fissa anziché l'accesso SSO.
  • Se possibile, evitare di applicare OLS e CLS a entrambi i livelli perché genera errori negli oggetti visivi del report. Gli errori possono causare confusione o preoccupazione per gli utenti. Per le colonne riepilogabili, è consigliabile creare misure che restituiscono BLANK in determinate condizioni anziché CLS (se possibile).

Supporto per la scrittura di modelli con l'endpoint XMLA

I modelli semantici Direct Lake supportano operazioni di scrittura con l'endpoint XMLA usando strumenti come SSMS (19.1 o versione successiva) e strumenti open source della community.

Suggerimento

Per altre informazioni sull'uso di strumenti di terze parti per sviluppare, gestire o ottimizzare modelli semantici, vedere lo scenario di utilizzo avanzato della gestione dei modelli di dati.

Prima di poter eseguire operazioni di scrittura, è necessario abilitare l'opzione di lettura/scrittura XMLA per la capacità. Per altre informazioni, vedere Abilitare la lettura/scrittura XMLA.

Operazioni di scrittura del modello con 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. Per altre informazioni, vedere Gestione del ciclo di vita del contenuto.
  • Attività di automazione come l'aggiornamento semantico del modello e l'applicazione di modifiche ai modelli semantici Direct Lake usando PowerShell e le API REST.

Quando si modifica un modello semantico utilizzando XMLA, è necessario aggiornare l'insieme ChangedProperties e PBI_RemovedChildren affinché l'oggetto modificato includa le proprietà modificate o rimosse. Se non si esegue l'aggiornamento, gli strumenti di modellazione di Power BI potrebbero sovrascrivere eventuali modifiche alla successiva sincronizzazione dello schema.

I modelli supportati per la modifica di un modello semantico tramite XMLA sono i seguenti:

  • Ridenominazione tabella/colonna (ChangeProperty = name)
  • Rimuovere la tabella (aggiungere una tabella a PBI_RemovedChildren annotazione nell'espressione di query)

Importante

Le tabelle Direct Lake create tramite applicazioni XMLA inizialmente saranno in uno stato non elaborato fino a quando l'applicazione non invia un comando di aggiornamento. Le query che coinvolgono tabelle non elaborate eseguiranno sempre il fallback alla modalità DirectQuery. Pertanto, quando si crea un nuovo modello semantico, assicurarsi di aggiornare il modello per elaborare le relative tabelle.

Per altre informazioni, vedere Connettività del modello semantico con l'endpoint XMLA.

Metadati del modello Direct Lake

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

  • La compatibilityLevel proprietà dell'oggetto di database è 1604 (o superiore).
  • 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 di analisi SQL del lakehouse o del warehouse. Direct Lake usa l'endpoint di analisi SQL per individuare lo schema e le informazioni di sicurezza, ma carica i dati direttamente da OneLake ,a meno che non venga eseguito il fallback alla modalità DirectQuery per qualsiasi motivo.

Attività successive alla pubblicazione

Dopo aver pubblicato un modello semantico Direct Lake, è necessario completare alcune attività di configurazione. Per altre informazioni, vedere Gestire modelli semantici Direct Lake.

Funzionalità non supportate

Le funzionalità del modello seguenti non sono supportate dai modelli semantici Direct Lake:

  • Tabelle calcolate che fanno riferimento a tabelle o colonne in modalità Direct Lake Storage
  • Colonne calcolate che fanno riferimento a tabelle o colonne in modalità Direct Lake Storage
  • Tabelle ibride
  • Aggregazioni definite dall'utente
  • I modelli compositi, in quanto non è possibile combinare tabelle in modalità di archiviazione Direct Lake con tabelle in modalità directQuery o dual storage nello stesso modello. Tuttavia, è possibile usare Power BI Desktop per creare una connessione dinamica a un modello semantico Direct Lake e quindi estenderlo con nuove misure e, da qui, è possibile fare clic sull'opzione per apportare modifiche a questo modello per aggiungere nuove tabelle (tramite Importazione, DirectQuery o modalità di archiviazione doppia). Questa azione crea una connessione DirectQuery al modello semantico in modalità Direct Lake, quindi le tabelle vengono visualizzate come modalità di archiviazione DirectQuery, ma questa modalità di archiviazione non indica il fallback a DirectQuery. Solo la connessione tra questo nuovo modello e il modello Direct Lake è DirectQuery e le query usano ancora Direct Lake per ottenere dati da OneLake. Per altre informazioni, vedere Creare un modello composito in un modello semantico.
  • Colonne basate sulle colonne dell'endpoint di analisi SQL che applicano la maschera dati dinamica.

Contenuto correlato