Freigeben über

Direct Lake-Semantikmodelle entwickeln

  • Artikel

Dieser Artikel deckt Entwurfsthemen ab, die für die Entwicklung von Direct Lake-Semantikmodellen relevant sind.

Erstellen des Modells

Sie verwenden das Fabric-Portal, um ein Direct Lake-Semantikmodell in einem Arbeitsbereich zu erstellen. Dabei handelt es sich um einen einfachen Prozess, bei dem ausgewählt wird, welche Tabellen aus einem einzelnen Lakehouse oder Warehouse zum Semantikmodell hinzugefügt werden sollen.

Sie können die Webmodellierungsumgebung verwenden, um das Semantikmodell weiterzuentwickeln. Mit dieser Umgebung können Sie Beziehungen zwischen Tabellen erstellen, Measures und Berechnungsgruppen erstellen, Datumstabellen markieren und Eigenschaften für ein Modell und seine Objekte festlegen (z. B. Spaltenformate). Sie können auch Sicherheit auf Zeilenebene (Row-Level Security, RLS) für das Modell einrichten, indem Sie Rollen und Regeln definieren und Mitglieder (Microsoft Entra-Benutzerkonten oder Sicherheitsgruppen) zu diesen Rollen hinzufügen.

Alternativ können Sie die Entwicklung Ihres Modells fortsetzen, indem Sie ein XMLA-kompatibles Tool wie SQL Server Management Studio (SSMS) (Version 19.1 oder höher) oder Open-Source-Communitytools verwenden. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Unterstützung für Schreibvorgänge des Modells mit dem XMLA-Endpunkt.

Tipp

In diesem Tutorial erfahren Sie, wie Sie ein Lakehouse, eine Delta-Tabelle und ein einfaches Direct Lake-Semantikmodell erstellen.

Modelltabellen

Modelltabellen basieren entweder auf einer Tabelle oder einer Sicht des SQL-Analyseendpunkts. Vermeiden Sie jedoch nach Möglichkeit die Verwendung von Sichten. Der Grund dafür ist, dass Abfragen einer Modelltabelle, die auf einer Sicht basiert, immer auf den DirectQuery-Modus zurückgreifen, was zu einer geringeren Abfrageleistung führen kann.

Zusätzlich zu Spalten, die Modellbeziehungen unterstützen, sollten Tabellen Spalten zum Filtern, Gruppieren, Sortieren und Zusammenfassen enthalten. Unnötige Spalten wirken sich zwar nicht auf die Abfrageleistung von Semantikmodellen aus (da sie nicht in den Arbeitsspeicher geladen werden), führen aber zu einem größeren Speicher in OneLake und erfordern daher mehr Computeressourcen zum Laden und Verwalten.

Warnung

Die Verwendung von Spalten, die dynamische Datenmaskierung (DDM) in Direct Lake-Semantikmodellen anwenden, werden nicht unterstützt.

Informationen zu den Tabellen, die Sie für die Aufnahme in Direct Lake-Semantikmodell auswählen sollten, finden Sie unter Bearbeiten von Tabellen für Direct Lake-Semantikmodelle.

Weitere Informationen zu den Spalten, die Sie in Ihre Semantikmodelltabellen aufnehmen sollten, finden Sie unter Grundlegendes zum Speicher für Direct Lake-Semantikmodelle.

Erzwingen von Datenzugriffsregeln

Wenn bei Ihnen bestimmte Anforderungen zum Bereitstellen einer Teilmenge von Modelldaten für verschiedene Benutzer gelten, können Sie Datenzugriffsregeln erzwingen. Sie erzwingen Regeln, indem Sie OLS (Object-Level Security, Sicherheit auf Objektebene) und/oder RLS (Row-Level Security, Sicherheit auf Zeilenebene) im SQL-Analyseendpunkt oder im Semantikmodell einrichten.

Hinweis

Das Thema zum Erzwingen von Datenzugriffsregeln unterscheidet sich zwar vom Festlegen von Berechtigungen für Inhaltsnutzer, Ersteller und Benutzer, die das Semantikmodell (und verwandte Fabric-Elemente) verwalten, ist aber damit verwandt. Weitere Informationen zum Festlegen von Berechtigungen finden Sie unter Verwalten von Direct Lake-Semantikmodellen.

