Freigeben über

Direct Lake-Semantikmodelle verwalten

  • Artikel

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

Aufgaben nach der Veröffentlichung

Nach der ersten Veröffentlichung eines Direct Lake-Semantikmodells, das für die Berichterstellung bereit ist, sollten Sie sofort einige Aufgaben ausführen. Diese Aufgaben können auch jederzeit während des Lebenszyklus des Semantikmodells angepasst werden.

Optional können Sie auch die Datenerkennung einrichten, um Berichtserstellern 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 Direct Lake-Semantikmodell verwendet eine Cloudverbindung mit dem SQL-Analyseendpunkt. Dies ermöglicht den Zugriff auf Quelldaten. Dabei handelt es sich entweder um die Parkettdateien 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).

Standardcloudverbindung

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

Teilbare Cloudverbindung

Sie können optional eine teilbare Cloudverbindung (Sharable Cloud Connection, SCC) erstellen, damit Verbindungen mit der Datenquelle mit einer festen Identität hergestellt werden können. Dies kann Unternehmenskunden dabei helfen, ihre Unternehmensdatenspeicher zu schützen. Die IT-Abteilung kann Anmeldeinformationen verwalten, SCCs erstellen und für die vorgesehenen Erstellern 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 feste Identität kann sich entweder mithilfe von OAuth 2.0 oder eines Dienstprinzipals authentifizieren.

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 von SQL-Analyseendpunkttabellen und -Sichten und Schemametadaten verfügen.

Die Verwendung eines bestimmten Benutzerkontos wird nicht empfohlen. Das liegt daran, dass Semantikmodellabfragen nicht erfolgreich sind, wenn sich das Kennwort ändert oder das Benutzerkonto gelöscht wird (beispielsweise, 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 von SQL-Analyseendpunkttabellen und -Sichten und Schemametadaten verfügen.

Aus Gründen der Kontinuität können die Dienstprinzipalanmeldeinformationen durch Geheimnis- oder Zertifikatrotation 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 teilbare Cloudverbindung erstellen, 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 Semantikmodell 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 technisch jedoch nicht erforderlich.

Hier finden Sie 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, sollten 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 Semantikmodell RLS erzwingt.
  • Nutzen Sie bei Verwendung einer festen Identität die Option Dienstprinzipal, da sie sicherer und zuverlässiger ist. Das liegt daran, dass sie nicht auf ein einzelnes Benutzerkonto oder seine Berechtigungen angewiesen ist und keine Wartung (und Unterbrechung) erforderlich ist, wenn sich das Kennwort ändert oder ein Benutzer die Organisation verlässt.
  • Wenn der Zugriff von verschiedenen Benutzern nur auf eine Teilmenge von Daten beschränkt werden muss, erzwingen Sie RLS nur auf der Semantikmodellebene, falls möglich. Auf diese Weise profitieren Benutzer von Hochleistungs-In-Memory-Abfragen.
  • Vermeiden Sie nach Möglichkeit OLS und CLS, da sie zu Fehlern in Berichtsvisuals führen. 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).

Verwalten der Sicherheitsrollenmitgliedschaft

Wenn Ihr Direct Lake-Semantikmodell 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 Sicherheitseinstellungen Ihres Modells.

Festlegen von Fabric-Elementberechtigungen

Die Direct Lake-Semantikmodelle 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: Berichtsverbraucher benötigen die Leseberechtigung und Berichtsersteller die Buildberechtigung. Berechtigungen für Semantikmodelle können direkt zugewiesen werden oder implizit über Arbeitsbereichsrollen erworben werden. Zum Verwalten der Semantikmodelleinstellungen (für die Aktualisierung und andere Konfigurationen) müssen Sie der Semantikmodellbesitzer sein.

Je nach eingerichteter Cloudverbindung und abhängig davon, ob Benutzer den SQL-Analyseendpunkt des Lakehouse oder des Warehouse abfragen müssen, müssen Sie möglicherweise weitere Berechtigungen erteilen (wie in der Tabelle in diesem Abschnitt beschrieben).

Hinweis

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

Berücksichtigen Sie die folgenden Szenarien und Berechtigungsanforderungen.

Szenario Erforderliche Berechtigungen Kommentare
Besucher können Berichte anzeigen. • Erteilen Sie die Leseberechtigung für die Berichte und die Leseberechtigung für das Semantikmodell.
• Wenn die Cloudverbindung SSO verwendet, erteilen Sie mindestens die Leseberechtigung für das Lakehouse oder Warehouse.		 Berichte müsse nicht zum gleichen Arbeitsbereich wie das Semantikmodell gehören. Weitere Informationen finden Sie unter Strategie für Consumer mit Leseberechtigung.
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 Semantikmodell, aber nicht das Lakehouse oder den SQL-Analyseendpunkt abfragen. • Erteilen Sie keine Berechtigung für das Lakehouse oder Warehouse. Nur geeignet, wenn die Cloudverbindung eine feste Identität verwendet.
Benutzer können das Semantikmodell und den SQL-Analyseendpunkt, aber nicht das Lakehouse abfragen. • Erteilen Sie Leseberechtigungen und ReadData-Berechtigungen für das Lakehouse oder Warehouse. Wichtig: An den SQL-Analyseendpunkt gesendete Abfragen umgehen Datenzugriffsberechtigungen, die vom Semantikmodell erzwungen werden.
Verwalten des Semantikmodells, einschließlich Aktualisierungseinstellungen • Erfordert den Besitz des Semantikmodells. Weitere Informationen finden Sie unter Semantikmodellbesitzer.

