Freigeben über

Übersicht über den Direct Lake

Direct Lake ist eine Speichermodusoption für Tabellen in einem Power BI-Semantikmodell, das in einem Microsoft Fabric-Arbeitsbereich gespeichert ist. Es ist für große Datenmengen optimiert, die schnell aus Delta-Tabellen in Den Speicher geladen werden können, die in OneLake gespeichert sind – der einzelne Speicher für alle Analysedaten. Nach dem Laden in den Arbeitsspeicher ermöglicht das Semantikmodell eine interaktive Hochleistungsanalyse.

Diagramm zeigt ein Direct Lake-Semantikmodell und wie es eine Verbindung mit Delta-Tabellen in OneLake herstellt, wie in den vorherigen Absätzen beschrieben.

Direct Lake eignet sich ideal für semantische Modelle, die mit großen Fabric Lakehouses, Warehouses und anderen Quellen mit Delta-Tabellen verbunden sind, insbesondere wenn das Replizieren des gesamten Datenvolumes in ein Importmodell schwierig oder unmöglich ist. Direct Lake-Abfragen werden, wie im Importmodus, vom VertiPaq-Abfrage-Engine verarbeitet, während bei DirectQuery Abfragen an die zugrunde liegende Datenquelle weitergeleitet werden. Dies bedeutet, dass Direct Lake-Abfragen wie der Importmodus normalerweise DirectQuery übertrifft.

Ein Direct Lake unterscheidet sich jedoch von einem Importmodus in einer wichtigen Weise: Ein Aktualisierungsvorgang für ein Direct Lake-Semantikmodell unterscheidet sich konzeptionell von einem Aktualisierungsvorgang für ein Importsemantikmodell. Im Importmodus werden die Daten repliziert und eine gesamte zwischengespeicherte Kopie der Daten für das semantische Modell erstellt, während eine Direct Lake-Aktualisierung nur Metadaten kopiert (wie weiter unten in diesem Artikel beschrieben), was einige Sekunden dauern kann. Die Direct Lake-Aktualisierung ist ein kostengünstiger Vorgang, der die Metadaten der neuesten Version der Delta-Tabellen analysiert und aktualisiert wird, um auf die neuesten Dateien in OneLake zu verweisen. Im Gegensatz dazu erzeugt eine Importaktualisierung eine Kopie der Daten, die erhebliche Zeit in Anspruch nehmen und erhebliche Datenquellen- und Kapazitätsressourcen (Arbeitsspeicher und CPU) verbrauchen kann. Direct Lake verschiebt die Datenvorbereitung auf OneLake und verwendet dabei die gesamte Breite der Fabric-Technologien für die Datenvorbereitung, einschließlich Spark-Aufträge, T-SQL-DML-Anweisungen, Datenflüsse, Pipelines und vieles mehr.

Der Direct Lake-Speichermodus bietet die folgenden wichtigsten Vorteile:

  • Ähnlich wie im Importmodus werden Direct Lake-Abfragen vom VertiPaq-Modul verarbeitet und stellen somit die Abfrageleistung bereit, die mit dem Importmodus vergleichbar ist, ohne dass der Verwaltungsaufwand für Datenaktualisierungszyklen zum Laden des gesamten Datenvolumes besteht.
  • Verwendet vorhandene Fabric-Investitionen, indem sie nahtlos in große Seehäuser, Lagerhäuser und andere Fabric-Quellen mit Delta-Tabellen integriert werden. Beispielsweise ist Direct Lake eine ideale Wahl für die Goldanalyseschicht in der Medallion Lakehouse-Architektur.
  • Maximiert die Rendite (Return on Investment, ROI), da analysierte Datenvolumes die maximalen Speichergrenzwerte der Kapazität überschreiten können, da nur die Daten, die zum Beantworten einer Abfrage benötigt werden, in den Arbeitsspeicher geladen werden.
  • Minimiert die Datenlatenz, indem ein semantisches Modell schnell und automatisch mit seinen Quellen synchronisiert wird und neue Daten für Geschäftsbenutzer ohne Aktualisierungszeitpläne zur Verfügung gestellt werden.

Wann sollten Sie den Direct Lake-Speichermodus verwenden?

Der primäre Anwendungsfall für den Direct Lake Speichermodus sind normalerweise IT-gesteuerte Analyseprojekte, die lake-zentrierte Architekturen verwenden. In solchen Szenarien haben Oder erwarten Sie, dass große Datenmengen in OneLake gesammelt werden. Das schnelle Laden dieser Daten in den Arbeitsspeicher, häufige und schnelle Aktualisierungsvorgänge, die effiziente Nutzung von Kapazitätsressourcen und die schnelle Abfrageleistung sind für diesen Anwendungsfall wichtig.

Anmerkung

Import- und DirectQuery-Semantikmodelle sind weiterhin in Fabric relevant, und sie sind die richtige Wahl des semantischen Modells für einige Szenarien. Der Importspeichermodus eignet sich z. B. häufig gut für einen Self-Service-Analysten, der die Freiheit und Flexibilität benötigt, um schnell und ohne Abhängigkeit von der IT zu handeln, um neue Datenelemente hinzuzufügen.

