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

Si può usare il portale Fabric per creare un modello semantico Direct Lake in una workspace. 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 il modello sicurezza a livello di riga (RLS) 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 modello write support with the XMLA endpoint più avanti in questo articolo.

Suggerimento

Per informazioni su come creare una lakehouse, una tabella Delta e un modello semantico Direct Lake di base, è possibile 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 del 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.

Avvertimento

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 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. È possibile applicare le regole configurando la sicurezza a livello di oggetto e/o la sicurezza a livello di riga nel endpoint di analisi SQL o nel modello semantico.

Nota

L'argomento relativo l'applicazione delle regole di accesso ai dati è diverso, ma correlato, all'impostazione delle autorizzazioni per consumer di contenuti, 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.

Sicurezza 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 colonna Salary dalla tabella Employee.

Per un endpoint di analisi SQL, è possibile configurare OLS per controllare l'accesso agli oggetti endpoint, ad esempio tabelle o viste e la sicurezza a livello di colonna 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

RLS implica la limitazione dell'accesso ai sottoinsiemi 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 RLS per controllare l'accesso alle righe in una tabella endpoint.

Importante

Quando una query utilizza una tabella con sicurezza a livello di riga (RLS) nell'endpoint di analisi SQL, passerà alla modalità DirectQuery. Le prestazioni delle query potrebbero risultare più lente.

Per un modello semantico, è possibile configurare il controllo RLS 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 cui sviluppare modelli semantici Direct Lake è ottenere query con prestazioni elevate 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 (RLS) o viene utilizzata una vista, la query passa alla modalità DirectQuery.
    1. Se la connessione cloud usa l'SSO (impostazione predefinita), la sicurezza a livello di riga (RLS) è determinata dal livello di accesso dell'utente del report.
    2. Se la connessione cloud utilizza un'identità fissa, la sicurezza a livello di riga viene determinata dal livello di accesso dell'identità fissa.
  4. Se la query supera i limiti 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 avere almeno autorizzazioni Read e ReadData per l'elemento di origine (lakehouse o warehouse). Le autorizzazioni di un elemento possono essere ereditate dai ruoli dell'area di lavoro o assegnate esplicitamente per quell'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 agli utenti dei report non viene concessa l'autorizzazione per eseguire query sul magazzino o sul lakehouse.

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 definite esplicitamente tramite le app di Power BI oppure acquisite implicitamente 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 hanno l'autorizzazione di scrittura per il modello semantico. Viceversa, le regole di accesso ai dati si applicano agli utenti assegnati al ruolo Viewer dell'area di lavoro. Tuttavia, gli utenti assegnati ai ruoli Amministratore, Membroo Collaboratore dell'area di lavoro dispongono implicitamente del permesso di scrittura per il modello semantico e pertanto le regole di accesso ai dati non vengono applicate. Per ulteriori informazioni, vedere Ruoli nelle aree di lavoro.

Regole nell'endpoint di analisi SQL

È opportuno applicare le regole di accesso ai dati nell'endpoint di analisi SQL quando il modello semantico connessione cloud usa 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 passerà alla modalità DirectQuery quando include qualsiasi tabella che applica la RLS (sicurezza a livello di riga) nell'endpoint di analisi SQL. Di conseguenza, il modello semantico potrebbe non conservare mai i dati nella cache in memoria per eseguire query ad alte prestazioni.

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 sugli elementi per interrogare il lakehouse o il 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, modello semantico e 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 è fattibile, applicare la RLS 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 nessun livello perché genera errori nelle visualizzazioni 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.

Mancia

Per altre informazioni sull'uso di strumenti di terze parti per sviluppare, gestire o ottimizzare modelli semantici, vedere scenario di gestione avanzata del modello di dati scenario di utilizzo.

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

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 tramite 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 le modifiche alla successiva sincronizzazione dello schema con Lakehouse.

Altre informazioni sui tag di derivazione degli oggetti del modello semantico sono disponibili nell'articolo tag di derivazione per i modelli semantici di Power BI.

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 interrogazioni che coinvolgono tabelle non processate riporteranno sempre 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 mostrano le differenze seguenti:

  • La proprietà compatibilityLevel 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 si riferisce all'endpoint di analisi SQL del data lakehouse o del magazzino dati. 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 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 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