Sicherheit auf Objektebene (Object-level Security, OLS)

OLS umfasst das Einschränken des Zugriffs auf die Erkennung und Abfrage von Objekten oder Spalten. Sie können OLS beispielsweise verwenden, um die Benutzer einzuschränken, die über die Tabelle Employee auf die Spalte Salary zugreifen können.

Sie können für einen SQL-Analyseendpunkt OLS zur Steuerung des Zugriffs auf die Endpunktobjekte (z. B. Tabellen oder Sichten) einrichten und CLS (Column-Level Security, Sicherheit auf Spaltenebene) zur Steuerung des Zugriffs auf Endpunkttabellenspalten.

Für ein Semantikmodell können Sie OLS einrichten, um den Zugriff auf Modelltabellen oder Spalten zu steuern. Sie müssen Open-Source-Communitytools wie Tabular Editor verwenden, um OLS einzurichten.

Sicherheit auf Zeilenebene (row-level security; RLS)

RLS umfasst das Einschränken des Zugriffs auf Teilmengen von Daten in Tabellen. Sie können beispielsweise RLS verwenden, um sicherzustellen, dass Vertriebsmitarbeiter nur auf Verkaufsdaten für Kunden in ihrer Vertriebsregion zugreifen können.

Sie können für einen SQL-Analyseendpunkt RLS einrichten, um den Zugriff auf Zeilen in einer Endpunkttabelle zu steuern.

Wichtig

Wenn eine Abfrage eine Tabelle verwendet, die RLS im SQL-Analyseendpunkt umfasst, erfolgt ein Fallback auf den DirectQuery-Modus. Die Abfrageleistung könnte langsamer sein.

Sie können für ein Semantikmodell RLS einrichten, um den Zugriff auf Zeilen in Modelltabellen zu steuern. RLS kann in der Webmodellierungsumgebung oder mithilfe eines Drittanbietertools eingerichtet werden.

Auswerten von Regeln

Der Grund für die Entwicklung von Direct Lake-Semantikmodellen besteht darin, Hochleistungsabfragen für große Datenmengen in OneLake zu ermöglichen. Daher sollten Sie sich bemühen, eine Lösung zu entwerfen, die die Chancen einer In-Memory-Abfrage maximiert.

In den folgenden Schritten wird die Auswertung von Abfragen (und ob sie fehlschlagen) näher beschrieben. Es ist nur möglich, von den Vorteilen des Direct Lake-Speichermodus zu profitieren, wenn der fünfte Schritt erreicht wird.

  1. Wenn die Abfrage eine Tabelle oder Spalte enthält, die durch OLS für das Semantikmodell eingeschränkt ist, wird ein Fehlerergebnis zurückgegeben (das Berichtsvisual wird nicht gerendert).
  2. Wenn die Abfrage eine Spalte enthält, die durch CLS für den SQL-Analyseendpunkt eingeschränkt ist, oder wenn die Tabelle verweigert wird, wird ein Fehlerergebnis zurückgegeben (das Berichtsvisual wird nicht gerendert).
    1. Wenn die Cloudverbindung SSO (Standardeinstellung) verwendet, wird CLS durch die Zugriffsebene des Berichtsanwenders bestimmt.
    2. Wenn die Cloudverbindung eine feste Identität verwendet, wird CLS durch die Zugriffsebene der festen Identität bestimmt.
  3. Wenn die Abfrage eine Tabelle im SQL-Analyseendpunkt enthält, die RLS erzwingt, oder wenn eine Sicht verwendet wird, führt die Abfrage ein Fallback auf den DirectQuery-Modus zurück.
    1. Wenn die Cloudverbindung SSO (Standardeinstellung) verwendet, wird RLS durch die Zugriffsebene des Berichtsanwenders bestimmt.
    2. Wenn die Cloudverbindung eine feste Identität verwendet, wird RLS durch die Zugriffsebene der festen Identität bestimmt.
  4. Wenn die Abfrage die Schutzmaßnahmen der Kapazität überschreitet, wird ein Fallback auf den DirectQuery-Modus ausgeführt.
  5. Andernfalls wird die Abfrage aus dem In-Memory-Cache erfüllt. Spaltendaten werden nach Bedarf in den Arbeitsspeicher geladen.