Wichtig

Sie sollten Berechtigungen stets gründlich testen, bevor Sie das Semantikmodell und Berichte in der Produktion freigeben.

Weitere Informationen finden Sie unter Berechtigungen für Semantikmodelle.

Aktualisieren von Direct Lake-Semantikmodellen

Die Aktualisierung eines Direct Lake-Semantikmodells führt zu einem Framing-Vorgang. Ein Aktualisierungsvorgang kann wie folgt 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 zugrundeliegenden Delta-Tabellen erkannt werden. Weitere Informationen finden Sie unter Automatische Updates (im nächsten Abschnitt 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 ETL-Prozesses (Extrahieren, Transformieren und Laden) auslösen.

Automatische Aktualisierungen

Es gibt eine Einstellung auf Semantikmodellebene 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. Dadurch wird sichergestellt, dass Datenänderungen in OneLake automatisch im Semantikmodell von Direct Lake berücksichtigt werden. Die Einstellung ist im Fabric-Portal im Abschnitt Aktualisieren der Semantikmodelleinstellungen verfügbar.

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

Es wird empfohlen, die Einstellung aktiviert zu lassen, insbesondere bei einem kleinen oder mittelgroßen Semantikmodell. Sie ist besonders hilfreich, wenn Anforderungen an latenzarme Berichterstellung vorliegen und Delta-Tabellen regelmäßig geändert werden.

In einigen Fällen sollten Sie automatische Updates möglicherweise deaktivieren. Ein Beispiel ist, wenn Sie den Abschluss von Datenaufbereitungsaufträgen oder des ETL-Prozesses zulassen müssen, bevor neue Daten für Consumer des Semantikmodells verfügbar gemacht werden. Wenn diese Option deaktiviert ist, können Sie eine Aktualisierung mithilfe einer programmgesteuerten Methode auslösen (weiter oben beschrieben).

Hinweis

Power BI setzt automatische Updates aus, wenn während einer Aktualisierung ein nicht behebbarer Fehler auftritt. Ein nicht behebbarer 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 Aktualisierungen automatisch fort, wenn eine nachfolgende bedarfsgesteuerte Aktualisierung ohne Fehler abgeschlossen wird.

Aufwärmen des Cache

Ein Aktualisierungsvorgang für Direct Lake-Semantikmodelle kann alle residenten Spalten aus dem Arbeitsspeicher entfernen. Das bedeutet, dass es bei den ersten Abfragen nach einer Aktualisierung eines Direct Lake-Semantikmodells zu einer Verzögerung kommen kann, da Spalten in den Arbeitsspeicher geladen werden. Verzögerungen sind u. U. nur bei extrem großen Datenmengen spürbar.

Um solche Verzögerungen zu vermeiden, wärmen Sie ggf. den Cache auf, indem sie programmgesteuert eine Abfrage an das Semantikmodell senden. Eine Abfrage kann bequem über eine semantische Verknüpfung gesendet werden. Dieser Vorgang sollte unmittelbar nach Abschluss des Aktualisierungsvorgangs ausgeführt werden.

Wichtig

Das Aufwärmen des Cache ist nur sinnvoll, wenn Verzögerungen nicht akzeptabel 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 das Fallback Ihrer Direct Lake-Semantikmodelle über die Einstellung der Eigenschaft DirectLakeBehavior steuern. 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. 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. Dabei können Sie beispielsweise die Abfrageleistung in verbundenen Berichten beobachten.

Sie können die Eigenschaft auf der Webmodellierungsoberfläche oder mithilfe von TOM (Tabular Object Model) oder TMSL (Tabular Model Scripting Language) festlegen.

Tipp

Deaktivieren Sie ggf. das DirectQuery-Fallback, 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 zu ermitteln, ob und wie häufig ein Fallback erfolgt.

Überwachen von Direct Lake-Semantikmodellen

Sie können ein Direct Lake-Semantikmodell überwachen, um die Leistung von DAX-Abfragen für Berichtsvisuals zu ermitteln oder festzustellen, wann ein Fallback auf den DirectQuery-Modus erfolgt.

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

Leistungsanalyse

Sie können die Leistungsanalyse in Power BI Desktop nutzen, um die erforderliche Verarbeitungszeit zur Aktualisierung von Berichtselementen aufzuzeichnen, die infolge einer Benutzerinteraktion initiiert wurde, die zum Ausführen einer Abfrage führt. Wenn in den Überwachungsergebnissen die Metrik Direkte Abfrage angezeigt wird, bedeutet dies, dass die DAX-Abfragen im DirectQuery-Modus verarbeitet wurden. Fehlt diese Metrik, wurden die DAX-Abfragen im Direct Lake-Modus verarbeitet.

Weitere Informationen finden Sie unter Analysieren mithilfe der 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 mit SQL Server Profiler.

Wichtig

Im Allgemeinen ermöglicht der Direct Lake-Speichermodus eine hohe Abfrageleistung, es sei denn, es ist ein Fallback auf den DirectQuery-Modus erforderlich. Da sich ein 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 erfolgen.

Azure Log Analytics

Sie können Azure Log Analytics verwenden, um Telemetriedaten im Zusammenhang mit einem Direct Lake-Semantikmodell zu sammeln, zu analysieren und Aktionen dafür auszuführen. Es handelt sich dabei um einen Dienst in Azure Monitor, den Power BI zum Speichern von Aktivitätsprotokollen verwendet.

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

Zugehöriger Inhalt