Übersicht über Direct Lake

Direct Lake ist eine Speichermodusoption für Tabellen in einem Power BI-Semantikmodell, das in einem Microsoft Fabric-Arbeitsbereich gespeichert ist. Sie ist für große Datenmengen optimiert, die schnell aus Delta-Tabellen, die ihre Daten in Parquet-Dateien in OneLake speichern, in den Speicher geladen werden können. OneLake ist der einzige Speicherort für alle Analysedaten. Sobald es in den Speicher geladen wurde, ermöglicht das Semantikmodell Hochleistungsabfragen. Mit Direct Lake entfällt die langsame und kostspielige Notwendigkeit, Daten in das Modell zu importieren.

Sie können den Speichermodus „Direct Lake“ verwenden, um eine Verbindung zu den Tabellen oder Ansichten eines einzelnen Fabric-Lakehouse oder Fabric-Warehouse herzustellen. Für beide Fabric-Elemente und die Semantikmodelle von Direct Lake ist eine Fabric-Kapazitätslizenz erforderlich.

In gewisser Weise ähnelt ein Semantikmodell von Direct Lake einem Importsemantikmodell. Das liegt daran, dass Modelldaten von der VertiPaq-Engine in den Speicher geladen werden, um eine schnelle Abfrageleistung zu gewährleisten (außer im Fall von DirectQuery-Fallback, das weiter unten in diesem Artikel erläutert wird).

Ein Semantikmodell von Direct Lake weist jedoch einen wichtigen Unterschied zu einem Importsemantikmodell auf. Das liegt daran, dass sich der Aktualisierungsvorgang für ein Semantikmodell von Direct Lake konzeptionell von einem Aktualisierungsvorgang für ein Importsemantikmodell unterscheidet. Bei einem Semantikmodell von Direct Lake umfasst eine Aktualisierung einen Framing-Vorgang (wird später in diesem Artikel beschrieben), der einige Sekunden dauern kann. Es handelt sich um einen kostengünstigen Vorgang, bei dem das Semantikmodell 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 Aktualisierung bei einem Importsemantikmodell eine Kopie der Daten, was viel Zeit in Anspruch nehmen und erhebliche Datenquellen- und Kapazitätsressourcen (Arbeitsspeicher und CPU) verbrauchen kann.

Hinweis

Eine inkrementelle Aktualisierung für ein Importsemantikmodell kann dazu beitragen, die Aktualisierungszeit zu verkürzen und die Nutzung von Kapazitätsressourcen zu reduzieren.

In welchen Fällen sollte der Speichermodus „Direct Lake“ verwendet werden?

Der primäre Anwendungsfall für einen „Direct Lake“-Speichermodus ist in der Regel für IT-gesteuerte Analyseprojekte, die auf sogenannten „Lake“-Architekturen basieren. In diesem Szenario liegen in OneLake große Datenmengen vor oder Sie gehen davon aus, dass solche Datenmengen entstehen werden. Das schnelle Laden dieser Daten in den Speicher, häufige und schnelle Aktualisierungsvorgänge, die effiziente Nutzung von Kapazitätsressourcen und eine schnelle Abfrageleistung sind für diesen Anwendungsfall von entscheidender Bedeutung.

Hinweis

Die Semantikmodelle „Import“ und „DirectQuery“ sind in Fabric nach wie vor relevant und für einige Szenarien die richtige Wahl. Der Speichermodus „Import“ eignet sich beispielsweise gut für die Rolle der Selbstbedienungsanalysten, die die Freiheit und Flexibilität benötigen, schnell und ohne Abhängigkeit von der IT-Abteilung neue Datenelemente hinzuzufügen.

Außerdem werden durch die OneLake-Integration Daten für Tabellen im Import-Speichermodus automatisch in Delta-Tabellen in OneLake geschrieben, ohne dass ein Migrationsaufwand entsteht. Wenn Sie diese Option verwenden, können Sie viele der Vorteile von Fabric nutzen, die den benutzenden Personen des Semantikmodells zur Verfügung stehen, wie z. B. die Integration mit Lakehouses über Verknüpfungen, SQL-Abfragen, Notizbücher und vieles mehr. Wir empfehlen Ihnen, diese Option in Betracht zu ziehen, um schnell von den Vorteilen von Fabric zu profitieren, ohne Ihr bestehendes Data-Warehouse- und/oder Analysesystem unbedingt oder sofort neu gestalten zu müssen.

