Ü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-Tabellenin 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 Speichermodus „Direct Lake“ verwenden, um eine Verbindung zu den Tabellen oder Ansichten eines einzelnen Fabric-Lakehouse oder Fabric-Warehouse herzustellen. Beide Fabric-Elemente und Direct Lake-Semantikmodelle erfordern eine Fabric-Kapazitätslizenz.
Auf irgendeine Weise ä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 von DirectQuery-Fallback-, die 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 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 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.
Anmerkung
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 den Direct Lake-Speichermodus ist typischerweise IT-gesteuerte Analyseprojekte, die auf seezentrierte Architekturen setzen. 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.
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 werden durch die OneLake-Integration Daten für Tabellen im Import-Speichermodus automatisch in Delta-Tabellen in OneLake geschrieben, ohne dass ein Migrationsaufwand entsteht. Mithilfe dieser Option können Sie viele der Vorzüge von Fabric nutzen, die den Benutzern des Importsemantikmodells zur Verfügung gestellt werden, z. B. die Integration in Lakehouses über Verknüpfungen, SQL-Abfragen, Notizbücher und 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 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 geben an das Semantikmodell gesendete Abfragen die neuesten Daten zurück. Diese Funktion lässt sich gut mit der automatischen Seitenaktualisierung von Power BI-Berichten kombinieren.
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. wenn ein Self-Service-Analyst 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.
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
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.
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.
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 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 zeigt die folgenden Benutzeraktionen, Prozesse und Features.
| Element | Beschreibung |
|---|---|
|
OneLake ist ein Data Lake, der Analysedaten im Parquet-Format speichert. Dieses Dateiformat ist optimiert zum Speichern von Daten für Direct Lake-Semantikmodelle. |
|
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 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 ist mit Tabellen oder Ansichten im Lakehouse oder im Warehouse verbunden. |
|
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 speicherinterne Leistung, die 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 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.
Framing
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.
Beachten Sie, dass das Semantikmodell das Delta-Protokoll jeder Delta-Tabelle während des Framings analysiert, um nur die betroffenen Spaltensegmente abzulegen 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.
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.
Weitere Informationen zur Versionsverwaltung und -rahmenung von Delta-Tabellen finden Sie unter Grundlegendes zum Speicher für 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
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 Rahmenvorgangs 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 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 das Fallback-Verhalten Ihrer Direct Lake-Semantikmodelle steuern, indem Sie die DirectLakeBehavior-Eigenschaft festlegen. 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ä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 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 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 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 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 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 Direct Lake-Semantikmodelltabellen nicht mit Tabellen in anderen Speichermodi wie Import, DirectQuery oder Dual gemischt werden können (mit Ausnahme von Sonderfällen, einschließlich Berechnungsgruppen, Was-wäre-wenn-Parameterund 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-Parameterund 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, dass die Datentypen der verwandten Spalten übereinstimmen.
- Einseitige Beziehungsspalten müssen eindeutige Werte enthalten. Abfragen schlagen fehl, wenn doppelte Werte in einer einseitigen Spalte erkannt werden.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 Mitwirkendenberechtigung für den Dienstprinzipal oder höhere Berechtigungen zu.
- Das Einbetten von Berichten erfordert ein V2-Einbettungstoken.
- Direct Lake unterstützt keine Dienstprinzipalprofile für die Authentifizierung.
- Angepasste semantische Direct Lake-Modelle, die von Service Principal und Viewer mit Service Principal erstellt wurden, werden unterstützt, aber standard-Direct Lake-Semantikmodelle werden nicht unterstützt.
Vergleich zu anderen Speichermodi
In der folgenden Tabelle wird der Direct Lake-Speichermodus mit dem Import- und DirectQuery-Speichermodus verglichen.
| Fähigkeit | Direkter See | Importieren | DirectQuery |
|---|---|---|---|
| Zulassung | 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 Lakehouse- oder Warehousetabellen (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-Speicher-Modus-Tabellen 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-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 | Nein | Ja | Ja |
| Hybridtabellen | Nein | Ja | Ja |
| Modelltabellenpartitionen | 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 | 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 Semantikmodellzeilenebene (RLS) | Ja – es wird jedoch dringend empfohlen, eine feste Identität Cloudverbindung 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 bei programmgesteuertem Reframing. Allerdings muss die Datenaufbereitung zuerst erfolgen | Nein | Ja |
| Power BI Embedded | Ja 2 | Ja | 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 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.