Freigeben über

Verwalten von Direct Lake-Semantikmodellen

  • Artikel

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

Aufgaben nach der Veröffentlichung

Nachdem Sie zuerst ein Direct Lake-Semantikmodell veröffentlicht haben, das für die Berichterstellung bereit ist, sollten Sie sofort einige Aufgaben nach der Veröffentlichung ausführen. Diese Aufgaben können auch jederzeit während des Lebenszyklus des semantischen Modells angepasst werden.

Optional können Sie auch die Datenerkennung einrichten, um Berichterstellenden das Lesen von Metadaten zu ermöglichen und sie dabei zu unterstützen, Daten im OneLake-Datenhub zu ermitteln und den Zugriff darauf anzufordern. Sie können das Semantikmodell auch empfehlen (zertifiziert oder höhergestuft), um mitzuteilen, dass es Qualitätsdaten enthält, die für die Nutzung geeignet sind.

Einrichten der Cloudverbindung

Ein Semantikmodell mit Direct Lake verwendet eine Cloudverbindung, um eine Verbindung mit dem SQL-Analyseendpunkt herzustellen. Dies ermöglicht den Zugriff auf Quelldaten. Dabei handelt es sich entweder um die Parquet-Dateien in OneLake (Direct Lake-Speichermodus, bei dem Spaltendaten in den Speicher geladen werden) oder den SQL-Analyseendpunkt (wenn Abfragen ein Fallback auf den DirectQuery-Modus durchführen).

Standardmäßige Cloudverbindung

Wenn Sie ein Direct Lake-Semantikmodell erstellen, wird die Standardmäßige Cloudverbindung verwendet. Es nutzt einmaliges Anmelden (Single Sign-On, SSO), was bedeutet, dass die Identität, die das semantische Modell (häufig ein Berichtsbenutzer) abfragt, zum Abfragen der SQL Analytics-Endpunktdaten verwendet wird.

Teilbare Cloud-Verbindung

Optional können Sie eine sharable Cloud-Verbindung (SCC) erstellen, damit Verbindungen mit der Datenquelle mit einer festen Identität hergestellt werden können. Sie kann Unternehmenskunden dabei helfen, ihre Unternehmensdatenspeicher zu schützen. Die IT-Abteilung kann Anmeldeinformationen verwalten, SCCs erstellen und für die vorgesehenen Erstellenden für die zentrale Zugriffsverwaltung freigeben.

Informationen zum Einrichten einer festen Identität finden Sie unter Angeben einer festen Identität für ein Direct Lake-Semantikmodell.

Authentifizierung

Die festgelegte Identität kann sich entweder mit OAuth 2.0 oder mithilfe eines Dienstprinzipals authentifizieren.

Anmerkung

Nur die Microsoft Entra-Authentifizierung wird unterstützt. Daher wird die Standardauthentifizierung für Direct Lake-Semantikmodelle nicht unterstützt.

OAuth 2.0

Wenn Sie OAuth 2.0 verwenden, können Sie sich mit einem Microsoft Entra-Benutzerkonto authentifizieren. Das Benutzerkonto muss über die Berechtigung zum Abfragen der SQL Analytics-Endpunkttabellen und -Ansichten und Schemametadaten verfügen.

Die Verwendung eines bestimmten Benutzerkontos ist keine empfohlene Methode. Das liegt daran, dass semantische Modellabfragen fehlschlagen, wenn die Kennwortänderung oder das Benutzerkonto gelöscht werden soll (z. B. wenn ein Mitarbeiter die Organisation verlässt).

Service Principal

Die Authentifizierung mit einem Dienstprinzipal ist die empfohlene Vorgehensweise, da sie nicht von einem bestimmten Benutzerkonto abhängig ist. Der Sicherheitsprinzipal muss über die Berechtigung zum Abfragen von SQL-Analyseendpunkttabellen und -Sichten sowie Schemametadaten verfügen.

Aus Gründen der Kontinuität können die Dienstprinzipalanmeldeinformationen durch Geheimnis- oder Zertifikatrotation verwaltet werden.

Anmerkung