Der Speichermodus „Direct Lake“ eignet sich auch zur Minimierung der Datenlatenz, um Daten schnell für geschäftliche benutzende Personen verfügbar zu machen. Wenn Ihre Delta-Tabellen in unregelmäßigen Abständen geändert werden (und vorausgesetzt, Sie haben die Daten bereits im Data Lake vorbereitet), können Sie sich darauf verlassen, dass automatische Updates als Reaktion auf diese Änderungen neu ausgerichtet werden. In diesem Fall werden bei Abfragen, die an das Semantikmodell gesendet werden, die neuesten Daten zurückgegeben. Diese Funktion lässt sich gut mit der automatischen Seitenaktualisierung von Power BI-Berichten kombinieren.

Beachten Sie, dass Direct Lake darauf angewiesen ist, dass die Datenaufbereitung im Data Lake erfolgt. Die Datenvorbereitung kann mithilfe verschiedener Tools erfolgen, z. B. Spark-Jobs für Fabric-Lakehouses, T-SQL-DML-Anweisungen für Fabric-Warehouses, -Datenflüsse, -Pipelines und andere. Dieser Ansatz trägt dazu bei, dass die Logik der Datenaufbereitung so weit unten in der Architektur wie möglich ausgeführt wird, um die Wiederverwendbarkeit zu maximieren. Wenn die Person, die das Semantikmodell erstellt hat, jedoch keine Möglichkeit hat, das Quellelement zu ändern, z. B. im Falle von Selbstbedienungsanalysten, die möglicherweise keine Schreibberechtigungen für ein von der IT verwaltetes See-Haus haben, dann könnte der Speichermodus „Import“ die bessere Wahl sein. Das liegt daran, dass es die Datenvorbereitung durch die Verwendung von Power Query unterstützt, das als Teil des Semantikmodells definiert ist.

Berücksichtigen Sie unbedingt Ihre aktuelle Fabric-Kapazitätslizenz und die Schutzmaßnahmen für die Fabric-Kapazität, wenn Sie den Speichermodus „Direct Lake“ in Betracht ziehen. Berücksichtigen Sie auch die Überlegungen und Einschränkungen, die weiter unten in diesem Artikel beschrieben werden.

Tipp

Wir empfehlen, einen Prototyp oder Proof of Concept (POC) zu erstellen, um festzustellen, ob ein Semantikmodell von Direct Lake die richtige Lösung ist sowie das Risiko zu mindern.

Funktionsweise von Direct Lake

In der Regel werden Abfragen, die an ein Semantikmodell von Direct Lake gesendet werden, aus einem speicherinternen Cache 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 nach Spalten statt nach Zeilen. Semantikmodelle laden ganze Spalten aus Delta-Tabellen in den Speicher, wenn sie von Abfragen benötigt werden.

Ein Semantikmodell von Direct Lake könnte auch DirectQuery-Fallback verwenden, was einen nahtlosen Wechsel in den DirectQuery-Modus umfasst. Beim DirectQuery-Fallback werden Daten direkt vom SQL-Analyse-Endpunkt des Lakehouse oder des Warehouse abgerufen. Ein Fallback kann beispielsweise auftreten, wenn eine Delta-Tabelle mehr Datenzeilen enthält, als von Ihrer Fabric-Kapazität unterstützt werden (siehe die Beschreibung weiter unten in diesem Artikel). In diesem Fall sendet eine DirectQuery-Operation eine Abfrage an den SQL-Analyseendpunkt. Fallbackvorgänge können zu einer langsameren Abfrageleistung führen.

Das folgende Diagramm zeigt, wie Direct Lake funktioniert, indem es das Szenario einer benutzenden Person verwendet, die einen Power BI-Bericht öffnet.

Das Diagramm veranschaulicht die folgenden Benutzeraktionen, Prozesse und Features.

