Freigeben über

Entwickeln von Direct Lake-Semantikmodellen

  • Artikel

In diesem Artikel werden Designthemen beschrieben, 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 einzigen Seehaus oder Lager zum Semantikmodell hinzugefügt werden sollen.

Anschließend können Sie das Webmodellierungserlebnis verwenden, um das Semantikmodell weiter zu entwickeln. Mit dieser Funktion können Sie Beziehungen zwischen Tabellen erstellen, Messwerte und Kalkulationsgruppen erstellen, Datumstabellen markieren und Eigenschaften für das Modell und seine Objekte festlegen (z. B. Spaltenformate). Sie können auch die 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 verwenden, z. B. SQL Server Management Studio (SSMS) (Version 19.1 oder höher) oder Open-Source-Communitytools. Weitere Informationen finden Sie unter Modellschreibunterstützung für den XMLA-Endpunkt weiter unten in diesem Artikel.

Tipp

Sie können lernen, wie Sie ein Lakehouse, eine Delta-Tabelle und ein einfaches Direct Lake-Semantikmodell erstellen, indem Sie dieses Tutorialabschließen.

Modelltabellen

Modelltabellen basieren entweder auf einer Tabelle oder einer Ansicht des SQL-Analyseendpunkts. Vermeiden Sie jedoch nach Möglichkeit die Verwendung von Sichten. Das liegt daran, dass Abfragen einer Modelltabelle, die auf einer Ansicht basiert, immer auf den DirectQuery-Moduszurückgreifen, was zu einer langsameren Abfrageleistung führen kann.

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

Warnung

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

Informationen zum Auswählen der Tabellen, die in Ihr Direct Lake-Semantikmodell aufgenommen werden sollen, finden Sie unter Bearbeiten von Tabellen für Direct Lake-Semantikmodelle.

Weitere Informationen zu Spalten, die in Ihre Semantikmodelltabellen aufgenommen werden sollen, finden Sie unter Grundlegendes zum Speicher für Direct Lake-Semantikmodelle.

Erzwingen von Datenzugriffsregeln

Wenn Sie anforderungen zum Bereitstellen von Teilmengen von Modelldaten an verschiedene Benutzer haben, können Sie Datenzugriffsregeln erzwingen. Sie erzwingen Regeln, indem Sie im SQL-Analyseendpunkt oder im semantischen Modell die Sicherheit auf Objektebene (Object-Level Security, OLS) und/oder zeilenebenen Sicherheit (RLS) einrichten.

Anmerkung

Das Erzwingen von Datenzugriffsregeln unterscheidet sich zwar vom Festlegen von Berechtigungen für Inhaltsbenutzende, Erstellende und Benutzende, die das Semantikmodell (und zugehörige Fabric-Elemente) verwalten, steht jedoch im Zusammenhang mit diesem Ansatz. Weitere Informationen zum Festlegen von Berechtigungen finden Sie unter Verwalten von Direct Lake-Semantikmodellen.

Sicherheit auf Objektebene (OLS)

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

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

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 tabellarischen Editor verwenden, um OLS einzurichten.