Außerdem schreibt die OneLake-Integration automatisch Daten für Tabellen im Importspeichermodus in Delta-Tabellen in OneLake ohne Migrationsaufwand, sodass Sie viele der Vorteile von Fabric erkennen können, die Benutzern des Importsemantikmodells zur Verfügung gestellt werden, z. B. die Integration mit Lakehouses über Verknüpfungen, SQL-Abfragen, Notizbücher usw. Wir empfehlen diese Option als schnelle Möglichkeit, die Vorteile von Fabric zu nutzen, ohne unbedingt oder sofort Ihr vorhandenes Data Warehouse und/oder Analysesystem neu zu gestalten.

Direct Lake hängt davon ab, dass die Datenvorbereitung im Datensee erfolgt. Die Datenvorbereitung kann mithilfe verschiedener Tools erfolgen, z. B. Spark-Aufträge für Fabric Lakehouses, T-SQL DML-Anweisungen für Fabric Warehouses, Dataflows, Pipelines und andere, wodurch sichergestellt wird, dass die Datenvorbereitungslogik in der Architektur vorgelagert durchgeführt wird, um die Wiederverwendbarkeit zu maximieren. Wenn der Autor des semantischen Modells jedoch nicht in der Lage ist, das Quellelement zu ändern, z. B. wenn ein Self-Service-Analyst keine Schreibberechtigungen für ein Lakehouse hat, das von der IT verwaltet wird, kann das Erweitern des Modells mit Tabellen im Importmodus eine gute Wahl sein, da der Importmodus die Datenvorbereitung mithilfe von Power Query unterstützt, das als Teil des semantischen Modells definiert ist.

Achten Sie darauf, dass Sie Ihre aktuelle Fabric-Kapazitätslizenz und die Fabric-Kapazitätsschutzschienen berücksichtigen, wenn Sie den Direct Lake-Speichermodus in Betracht ziehen. Berücksichtigen Sie auch die Überlegungen und Einschränkungen, die weiter unten in diesem Artikel beschrieben werden.

Tipp

Es wird empfohlen, einen Prototypoder einen Machbarkeitsnachweis (POC) zu erstellen, um zu bestimmen, ob ein Direct Lake-Semantikmodell die richtige Lösung ist und um Risiken zu minimieren.

Kernkonzepte und Terminologie

In diesem Artikel wird vorausgesetzt, dass Sie mit den folgenden Konzepten vertraut sind:

  • Benutzer interagieren mit visuellen Elementen in Power BI-Berichten, die DAX-Abfragen für das semantische Modell generieren.
  • Speichermodus: Das semantische Modell verarbeitet die DAX-Abfragen je nach verwendeter Speichermodus unterschiedlich. Beispiel:
    • Import- und Direct Lake-Speichermodi verwenden das VertiPaq-Modul, um DAX-Abfragen zu verarbeiten und Ergebnisse an den Power BI-Bericht und den Benutzer zurückzugeben.
    • DirectQuery übersetzt dagegen DAX-Abfragen in die Abfragesyntax der Datenquelle (in der Regel eine Form von SQL) und verknüpft sie mit der zugrunde liegenden Datenbank. Quelldatenbankabfrageprozessoren sind häufig nicht auf BI-stilbezogene, aggregierte Abfragen ausgerichtet und führen daher zu langsamerer Leistung und reduzierter Benutzerinteraktivität im Vergleich zu Import- und Direct Lake-Modi.

Der Speichermodus ist eine Eigenschaft einer Tabelle im semantischen Modell. Wenn ein semantisches Modell Tabellen mit verschiedenen Speichermodi enthält, wird es als zusammengesetztes Modell bezeichnet. Weitere Informationen zu Speichermodi finden Sie unter Semantikmodellmodi im Power BI-Dienst.

  • Der Direct Lake-Modus kann zwei verschiedene Zugriffsmethoden verwenden:

    • Direct Lake auf OneLake hängt nicht von SQL-Endpunkten ab und kann Daten aus jeder Fabric-Datenquelle mit Delta-Tabellen verwenden. Direct Lake auf OneLake fällt nicht auf den DirectQuery-Modus zurück.

    Anmerkung

    Direct Lake auf OneLake befindet sich derzeit in der öffentlichen Vorschau.

    • Direct Lake auf SQL-Endpunkten verwendet den SQL-Endpunkt eines Fabric-Lakehouse oder -Warehouse für die Delta-Tabellenermittlung und Berechtigungsprüfungen. Direct Lake auf SQL-Endpunkten kann auf den DirectQuery-Modus zurückgreifen, wenn die Daten nicht direkt aus einer Delta-Tabelle geladen werden können, z. B. wenn die Datenquelle eine SQL-Ansicht ist oder wenn das Warehouse SQL-basierte Row-Level Security (RLS) verwendet. Direct Lake auf SQL-Endpunkten ist allgemein verfügbar und wird in der Produktion vollständig unterstützt.

Vergleich der Speichermodi

In der folgenden Tabelle wird der Direct Lake-Speichermodus mit dem Import- und DirectQuery-Speichermodus verglichen.