Artikel	Beschreibung
	OneLake ist ein Data Lake, der Analysedaten im Parquet-Format speichert. Dieses Dateiformat ist für die Speicherung von Daten für Direct Lake-Semantikmodelle optimiert.
	Ein Fabric-Lakehouse oder Fabric-Warehouse befindet sich in einem Arbeitsbereich, der die Fabric-Kapazität überschreitet. Das Lakehouse verfügt über einen SQL-Analyseendpunkt, der eine SQL-basierte Abfrageerfahrung bietet. Tabellen (oder Ansichten) bieten eine Möglichkeit, die Delta-Tabellen in OneLake mithilfe von Transact-SQL (T-SQL) abzufragen.
	Ein Semantikmodell von Direct Lake ist in einem Fabric-Arbeitsbereich vorhanden. Es ist mit Tabellen oder Ansichten im Lakehouse oder im Warehouse verbunden.
	Eine benutzende Person öffnet einen Power BI-Bericht.
	Der Power BI-Bericht sendet DAX-Abfragen (Data Analysis Expressions) an das Direct Lake-Semantikmodell.
	Wenn möglich (und erforderlich), lädt das Semantikmodell Spalten direkt aus den in OneLake gespeicherten Parquet-Dateien in den Speicher. Abfragen erzielen eine sehr schnelle speicherinterne Leistung.
	Das Semantikmodell gibt Abfrageergebnisse zurück.
	Der Power BI-Bericht stellt die visuellen Elemente dar.
	Unter bestimmten Umständen, z. B. wenn das Semantikmodell die Schutzmaßnahmen der Kapazität überschreitet, werden Abfragen des Semantikmodells automatisch in den DirectQuery-Modus zurückgesetzt. In diesem Modus werden Abfragen an den SQL-Analyseendpunkt des Lakehouse oder Warehouse gesendet.
	An den SQL-Analyseendpunkt gesendete DirectQuery-Abfragen fragen wiederum die Delta-Tabellen in OneLake ab. Aus diesem Grund kann die Abfrageleistung langsamer sein als bei speicherinternen Abfragen.

In den folgenden Abschnitten werden die Konzepte und Funktionen von Direct Lake beschrieben, darunter Spaltenladen, Framing, automatische Updates und DirectQuery-Fallback.

Laden von Spalten (Transcodierung)

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

Wenn das Semantikmodell eine DAX-Abfrage (oder eine Abfrage mit mehrdimensionalen Ausdrücken – MDX) erhält, bestimmt es zunächst, welche Spalten benötigt werden, um ein Abfrageergebnis zu erzeugen. Zu den erforderlichen Spalten gehören alle Spalten, die direkt von der Abfrage verwendet werden, sowie Spalten, die für Beziehungen und Messungen erforderlich sind. In der Regel ist die Anzahl der Spalten, die zur Erstellung eines Abfrageergebnisses benötigt werden, viel geringer als die Anzahl der im Semantikmodell definierten Spalten.

Sobald klar ist, welche Spalten benötigt werden, bestimmt das Semantikmodell, welche Spalten bereits im Speicher vorhanden sind. Wenn sich für die Abfrage benötigte Spalten nicht im Speicher befinden, lädt das Semantikmodell alle Daten für diese Spalten aus OneLake. Das Laden von Spaltendaten ist in der Regel ein sehr 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. Bei zukünftigen Abfragen, die nur residente Spalten betreffen, müssen keine weiteren Spalten in den Speicher geladen werden.

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 die Entfernung von Spalten sind u. a.:

• Das Modell oder die Tabelle wurde aktualisiert (siehe Framing im nächsten Abschnitt).
• Die Spalte wurde seit einiger Zeit nicht mehr verwendet.
• Andere Gründe für die Speicherverwaltung, einschließlich Speicherdruck in der Kapazität aufgrund anderer, paralleler Vorgänge.

Die von Ihnen gewählte Fabric-SKU bestimmt den maximal verfügbaren Speicher für jedes Direct Lake-Semantikmodell auf der Kapazität. Weitere Informationen zu Schutzmaßnahmen für die Ressourcen und zu den maximalen Speicherbeschränkungen finden Sie unter Schutzmaßnahmen und Beschränkungen der Fabric-Kapazität weiter unten.

Framing

Framing bietet Modellbesitzern die Point-in-Time-Kontrolle darüber, welche Daten in das Semantikmodell geladen werden. Framing ist ein Vorgang in Direct Lake, der durch die Aktualisierung eines Semantikmodells ausgelöst wird und in den meisten Fällen nur wenige Sekunden dauert. 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 Parquet-Dateien in OneLake zu verweisen.