Die Fabric-Mandanteneinstellungen müssen Dienstprinzipale zulassen, und der Dienstprinzipal muss zu einer deklarierten Sicherheitsgruppe gehören.

Einmaliges Anmelden

Wenn Sie eine gemeinsam genutzte Cloudverbindung herstellen, ist das Kontrollkästchen Einmaliges Anmelden standardmäßig deaktiviert. Dies ist das richtige Setup bei Verwendung einer festen Identität.

Sie können SSO aktivieren, wenn Die Identität, die das semantische Modell abfragt, auch den SQL-Analyseendpunkt abfragen soll. In dieser Konfiguration verwendet das Direct Lake-Semantikmodell die feste Identität, um das Modell und die Benutzeridentität zu aktualisieren, um Daten abzufragen.

Bei Verwendung einer festen Identität ist es üblich, SSO zu deaktivieren, sodass die feste Identität sowohl für Aktualisierungen als auch für Abfragen verwendet wird, es besteht jedoch keine technische Notwendigkeit, dies zu tun.

Hier sind empfohlene Methoden für Cloudverbindungen:

  • Wenn alle Benutzer auf die Daten zugreifen können (und dazu berechtigt sind), müssen Sie keine gemeinsame Cloudverbindung erstellen. Stattdessen können die standardmäßigen Cloudverbindungseinstellungen verwendet werden. In diesem Fall wird die Identität des Benutzers verwendet, der das Modell abfragt, falls Abfragen in den DirectQuery-Modus zurückfallen.
  • Stellen Sie eine gemeinsam genutzte Cloudverbindung her, wenn Sie eine festgelegte Identität zum Abfragen von Quelldaten verwenden möchten. Das könnte daran liegen, dass den Benutzenden, die das Semantikmodell abfragen, keine Berechtigung zum Lesen des Lakehouse oder Warehouse gewährt wird. Dieser Ansatz ist besonders relevant, wenn das semantische Modell RLS erzwingt.
  • Wenn Sie eine feste Identität verwenden, verwenden Sie die Option Dienstprinzipal, da sie sicherer und zuverlässiger ist. Das liegt daran, dass es nicht auf ein einzelnes Benutzerkonto oder seine Berechtigungen angewiesen ist und keine Wartung (und Unterbrechung) erforderlich ist, wenn sie ihr Kennwort ändern oder die Organisation verlassen.
  • Wenn der Zugriff von verschiedenen Benutzenden nur auf eine Teilmenge von Daten beschränkt werden muss, erzwingen Sie die Sicherheit auf Zeilenebene nur auf der Semantikmodellebene (sofern möglich). Auf diese Weise profitieren Benutzer von leistungsstarken In-Memory-Abfragen.
  • Vermeiden Sie nach Möglichkeit OLS und CLS, da diese Ansätze zu Fehlern in Berichtsvisuals führen. Fehler können Verwirrung oder Bedenken für Benutzer erzeugen. Für zusammenfassbare Spalten sollten Sie Measures erstellen, die unter bestimmten Bedingungen BLANK anstelle von CLS zurückgeben (sofern möglich).

Verwalten der Sicherheitsrollenmitgliedschaft

Wenn Ihr Direct Lake-Semantikmodell die Sicherheit auf Zeilenebene (Row-Level Security, RLS) erzwingt, müssen Sie möglicherweise die Mitglieder verwalten, die den Sicherheitsrollen zugewiesen sind. Weitere Informationen finden Sie unter Verwalten der Sicherheit in Ihrem Modell.

Festlegen von Fabric-Elementberechtigungen

Die semantischen Direct Lake-Modelle entsprechen einem mehrschichtigen Sicherheitsmodell. Sie führen Berechtigungsprüfungen über den SQL-Analyseendpunkt durch, um festzustellen, ob die Identität, die versucht, auf die Daten zuzugreifen, über die erforderlichen Datenzugriffsberechtigungen verfügt.