Fähigkeit Direkter See auf OneLake Direct Lake auf SQL-Endpunkten Importieren Direktabfrage
Zulassung Nur Fabric-Kapazitätsabonnement (SKUs) Nur Fabric-Kapazitätsabonnement (SKUs) Beliebige Fabric- oder Power BI-Lizenz (einschließlich Microsoft Fabric Free-Lizenzen) Beliebige Fabric- oder Power BI-Lizenz (einschließlich Microsoft Fabric Free-Lizenzen)
Datenquelle Tabellen einer beliebigen Fabric-Datenquelle, die von Delta-Tabellen unterstützt werden Nur Lakehouse- oder Warehousetabellen (oder Ansichten) Jeder Verbinder Jeder Connector, der den DirectQuery-Modus unterstützt
Herstellen einer Verbindung mit SQL Analytics-Endpunktansichten Nein Ja – wird aber automatisch auf den DirectQuery-Modus zurückgesetzt Ja Ja
Zusammengesetzte Modelle Nein 1 Nein 1 Ja – kann mit DirectQuery- oder Dual-Speicher-Modus-Tabellen kombiniert werden Ja – kann mit Tabellen im Import- oder Dual-Speichermodus kombiniert werden
Einmaliges Anmelden (Single Sign-On, SSO) Ja Ja Nicht zutreffend Ja
Berechnete Tabellen Ja – Aber Berechnungen können nicht auf Tabellenspalten im Direct Lake-Modus verweisen. Nein – außer Berechnungsgruppen, Was-wäre-wenn-Parameterund Feldparameter, die implizit berechnete Tabellen erstellen Ja Nein – Berechnete Tabellen verwenden den Importspeichermodus auch dann, wenn sie auf andere Tabellen im DirectQuery-Modus verweisen
Berechnete Spalten Ja – Aber Berechnungen können nicht auf Tabellenspalten im Direct Lake-Modus verweisen. Nein Ja Ja
Hybridtabellen Nein Nein Ja Ja
Modelltabellenpartitionen Nein – Partitionierung kann jedoch auf Delta-Tabellenebene erfolgen Nein – Partitionierung kann jedoch auf Delta-Tabellenebene erfolgen Ja – entweder automatisch durch inkrementelle Aktualisierung oder manuell mithilfe des XMLA-Endpunkts erstellt Nein
Benutzerdefinierte Aggregationen Nein Nein Ja – Das Importieren von Aggregationstabellen in DirectQuery-Tabellen wird unterstützt. Ja
Sicherheit auf Sql Analytics-Endpunktebene oder Sicherheit auf Spaltenebene Nein Ja – kann jedoch Fehler erzeugen, wenn die Berechtigung verweigert wird Ja – muss jedoch Berechtigungen mit Sicherheit auf Objektebene auf Semantikmodellebene duplizieren Ja – Aber Abfragen können Fehler erzeugen, wenn die Berechtigung verweigert wird
Sicherheit auf SQL Analytics-Endpunktzeilenebene (RLS) Nein Ja – Aber Abfragen werden auf den DirectQuery-Modus zurückgesetzt Ja – muss jedoch Berechtigungen mit Semantikmodell-RLS duplizieren Ja
Sicherheit auf Semantikmodellzeilenebene (RLS) Ja – es wird jedoch dringend empfohlen, eine feste Identität Cloudverbindung zu verwenden. Ja – es wird jedoch dringend empfohlen, eine feste Identität Cloudverbindung zu verwenden. Ja Ja
Sicherheit auf Semantikmodellobjektebene (OLS) Ja Ja Ja Ja
Große Datenvolumes ohne Aktualisierungsanforderung Ja Ja Nein Ja
Verringern der Datenlatenz Ja – wenn automatische Updates aktiviert sind oder programmgesteuertes Reframing Ja – wenn automatische Updates aktiviert sind oder programmgesteuertes Reframing Nein Ja
Power BI Eingebettet Ja 2 Ja 2 Ja Ja

1 Wenn Sie Direct Lake auf SQL-Endpunkten verwenden, können Sie Tabellen im Direct Lake-Speichermodus nicht mit DirectQuery- oder Dual-Speichermodustabellen im selben Semantikmodell kombinieren. Sie können power BI Desktop jedoch verwenden, um ein zusammengesetztes Modell in einem Direct Lake-Semantikmodell zu erstellen und es dann mit neuen Tabellen (mithilfe des Import-, DirectQuery- oder Dual-Speichermodus) oder Berechnungen zu erweitern. Weitere Informationen finden Sie unter Erstellen eines zusammengesetzten Modells auf einem semantischen Modell.

2 Erfordert ein V2-Embed-Token. Wenn Sie einen Dienstprinzipal verwenden, müssen Sie eine Cloudverbindung mit fester Identität verwenden.

Funktionsweise von Direct Lake

In der Regel werden Abfragen, die an ein Direct Lake-Semantikmodell gesendet werden, aus einem Speichercache der Spalten verarbeitet, die aus Delta-Tabellen stammen. Der zugrunde liegende Speicher für eine Delta-Tabelle besteht aus einer oder mehreren Parquet-Dateien in OneLake. Parquet-Dateien organisieren Daten spaltenweise und nicht zeilenweise. Semantische Modelle laden ganze Spalten aus Delta-Tabellen in den Arbeitsspeicher, da sie von Abfragen benötigt werden.

Direct Lake auf OneLake ist nicht mit dem SQL-Endpunkt gekoppelt und bietet eine engere Integration in OneLake-Features wie OneLake-Sicherheit und effizientere DAX-Abfragepläne, da beispielsweise die Überprüfung auf SQL-basierte Sicherheit nicht erforderlich ist. DirectQuery-Fallback wird von Direct Lake auf OneLake nicht unterstützt.

