Direct Lake

Der Direct Lake-Modus ist eine Semantikmodell-Funktionalität zum Analysieren sehr großer Datenmengen in Power BI. Direct Lake basiert auf dem direkten Laden von Dateien im Parquet-Format aus einem Data Lake ohne die Notwendigkeit, einen Lakehouse-Endpunkt abfragen und Daten in ein Power BI-Modell importieren oder duplizieren zu müssen. Direct Lake ist ein schneller Weg zum direkten Laden der Daten aus dem Data Lake in die Power BI-Engine, die für die Analyse bereit ist. Das folgende Diagramm zeigt einen Vergleich zwischen klassischen Import- und DirectQuery-Modi und dem Direct Lake-Modus.

Im DirectQuery-Modus fragt die Power BI-Engine die Daten an der Quelle ab. Dies kann zwar langsam sein, dafür wird aber das Kopieren der Daten wie beim klassischen Importmodus vermieden. Alle Änderungen an der Datenquelle spiegeln sich sofort in den Abfrageergebnissen wider.

Andererseits kann die Leistung im Importmodus besser sein, da die Daten zwischengespeichert und für DAX- und MDX-Berichtsabfragen optimiert werden, ohne dass SQL-Abfragen oder andere Arten von Abfragen übersetzt und an die Datenquelle übergeben werden müssen. Die Power BI-Engine muss jedoch alle neuen Daten während der Aktualisierung zuerst in das Modell kopieren. Jegliche Änderungen an der Quelle werden erst mit der nächsten Modellaktualisierung übernommen.

Im Direct Lake-Modus entfällt die Importanforderung, da die Daten direkt aus OneLake geladen werden. Im Gegensatz zu DirectQuery gibt es keine Übersetzung von DAX oder MDX in andere Abfragesprachen und auch keine Abfrageausführung in anderen Datenbanksystemen, was zu einer vergleichbaren Leistung wie im Importmodus führt. Da es keinen expliziten Importvorgang gibt, ist es möglich, alle Änderungen an der Datenquelle bei ihrem Auftreten zu übernehmen. Dadurch können die Vorteile des DirectQuery- und des Importmodus kombiniert werden, ohne von ihren Nachteilen betroffen zu sein. Der Direct Lake-Modus kann die ideale Wahl für die Analyse sehr großer Modelle sowie von Modellen sein, deren Datenquelle häufig aktualisiert wird.

Direct Lake unterstützt auch Sicherheit auf Zeilenebene und Sicherheit auf Objektebene, sodass Benutzer nur die Daten sehen, für die sie Leseberechtigung besitzen.

Voraussetzungen

Direct Lake wird nur für Microsoft Fabric F-SKUs unterstützt.

Lakehouse

Bevor Sie Direct Lake verwenden, müssen Sie ein Lakehouse (oder ein Warehouse) mit mindestens einer Delta-Tabelle in einem Arbeitsbereich bereitstellen, der auf einer unterstützten Microsoft Fabric-Kapazität gehostet wird. Das Lakehouse ist erforderlich, da es den Speicherort für Ihre Dateien im Parquet-Format in OneLake bereitstellt. Das Lakehouse bietet ebenfalls einen Zugriffspunkt zum Starten der Webmodellierung, um ein Direct Lake-Modell zu erstellen.

Informationen zum Bereitstellen eines Lakehouse, Erstellen einer Delta-Tabelle im Lakehouse und Erstellen eines einfachen Modells für das Lakehouse finden Sie unter Erstellen eines Lakehouse für Direct Lake.

SQL-Endpunkt

Im Rahmen der Bereitstellung eines Lakehouse werden ein SQL-Endpunkt für SQL-Abfragen und ein Standardmodell für die Berichterstellung erstellt und mit allen Tabellen aktualisiert, die dem Lakehouse hinzugefügt werden. Während der Direct Lake-Modus den SQL-Endpunkt beim direkten Laden von Daten aus OneLake nicht abfragt, ist dies erforderlich, wenn ein nahtloser Fallback des Direct Lake-Modells in den DirectQuery-Modus erfolgen muss, z. B. wenn die Datenquelle bestimmte Features wie erweiterte Sicherheit oder Ansichten verwendet, die von Direct Lake nicht gelesen werden können. Der Direct Lake-Modus fragt auch den SQL-Endpunkt nach Schema- und sicherheitsbezogenen Informationen ab.