Quellelementberechtigungen

Für den Zugriff auf Daten wird eins der folgenden Konten verwendet:

  • Wenn die Cloudverbindung SSO (Standard) verwendet, wird der Berichtsanwender verwendet.
  • Wenn die Cloudverbindung eine feste Identität verwendet, wird die feste Identität verwendet.

Das Konto muss mindestens über Leseberechtigungen und ReadData-Berechtigungen für das Quellelement (Lakehouse oder Warehouse) verfügen. Elementberechtigungen können von Arbeitsbereichsrollen geerbt oder explizit für das Element zugewiesen werden, wie in diesem Artikel beschrieben.

Angenommen, diese Anforderung wird erfüllt, gewährt Fabric dem Semantikmodell die erforderlichen Berechtigungen zum Lesen der Delta-Tabellen und zugeordneter Parquet-Dateien (um Spaltendaten in den Arbeitsspeicher zu laden), und Datenzugriffsregeln können angewendet werden.

Optionen für Datenzugriffsregeln

Sie können Datenzugriffsregeln wie folgt festlegen:

  • Nur im Semantikmodell
  • Nur im SQL-Analyseendpunkt
  • Sowohl im Semantikmodell als auch im SQL-Analyseendpunkt

Regeln im Semantikmodell

Wenn Sie Datenzugriffsregeln erzwingen müssen, sollten Sie dies im Semantikmodell tun, sofern möglich. Das liegt daran, dass die vom Semantikmodell erzwungene RLS erreicht wird, indem der In-Memory-Cache von Daten gefiltert wird, um Hochleistungsabfragen zu erzielen.

Dies ist auch ein geeigneter Ansatz, wenn Berichtsanwendern keine Berechtigung zum Abfragen des Lakehouse oder Warehouse erteilt wird.

In beiden Fällen wird dringend empfohlen, dass die Cloudverbindung anstelle von SSO eine feste Identität verwendet. SSO würde bedeuten, dass Endbenutzer direkt auf den SQL-Analyseendpunkt zugreifen können und damit Sicherheitsregeln im Semantikmodell umgehen können.

Wichtig

Berechtigungen für Semantikmodellelemente können explizit über Power BI-Apps festgelegt oder implizit über Arbeitsbereichsrollen erworben werden.

Insbesondere werden Datenzugriffsregeln für Semantikmodelle nicht für Benutzer erzwungen, die über Schreibberechtigungen für das Semantikmodell verfügen. Umgekehrt gelten Datenzugriffsregeln für Benutzer, die der Arbeitsbereichsrolle Viewer zugewiesen sind. Benutzer, die der Arbeitsbereichsrolle Administrator, Mitglied oder Mitwirkender zugewiesen sind, haben implizit Schreibberechtigungen für das Semantikmodell, und daher werden Datenzugriffsregeln nicht erzwungen. Weitere Informationen finden Sie unter Rollen in Arbeitsbereichen.

Regeln im SQL-Analyseendpunkt

Es ist angemessen, Datenzugriffsregeln im SQL-Analyseendpunkt zu erzwingen, wenn die Cloudverbindung des Semantikmodells einmaliges Anmelden (Single Sign-On, SSO) verwendet. Das liegt daran, dass die Identität des Benutzers zum Abfragen des SQL-Analyseendpunkts delegiert wird, um sicherzustellen, dass Abfragen nur die Daten zurückgeben, auf die der Benutzer zugreifen darf. Es ist auch angemessen, Datenzugriffsregeln auf dieser Ebene zu erzwingen, wenn Benutzer den SQL-Analyseendpunkt direkt auf andere Workloads abfragen (z. B. zum Erstellen eines paginierten Power BI-Berichts oder zum Exportieren von Daten).

Insbesondere führt eine Semantikmodellabfrage jedoch ein Fallback auf den DirectQuery-Modus aus, wenn sie eine Tabelle enthält, die RLS im SQL-Analyseendpunkt erzwingt. Folglich speichert das Semantikmodell möglicherweise niemals Daten im Arbeitsspeicher zwischen, um Hochleistungsabfragen zu ermöglichen.