Bei Direct Lake auf SQL-Endpunkten kann eine DAX-Abfrage DirectQuery-Fallback verwenden, was einen nahtlosen Wechsel zum DirectQuery-Modus erfordert. Beim DirectQuery-Fallback werden Daten direkt vom SQL-Analyse-Endpunkt des Lakehouse oder des Warehouse abgerufen. Fallback tritt beispielsweise auf, wenn sql-basierte Sicherheit im SQL-Endpunkt erkannt wird. In diesem Fall sendet ein DirectQuery-Vorgang eine Abfrage an den SQL-Analyseendpunkt. Fallbackvorgänge können zu einer langsameren Abfrageleistung führen.

In den folgenden Abschnitten werden Direct Lake-Konzepte und -Features beschrieben, einschließlich Spaltenladevorgang, Rahmen, automatische Updates und DirectQuery-Fallback.

Laden von Spalten (Transcodierung)

Direct Lake-Semantikmodelle laden Daten aus OneLake nur dann, wenn Spalten zum ersten Mal abgefragt werden. Der Prozess des Ladens von Daten auf Abruf von OneLake wird als Transcodierung bezeichnet.

Wenn das semantische Modell eine DAX-Abfrage (oder eine MDX-Abfrage) empfängt, bestimmt es zuerst, welche Spalten erforderlich sind, um ein Abfrageergebnis zu erzeugen. Jede Spalte, die direkt in der Abfrage verwendet wird, wird benötigt, ebenso wie Spalten, die aufgrund von Beziehungen und Maßnahmen erforderlich sind. In der Regel ist die Anzahl der Spalten, die zum Erstellen eines Abfrageergebnisses erforderlich sind, wesentlich kleiner als die Anzahl der spalten, die im semantischen Modell definiert sind.

Sobald es versteht, welche Spalten benötigt werden, bestimmt das Semantikmodell, welche Spalten sich bereits im Arbeitsspeicher befinden. Wenn spalten, die für die Abfrage benötigt werden, nicht im Arbeitsspeicher enthalten sind, lädt das semantische Modell alle Daten für diese Spalten aus OneLake. Das Laden von Spaltendaten ist in der Regel ein schneller Vorgang, kann jedoch von Faktoren wie der Kardinalität der in den Spalten gespeicherten Daten abhängen.

Spalten, die in den Speicher geladen wurden, residieren dann im Speicher. Zukünftige Abfragen, die nur residente Spalten umfassen, müssen keine weiteren Spalten in den Arbeitsspeicher laden.

Eine Spalte residiert so lange im Speicher, bis es einen Grund gibt, sie aus dem Speicher zu entfernen (zu löschen). Gründe für das Entfernen von Spalten sind:

  • Das Modell oder die Tabelle wurde nach einem Delta-Tabellen-Update an der Quelle aktualisiert (siehe Framing im nächsten Abschnitt).
  • Die Spalte wurde seit einiger Zeit nicht mehr von Abfragen verwendet.
  • Andere Ursachen für die Speicherverwaltung, einschließlich des Speicherdrucks in der Kapazität aufgrund anderer gleichzeitiger Vorgänge.

Die Wahl der Fabric-SKU bestimmt den maximal verfügbaren Arbeitsspeicher für jedes Direct Lake-Semantikmodell innerhalb der Kapazität. Weitere Informationen zu Ressourcenschutzmaßnahmen und maximalen Speichergrenzwerten finden Sie unter Fabric-Kapazitätsschienen und Beschränkungen weiter unten in diesem Artikel.

Einrahmung

Framing bietet Modellbesitzern die zeitpunktbezogene Kontrolle darüber, welche Daten in das semantische Modell geladen werden. Framing ist ein Direct Lake-Prozess, der durch die Aktualisierung eines semantischen Modells ausgelöst wird. In den meisten Fällen dauert es nur ein paar Sekunden, bis er abgeschlossen ist. Das liegt daran, dass es sich um einen kostengünstigen Vorgang handelt, bei dem das Semantikmodell die Metadaten der neuesten Version der Delta Lake-Tabellen analysiert und aktualisiert wird, um auf die neuesten Parkettdateien in OneLake zu verweisen.

Wenn Framing auftritt, werden residente Tabellenspaltensegmente und Wörterbücher möglicherweise aus dem Speicher entfernt, wenn sich die zugrunde liegenden Daten geändert haben, und der Zeitpunkt der Aktualisierung zur neuen Baseline für alle zukünftigen Transcodierungsereignisse. Ab diesem Zeitpunkt betrachten Direct Lake-Abfragen nur Daten in den Delta-Tabellen ab dem Zeitpunkt des letzten Rahmenvorgangs. Aus diesem Grund werden Direct Lake-Tabellen abgefragt, um Daten basierend auf dem Status der Delta-Tabelle zum Zeitpunkt der letzten Rahmenoperationzurückzugeben. Diese Zeit ist nicht notwendigerweise der neueste Zustand der Delta-Tabellen.