Sie müssen Benutzern Berechtigungen erteilen, damit sie das Direct Lake-Semantikmodell verwenden oder verwalten können. Kurz gesagt, benötigen Berichtsanwender die Berechtigung "Lesen", und Berichtsersteller benötigen die Berechtigung "Erstellen". Berechtigungen für Semantikmodelle können direkt zugewiesen werden oder implizit über Arbeitsbereichsrollen erworben werden. Zum Verwalten der Semantikmodelleinstellungen (für Aktualisierung und andere Konfigurationen) müssen Sie der Semantikmodellbesitzersein.

Je nach eingerichteter Cloudverbindung und ob Benutzer den SQL-Analyseendpunkt des Lakehouse oder des Warehouse SQL Analytics-Endpunkts abfragen müssen, müssen Sie möglicherweise andere Berechtigungen erteilen (in der Tabelle in diesem Abschnitt beschrieben).

Anmerkung

Insbesondere benötigen Benutzer keine Berechtigung zum Lesen von Daten in OneLake. Das liegt daran, dass Fabric dem semantischen Modell die erforderlichen Berechtigungen zum Lesen der Delta-Tabellen und zugeordneter Parkettdateien gewährt (um Spaltendaten in den Speicher zu laden). Das semantische Modell verfügt außerdem über die erforderlichen Berechtigungen, um den SQL-Analyseendpunkt regelmäßig zu lesen, um Berechtigungsprüfungen durchzuführen, um zu bestimmen, auf welche Daten der abfrageende Benutzer (oder eine feste Identität) zugreifen kann.

Berücksichtigen Sie die folgenden Szenarien und Berechtigungsanforderungen.

Szenario Erforderliche Berechtigungen Kommentare
Benutzer können Berichte anzeigen • Erteilen Lese- Berechtigung für die Berichte und Lese- Berechtigung für das semantische Modell.
• Wenn die Cloudverbindung SSO verwendet, erteilen Sie mindestens die Leseberechtigung für das Lakehouse oder Warehouse.		 Berichte müssen nicht zum gleichen Arbeitsbereich wie das semantische Modell gehören. Weitere Informationen finden Sie unter Strategie für schreibgeschützte Consumer.
Benutzer können Berichte erstellen • Erteilen Sie die Buildberechtigung für das Semantikmodell.
• Wenn die Cloudverbindung SSO verwendet, erteilen Sie mindestens die Leseberechtigung für das Lakehouse oder Warehouse.		 Weitere Informationen finden Sie unter Strategie für Inhaltsersteller.
Benutzer können das semantische Modell abfragen, jedoch nicht das Lakehouse oder den SQL-Analyseendpunkt. • Erteilen Sie keine Genehmigung für das Seehaus oder Lager. Nur geeignet, wenn die Cloudverbindung eine feste Identität verwendet.
Benutzer können das semantische Modell und den SQL-Analyseendpunkt abfragen, aber die Abfrage des Lakehouse ist nicht erlaubt. • Erteilen Sie Leseberechtigungen und ReadData-Berechtigungen für das Lakehouse oder Warehouse. Wichtige: An den SQL Analytics-Endpunkt gesendete Abfragen umgehen die vom semantischen Modell erzwungenen Datenzugriffsberechtigungen.
Verwalten des semantischen Modells, einschließlich Aktualisierungseinstellungen • Erfordert den Besitz des semantischen Modells. Weitere Informationen finden Sie unter Besitz von Semantikmodellen.

Wichtig

Sie sollten die Berechtigungen immer gründlich testen, bevor Sie Ihr semantisches Modell und Berichte in die Produktion freigeben.

Weitere Informationen finden Sie unter Berechtigungen des semantischen Modells.

Aktualisieren der Direct Lake-Semantikmodelle

Die Aktualisierung eines Direct Lake-Semantikmodells führt zu einem Framingvorgang. Ein Aktualisierungsvorgang kann ausgelöst werden:

  • Manuell durch Ausführen einer bedarfsgesteuerten Aktualisierung im Fabric-Portal, durch Ausführen des TMSL-Befehls (Tabular Model Scripting Language) Refresh über ein Skript in SQL Server Management Studio (SSMS) oder mithilfe eines Drittanbietertools, das über den XMLA-Endpunkt eine Verbindung herstellt
  • Automatisch durch Einrichten eines Aktualisierungszeitplans im Fabric-Portal
  • Automatisch, wenn Änderungen in den zugrunde liegenden Delta-Tabellen erkannt werden – weitere Informationen finden Sie unter Automatische Updates (weiter beschrieben).
  • Programmgesteuert durch Auslösen einer Aktualisierung mithilfe der Power BI-REST-API oder mithilfe von TOM. Sie können eine programmgesteuerte Aktualisierung als letzten Schritt eines Extrakt-, Transformations- und Ladeprozesses (ETL) auslösen.