Regeln auf beiden Ebenen

Datenzugriffsregeln können auf beiden Ebenen erzwungen werden. Dieser Ansatz ist jedoch komplexer und erfordert mehr Verwaltungsaufwand. In diesem Fall wird dringend empfohlen, dass die Cloudverbindung anstelle von SSO eine feste Identität verwendet.

Vergleich der Optionen für Datenzugriffsregeln

In der folgenden Tabelle werden die Optionen für die Einrichtung von Datenzugriffsoptionen verglichen.

Anwenden von Datenzugriffsregeln auf Kommentar
Nur Semantikmodell Verwenden Sie diese Option, wenn Benutzern keine Elementberechtigungen zum Abfragen des Lakehouse oder Warehouse erteilt werden. Richten Sie die Cloudverbindung ein, um eine feste Identität zu verwenden. Hohe Abfrageleistung kann über den In-Memory-Cache erzielt werden.
Nur SQL-Analyseendpunkt Verwenden Sie diese Option mit konsistenten Datenzugriffsregeln, wenn Benutzer auf Daten aus dem Warehouse oder dem Semantikmodell zugreifen müssen. Stellen Sie sicher, dass SSO für die Cloudverbindung aktiviert ist. Die Abfrageleistung kann gering sein.
Lakehouse oder Warehouse und Semantikmodell Diese Option erfordert zusätzlichen Verwaltungsaufwand. Richten Sie die Cloudverbindung ein, um eine feste Identität zu verwenden.

Hier finden Sie empfohlene Methoden zum Erzwingen von Datenzugriffsregeln:

  • Wenn der Zugriff von verschiedenen Benutzern auf eine Teilmenge von Daten beschränkt werden muss, erzwingen Sie RLS nur auf der Semantikmodellebene. Auf diese Weise profitieren Benutzer von Hochleistungs-In-Memory-Abfragen. In diesem Fall wird dringend empfohlen, dass die Cloudverbindung anstelle von SSO eine feste Identität verwendet.
  • Vermeiden Sie nach Möglichkeit die Erzwingung von OLS und CLS auf beiden Ebenen, da dies zu Fehlern in Berichtsvisuals führt. Fehler können zu Verwirrung oder Besorgnis bei Benutzern führen. Für zusammenfassbare Spalten sollten Sie Measures erstellen, die unter bestimmten Bedingungen BLANK anstelle von CLS zurückgeben (sofern möglich).

Unterstützung für Schreibvorgänge des Modells mit dem XMLA-Endpunkt

Direct Lake-Semantikmodelle unterstützen Schreibvorgänge mit dem XMLA-Endpunkt mithilfe von Tools wie SSMS (19.1 oder höher) und Open-Source-Communitytools.

Tipp

Weitere Informationen zur Verwendung von Drittanbietertools zum Entwickeln, Verwalten oder Optimieren von Semantikmodellen finden Sie im Nutzungsszenario für die erweiterte Datenmodellverwaltung.

Bevor Sie Schreibvorgänge ausführen können, muss die Lese-/Schreiboption von XMLA für die Kapazität aktiviert werden. Weitere Informationen finden Sie unter Aktivieren von XMLA-Lese-/Schreibzugriff.

Modellschreibvorgänge mit dem XMLA-Endpunkt unterstützen Folgendes:

  • Anpassen, Zusammenführen, Erstellen von Skripts, Debuggen und Testen von Direct Lake-Modellmetadaten.
  • Quell- und Versionskontrolle, Continuous Integration und Continuous Deployment (CI/CD) mit Azure DevOps und GitHub. Weitere Informationen finden Sie unter Inhaltslebenszyklusverwaltung.
  • Automatisierungsaufgaben wie die Aktualisierung des Semantikmodells und das Anwenden von Änderungen auf Direct Lake-Semantikmodelle mithilfe von PowerShell und REST-APIs

Beim Ändern eines Semantikmodells mithilfe von XMLA müssen Sie die ChangedProperties- und die PBI_RemovedChildren-Sammlung für das geänderte Objekt aktualisieren, um geänderte oder entfernte Eigenschaften einzuschließen. Wenn Sie diese Aktualisierung nicht ausführen, überschreiben Power BI-Modellierungstools möglicherweise alle Änderungen, wenn das Schema das nächste Mal synchronisiert wird.