Wenn Framing auftritt, werden residente Spalten möglicherweise aus dem Speicher entfernt und der Zeitpunkt der Aktualisierung wird zur neuen Basislinie für alle zukünftigen Transcodierungsereignisse. Ab diesem Zeitpunkt berücksichtigen Direct Lake-Abfragen nur Daten in den Delta-Tabellen zum Zeitpunkt des letzten Framingvorgangs. Aus diesem Grund werden Direct Lake-Tabellen abgefragt, um Daten basierend auf dem Zustand der Delta-Tabelle zum Zeitpunkt des letzten Framingvorgangs zurückzugeben. Diese Zeit entspricht nicht unbedingt dem neuesten Stand der Delta-Tabellen.

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

Im Diagramm sind die folgenden Prozesse und Funktionen dargestellt.

Artikel	Beschreibung
	In einem Fabric-Arbeitsbereich ist ein Semantikmodell 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 Parquet-Dateien, 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 Stand einer Delta-Tabelle darstellen, wenn eine Transcodierung stattfindet. Bedenken Sie, dass das Framing Ihnen dabei helfen kann, konsistente Abfrageergebnisse in Umgebungen zu liefern, in denen Daten in Delta-Tabellen flüchtig sind. Daten können aus verschiedenen Gründen vorübergehend sein, z. B. wenn lang andauernde ETL-Prozesse (Extrahieren, Transformieren, Laden) stattfinden.

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

Weitere Informationen zur Versionsverwaltung und zum Framing von Delta-Tabellen finden Sie unter Grundlegendes zum Speicher für Direct Lake-Semantikmodelle.

Automatische Aktualisierungen

Es gibt eine Einstellung auf Semantikmodellebene, um Direct Lake-Tabellen automatisch zu aktualisieren. Standardmäßig ist sie aktiviert. Dadurch wird sichergestellt, dass Datenänderungen in OneLake automatisch im Semantikmodell von Direct Lake berücksichtigt werden. Sie sollten automatische Updates deaktivieren, wenn Sie Datenänderungen durch Framing steuern möchten, wie im vorherigen Abschnitt erläutert. Weitere Informationen finden Sie unter Verwalten von Direct Lake-Semantikmodellen.

Tipp

Sie können die automatische Seitenaktualisierung in Ihren Power BI-Berichten einrichten. Es handelt sich um eine Funktion, die eine bestimmte Berichtsseite automatisch aktualisiert, vorausgesetzt, der Bericht ist mit einem Semantikmodell von Direct Lake (oder anderen Semantikmodellen) verknüpft.

DirectQuery-Fallback

Eine an ein Direct Lake-Semantikmodell gesendete Abfrage kann auf den DirectQuery-Modus zurückgreifen. In diesem Fall werden die Daten direkt vom SQL-Analyseendpunkt des Lakehouse oder Warehouse abgerufen. Solche Abfragen geben immer die neuesten Daten zurück, da sie nicht auf den Zeitpunkt des letzten Framingvorgangs beschränkt sind.

Eine Abfrage fällt immer zurück, wenn das Semantikmodell eine Ansicht im SQL-Analyseendpunkt oder eine Tabelle im SQL-Analyseendpunkt abfragt, die die Sicherheit auf Zeilenebene (RLS) erzwingt.

Außerdem kann eine Abfrage zurückfallen, wenn das Semantikmodell die Schutzmaßnahmen der Kapazität überschreitet.

Wichtig

Wenn möglich, sollten Sie Ihre Lösung immer so gestalten – oder Ihre Kapazität so bemessen, – dass ein DirectQuery-Fallback vermieden wird. Das liegt daran, dass dies zu einer langsameren Abfrageleistung führen könnte.

Sie können das Fallback Ihrer Direct Lake-Semantikmodell über die Einstellung der Eigenschaft DirectLakeBehavior steuern. Weitere Informationen finden Sie unter Festlegen der Direct Lake-Verhaltenseigenschaft.

Fabric-Kapazitätsschutzmaßnahmen und Beschränkungen

Für Direct Lake-Semantikmodelle ist eine Fabric-Kapazitätslizenz erforderlich. Außerdem gibt es Kapazitätsschutzmaßnahmen und Beschrä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). Beachten Sie, dass Microsoft die Kaufoptionen konsolidiert und die Power BI Premium-SKUs pro Kapazität einstellt. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F-SKUs) in Betracht ziehen.

