Freigeben über

Entwickeln von Direct Lake-Semantikmodellen

In diesem Artikel werden Designthemen beschrieben, die für die Entwicklung von Direct Lake-Semantikmodellen relevant sind.

Erstellen des Modells

Sie können ein Direct Lake-Semantikmodell in Power BI Desktop oder aus vielen Fabric-Elementen im Browser erstellen. Beispielsweise können Sie in einem geöffneten Lakehouse ein neues semantisches Modell auswählen, um ein neues semantisches Modell im Direct Lake-Speichermodus zu erstellen.

Sie können entweder Power BI Desktop oder Webmodellierung im Browser verwenden, um das semantische Modell zu bearbeiten, um Beziehungen hinzuzufügen, Felder umzubenennen, Measures hinzuzufügen und andere Aufgaben zur semantischen Modellierung hinzuzufügen.

Alternativ können Sie wie bei jedem Power BI-Semantikmodell die Entwicklung Ihres Modells mit einem XMLA-kompatiblen Tool fortsetzen, 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. Fabric-Notebooks können auch programmgesteuert semantische Modelle mit semantischen Verbindungen und Semantische Link-Labore erstellen und bearbeiten.

Tip

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

Model tables

Modelltabellen basieren entweder auf einer Tabelle oder einer Ansicht des SQL-Analyseendpunkts. Vermeiden Sie jedoch nach Möglichkeit die Verwendung von Sichten. Abfragen einer Modelltabelle basierend auf einer Ansicht greifen auf den DirectQuery-Modus zurück, was zu einer langsameren Abfrageleistung führen kann.

Warning

Ansichten können nur in Direct Lake auf SQL verwendet werden und können nicht in Direct Lake auf OneLake verwendet werden.

Tabellen sollten Zusätzlich zu Spalten, die Modellbeziehungen unterstützen, Spalten zum Filtern, Gruppieren, Sortieren und Zusammenfassen enthalten. Unnötige Spalten wirken sich 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 dazu führen, dass mehr Computeressourcen geladen und verwaltet werden.

Warning

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

Importtabellen können mit Direct Lake zu semantischen Modellen bei OneLake-Tabellen hinzugefügt werden. Berechnete Tabellen können hinzugefügt werden, solange sie nicht auf eine Direct Lake-Tabelle verweisen. Berechnungsgruppen können hinzugefügt werden.

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 zur Leistung von Direct Lake-Abfragen.

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.

Note

Das Thema des Erzwingens von Datenzugriffsregeln ist zwar verschieden, aber dennoch verwandt mit dem Festlegen von Berechtigungen für Inhaltskonsumenten, -ersteller und -nutzer, die das semantische Modell (und verwandte Fabric-Elemente) verwalten. 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.

Important

Wenn eine Abfrage eine Tabelle verwendet, die RLS im SQL-Analyseendpunkt enthält, greift sie auf den DirectQuery-Modus zurück. 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 (berichtsvisuale Elemente können nicht gerendert werden).
  2. Wenn die Abfrage eine Spalte enthält, die vom SQL-Analyseendpunkt CLS eingeschränkt ist (oder die Tabelle verweigert wird), wird ein Fehlerergebnis zurückgegeben (berichtsvisuale Elemente können nicht gerendert werden).
    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.

Important

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 angemessen, 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 exportieren von Daten).

Insbesondere fällt eine Semantikmodellabfrage jedoch in den DirectQuery-Modus zurück, wenn sie eine Tabelle enthält, die RLS im SQL-Analyseendpunkt erzwingt. Das semantische Modell speichert also 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 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 Comment
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.

Tip

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.

Important

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).

Post-publication tasks

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.

Related content

  • Last updated on