Unterstützte Modelle zum Ändern eines Semantikmodells mithilfe von XMLA:

  • Umbenennen von Tabellen/Spalten (ChangeProperty = Name)
  • Entfernen einer Tabelle (Hinzufügen einer Tabelle zur Anmerkung PBI_RemovedChildren im Abfrageausdruck)

Wichtig

Direct Lake-Tabellen, die mit XMLA-Anwendungen erstellt werden, befinden sich zunächst in einem nicht verarbeiteten Zustand, bis die Anwendung einen Aktualisierungsbefehl sendet. Abfragen, die nicht verarbeitete Tabellen umfassen, führen immer ein Fallback auf den DirectQuery-Modus zurück. Wenn Sie also ein neues Semantikmodell erstellen, aktualisieren Sie das Modell unbedingt, um seine Tabellen zu verarbeiten.

Weitere Informationen finden Sie unter Konnektivität der Semantikmodelle mit dem XMLA-Endpunkt.

Direct Lake-Modellmetadaten

Wenn Sie eine Verbindung mit einem Direct Lake-Semantikmodell mit dem XMLA-Endpunkt herstellen, sehen die Metadaten wie bei jedem anderen Modell aus. Direct Lake-Modelle weisen jedoch die folgenden Unterschiede auf:

  • Die compatibilityLevel-Eigenschaft des Datenbankobjekts ist 1604 (oder höher).
  • Die Moduseigenschaft von Direct Lake-Partitionen ist auf directLake festgelegt.
  • Direct Lake-Partitionen verwenden freigegebene Ausdrücke, um Datenquellen zu definieren. Dieser Ausdruck verweist auf den SQL-Analyseendpunkt des Lakehouse oder Warehouse. Direct Lake verwendet den SQL-Analyseendpunkt, um Schema- und Sicherheitsinformationen zu ermitteln, die Daten werden aber direkt aus OneLake geladen (es sei denn, aus irgendeinem Grund erfolgt ein Fallback auf den DirectQuery-Modus).

Aufgaben nach der Veröffentlichung

Nachdem Sie ein Direct Lake-Semantikmodell veröffentlicht haben, sollten Sie einige Setupaufgaben ausführen. Weitere Informationen finden Sie unter Verwalten von Direct Lake-Semantikmodellen.

Nicht unterstützte Funktionen

Die folgenden Modellfeatures werden von Direct Lake-Semantikmodellen nicht unterstützt:

  • Berechnete Tabellen, die auf Tabellen oder Spalten im Direct Lake-Speichermodus verweisen
  • Berechnete Spalten, die auf Tabellen oder Spalten im Direct Lake-Speichermodus verweisen
  • Hybridtabellen
  • Benutzerdefinierte Aggregationen
  • Zusammengesetzte Modelle, da Sie Tabellen im Direct Lake-Speichermodus nicht mit DirectQuery- oder Dualspeichermodustabellen im selben Modell kombinieren können. Sie können Power BI Desktop jedoch verwenden, um eine Liveverbindung mit einem Direct Lake-Semantikmodell zu erstellen und dann mit neuen Measures zu erweitern. Anschließend können Sie auf die Option klicken, um Änderungen an diesem Modell vorzunehmen und neue Tabellen hinzuzufügen (mithilfe des Import-, DirectQuery- oder Dualspeichermodus). Diese Aktion erstellt eine DirectQuery-Verbindung mit dem Semantikmodell im Direct Lake-Modus, sodass die Tabellen als DirectQuery-Speichermodus angezeigt werden, dieser Speichermodus weist jedoch nicht auf ein Fallback auf DirectQuery hin. Nur die Verbindung zwischen diesem neuen Modell und dem Direct Lake-Modell ist DirectQuery, und Abfragen verwenden weiterhin Direct Lake, um Daten aus OneLake abzurufen. Weitere Informationen finden Sie unter Erstellen eines zusammengesetzten Modells für ein Semantikmodell.
  • Spalten, die auf SQL-Analyseendpunktspalten basieren, die dynamische Datenmaskierung anwenden

Zugehöriger Inhalt