Data Warehouse

Alternativ zu einem Lakehouse mit SQL-Endpunkt können Sie auch ein Warehouse bereitstellen und Tabellen mithilfe von SQL-Anweisungen oder Datenpipelines hinzufügen. Das Verfahren zur Bereitstellung eines eigenständigen Data Warehouse ist fast identisch mit dem Verfahren für ein Lakehouse.

Unterstützung für Modellschreibvorgänge mit XMLA-Endpunkt

Direct Lake-Modelle unterstützen Schreibvorgänge über den XMLA-Endpunkt mithilfe von Tools wie SQL Server Management Studio (19.1 und höher) und den neuesten Versionen externer BI-Tools wie Tabular Editor und DAX Studio. Modellschreibvorgänge über die XMLA-Endpunkt-Unterstützung:

• Anpassen, Zusammenführen, Erstellen von Skripts, Debuggen und Testen von Direct Lake-Modellmetadaten.

• Quell- und Versionskontrolle, Continuous Integration und Continuous Deployment (CI/CD) mit Azure DevOps und GitHub.

• Automatisierungsaufgaben wie das Aktualisieren und Anwenden von Änderungen auf Direct Lake-Modelle mithilfe von PowerShell und REST-APIs.

Beachten Sie, dass Direct Lake-Tabellen, die mit XMLA-Anwendungen erstellt wurden, zunächst in einem unbearbeiteten Zustand sind, bis die Anwendung einen Aktualisierungsbefehl ausgibt. Nicht verarbeitete Tabellen werden auf den DirectQuery-Modus zurückgesetzt. Achten Sie beim Erstellen eines neuen Semantikmodells darauf, dieses zu aktualisieren, um Ihre Tabellen zu verarbeiten.

Aktivieren von XMLA-Lese-/Schreibzugriff

Bevor Schreibvorgänge für Direct Lake-Modelle über den XMLA-Endpunkt ausgeführt werden können, muss XMLA-Lese-/Schreibzugriff für die Kapazität aktiviert sein.

Für Fabric-Testkapazitäten verfügt der Testbenutzer über die Administratorrechte, die erforderlich sind, um XMLA-Lese-/Schreibzugriff zu aktivieren.

1. Wählen Sie im Verwaltungsportal die Option Kapazitätseinstellungen aus.

2. Klicken Sie auf die Registerkarte Testversion.

3. Wählen Sie die Kapazität mit Testversion und Ihrem Benutzernamen im Kapazitätsnamen aus.

4. Erweitern Sie Power BI-Workloads, und wählen Sie dann in der Einstellung XMLA-Endpunkt die Option Schreibzugriff aus.

   

Beachten Sie, dass die Einstellung des XMLA-Endpunkts für alle Arbeitsbereiche und Modelle gilt, die dieser Kapazität zugewiesen sind.

Direct Lake-Modellmetadaten

Beim Herstellen einer Verbindung mit einem eigenständigen Direct Lake-Modell über den XMLA-Endpunkt sehen die Metadaten wie bei jedem anderen Modell aus. Direct Lake-Modelle weisen jedoch die folgenden Unterschiede auf:

• Die compatibilityLevel-Eigenschaft des Datenbankobjekts ist 1604 oder höher.

• Die Mode-Eigenschaft von Direct Lake-Partitionen ist auf „directLake“ festgelegt.

• Direct Lake-Partitionen verwenden freigegebene Ausdrücke, um Datenquellen zu definieren. Der Ausdruck verweist auf den SQL-Endpunkt eines Lakehouse. Direct Lake verwendet den SQL-Endpunkt, um Informationen zum Schema und zur Sicherheit zu ermitteln, lädt die Daten jedoch direkt aus den Delta-Tabellen (es sei denn, Direct Lake muss aus irgendeinem Grund auf den DirectQuery-Modus zurückgreifen).

Hier sehen Sie ein Beispiel für eine XMLA-Abfrage in SSMS:

Weitere Informationen zur Toolunterstützung über den XMLA-Endpunkt finden Sie unter Konnektivität der Semantikmodelle mit dem XMLA-Endpunkt.

Fallback

Power BI-Semantikmodelle im Direct Lake-Modus lesen Delta-Tabellen direkt aus OneLake. Wenn eine DAX-Abfrage eines Direct Lake-Modells jedoch die Grenzwerte für die SKU überschreitet oder Features verwendet, die den Direct Lake-Modus nicht unterstützen, z. B. SQL-Ansichten in einem Warehouse, kann ein Fallback der Abfrage in den DirectQuery-Modus erfolgen. Im DirectQuery-Modus verwenden Abfragen SQL, um die Ergebnisse vom SQL-Endpunkt des Lakehouse oder Warehouse abzurufen, was sich auf die Abfrageleistung auswirken kann. Sie können den Fallback zum DirectQuery-Modus deaktivieren, wenn Sie DAX-Abfragen nur im reinen Direct Lake-Modus verarbeiten möchten. Das Deaktivieren von Fallbacks wird empfohlen, wenn Sie keinen Fallback in DirectQuery benötigen. Dies kann auch hilfreich sein, wenn die Abfrageverarbeitung für ein Direct Lake-Modell analysiert wird, um festzustellen, ob und wie oft ein Fallback auftritt. Weitere Informationen zum DirectQuery-Modus finden Sie unter Semantikmodellmodi in Power BI.

Guardrails definieren Ressourcengrenzwerte für den Direct Lake-Modus, ab denen ein Fallback in den DirectQuery-Modus zum Verarbeiten von DAX-Abfragen erforderlich ist. Ausführliche Informationen zum Ermitteln der Anzahl von Parquet-Dateien und Zeilengruppen für eine Delta-Tabelle finden Sie in der Referenz zu Delta-Tabelleneigenschaften.

Bei Direct Lake-Semantikmodellen stellt Maximaler Arbeitsspeicher den oberen Speicherressourcengrenzwert für die Anzahl der Paging-Daten dar. Tatsächlich ist dies kein „Guardrail”, da die Überschreitung kein Fallback in den DirectQuery-Modus verursacht. Dies kann jedoch Auswirkungen auf die Leistung haben, wenn die Datenmenge groß genug ist, um ein Paging-In und Paging-Out der Modelldaten aus den OneLake-Daten hervorzurufen.

In der folgenden Tabelle sind die Ressourcengrenzwerte und die Werte für den maximalen Arbeitsspeicher aufgeführt:

Fabric-SKUs	Parquet-Dateien pro Tabelle	Zeilengruppen pro Tabelle	Zeilen pro Tabelle (Millionen)	Maximale Modellgröße auf Datenträger/OneLake1 (GB)	Maximaler Speicher (GB)
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: Bei Überschreitung der maximalen Modellgröße auf dem Datenträger/in OneLake werden alle Abfragen für das Modell in den DirectQuery-Modus zurückgesetzt. Dies stellt einen Unterschied zu anderen Grenzwerten dar, die pro Abfrage ausgewertet werden.

Je nach Fabric-SKU gelten für Direct Lake-Modelle zusätzliche Kapazitätseinheiten und Grenzwerte für den maximalen Arbeitsspeicher pro Abfrage. Weitere Informationen finden Sie unter Kapazitäten und SKUs.

Fallbackverhalten

Direct Lake-Modelle umfassen die DirectLakeBehavior-Eigenschaft, die drei Optionen hat:

Automatisch – (Standard) Gibt an, dass Abfragen auf den DirectQuery-Modus zurückgesetzt werden, wenn Daten nicht effizient in den Arbeitsspeicher geladen werden können.

DirectLakeOnly – Gibt an, dass alle Abfragen nur den Direct Lake-Modus verwenden. Fallback auf den DirectQuery-Modus ist deaktiviert. Wenn Daten nicht in den Arbeitsspeicher geladen werden können, wird ein Fehler zurückgegeben. Verwenden Sie diese Einstellung, um zu bestimmen, ob DAX-Abfragen beim Laden von Daten in den Speicher fehlschlagen, so dass ein Fehler zurückgegeben werden muss.