Das semantische Modell analysiert das Delta-Protokoll jeder Delta-Tabelle während des Prozesses, um nur die betroffenen Spaltensegmente zu entfernen und neu hinzugefügte Daten während der Transcodierung neu zu laden. Eine wichtige Optimierung besteht darin, dass Wörterbücher üblicherweise nicht gelöscht werden, wenn die inkrementelle Rahmung wirksam wird. Stattdessen werden neue Werte den vorhandenen Wörterbüchern hinzugefügt. Dieser inkrementelle Rahmenansatz trägt dazu bei, die Nachladebelastung zu reduzieren und die Abfrageleistung zu verbessern. Im idealen Fall, wenn eine Delta-Tabelle keine Aktualisierungen erhalten hat, ist kein Erneutes Laden für Spalten erforderlich, die bereits im Arbeitsspeicher vorhanden sind, und Abfragen zeigen deutlich weniger Leistungseinbußen nach dem Framing, da die inkrementelle Framing im Wesentlichen das Semantikmodell ermöglicht, wesentliche Teile der vorhandenen In-Memory-Daten an Ort und Stelle zu aktualisieren.

Im folgenden Diagramm wird die Funktionsweise des Direct Lake-Framings dargestellt.

Im Diagramm wird dargestellt, wie das Direct Lake-Framing funktioniert.

Das Diagramm zeigt die folgenden Prozesse und Features.

Element Beschreibung
Ein semantisches Modell ist in einem Fabric-Arbeitsbereich vorhanden.
Die Framingvorgänge finden regelmäßig statt und bilden die Grundlage für alle zukünftigen Transcodierungsereignisse. Framingvorgänge können automatisch, manuell, planmäßig oder programmgesteuert ausgeführt werden.
OneLake speichert Metadaten- und Parkettdateien, die als Delta-Tabellen dargestellt werden.
Der letzte Framingvorgang umfasst Parquet-Dateien, die mit den Delta-Tabellen verknüpft sind, und insbesondere die Parquet-Dateien, die vor dem letzten Framingvorgang hinzugefügt wurden.
Ein späterer Framing-Vorgang umfasst Parquet-Dateien, die nach dem letzten Framing-Vorgang hinzugefügt wurden.
Die residenten Spalten im Semantikmodell von Direct Lake können aus dem Speicher entfernt werden, und der Zeitpunkt der Aktualisierung wird zur neuen Basislinie für alle zukünftigen Transcodierungsereignisse.
Nachfolgende Datenänderungen, die durch neue Parquet-Dateien dargestellt werden, sind erst beim nächsten Framingvorgang sichtbar.

Es ist nicht immer wünschenswert, Daten zu haben, die den neuesten Status einer Delta-Tabelle darstellen, wenn ein Transcodierungsvorgang stattfindet. Beachten Sie, dass die Rahmenerstellung Ihnen helfen kann, konsistente Abfrageergebnisse in Umgebungen bereitzustellen, in denen Daten in Delta-Tabellen vorübergehend sind. Daten können aus mehreren Gründen vorübergehend sein, z. B. wenn lange ausgeführte Extrakt-, Transformations- und Ladeprozesse (ETL) auftreten.

Die Aktualisierung für ein Direct Lake-Semantikmodell kann manuell, automatisch oder programmgesteuert erfolgen. Weitere Informationen finden Sie unter Refresh Direct Lake-Semantikmodelle.

Automatische Updates

Es gibt eine Einstellung auf Semantikmodellebene, um Direct Lake-Tabellen automatisch zu aktualisieren. Sie ist standardmäßig aktiviert. Es stellt sicher, dass Datenänderungen in OneLake automatisch im Direct Lake-Semantikmodell widerspiegelt werden. Sie sollten automatische Updates deaktivieren, wenn Sie Datenänderungen durch Framing steuern möchten, die im vorherigen Abschnitt erläutert wurde. Weitere Informationen finden Sie unter Verwalten von Direct Lake-Semantikmodellen.

Tipp

Sie können die automatische Seitenaktualisierung in Ihren Power BI-Berichten einrichten. Es ist eine Funktion, die automatisch eine bestimmte Berichtsseite aktualisiert, sofern der Bericht eine Verbindung mit einem Direct Lake-Semantikmodell (oder anderen Arten von Semantikmodell) verbindet.

DirectQuery-Fallback

Wenn Sie Direct Lake auf SQL-Endpunkten verwenden, kann eine an ein Direct Lake-Semantikmodell gesendete Abfrage auf den DirectQuery-Modus zurückgreifen, in diesem Fall wird die Tabelle nicht mehr im Direct Lake-Modus ausgeführt. Sie ruft Daten direkt vom SQL-Analyseendpunkt des Lakehouses oder Datenlagers ab. Solche Abfragen geben immer die neuesten Daten zurück, da sie nicht auf den Zeitpunkt des letzten Rahmenvorgangs beschränkt sind.

Wenn DirectQuery-Fallback auftritt, verwendet eine Abfrage nicht mehr den Direct Lake-Modus. Eine Abfrage kann den Direct Lake-Modus nicht nutzen, wenn das semantische Modell eine Ansicht im SQL-Analyseendpunkt abfragt, oder eine Tabelle im SQL-Analyseendpunkt, die die Sicherheit auf Zeilenebene (RLS) erzwingt. Außerdem kann eine Abfrage den Direct Lake-Modus nicht nutzen, wenn eine Delta-Tabelle die Grenzwerte der Kapazität überschreitet.

Wichtig

Wenn möglich, sollten Sie Ihre Lösung – oder ihre Kapazität – immer entwerfen, um DirectQuery-Fallback zu vermeiden. Das liegt daran, dass sie zu einer langsameren Abfrageleistung führen kann.