Weitere Informationen finden Sie unter Wichtiges Update zur 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)	Maximaler Speicher (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

¹ Bei Direct Lake-Semantikmodellen stellt Maximaler Speicher die obere Grenze der Speicherressource dar, die angibt, wie viele Daten ausgelagert werden können. Aus diesem Grund handelt es sich nicht um eine Schutzmaßnahme, da ein Überschreiten nicht zu einem Fallback in den DirectQuery-Modus führt. Allerdings kann es Auswirkungen auf die Leistung haben, wenn die Datenmenge groß genug ist, um ein übermäßiges Ein- und Auslagern der Modelldaten aus den OneLake-Daten zu verursachen.

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 das Direct Lake-Semantikmodell optimieren, um eine unnötige Skalierung auf eine höhere Fabric-SKU zu vermeiden (was zu höheren Kosten führen würde).

Darüber hinaus gelten Kapazitätseinheiten und maximaler Arbeitsspeicher pro Abfragegrenzwert für Direct Lake-Semantikmodelle. Weitere Informationen finden Sie unter Kapazitäten und SKUs.

Überlegungen und Einschränkungen

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

Hinweis

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

• Wenn eine Tabelle mit einem Semantikmodell von Direct Lake mit einer Tabelle im SQL-Analyseendpunkt verbunden wird, die Sicherheit auf Zeilenebene (RLS) erzwingt, werden Abfragen, die diese Modelltabelle betreffen, immer in den DirectQuery-Modus zurückfallen. Die Abfrageleistung könnte langsamer sein.
• Wenn eine Tabelle mit einem Semantikmodell von Direct Lake mit einer Ansicht im SQL-Analyseendpunkt verbunden wird, werden Abfragen, die diese Modelltabelle betreffen, immer in den DirectQuery-Modus zurückfallen. Die Abfrageleistung könnte langsamer sein.
• Die zusammengesetzte Modellierung wird nicht unterstützt. Das bedeutet, dass Tabellen mit dem Semantikmodell „Direct Lake“ nicht mit Tabellen in anderen Speichermodi wie „Import“, „DirectQuery“ oder „Dual“ gemischt werden können (außer in Sonderfällen, einschließlich Berechnungsgruppen, Was-wäre-wenn-Parametern und Feldparametern).
• 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.
• Tabellen im Speichermodus „Direct Lake“ 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.
• Tabellenbeziehungen erfordern, dass die Datentypen der verbundenen Spalten übereinstimmen.
• Einseitige Beziehungsspalten müssen eindeutige Werte enthalten. Abfragen schlagen fehl, wenn in einer einseitigen Spalte doppelte Werte erkannt werden.
• Die automatische Daten-/Zeitintelligenz in Power BI Desktop wird nicht unterstützt. Das Markieren einer eigenen Datumstabelle als Datumstabelle wird unterstützt.
• Die Länge der Zeichenfolgenspaltenwerte ist auf 32.764 Unicode-Zeichen beschränkt.
• Der Gleitkommawert NaN (nicht numerisch) wird nicht unterstützt.
• Einbettungsszenarien, die das Verwendungsszenario Für Ihre Kundschaft verwenden, werden nicht unterstützt.
• Die Veröffentlichung im Web von Power BI wird nur unterstützt, wenn eine feste Identität für das Direct Lake-Semantikmodell verwendet wird.
• In der Webmodellierungsoberfläche ist die Validierung für Direct Lake-Semantikmodelle beschränkt. Es wird davon ausgegangen, dass die Auswahl der benutzenden Person korrekt ist, und es werden keine Abfragen zur Validierung der Kardinalität oder der Auswahl von Kreuzfiltern für Beziehungen oder für die ausgewählte Datumsspalte in einer markierten Datumstabelle ausgegeben.
• Im Fabric-Portal listet die Registerkarte Direct Lake im Aktualisierungsverlauf nur Direct Lake-bezogene Aktualisierungsfehler auf. Erfolgreiche Aktualisierungsvorgänge (Framing) werden nicht aufgeführt.
• 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.
• Die Erstellung eines Semantikmodells für Direct Lake in einem Arbeitsbereich, der sich in einer anderen Region des Arbeitsbereichs für Datenquellen befindet, wird nicht unterstützt. Wenn sich das Lakehouse beispielsweise in USA, Westen-Mitte befindet, können Sie Semantikmodelle nur von 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. Um herauszufinden, in welcher Region Sie sich befinden, sehen Sie sich Ihre Fabric-Heimatregion an.
• Sie können ein benutzerdefiniertes Direct Lake-Semantikmodell mithilfe einer Dienstprinzipalidentität erstellen und anzeigen, das standardmäßige Direct Lake-Semantikmodell unterstützt jedoch keine Dienstprinzipale. Stellen Sie sicher, dass die Dienstprinzipalauthentifizierung für Fabric-REST-APIs in Ihrem Mandanten aktiviert ist, und weisen Sie dem Arbeitsbereich Ihres Direct Lake-Semantikmodells die Berechtigung „Mitwirkender“ für den Dienstprinzipal oder höhere Berechtigungen zu.
• Direct Lake unterstützt keine Dienstprinzipalprofile für die Authentifizierung.

Vergleich zu anderen Speichermodi

In der folgenden Tabelle wird der Speichermodus „Direct Lake“ mit den Speichermodi „Import“ und „DirectQuery“ verglichen.

Funktion	Direct Lake	Import	DirectQuery
Lizenzierung	Nur Fabric-Kapazitätsabonnement (SKUs)	Beliebige Fabric- oder Power BI-Lizenz (einschließlich kostenlose Microsoft Fabric-Lizenzen)	Beliebige Fabric- oder Power BI-Lizenz (einschließlich kostenlose Microsoft Fabric-Lizenzen)
Datenquelle	Nur Lakehouse- oder Warehousetabellen (oder Ansichten)	Jeder Connector	Jeder Connector, der den DirectQuery-Modus unterstützt
Herstellen einer Verbindung mit SQL Analytics-Endpunktansichten	Ja – wird aber automatisch auf den DirectQuery-Modus zurückgesetzt	Ja	Ja
Zusammengesetzte Modelle	Nein 1	Ja – kann mit DirectQuery- oder Dual-Speichermodustabellen kombiniert werden	Ja – kann mit Tabellen im Import- oder Dual-Speichermodus kombiniert werden
Einmaliges Anmelden (Single Sign-On, SSO)	Ja	Nicht zutreffend	Ja
Berechnete Tabellen	Nein – außer Berechnungsgruppen, Was-wäre-wenn-Parametern und Feldparametern , 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	No	Ja	Ja
Hybridtabellen	No	Ja	Ja
Modelltabellenpartitionen	Nein – Partitionierung kann jedoch auf Delta-Tabellenebene erfolgen	Ja – entweder automatisch durch inkrementelle Aktualisierung oder manuell mithilfe des XMLA-Endpunkts erstellt	No
Benutzerdefinierte Aggregationen	No	Ja	Ja
Sicherheit auf SQL Analytics-Endpunktebene oder Sicherheit auf Spaltenebene	Ja – Abfragen werden jedoch auf den DirectQuery-Modus zurückgesetzt und können 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)	Ja – Aber Abfragen werden auf den DirectQuery-Modus zurückgesetzt	Ja – muss jedoch Berechtigungen mit Semantikmodell-RLS duplizieren	Ja
Sicherheit auf Zeilenebene im Semantikmodell (RLS)	Ja – es wird jedoch dringend empfohlen, eine Cloudverbindung mit fester Identität zu verwenden	Ja	Ja
Sicherheit auf Objektebene im Semantikmodell (OLS)	Ja	Ja	Ja
Große Datenmengen ohne Aktualisierungsbedarf	Ja	Weniger geeignet – eine größere Kapazitätsgröße kann zum Abfragen und Aktualisieren erforderlich sein	Ja
Verringern der Datenlatenz	Ja – wenn automatische Updates aktiviert sind oder bei programmgesteuertem Reframing. Allerdings muss die Datenaufbereitung zuerst erfolgen	No	Ja

¹ Sie können Tabellen im Direct Lake-Speichermodus nicht mit DirectQuery- oder Dualspeichermodustabellen im selben Semantikmodell kombinieren. Sie können jedoch Power BI Desktop verwenden, um ein zusammengesetztes Modell auf 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 für ein Semantikmodell.

Zugehöriger Inhalt

• Direct Lake-Semantikmodelle entwickeln
• Direct Lake-Semantikmodelle verwalten
• Grundlegendes zu Speicher für Direct Lake-Semantikmodelle
• Erstellen eines Lakehouse für Direct Lake
• Analysieren der Abfrageverarbeitung für Direct Lake-Semantikmodelle