Ü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. Es ist für große Datenmengen optimiert, die schnell aus Delta-Tabellen in den Speicher geladen werden können, die ihre Daten in Parkettdateien in OneLake speichern – der einzige Speicher für alle Analysedaten. Nach dem Laden in den Arbeitsspeicher ermöglicht das Semantikmodell Hochleistungsabfragen. Direct Lake beseitigt die langsame und kostspielige Notwendigkeit, Daten in das Modell zu importieren.
Sie können den Direct Lake-Speichermodus verwenden, um eine Verbindung mit den Tabellen oder Ansichten eines einzelnen Fabric Lakehouse oder Fabric Warehouse herzustellen. Beide Fabric-Elemente und Direct Lake-Semantikmodelle erfordern eine Fabric-Kapazitätslizenz.
In einigen Fällen ähnelt ein Direct Lake-Semantikmodell einem Importsemantikmodell. Das liegt daran, dass Modelldaten vom VertiPaq-Modul für eine schnelle Abfrageleistung in den Arbeitsspeicher geladen werden (mit Ausnahme des DirectQuery-Fallbacks, der weiter unten in diesem Artikel erläutert wird).
Ein Direct Lake-Semantikmodell unterscheidet sich jedoch von einem Importsemantikmodell in einer wichtigen Weise. Das liegt daran, dass sich ein Aktualisierungsvorgang für ein Direct Lake-Semantikmodell von einem Aktualisierungsvorgang für ein Importsemantikmodell unterscheidet. Bei einem Direct Lake-Semantikmodell umfasst eine Aktualisierung einen Rahmenvorgang (weiter unten 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 für ein Importsemantikmodell eine Kopie der Daten, die erhebliche Zeit in Anspruch nehmen und erhebliche Datenquellen- und Kapazitätsressourcen (Arbeitsspeicher und CPU) verbrauchen kann.
Hinweis
Die inkrementelle Aktualisierung für ein Importsemantikmodell kann dazu beitragen, die Aktualisierungszeit und den Einsatz von Kapazitätsressourcen zu reduzieren.
Wann sollten Sie den Direct Lake-Speichermodus verwenden?
Der primäre Anwendungsfall für einen Direct Lake-Speichermodus ist in der Regel für IT-gesteuerte Analyseprojekte, die seeorientierte Architekturen nutzen. In diesem Szenario haben Sie große Datenmengen in OneLake – oder erwarten Sie, dass sie sich ansammeln. 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.
Hinweis
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. Mithilfe dieser Option können Sie viele der Vorteile von Fabric erkennen, die Benutzern des Importsemantikmodells zur Verfügung gestellt werden, z. B. die Integration in Seehäuser über Verknüpfungen, SQL-Abfragen, Notizbücher und vieles mehr. Es wird empfohlen, diese Option als schnelle Möglichkeit zu betrachten, um die Vorteile von Fabric zu nutzen, ohne notwendigerweise oder sofort ihr vorhandenes Data Warehouse und/oder Analysesystem neu zu entwerfen.
Der Direct Lake-Speichermodus eignet sich auch für die Minimierung der Datenlatenz, um Daten für Geschäftsbenutzer schnell verfügbar zu machen. Wenn Ihre Delta-Tabellen zeitweise geändert werden (und vorausgesetzt, Sie haben die Datenvorbereitung bereits im Data Lake vorgenommen), können Sie von automatischen Aktualisierungen abhängig sein, die als Reaktion auf diese Änderungen neu angepasst werden. In diesem Fall geben an das Semantikmodell gesendete Abfragen die neuesten Daten zurück. Diese Funktion funktioniert gut in Zusammenarbeit mit dem Feature für die automatische Seitenaktualisierung von Power BI-Berichten.
Denken Sie daran, dass Direct Lake von der Datenvorbereitung im Datensee abhängt. 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. Mit diesem Ansatz wird sichergestellt, dass die Datenvorbereitungslogik in der Architektur so gering wie möglich ausgefü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. im Fall eines Self-Service-Analysten, der möglicherweise keine Schreibberechtigungen für ein Seehaus besitzt, das von der IT verwaltet wird, ist der Importspeichermodus möglicherweise eine bessere Wahl. Das liegt daran, dass sie die Datenvorbereitung mithilfe von Power Query unterstützt, das als Teil des semantischen Modells definiert ist.
Achten Sie darauf, ihre aktuelle Fabric-Kapazitätslizenz und die Fabric-Kapazitätsschutzschienen zu berücksichtigen, wenn Sie den Direct Lake-Speichermodus in Betracht ziehen. Berücksichtigen Sie außerdem die Überlegungen und Einschränkungen, die weiter unten in diesem Artikel beschrieben werden.
Tipp
Es wird empfohlen, einen Prototyp oder einen Machbarkeitsnachweis (PoC) zu erstellen, um zu bestimmen, ob ein Direct Lake-Semantikmodell die richtige Lösung ist und um Risiken zu minimieren.
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 ist eine oder mehrere Parkettdateien in OneLake. Geparkte Dateien organisieren Daten nach Spalten und nicht nach Zeilen. Semantische Modelle laden ganze Spalten aus Delta-Tabellen in den Arbeitsspeicher, da sie von Abfragen benötigt werden.
Ein Direct Lake-Semantikmodell kann auch DirectQuery-Fallback verwenden, was einen nahtlosen Wechsel zum DirectQuery-Modus erfordert. DirectQuery-Fallback ruft Daten direkt vom SQL-Analyseendpunkt des Lakehouse oder des Lagers ab. Fallback kann beispielsweise auftreten, wenn eine Delta-Tabelle mehr Datenzeilen enthält als von Der Fabric-Kapazität unterstützt (weiter unten in diesem Artikel beschrieben). In diesem Fall sendet ein DirectQuery-Vorgang eine Abfrage an den SQL-Analyseendpunkt. Fallbackvorgänge können zu einer langsameren Abfrageleistung führen.
Das folgende Diagramm zeigt, wie Direct Lake mithilfe des Szenarios eines Benutzers funktioniert, der einen Power BI-Bericht öffnet.
Das Diagramm veranschaulicht die folgenden Benutzeraktionen, Prozesse und Features.
| Artikel | Beschreibung |
|---|---|
 |
OneLake ist ein Data Lake, der Analysedaten im Parkettformat speichert. Dieses Dateiformat ist für das Speichern von Daten für Direct Lake-Semantikmodelle optimiert . |
 |
Ein Fabric Lakehouse oder Fabric Warehouse ist in einem Arbeitsbereich vorhanden, der sich auf Fabric-Kapazität befindet. Das Lakehouse verfügt über einen SQL-Analyseendpunkt, der eine SQL-basierte Benutzeroberfläche für abfragen bietet. Tabellen (oder Ansichten) bieten eine Möglichkeit, die Delta-Tabellen in OneLake mithilfe von Transact-SQL (T-SQL) abzufragen. |
 |
In einem Fabric-Arbeitsbereich ist ein Direct Lake-Semantikmodell vorhanden. Es verbindet sich mit Tischen oder Ansichten im Seehaus oder Lagerhaus. |
 |
Ein Benutzer ö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 semantische Modell Spalten direkt aus den in OneLake gespeicherten Parkettdateien in den Speicher. Abfragen erzielen eine in-Memory-Leistung, was sehr schnell ist. |
 |
Das semantische Modell gibt Abfrageergebnisse zurück. |
 |
Der Power BI-Bericht rendert die visuellen Elemente. |
 |
Unter bestimmten Umständen, z. B. wenn das semantische Modell die Guardrails der Kapazität überschreitet, fallen Semantikmodellabfragen automatisch auf den DirectQuery-Modus zurück. In diesem Modus werden Abfragen an den SQL-Analyseendpunkt des Lakehouse oder Warehouse gesendet. |
 |
DirectQuery-Abfragen, die an den SQL-Analyseendpunkt gesendet wurden, fragen wiederum die Delta-Tabellen in OneLake ab. Aus diesem Grund ist die Abfrageleistung möglicherweise langsamer als In-Memory-Abfragen. |
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 nur Daten aus OneLake als und wenn Spalten zum ersten Mal abgefragt werden. Der Prozess des Ladens von Daten bei Bedarf 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. Erforderliche Spalten umfassen alle Spalten, die direkt von der Abfrage verwendet werden, sowie Spalten, die für Beziehungen und Measures 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.
Nachdem sie verstanden hat, welche Spalten benötigt werden, bestimmt das Semantikmodell, welche Spalten bereits im Arbeitsspeicher vorhanden sind. 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 sehr schneller Vorgang, kann jedoch von Faktoren wie der Kardinalität der in den Spalten gespeicherten Daten abhängen.
Spalten, die in den Arbeitsspeicher geladen werden, befinden sich dann im Arbeitsspeicher. Zukünftige Abfragen, die nur residente Spalten umfassen, müssen keine weiteren Spalten in den Arbeitsspeicher laden.
Eine Spalte bleibt resident, bis der Grund dafür besteht, dass sie aus dem Speicher entfernt (entfernt) werden soll. Gründe für das Entfernen von Spalten sind:
- Das Modell oder die Tabelle wurde aktualisiert (siehe Framing im nächsten Abschnitt).
- Für einige Zeit wurde die Spalte nicht 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 für die Kapazität. Weitere Informationen zu Ressourcenschutzläufen und maximalen Speichergrenzwerten finden Sie unter Fabric-Kapazitätsschutzschienen und Einschränkungen weiter unten in diesem Artikel.
Rahmung
Framing bietet Modellbesitzern die Point-in-Time-Kontrolle darüber, welche Daten in das semantische Modell geladen werden. Framing ist ein Direct Lake-Vorgang, der durch eine Aktualisierung eines semantischen Modells ausgelöst wird, und in den meisten Fällen dauert es nur ein paar Sekunden, bis es 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 die Rahmenung 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 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 am Punkt des letzten Rahmenvorgangs zurückzugeben. Diese Zeit ist nicht unbedingt der neueste Status der Delta-Tabellen.
Das folgende Diagramm zeigt, wie Direct Lake-Rahmenvorgänge funktionieren.
Das Diagramm zeigt die folgenden Prozesse und Features.
| Artikel | Beschreibung |
|---|---|
|
Ein semantisches Modell ist in einem Fabric-Arbeitsbereich vorhanden. |
|
Rahmenvorgänge werden regelmäßig durchgeführt, und sie legen den Basisplan für alle zukünftigen Transcodierungsereignisse fest. Rahmenvorgä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 Rahmenvorgang umfasst Parkettdateien im Zusammenhang mit den Delta-Tischen und insbesondere die Parkettdateien, die vor dem letzten Rahmenvorgang hinzugefügt wurden. |
|
Eine spätere Umrahmung umfasst Parkettdateien, die nach dem letzten Rahmenvorgang hinzugefügt wurden. |
|
Resident columns in the Direct Lake semantic model might be viced from memory, and the point in time of the refresh wird the new baseline for all future transcoding events. |
|
Nachfolgende Datenänderungen, dargestellt durch neue Parkettdateien, sind erst sichtbar, wenn der nächste Rahmenvorgang erfolgt. |
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.
Weitere Informationen zur Versionsverwaltung und -rahmenung von Delta-Tabellen finden Sie unter "Grundlegendes zum Speicher für Direct Lake-Semantikmodelle".
Automatische Aktualisierungen
Es gibt eine Einstellung auf semantischer Modellebene, um Direct Lake-Tabellen automatisch zu aktualisieren. Standardmäßig ist sie 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 ein Feature, das automatisch eine bestimmte Berichtsseite aktualisiert, die bereitstellt, dass der Bericht eine Verbindung mit einem Direct Lake-Semantikmodell (oder anderen Arten von Semantikmodell) herstellt.
DirectQuery-Fallback
Eine an ein Direct Lake-Semantikmodell gesendete Abfrage kann auf den DirectQuery-Modus zurückgesetzt werden. In diesem Fall werden 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 Rahmenvorgangs beschränkt sind.
Eine Abfrage fällt immer zurück, 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 zurückfallen, wenn das semantische Modell die Schutzschienen 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 Fallbacks Ihrer Direct Lake-Semantikmodelle steuern, indem Sie die DirectLakeBehavior-Eigenschaft festlegen. Weitere Informationen finden Sie unter Festlegen der Direct Lake-Verhaltenseigenschaft.
Fabric-Kapazitätsschutzschienen und Einschränkungen
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). Beachten Sie, dass Microsoft Kaufoptionen konsolidiert und die Power BI Premium pro Kapazitäts-SKUs zurückgibt. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F-SKUs) in Betracht ziehen.
Weitere Informationen finden Sie unter Wichtigen 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) | 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 Bei Direct Lake-Semantikmodellen stellt Max Memory den oberen Speicherressourcengrenzwert für die Menge der Daten dar, in die einGelagert werden kann. 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 dieser Wert überschritten wird, führt die Maximale Modellgröße auf datenträger/OneLake dazu, dass alle Abfragen auf das semantische Modell auf den DirectQuery-Modus zurückgesetzt werden. Alle anderen in der Tabelle dargestellten Schutzläufe werden pro Abfrage ausgewertet. Daher ist es wichtig, dass Sie Ihre Delta-Tabellen und das Direct Lake-Semantikmodell optimieren, um zu vermeiden, dass Sie unnötig auf eine höhere Fabric-SKU skalieren müssen (was zu höheren Kosten führt).
Darüber hinaus gelten Kapazitätseinheiten und max. Arbeitsspeicher pro Abfragegrenzwert 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.
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 Direct Lake-Semantikmodelltabelle eine Verbindung mit einer Tabelle im SQL-Analyseendpunkt herstellt, die die Sicherheit auf Zeilenebene (RLS) erzwingt, fallen Abfragen, die diese Modelltabelle einbeziehen, immer auf den DirectQuery-Modus zurück. Die Abfrageleistung ist möglicherweise langsamer.
- Wenn eine Direct Lake-Semantikmodelltabelle eine Verbindung mit einer Ansicht im SQL-Analyseendpunkt herstellt, fallen Abfragen, die diese Modelltabelle einbeziehen, immer auf den DirectQuery-Modus zurück. Die Abfrageleistung ist möglicherweise langsamer.
- Die zusammengesetzte Modellierung wird nicht unterstützt. Dies bedeutet, dass Tabellen des Direct Lake-Semantikmodells nicht mit Tabellen in anderen Speichermodi gemischt werden können, z. B. Import, DirectQuery oder Dual (mit Ausnahme von Sonderfällen, einschließlich Berechnungsgruppen, Was-wäre-wenn-Parameter und Feldparameter).
- Berechnete Spalten und berechnete Tabellen, die auf Spalten oder Tabellen im Direct Lake-Speichermodus verweisen, werden nicht unterstützt. Berechnungsgruppen, Was-wäre-wenn-Parameter und Feldparameter, die implizit berechnete Tabellen erstellen, und berechnete Tabellen, die nicht auf Direct Lake-Spalten oder -Tabellen verweisen, werden 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.
- Tabellenbeziehungen erfordern die Datentypen verwandter Spalten, die übereinstimmen.
- Einseitige Spalten von Beziehungen müssen eindeutige Werte enthalten. Abfragen schlagen fehl, wenn doppelte Werte in einer einseitigen Spalte 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 (keine Zahl) wird nicht unterstützt.
- Einbettungsszenarien, die das Szenario für die Kundennutzung 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. 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.
- 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 der Grenzwert überschritten wird, können Abfragen am semantischen Modell aufgrund übermäßiger Auslagerungen in und außerhalb der Modelldaten langsamer sein.
- 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 und verknüpfung mit den Tabellen zu erstellen, bevor Sie das Semantikmodell erstellen. Informationen dazu, in welcher Region Sie sich befinden, finden Sie unter "Fabric Home Region".
Vergleich zu anderen Speichermodi
In der folgenden Tabelle wird der Direct Lake-Speichermodus mit dem Import- und DirectQuery-Speichermodus verglichen.
| Funktion | Direct Lake | Import | DirectQuery |
|---|---|---|---|
| Lizenzierung | 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 | Nur Seehaus- oder Lagertische (oder Ansichten) | Jeder Verbinder | 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 semantischen Modell-RLS duplizieren | Ja |
| Sicherheit auf Semantikmodellzeilenebene (RLS) | Ja – es wird jedoch dringend empfohlen, eine feste Identitätscloudverbindung zu verwenden. | Ja | Ja |
| Sicherheit auf Semantikmodellobjektebene (OLS) | Ja | Ja | Ja |
| Große Datenvolumes ohne Aktualisierungsanforderung | 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 programmgesteuertes Reframing; die Datenvorbereitung muss jedoch zuerst vorgelagert erfolgen. | No | Ja |
1 Sie können Tabellen im Direct Lake-Speichermodus nicht mit DirectQuery- oder Dualspeichermodustabellen 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 für ein semantisches Modell.