Sie können das Fallback-Verhalten Ihrer Direct Lake-Semantikmodelle steuern, indem Sie die DirectLakeBehavior-Eigenschaft festlegen. Diese Einstellung gilt nur für Direct Lake auf SQL-Endpunkten. Direct Lake auf OneLake unterstützt kein DirectQuery-Fallback. Weitere Informationen finden Sie unter Festlegen der Direct Lake-Verhaltenseigenschaft.

Datensicherheit und Zugriffsberechtigungen

Direct Lake verwendet standardmäßig einmaliges Anmelden (Single Sign-On, SSO), was bedeutet, dass die Identität, die das semantische Modell (häufig ein Berichtsbenutzer) abfragt, für den Zugriff auf die Daten autorisiert werden muss. Alternativ können Sie ein Direct Lake-Modell an eine sharable Cloud-Verbindung (SCC) binden, um eine feste Identität bereitzustellen und SSO zu deaktivieren. In diesem Fall erfordert nur die feste Identität Lesezugriff auf die Daten in der Quelle.

Berechtigungen für Fabric-Elemente

Die semantischen Direct Lake-Modelle entsprechen einem mehrschichtigen Sicherheitsmodell. Sie führen Berechtigungsprüfungen durch, um festzustellen, ob die Identität, die versucht, auf die Daten zuzugreifen, über die erforderlichen Datenzugriffsberechtigungen im Quelldatenelement und im Semantikmodell verfügt. Berechtigungen können direkt oder implizit mithilfe von Arbeitsbereichsrollen in Microsoft Fabric zugewiesen werden.

Es ist wichtig zu wissen, dass Direct Lake auf OneLake- und Direct Lake auf SQL-Endpunkten Berechtigungsprüfungen unterschiedlich durchführt.

  • Direct Lake auf OneLake erfordert Lese - und ReadAll-Berechtigungen im Lakehouse/Warehouse, um auf Delta-Tabellen zuzugreifen.
  • Direct Lake auf SQL-Endpunkten erfordert Lese - und ReadData-Berechtigungen im Lakehouse/Warehouse für den Zugriff auf Daten vom SQL-Analyseendpunkt.

Anmerkung

Direct Lake auf OneLake erfordert, dass Benutzer über die Berechtigung zum Lesen von Delta-Tabellen in OneLake verfügen müssen, aber nicht unbedingt über die Berechtigung für den SQL-Endpunkt. Dadurch wird ein zentralisiertes Sicherheitsdesign erzwungen, bei dem OneLake die einzige Quelle der Zugriffssteuerung ist.

Direct Lake auf SQL-Endpunkten erfordert andererseits, dass Benutzer Lesezugriff auf den SQL-Endpunkt und nicht unbedingt auf Delta-Tabellen in OneLake haben. 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.

Berechtigungen für Semantikmodelle

Zusätzlich zu Fabric-Elementberechtigungen müssen Sie Benutzern auch Berechtigungen erteilen, damit sie das Direct Lake-Semantikmodell verwenden oder verwalten können. Kurz gesagt benötigen Berichtsanwender Leseberechtigungen , und Berichtsersteller benötigen zusätzliche Buildberechtigungen . Semantische Modellberechtigungen können direkt oderimplizit mithilfe von Arbeitsbereichsrollen zugewiesen werden. Zum Verwalten der Semantikmodelleinstellungen (für Aktualisierung und andere Konfigurationen) müssen Sie der Semantikmodellbesitzersein.

Berechtigungsanforderungen

Berücksichtigen Sie die folgenden Szenarien und Berechtigungsanforderungen.

Szenario Erforderliche Berechtigungen Kommentare
Benutzer können Berichte anzeigen Erteilen Sie leseberechtigungen für die Berichte und die Leseberechtigung für das semantische Modell.

Wenn das Semantikmodell Direct Lake auf SQL-Endpunkten verwendet und die Cloudverbindung SSO verwendet, erteilen Sie mindestens Lese- und ReadData-Berechtigungen für das Lakehouse oder Warehouse.

Wenn das semantische Modell Direct Lake auf OneLake verwendet und die Cloudverbindung SSO verwendet, erteilen Sie mindestens Lese - und ReadAll-Berechtigung für die Delta-Tabellen in OneLake.		 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 Build-Berechtigung für das semantische Modell.

Wenn das Semantikmodell Direct Lake auf SQL-Endpunkten verwendet und die Cloudverbindung SSO verwendet, erteilen Sie mindestens Lese- und ReadData-Berechtigungen für das Lakehouse oder Warehouse.

Wenn das semantische Modell Direct Lake auf OneLake verwendet und die Cloudverbindung SSO verwendet, erteilen Sie mindestens Lese - und ReadAll-Berechtigung für die Delta-Tabellen in OneLake.		 Weitere Informationen finden Sie unter Strategie für Inhaltsersteller.
Benutzer können Berichte anzeigen, jedoch nicht das Lakehouse, den SQL-Analyseendpunkt oder die Delta-Tabellen in OneLake abfragen. Erteilen Sie leseberechtigungen für die Berichte und die Leseberechtigung für das semantische Modell.

Erteilen Sie Benutzern keine Berechtigung für die Tabellen "Lakehouse", "Warehouse" oder "Delta".		 Nur geeignet, wenn das Direct Lake-Modell eine feste Identität über eine Cloudverbindung mit deaktiviertem SSO verwendet.
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.