Sicherheit auf Zeilenebene (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 die Sicherheit auf Zeilenebene (RLS) einrichten, um den Zugriff auf Zeilen in einer Endpunkttabelle zu steuern.

Wichtig

Wenn eine Abfrage eine Tabelle verwendet, die RLS im SQL-Analyseendpunkt enthält, wird sie auf den DirectQuery-Modus zurückgesetzt. Die Abfrageleistung ist möglicherweise langsamer.

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

Wie Abfragen ausgewertet werden

Der Grund für die Entwicklung von Direct Lake-Semantikmodellen besteht darin, hochleistungsfähige Abfragen über große Datenmengen in OneLake zu erzielen. 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. Die Vorteile des Direct Lake-Speichermodus sind nur möglich, wenn der fünfte Schritt erreicht wird.

  1. Wenn die Abfrage eine Tabelle oder Spalte enthält, die durch das semantische Modell OLS eingeschränkt ist, wird ein Fehlerergebnis zurückgegeben (die Berichtsvisualisierung wird fehlschlagen).
  2. Wenn die Abfrage eine Spalte enthält, die durch den SQL-Analyseendpunkt CLS eingeschränkt ist (oder wenn der Zugriff auf die Tabelle verweigert wird), wird ein Fehlerergebnis zurückgegeben (die Berichtsvisualisierung wird nicht dargestellt).
    1. Wenn die Cloudverbindung SSO (Standard) 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 eine Ansicht verwendet wird, greift die Abfrage auf den DirectQuery-Modus zurück.
    1. Wenn die Cloudverbindung SSO (Standard) 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 Speichercache erfüllt. Spaltendaten werden nach Bedarf in den Arbeitsspeicher geladen.

Quellelementberechtigungen

Das Konto, das für den Zugriff auf Daten verwendet wird, ist eine der folgenden Optionen.

  • Wenn die Cloudverbindung SSO (Standard) verwendet, handelt es sich um den Berichtsanwender.
  • Wenn die Cloudverbindung eine feste Identität verwendet, handelt es sich um die feste Identität.

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

Sofern diese Anforderung erfüllt ist, gewährt Fabric dem semantischen Modell den erforderlichen Zugriff, um die Delta-Tabellen und die zugehörigen Parkettdateien zu lesen (um Spaltendaten in den Speicher zu laden), und Datenzugriffsregeln können angewendet werden.

Datenzugriffsregeloptionen

Sie können Datenzugriffsregeln wie folgt festlegen:

  • Nur das semantische Modell.
  • Nur der SQL-Analyseendpunkt.
  • Sowohl im semantischen Modell als auch im SQL-Analyseendpunkt.

Regeln im semantischen Modell

Wenn Sie Datenzugriffsregeln erzwingen müssen, sollten Sie dies im semantischen Modell tun, wenn es lebensfähig ist. Das liegt daran, dass RLS, die vom Semantikmodell erzwungen werden, erreicht wird, indem der Speichercache von Daten gefiltert wird, um hochleistungsfähige Abfragen zu erzielen.

Dies ist auch ein geeigneter Ansatz, wenn Berichtsanwendenden 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 daher Sicherheitsregeln im semantischen Modell 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. Benutzende, die der Arbeitsbereichsrolle Administrator, Mitglied oder Mitwirkender zugewiesen sind, haben implizit Schreibberechtigungen für das Semantikmodell, weshalb Datenzugriffsregeln nicht erzwungen werden. Weitere Informationen finden Sie unter Rollen in Arbeitsbereichen.

Regeln im SQL-Analyseendpunkt

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

Insbesondere wird eine Semantikmodellabfrage jedoch auf den DirectQuery-Modus zurückgesetzt, 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 erzielen.

Regeln auf beiden Ebenen

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

Vergleich von Datenzugriffsregeloptionen

In der folgenden Tabelle werden die Datenzugriffsoptionen verglichen.

Anwenden von Datenzugriffsregeln Kommentar
Nur semantisches Modell Verwenden Sie diese Option, wenn Benutzenden keine Elementberechtigungen zum Abfragen von Lakehouses oder Warehouses erteilt werden. Richten Sie die Cloudverbindung ein, um eine feste Identität zu verwenden. Hohe Abfrageleistung kann aus dem Speichercache erzielt werden.
Nur SQL-Analyseendpunkt Verwenden Sie diese Option, wenn Benutzer auf Daten aus dem Warehouse oder dem semantischen Modell und mit konsistenten Datenzugriffsregeln zugreifen müssen. Stellen Sie sicher, dass SSO für die Cloudverbindung aktiviert ist. Die Abfrageleistung kann langsam 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 sind empfohlene Methoden zum Erzwingen von Datenzugriffsregeln:

  • Wenn unterschiedliche Benutzer auf Teilmengen von Daten beschränkt werden müssen, wann immer möglich, erzwingen Sie RLS nur auf der Semantikmodell Ebene. Auf diese Weise profitieren Benutzer von leistungsstarken 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 das Erzwingen von OLS und CLS auf einer der Ebenen, da dies zu Fehlern in Berichtsvisualisierungen führt. Fehler können zu Verwirrung oder Sorge für Benutzer führen. Für zusammenfassbare Spalten sollten Sie Measures erstellen, die unter bestimmten Bedingungen BLANK anstelle von CLS zurückgeben (sofern möglich).

Modellschreibunterstützung 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 XMLA-Lese-/Schreibzugriffsoption für die Kapazität aktiviert sein. Weitere Informationen finden Sie unter Aktivieren von XMLA-Lese-/Schreibzugriff.

Modellschreibvorgänge mit der XMLA-Endpunktunterstützung:

  • Anpassen, Mergen, Skripting, Debuggen und Testen von Direct Lake-Modellmetadaten
  • Quell- und Versionskontrolle, kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) mit Azure DevOps und GitHub. Weitere Informationen finden Sie unter Content Lifecycle Management.
  • Automatisierungsaufgaben wie das Aktualisieren semantischer Modelle und das Anwenden von Änderungen an semantischen Modellen in Direct Lake mithilfe von PowerShell und REST-APIs.

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

Weitere Informationen zu Datenherkunftskategorien für Objekte semantischer Modelle finden Sie im Artikel zu Datenherkunftskategorien der Power BI-Semantikmodelle.

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, greifen immer auf den DirectQuery-Modus zurück. Wenn Sie also ein neues semantisches Modell erstellen, müssen Sie das Modell aktualisieren, um seine Tabellen zu verarbeiten.

Weitere Informationen finden Sie unter Semantikmodellkonnektivität mit dem XMLA-Endpunkt.

Direct Lake-Modellmetadaten

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

  • Die compatibilityLevel Eigenschaft des Datenbankobjekts ist 1604 (oder höher).
  • Die Moduseigenschaft von Direct Lake-Partitionen ist auf directLakefestgelegt.
  • Direct Lake-Partitionen verwenden freigegebene Ausdrücke zum Definieren von Datenquellen. Dieser Ausdruck verweist auf den SQL-Analyseendpunkt des Lakehouse oder Warehouse. Direct Lake verwendet den SQL-Analyseendpunkt zum Ermitteln von Schema- und Sicherheitsinformationen, lädt jedoch die Daten direkt aus OneLake (es sei denn, es aus irgendeinem Grund auf den DirectQuery--Modus zurückfällt).

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 Features

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 herzustellen 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 semantischen Modell im Direct Lake-Modus, sodass die Tabellen als DirectQuery-Speichermodus angezeigt werden, dieser Speichermodus weist jedoch nicht auf 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 auf einem semantischen Modell.
  • Spalten, die auf SQL-Analyseendpunktspalten basieren, die die dynamische Datenmaskierung anwenden

Verwandte Inhalte