Automatische Updates

Es gibt eine Einstellung auf Semantikmodellebene mit dem Namen Direct Lake-Daten auf dem neuesten Stand halten, die automatische Updates von Direct Lake-Tabellen durchführt. Sie ist standardmäßig aktiviert. Es stellt sicher, dass Datenänderungen in OneLake automatisch im Direct Lake-Semantikmodell widerspiegelt werden. Die Einstellung ist im Fabric-Portal im Abschnitt Aktualisieren der Semantikmodelleinstellungen verfügbar.

Wenn die Einstellung aktiviert ist, führt das Semantikmodell einen Rahmenvorgang aus, wenn Datenänderungen in zugrunde liegenden Delta-Tabellen erkannt werden. Der Framingvorgang ist immer nur für die Tabellen spezifisch, in denen Datenänderungen erkannt werden.

Es wird empfohlen, die Einstellung eingeschaltet zu lassen, insbesondere, wenn Sie über ein kleines oder mittelgroßes Semantikmodell verfügen. Dies ist besonders hilfreich, wenn Sie über Anforderungen an die Berichterstellung mit geringer Latenz verfügen und Delta-Tabellen regelmäßig geändert werden.

In einigen Fällen möchten Sie möglicherweise automatische Updates deaktivieren. Sie müssen z. B. den Abschluss von Datenvorbereitungsaufträgen oder den ETL-Prozess zulassen, bevor Sie neue Daten für Verbraucher des Semantikmodells verfügbar machen. Wenn diese Option deaktiviert ist, können Sie eine Aktualisierung mithilfe einer programmgesteuerten Methode auslösen (weiter oben beschrieben).

Anmerkung

Power BI setzt automatische Updates aus, wenn während einer Aktualisierung ein nicht behebbarer Fehler auftritt. Ein nicht wiederherstellbarer Fehler kann z. B. auftreten, wenn eine Aktualisierung nach mehreren Versuchen fehlschlägt. Stellen Sie daher sicher, dass Ihr Semantikmodell erfolgreich aktualisiert werden kann. Power BI setzt automatische Updates automatisch fort, wenn eine nachfolgende On-Demand-Aktualisierung ohne Fehler abgeschlossen ist.

Aufwärmen des Cache

Ein Aktualisierungsvorgang für Direct Lake-Semantikmodelle kann alle residenten Spalten aus dem Arbeitsspeicher entfernen. Dies bedeutet, dass es bei den ersten Abfragen nach einer Aktualisierung eines Direct Lake-Semantikmodells zu einer Verzögerung kommen kann, da Spalten in den Speicher geladen werden. Verzögerungen können nur dann spürbar sein, wenn Sie extrem große Datenmengen haben.

Um solche Verzögerungen zu vermeiden, erwägen Sie, den Cache programmgesteuert zu erwärmen, indem sie eine Abfrage an das semantische Modell senden. Eine bequeme Möglichkeit, um eine Abfrage zu senden, besteht darin, den semantischen Linkzu verwenden. Dieser Vorgang sollte unmittelbar nach Abschluss des Aktualisierungsvorgangs ausgeführt werden.

Wichtig

Das Erwärmen des Caches kann nur dann sinnvoll sein, wenn Verzögerungen inakzeptabel sind. Achten Sie darauf, Daten nicht unnötig in den Speicher zu laden, da dies zu einer Auslastung anderer Kapazitätsworkloads und dazu führen kann, dass diese gedrosselt werden oder ihre Priorität heruntergestuft wird.

Festlegen der Direct Lake-Verhaltenseigenschaft