Anforderungen an die Fabric-Kapazität

Für Direct Lake-Semantikmodelle ist eine Fabric-Kapazitätslizenz erforderlich. Außerdem gibt es Kapazitätsschutzschienen und Einschränkungen, die für Ihr Fabric-Kapazitätsabonnement (Fabric Capacity Subscription, SKU) gelten, wie in der folgenden Tabelle dargestellt.

Wichtig

Die erste Spalte in der folgenden Tabelle enthält auch Power BI Premium-Kapazitätsabonnements (P SKUs). Microsoft konsolidiert Kaufoptionen und setzt die Power BI Premium pro Kapazitäts-SKUs zurück. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F SKUs) in Betracht ziehen.

Weitere Informationen finden Sie unter Wichtige Aktualisierung der Power BI Premium-Lizenzierung und Power BI Premium.

Fabric-SKU Parquet-Dateien pro Tabelle Zeilengruppen pro Tabelle Zeilen pro Tabelle (Millionen) Maximale Modellgröße auf Datenträger/OneLake (GB) Max. Arbeitsspeicher (GB) 1
F2 1.000 1.000 300 10 3
F4 1.000 1.000 300 10 3
F8 1.000 1.000 300 10 3
F16 1.000 1.000 300 20 5
F32 1.000 1.000 300 40 10
F64/FT1/P1 5.000 5.000 1,500 Unbegrenzt 25
F128/P2 5.000 5.000 3,000 Unbegrenzt 50
F256/P3 5.000 5.000 6.000 Unbegrenzt 100
F512/P4 10.000 10.000 12,000 Unbegrenzt 200
F1024/P5 10.000 10.000 24,000 Unbegrenzt 400
F2048 10.000 10.000 24,000 Unbegrenzt 400

1 Für Direct Lake-Semantikmodelle stellt Maximalspeicher das obere Speicherressourcenlimit für, wie viele Daten eingelesen werden können, dar. Aus diesem Grund ist es keine Schutzschiene, da die Überschreitung nicht zu einem Fallback in den DirectQuery-Modus führt; Dies kann jedoch auswirkungen auf die Leistung haben, wenn die Datenmenge groß genug ist, um zu übermäßigem Paging in und aus den Modelldaten aus den OneLake-Daten zu führen.

Wenn die maximale Modellgröße auf der Festplatte/OneLake überschritten wird, werden alle Abfragen an das Semantikmodell in den DirectQuery-Modus zurückfallen. Alle anderen in der Tabelle dargestellten Schutzmaßnahmen werden pro Abfrage ausgewertet. Daher ist es wichtig, dass Sie Ihre Delta-Tabellen und dasDirect Lake-Semantikmodell optimieren, um zu vermeiden, dass Sie unnötig auf eine höhere Fabric-SKU skalieren müssen.

Darüber hinaus gelten die Kapazitätseinheit und der Grenzwert für den maximalen Arbeitsspeicher pro Abfrage für Direct Lake-Semantikmodelle. Weitere Informationen finden Sie unter Kapazitäten und SKUs.

Überlegungen und Einschränkungen

Die semantischen Direct Lake-Modelle stellen einige Überlegungen und Einschränkungen dar.

Anmerkung

Die Funktionen und Features der Direct Lake-Semantikmodelle entwickeln sich schnell weiter. Überprüfen Sie regelmäßig die aktuelle Liste der Überlegungen und Einschränkungen.

Berücksichtigung /Einschränkung Direkter See auf OneLake Direct Lake für SQL (Analyse-Endpunkt)
Wenn der SQL-Analyseendpunkt die Sicherheit auf Zeilenebene erzwingt, werden DAX-Abfragen je nach Art des verwendeten Direct Lake-Modus unterschiedlich verarbeitet.

Wenn Direct Lake auf OneLake verwendet wird, werden Abfragen erfolgreich ausgeführt, und SQL-basierte RLS wird nicht angewendet. Direct Lake auf OneLake erfordert, dass der Benutzer Zugriff auf die Dateien in OneLake hat, was SQL-basierte RLS nicht beobachtet.		 Abfragen werden erfolgreich sein. Ja, es sei denn, Fallback ist deaktiviert, in diesem Fall schlagen Abfragen fehl.
Wenn eine Tabelle im semantischen Modell auf einer (nicht materialisierten) SQL-Ansicht basiert, werden DAX-Abfragen je nach Art des verwendeten Direct Lake-Modus unterschiedlich verarbeitet.

Direct Lake auf SQL-Endpunkten wird in diesem Fall auf DirectQuery zurückgreifen.