DirectQueryOnly – Gibt an, dass alle Abfragen nur den DirectQuery-Modus verwenden. Verwenden Sie diese Einstellung, um die Fallbackleistung zu testen.

Die Eigenschaft DirectLakeBehavior kann mithilfe von Tabular Object Model (TOM) oder Tabular Model Scripting Language (TMSL) konfiguriert werden.

Das folgende Beispiel legt fest, dass alle Abfragen nur den Direct Lake-Modus verwenden:

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Analysieren der Abfrageverarbeitung

Um zu ermitteln, ob die DAX-Abfragen eines Berichtsvisuals an die Datenquelle die beste Leistung bieten, indem der Direct Lake-Modus verwenden wird oder ob auf den DirectQuery-Modus zurückgegriffen wird, können Sie die Leistungsanalyse in Power BI Desktop, SQL Server Profiler oder andere Drittanbietertools verwenden und Abfragen zu analysieren. Weitere Informationen finden Sie unter Analysieren der Abfrageverarbeitung für Direct Lake-Modelle.

Aktualisieren

Standardmäßig werden Datenänderungen in OneLake automatisch in einem Direct Lake-Modell widergespiegelt. Sie können dieses Verhalten ändern, indem Sie Halten Sie Ihre Direct Lake-Daten auf dem neuesten Stand in den Einstellungen des Modells deaktivieren.

Sie könnten diese Einstellungen deaktivieren, wenn Sie z. B. den Abschluss von Datenvorbereitungsaufträgen zulassen müssen, bevor Sie neue Daten für Consumer des Modells verfügbar machen. Bei Deaktivierung können Sie die Aktualisierung manuell oder mithilfe der Aktualisierungs-APIs aufrufen. Das Aufrufen einer Aktualisierung für ein Direct Lake-Modell ist ein kostengünstiger Vorgang, bei dem das Modell die Metadaten der neuesten Version der Delta Lake-Tabelle analysiert und aktualisiert wird, um auf die neuesten Dateien in OneLake zu verweisen.

Beachten Sie, dass Power BI automatische Aktualisierungen von Direct Lake-Tabellen anhalten kann, wenn während der Aktualisierung ein nicht behebbarer Fehler auftritt. Stellen Sie daher sicher, dass das Semantikmodell erfolgreich aktualisiert werden kann. Power BI setzt automatische Updates automatisch fort, wenn eine nachfolgende vom Benutzer aufgerufene Aktualisierung ohne Fehler abgeschlossen wird.

Mehrschichtige Datenzugriffssicherheit

Direct Lake-Modelle, die auf Lakehouses und Warehouses aufbauen, entsprechen dem mehrschichtigen Sicherheitsmodell, das Lakehouses und Warehouses unterstützen, indem Berechtigungsprüfungen über den T-SQL-Endpunkt durchgeführt werden, um festzustellen, ob die Identität des versuchten Datenzugriffs über die erforderlichen Datenzugriffsberechtigungen verfügt. Standardmäßig verwenden Direct Lake-Modelle Einmaliges Anmelden (Single Sign-On, SSO), sodass die effektiven Berechtigungen des interaktiven Benutzers bestimmen, ob der Datenzugriff des Benutzers zugelassen oder verweigert wird. Wenn das Direct Lake-Modell für die Verwendung einer festen Identität konfiguriert ist, bestimmt die effektive Berechtigung der festen Identität, ob mit dem Semantikmodell interagierende Benutzer auf die Daten zugreifen können. Der T-SQL-Endpunkt gibt „Zugelassen“ oder „Verweigert“ an das Direct Lake-Modell basierend auf der Kombination aus OneLake-Sicherheits- und SQL-Berechtigungen zurück.

