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 die Datenermittlung auch einrichten, um Berichtserstellern das Lesen von Metadaten zu ermöglichen, die Daten im OneLake-Datenhub zu ermitteln und den Zugriff darauf anzufordern. Sie können auch das semantische Modell unterstützen (zertifiziert oder höhergestuft), um zu kommunizieren, dass es Qualitätsdaten für die Verwendung darstellt.

Einrichten der Cloudverbindung

Ein Semantikmodell mit Direct Lake verwendet eine Cloudverbindung, um eine Verbindung mit dem SQL-Analyseendpunkt herzustellen. Er ermöglicht den Zugriff auf Quelldaten, die entweder die Parkettdateien in OneLake (Direct Lake-Speichermodus, bei dem Spaltendaten in den Speicher geladen werden) oder den SQL-Analyseendpunkt (wenn Abfragen auf den DirectQuery-Modus zurückfallen ).

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.

Sharable 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 mit den vorgesehenen Erstellern für die zentrale Zugriffsverwaltung teilen.

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

Authentifizierung

Die feste Identität kann mithilfe von OAuth 2.0 oder dienstprinzipal authentifiziert werden.

Hinweis

Es wird nur die Microsoft Entra Authentifizierung 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).

Dienstprinzipal

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 der SQL Analytics-Endpunkttabellen und -Ansichten und Schemametadaten verfügen.

Für die Kontinuität können die Dienstprinzipalanmeldeinformationen durch die Drehung des geheimen Schlüssels/Zertifikats verwaltet werden.

Hinweis

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

Einmaliges Anmelden

Wenn Sie eine freigegebene Cloudverbindung erstellen, ist das Kontrollkästchen für 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, dies ist jedoch nicht erforderlich.

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 sollte die Identität des Benutzers, der das Modell abfragt, abfragen, auf den DirectQuery-Modus zurückgreifen.
  • Erstellen Sie eine freigegebene Cloudverbindung, wenn Sie eine feste Identität zum Abfragen von Quelldaten verwenden möchten. Das könnte daran liegen, dass den Benutzern, die das Semantikmodell abfragen, keine Berechtigung zum Lesen des Lakehouse oder Warehouse gewährt werden. Dieser Ansatz ist besonders relevant, wenn das semantische Modell RLS erzwingt.
  • Wenn Sie eine feste Identität verwenden, verwenden Sie die Dienstprinzipaloption , 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 unterschiedliche Benutzer nur auf Teilmengen von Daten zugreifen müssen, wenn dies praktikabel ist, erzwingen Sie RLS nur auf der Semantikmodellebene. Auf diese Weise profitieren Benutzer von leistungsstarken In-Memory-Abfragen.
  • Vermeiden Sie nach Möglichkeit OLS und CLS, da sie zu Fehlern in grafischen Berichten führt. Fehler können Verwirrung oder Bedenken für Benutzer erzeugen. Für zusammenfassende Spalten sollten Sie Maßnahmen erstellen, die BLANK in bestimmten Bedingungen anstelle von CLS (sofern möglich) zurückgeben.

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 von Sicherheit auf 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, dass Verbraucher von Berichten Leseberechtigung benötigen, und Berichtsersteller benötigen Build-Berechtigung. Semantische Modellberechtigungen können direkt oder implizit über Arbeitsbereichsrollen zugewiesen werden. Zum Verwalten der Semantikmodelleinstellungen (für Aktualisierungen und andere Konfigurationen) müssen Sie der Besitzer des semantischen Modells sein.

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

Hinweis

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 der Leseberechtigung für die Berichte und Leseberechtigung für das semantische Modell.
• Wenn die Cloudverbindung SSO verwendet, erteilen Sie mindestens leseberechtigung für das Seehaus oder Lager.		 Berichte müssen nicht zum gleichen Arbeitsbereich wie das semantische Modell gehören. Weitere Informationen finden Sie unter Strategie für schreibgeschützte Verbraucher.
Benutzer können Berichte erstellen • Erteilen der Buildberechtigung für das semantische Modell.
• Wenn die Cloudverbindung SSO verwendet, erteilen Sie mindestens leseberechtigung für das Seehaus oder Lager.		 Weitere Informationen finden Sie unter Strategie für Inhaltsersteller.
Benutzer können das semantische Modell abfragen, aber die Abfrage des Lakehouse- oder SQL-Analyseendpunkts verweigert werden. • 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 verweigert werden. • Erteilen von Lese - und ReadData-Berechtigungen für das Seehaus oder Lager. Wichtig: An den SQL-Analyseendpunkt 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 Semantikmodellbesitz.

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 für Semantikmodelle.

Aktualisieren der Direct Lake-Semantikmodelle

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

  • Manuelles Ausführen einer On-Demand-Aktualisierung im Fabric-Portal oder durch Ausführen des Befehls "Tabular Model Scripting Language (TMSL)" über ein Skript in SQL Server Management Studio (SSMS) oder mithilfe eines Drittanbietertools, das über den XMLA-Endpunkt eine Verbindung herstellt.
  • Automatisches 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 unten beschrieben).
  • Programmgesteuert durch Auslösen einer Aktualisierung mithilfe der Power BI-REST-API oder VON TOM. Sie können eine programmgesteuerte Aktualisierung als letzten Schritt eines Extrakt-, Transformations- und Ladeprozesses (ETL) auslösen.

Automatische Aktualisierungen

Es gibt eine Einstellung auf semantischer Modellebene mit dem Namen "Direct Lake-Daten auf dem neuesten Stand halten", die automatische Aktualisierungen von Direct Lake-Tabellen durchführt. Standardmäßig ist sie 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 Rahmenvorgang ist immer spezifisch für nur die Tabellen, in denen Datenmodifizierer erkannt werden.

Es wird empfohlen, die Einstellung zu aktivieren, 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).

Hinweis

Power BI hält automatische Updates an, wenn während der Aktualisierung ein nicht wiederherstellbarer 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.

Warm the cache

Ein Semantikmodellaktualisierungsvorgang des Direct Lake-Modells kann alle residenten Spalten aus dem Arbeitsspeicher entfernen. Dies bedeutet, dass die ersten Abfragen nach einer Aktualisierung eines Direct Lake-Semantikmodells einige Verzögerung erleben könnten, wenn Spalten in den Arbeitsspeicher 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 zu erwärmen , indem Sie programmgesteuert eine Abfrage an das semantische Modell senden. Eine bequeme Möglichkeit zum Senden einer Abfrage besteht darin, semantischen Link zu 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, dass Daten nicht unnötig in den Arbeitsspeicher geladen werden, der druck auf andere Kapazitätsworkloads führen könnte, was dazu führt, dass sie gedrosselt oder entprioritisiert werden.

Festlegen der Direct Lake-Verhaltenseigenschaft

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

  • Automatische: (Standard) Abfragen greifen auf den DirectQuery-Modus zurück, wenn die erforderlichen Daten nicht effizient in den Arbeitsspeicher 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 Webmodellierungsoberfläche oder mithilfe von Tabellarischen Objektmodell (TOM) oder tabellarischen Modellskripting Language (TMSL) festlegen.

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 Leistungsanalyse, SQL Server Profiler, Azure Log Analytics oder ein Open Source-, Community-Tool wie DAX Studio verwenden.

Leistungsanalyse

Sie können Leistungsanalyse 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 Direct-Abfragemetrik 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 Leistungsanalyse.

SQL Server Profiler

Sie können SQL Server Profiler verwenden, um Details zur Abfrageleistung abzurufen, indem Sie Abfrageereignisse nachverfolgen. Es 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

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.

Zugehöriger Inhalt