Es wird nicht unterstützt, einen Direct Lake auf OneLake-Tabelle basierend auf einer nicht materialisierten SQL-Ansicht zu erstellen. Sie können stattdessen eine materialisierte Lakehouse-Ansicht verwenden, da Delta-Tabellen erstellt werden. Alternativ können Sie einen anderen Speichermodus wie Import oder DirectLake für Tabellen verwenden, die auf nicht materialisierten SQL-Ansichten basieren.		 Nicht zutreffend Ja, es sei denn, Fallback ist deaktiviert, in diesem Fall schlagen Abfragen fehl.
Die zusammengesetzte Modellierung wird zu diesem Zeitpunkt nicht unterstützt. Dies bedeutet, dass Tabellen mit direct Lake-Semantikmodelltabellen in anderen Speichermodi wie Import, DirectQuery oder Dual nicht gemischt werden können (mit Ausnahme von Sonderfällen, einschließlich Berechnungsgruppen, Was-wäre-wenn-Parameter und Feldparameter). Nicht unterstützt Nicht unterstützt
Berechnete Spalten und berechnete Tabellen, die auf Spalten oder Tabellen im Direct Lake-Speichermodus verweisen, werden nicht unterstützt. Berechnungsgruppen, Was-wäre-wenn-Parameterund Feldparameter, die implizit berechnete Tabellen erstellen, und berechnete Tabellen, die nicht auf Direct Lake-Spalten oder -Tabellen verweisen, werden unterstützt. Nicht unterstützt Nicht unterstützt
Direct Lake-Speichermodustabellen unterstützen keine komplexen Delta-Tabellenspaltentypen. Binäre und GUID-Semantiktypen werden ebenfalls nicht unterstützt. Sie müssen diese Datentypen in Zeichenfolgen oder andere unterstützte Datentypen konvertieren. Nicht unterstützt Nicht unterstützt
Tabellenbeziehungen erfordern, dass die Datentypen der verwandten Spalten übereinstimmen. Ja Ja
Einseitige Beziehungsspalten müssen eindeutige Werte enthalten. Abfragen schlagen fehl, wenn doppelte Werte in einer einseitigen Spalte erkannt werden. Ja Ja
Automatische Datums-/Uhrzeitintelligenz in Power BI Desktop zum Erstellen von Beziehungen mit nur dem Datumsteil einer Datetime-Spalte. Hinweis: Das Markieren einer eigenen Datumstabelle als Datumstabelle und das Erstellen von Beziehungen mithilfe von Datumsspalten wird unterstützt. Unterstützt Nicht unterstützt
Die Länge der Zeichenfolgenspaltenwerte ist auf 32.764 Unicode-Zeichen beschränkt. Ja Ja
Nicht numerische Gleitkommawerte, z. B. NaN (keine Zahl), werden nicht unterstützt. Ja Ja
Die Veröffentlichung im Web von Power BI mithilfe eines Dienstprinzipals wird nur unterstützt, wenn eine feste Identität für das Direct Lake-Semantikmodell verwendet wird. Ja Ja
In der Webmodellierungserfahrungist die Validierung für Direct Lake-Semantikmodelle beschränkt. Benutzerauswahlen werden als richtig angenommen, und es werden keine Abfragen ausgegeben, um Kardinalität oder Kreuzfilterauswahlen für Beziehungen oder für die ausgewählte Datumsspalte in einer markierten Datumstabelle zu überprüfen. Ja Ja
Im Fabric-Portal listet die Registerkarte "Direct Lake " im Aktualisierungsverlauf Direct Lake-bezogene Aktualisierungsfehler auf. Erfolgreiche Aktualisierungsvorgänge (Framing) werden normalerweise nicht aufgelistet, es sei denn, der Aktualisierungsstatus ändert sich, z. B. von keinem vorherigen Vorgang oder einem Aktualisierungsfehler in einen Aktualisierungserfolg oder einen Aktualisierungserfolg mit Warnung. Ja Ja
Ihre Fabric-SKU bestimmt den maximal verfügbaren Arbeitsspeicher pro Direct Lake-Semantikmodell für die Kapazität. Wenn das Limit überschritten wird, können Abfragen an das Semantikmodell aufgrund übermäßigen Paging in und aus den Modelldaten langsamer sein. Ja Ja
Das Erstellen eines Direct Lake-Semantikmodells in einem Arbeitsbereich, der sich in einem anderen Bereich des Datenquellenarbeitsbereichs befindet, wird nicht unterstützt. Wenn sich das Lakehouse beispielsweise in West Central US befindet, können Sie nur semantische Modelle aus diesem Lakehouse in derselben Region erstellen. Eine Problemumgehung besteht darin, ein Lakehouse im Arbeitsbereich der anderen Region zu erstellen und eine Verknüpfung zu den Tabellen herzustellen, bevor das Semantikmodelll erstellt wird. Informationen dazu, in welcher Region Sie sich befinden, finden Sie unter Bestimmen Ihrer Fabric-Startregion. Ja Ja
Das Einbetten von Berichten erfordert ein V2-Einbettungstoken. Ja Nicht unterstützt
Dienstprinzipalprofile für die Authentifizierung. Nicht unterstützt Nicht unterstützt
Power BI Direct Lake-Semantikmodelle können von Dienstprinzipalen und bei der Viewer-Rollenmitgliedschaft mit Dienstprinzipalen erstellt und abgefragt werden, aber die standardmäßigen Direct Lake-Semantikmodelle auf dem Lakehouse/Warehouse unterstützen dieses Szenario nicht. Ja Ja
Shortcuts in einem Lakehouse können als Datenquellen für semantische Modell-Tabellen verwendet werden. Während der öffentlichen Vorschau nicht unterstützt Unterstützt
Erstellen von Direct Lake-Modellen in persönlichen Arbeitsbereichen (Mein Arbeitsbereich). Nicht unterstützt Nicht unterstützt
Bereitstellungspipelineregeln zum erneuten Binden der Datenquelle. Nicht unterstützt Unterstützt

Verwandte Inhalte