Beispielsweise kann ein Warehouse-Administrator einem Benutzer SELECT-Berechtigungen für eine Tabelle gewähren, sodass der Benutzer diese Tabelle lesen kann, auch wenn der Benutzer über keine OneLake-Sicherheitsberechtigungen verfügt. Der Benutzer wurde auf Lakehouse/Warehouse-Ebene autorisiert. Umgekehrt kann ein Warehouse-Administrator auch den Lesezugriff eines Benutzers auf eine Tabelle verweigern. Dann kann der Benutzer diese Tabelle nicht lesen, auch wenn er über OneLake-Sicherheitsberechtigungen zum Lesen verfügt. Die Anweisung zum Verweigern überschreibt alle gewährten OneLake-Sicherheits- oder SQL-Berechtigungen. In der folgenden Tabelle finden Sie die effektiven Berechtigungen, die ein Benutzer mit den verschiedenen Kombinationen aus OneLake-Sicherheits- und SQL-Berechtigungen haben kann.

OneLake-Sicherheitsberechtigungen	SQL-Berechtigungen	Effektive Berechtigungen
Zulassen	Keine	Zulassen
Keine	Zulassen	Zulassen
Zulassen	Verweigern	Verweigern
Keine	Verweigern	Verweigern

Bekannte Probleme und Einschränkungen

• Nur Tabellen im semantischen Modell, die von Tabellen in einem Lakehouse oder Warehouse abgeleitet sind, unterstützen den Direct Lake-Modus. Obwohl Tabellen im Modell von SQL-Ansichten im Lakehouse oder Warehouse abgeleitet werden können, fallen Abfragen, die diese Tabellen verwenden, in den DirectQuery-Modus zurück.

• Direct Lake Semantikmodell-Tabellen können nur von Tabellen und Ansichten aus einem einzigen Lakehouse oder Warehouse abgeleitet werden.

• Direct Lake-Tabellen können derzeit nicht mit anderen Tabellentypen wie Import, DirectQuery oder Dual im selben Modell gemischt werden. Zusammengesetzte Modelle werden derzeit nicht unterstützt.

• DateTime-Beziehungen werden in Direct Lake-Modellen nicht unterstützt.

• Berechnete Spalten und Tabellen werden nicht unterstützt.

• Einige Datentypen werden möglicherweise nicht unterstützt, z. B. präzise Dezimalstellen und „Money“-Typen.

• Direct Lake-Tabellen unterstützen keine komplexen Delta-Tabellen-Spaltentypen. Binäre und Guid-Semantiktypen werden ebenfalls nicht unterstützt. Sie müssen diese Datentypen in Zeichenfolgen oder andere unterstützte Datentypen konvertieren.

• Bei Tabellenbeziehungen müssen die Datentypen der Schlüsselspalten übereinstimmen. Primärschlüsselspalten müssen eindeutige Werte enthalten. DAX-Abfragen schlagen fehl, wenn doppelte Primärschlüsselwerte erkannt werden.

• Die Länge der Zeichenfolgenspaltenwerte ist auf 32.764 Unicode-Zeichen beschränkt.

• Der Gleitkommawert "NaN" (Not A Number) wird in Direct Lake-Modellen nicht unterstützt.

• Eingebettete Szenarien, die auf eingebetteten Entitäten basieren, werden noch nicht unterstützt.

• Die Validierung ist für Direct Lake-Modelle beschränkt. Es wird davon ausgegangen, dass die Benutzerauswahlen korrekt sind, und keine Abfragen validieren die Kardinalitäts- und Kreuzfilterauswahlen für Beziehungen oder für die ausgewählte Datumsspalte in einer Datumstabelle.

• Auf der Registerkarte „Direct Lake“ im Aktualisierungsverlauf werden nur fehlgeschlagene Direct Lake-Aktualisierungen aufgelistet. Erfolgreiche Aktualisierungen werden derzeit nicht aufgeführt.

Erste Schritte

Die beste Möglichkeit, mit einer Direct Lake-Lösung in Ihrer Organisation loszulegen, besteht darin, ein Lakehouse, eine Delta-Tabelle im Lakehouse und dann ein einfaches Semantikmodell für das Lakehouse in Ihrem Microsoft Fabric-Arbeitsbereich zu erstellen. Weitere Informationen finden Sie unter Erstellen eines Lakehouse für Direct Lake.

Zugehöriger Inhalt

• Erstellen eines Lakehouse für Direct Lake
• Analysieren der Abfrageverarbeitung für Direct Lake-Semantikmodelle