Sie können den Fallback Ihrer Direct Lake-Semantikmodelle steuern, indem Sie seine DirectLakeBehavior-Eigenschaft festlegen. Sie kann auf Folgendes festgelegt werden:

  • Automatic: (Standardeinstellung) Abfragen greifen auf den DirectQuery-Modus zurück, wenn die erforderlichen Daten nicht effizient in den Speicher geladen werden können.
  • DirectLakeOnly: Alle Abfragen verwenden nur den Direct Lake-Speichermodus. Der Fallback auf den DirectQuery-Modus ist deaktiviert. Wenn Daten nicht in den Arbeitsspeicher geladen werden können, wird ein Fehler zurückgegeben.
  • DirectQueryOnly: Alle Abfragen verwenden nur den DirectQuery-Modus. Verwenden Sie diese Einstellung, um die Fallbackleistung zu testen, wobei Sie beispielsweise die Abfrageleistung in verbundenen Berichten beobachten können.

Sie können die Eigenschaft in der Webmodellierungsumgebungfestlegen oder mithilfe des Tabular Object Model (TOM) oder der Tabular Model Scripting Language (TMSL).

Tipp

Erwägen Sie das Deaktivieren von DirectQuery-Fallbacks, wenn Sie Abfragen nur im Direct Lake-Speichermodus verarbeiten möchten. Es wird empfohlen, fallback zu deaktivieren, wenn Sie nicht auf DirectQuery zurückgreifen möchten. Es kann auch hilfreich sein, wenn Sie die Abfrageverarbeitung für ein Direct Lake-Semantikmodell analysieren möchten, um festzustellen, ob und wie oft Fallback auftritt.

Überwachen der Direct Lake-Semantikmodelle

Sie können ein Direct Lake-Semantikmodell überwachen, um die Leistung visueller DAX-Abfragen des Berichts zu ermitteln oder zu bestimmen, wann es auf den DirectQuery-Modus zurückfällt.

Sie können Performance Analyzer, SQL Server Profiler, Azure Log Analytics oder ein Open Source-, Communitytool wie DAX Studio verwenden.

Leistungsanalyse

Sie können Performance Analyzer- in Power BI Desktop verwenden, um die Verarbeitungszeit aufzuzeichnen, die zum Aktualisieren von Berichtselementen erforderlich ist, die aufgrund einer Benutzerinteraktion initiiert wurden, die zur Ausführung einer Abfrage führt. Wenn die Überwachungsergebnisse eine DirectQuery Metrik anzeigen, bedeutet dies, dass die DAX-Abfragen im DirectQuery-Modus verarbeitet wurden. In Abwesenheit dieser Metrik wurden die DAX-Abfragen im Direct Lake-Modus verarbeitet.

Weitere Informationen finden Sie unter Analysieren mithilfe von Performance Analyzer.

SQL Server Profiler

Sie können SQL Server Profiler- verwenden, um Details zur Abfrageleistung abzurufen, indem Sie Abfrageereignisse nachverfolgen. Sie wird mit SQL Server Management Studio (SSMS)installiert. Bevor Sie beginnen, stellen Sie sicher, dass Die neueste Version von SSMS installiert ist.

Weitere Informationen finden Sie unter Analysieren mithilfe von SQL Server Profiler.

Wichtig

Im Allgemeinen bietet der Direct Lake-Speichermodus eine schnelle Abfrageleistung, es sei denn, ein Fallback auf den DirectQuery-Modus ist erforderlich. Da sich der Fallback auf den DirectQuery-Modus auf die Abfrageleistung auswirken kann, ist es wichtig, die Abfrageverarbeitung für ein Direct Lake-Semantikmodell zu analysieren, um festzustellen, ob, wie oft und warum Fallbacks auftreten.

Azure Log Analytics (Protokollanalyse)

Sie können Azure Log Analytics- verwenden, um Telemetriedaten zu sammeln, zu analysieren und zu verarbeiten, die einem Direct Lake-Semantikmodell zugeordnet sind. Es ist ein Dienst in Azure Monitor, den Power BI zum Speichern von Aktivitätsprotokollen verwendet.

Weitere Informationen finden Sie unter Verwenden von Azure Log Analytics in Power BI.

Verwandte Inhalte