Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Direct Lake ist eine Power BI-Semantikmodell-Speichermodusoption, die in Microsoft Fabric verfügbar ist. Es ist für große Datenmengen optimiert, um schnell in den Arbeitsspeicher aus Delta-Tabellen geladen zu werden, die im OneLake verfügbar sind – der einzelne Speicher für alle Analysedaten. Nach dem Laden in den Arbeitsspeicher ermöglicht das Semantikmodell eine interaktive Hochleistungsanalyse.
Direct Lake eignet sich ideal für semantische Modelle, die mit großen Fabric Lakehouses, Warehouses und anderen Fabric-Datenquellen mit Delta-Tabellen verbunden sind. Direct Lake ist besonders nützlich, wenn es schwierig oder unmöglich ist, das gesamte Datenvolumen in eine Importtabelle zu replizieren. Direct Lake- und Importabfragen werden vom VertiPaq-Abfragemodul verarbeitet, während DirectQuery Abfragen zur zugrunde liegenden Datenquelle verknüpft. Direct Lake- und Importabfragen übersteigen normalerweise DirectQuery-Abfragen beim Laden und Interagieren mit visuellen Elementen in Berichten.
Ein Direct Lake unterscheidet sich jedoch von einem Importmodus in einer wichtigen Weise: Ein Aktualisierungsvorgang für ein Direct Lake-Semantikmodell unterscheidet sich konzeptionell von einem Aktualisierungsvorgang für ein Importsemantikmodell. Im Importmodus werden die Daten repliziert und eine gesamte zwischengespeicherte Kopie der Daten für das semantische Modell erstellt, während eine Direct Lake-Aktualisierung nur Metadaten kopiert (wie weiter unten in diesem Artikel beschrieben), was einige Sekunden dauern kann. Die Direct Lake-Aktualisierung ist ein kostengünstiger Vorgang, der die Metadaten der neuesten Version der Delta-Tabellen analysiert und aktualisiert wird, um auf die neuesten Dateien in OneLake zu verweisen. Im Gegensatz dazu erzeugt eine Importaktualisierung eine Kopie der Daten, die erhebliche Zeit in Anspruch nehmen und erhebliche Datenquellen- und Kapazitätsressourcen (Arbeitsspeicher und CPU) verbrauchen kann. Direct Lake verschiebt die Datenvorbereitung auf OneLake und verwendet dabei die gesamte Breite der Fabric-Technologien für die Datenvorbereitung, einschließlich Spark-Aufträge, T-SQL-DML-Anweisungen, Datenflüsse, Pipelines und vieles mehr.
Der Direct Lake-Speichermodus bietet die folgenden wichtigsten Vorteile:
- Ähnlich wie im Importmodus werden Direct Lake-Abfragen vom VertiPaq-Modul verarbeitet und stellen somit die Abfrageleistung bereit, die mit dem Importmodus vergleichbar ist, ohne dass der Verwaltungsaufwand für Datenaktualisierungszyklen zum Laden des gesamten Datenvolumes besteht.
- Verwendet vorhandene Fabric-Investitionen, indem sie nahtlos in große Seehäuser, Lagerhäuser und andere Fabric-Quellen mit Delta-Tabellen integriert werden. Beispielsweise ist Direct Lake eine ideale Wahl für die Goldanalyseschicht in der Medallion Lakehouse-Architektur.
- Maximiert die Rendite (Return on Investment, ROI), da analysierte Datenvolumes die maximalen Speichergrenzwerte der Kapazität überschreiten können, da nur die Daten, die zum Beantworten einer Abfrage benötigt werden, in den Arbeitsspeicher geladen werden.
- Minimiert die Datenlatenz, indem ein semantisches Modell schnell und automatisch mit seinen Quellen synchronisiert wird und neue Daten für Geschäftsbenutzer ohne Aktualisierungszeitpläne zur Verfügung gestellt werden.
Wann sollten Sie den Direct Lake-Speichermodus verwenden?
Der primäre Anwendungsfall für den Direct Lake Speichermodus sind normalerweise IT-gesteuerte Analyseprojekte, die lake-zentrierte Architekturen verwenden. In solchen Szenarien haben Oder erwarten Sie, dass große Datenmengen in OneLake gesammelt werden. Das schnelle Laden dieser Daten in den Arbeitsspeicher, häufige und schnelle Aktualisierungsvorgänge, die effiziente Nutzung von Kapazitätsressourcen und die schnelle Abfrageleistung sind für diesen Anwendungsfall wichtig.
Anmerkung
Import- und DirectQuery-Tabellen in semantischen Modellen sind weiterhin in Fabric relevant, und sie sind für einige Szenarien die richtige Wahl des Semantikmodells. 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.
Ein semantisches Modell mit Importtabellen und Direct Lake-Tabellen bietet auch Flexibilität bei Bedarf für viele BI-Szenarien.
Außerdem schreibt die OneLake-Integration automatisch Daten für Tabellen im Importspeichermodus in Delta-Tabellen in OneLake ohne Migrationsaufwand, sodass Sie viele der Vorteile von Fabric erkennen können, die Benutzern des Importsemantikmodells zur Verfügung gestellt werden, z. B. die Integration mit Lakehouses über Verknüpfungen, SQL-Abfragen, Notizbücher usw. Wir empfehlen diese Option als schnelle Möglichkeit, die Vorteile von Fabric zu nutzen, ohne unbedingt oder sofort Ihr vorhandenes Data Warehouse und/oder Analysesystem neu zu gestalten.
Direct Lake hängt davon ab, dass die Datenvorbereitung im Datensee erfolgt. Die Datenvorbereitung kann mithilfe verschiedener Tools erfolgen, z. B. Spark-Aufträge für Fabric Lakehouses, T-SQL DML-Anweisungen für Fabric Warehouses, Dataflows, Pipelines und andere, wodurch sichergestellt wird, dass die Datenvorbereitungslogik in der Architektur vorgelagert durchgeführt wird, um die Wiederverwendbarkeit zu maximieren. Wenn der Autor des semantischen Modells jedoch nicht in der Lage ist, das Quellelement zu ändern, z. B. wenn ein Self-Service-Analyst keine Schreibberechtigungen für ein Lakehouse hat, das von der IT verwaltet wird, kann das Erweitern des Modells mit Tabellen im Importmodus eine gute Wahl sein, da der Importmodus die Datenvorbereitung mithilfe von Power Query unterstützt, das als Teil des semantischen Modells definiert ist.
Achten Sie darauf, dass Sie Ihre aktuelle Fabric-Kapazitätslizenz und die Fabric-Kapazitätsschutzschienen berücksichtigen, wenn Sie den Direct Lake-Speichermodus in Betracht ziehen. Berücksichtigen Sie auch die Überlegungen und Einschränkungen, die weiter unten in diesem Artikel beschrieben werden.
Tipp
Es wird empfohlen, einen Prototypoder einen Machbarkeitsnachweis (POC) zu erstellen, um zu bestimmen, ob ein Direct Lake-Semantikmodell die richtige Lösung ist und um Risiken zu minimieren.
Kernkonzepte und Terminologie
In diesem Artikel wird vorausgesetzt, dass Sie mit den folgenden Konzepten vertraut sind:
- Benutzer laden und interagieren mit visuellen Elementen in Power BI-Berichten, die DAX-Abfragen für das semantische Modell generieren.
-
Speichermodus: Das semantische Modell verarbeitet die DAX-Abfragen je nach verwendeter Tabellenspeichermodus unterschiedlich. Beispiel:
- Import- und Direct Lake-Speichermodi verwenden das VertiPaq-Modul, um DAX-Abfragen zu verarbeiten und Ergebnisse an den Power BI-Bericht und den Benutzer zurückzugeben.
- DirectQuery übersetzt DAX-Abfragen in die Abfragesyntax der Datenquelle, z. B. eine SQL-Abfrage, und führt sie in der zugrunde liegenden Quelldatenbank aus. Diese Quelldatenbanken sind in der Regel nicht für hohe Abfragelasten optimiert, die von Berichten und aggregierten Abfragen stammen, die von den visuellen Elementen benötigt werden. Dies kann zu einer langsameren Leistung im Vergleich zu Import- und Direct Lake-Modi führen.
Der Speichermodus ist eine Eigenschaft einer Tabelle im semantischen Modell. Wenn ein semantisches Modell Tabellen mit verschiedenen Speichermodi enthält, wird es als zusammengesetztes Modell bezeichnet. Weitere Informationen zu Speichermodi finden Sie unter Semantikmodellmodi im Power BI-Dienst.
Der Speichermodus für direct Lake-Tabellen verfügt über zwei Optionen:
- Direct Lake auf OneLake kann Daten aus einer oder mehreren Fabric-Datenquellen mit Delta-Tabellen verwenden. Direct Lake auf OneLake fällt nicht über den SQL-Analyseendpunkt der Datenquelle auf den DirectQuery-Modus zurück. Semantische Modelle mit Direct Lake in OneLake-Tabellen können auch Importtabellen aus anderen Datenquellen hinzufügen lassen.
Anmerkung
Direct Lake auf OneLake befindet sich derzeit in der öffentlichen Vorschau. Aktivieren Sie die Mandanteneinstellung Benutzer können Direct Lake auf OneLake-Semantikmodellen erstellen (Vorschau) im Verwaltungsportal, um semantische Modelle mit diesem Tabellenspeichermodus zu erstellen. Bereits erstellte Semantikmodelle werden von dieser Mandanteneinstellung nicht beeinflusst.
- Direct Lake auf SQL kann die Daten aus einer einzelnen Fabric-Datenquelle mit Delta-Tabellen verwenden. Der SQL-Analyseendpunkt wird für Delta-Tabellen- und SQL-Ansichtsermittlungs- und Berechtigungsprüfungen verwendet. Direct Lake auf SQL-Endpunkten greifen auf den DirectQuery-Tabellenspeichermodus zurück, wenn die Daten nicht direkt aus einer Delta-Tabelle geladen werden können, z. B. wenn die Datenquelle eine SQL-Ansicht ist oder wenn das Warehouse SQL-basierte granulare Zugriffssteuerung verwendet. Die Semantikmodelleigenschaft , Direct Lake-Verhalten, steuert das Fallbackverhalten.
Vergleich der Speichermodi
In der folgenden Tabelle wird der Direct Lake-Speichermodus mit dem Import- und DirectQuery-Speichermodus verglichen.
| Fähigkeit | Direkter See auf OneLake | Direct Lake auf SQL-Endpunkten | Importieren | Direktabfrage |
|---|---|---|---|---|
| Mandanteneinstellung | Aktivieren Sie die Mandanteneinstellung Benutzer kann Direct Lake auf OneLake-Semantikmodellen (Vorschau) im Verwaltungsportal erstellen. | Für alle Mandanten aktiviert. | Für alle Mandanten aktiviert. | Für alle Mandanten aktiviert. |
| Zulassung | Nur Fabric-Kapazitätsabonnement (SKUs) | Nur Fabric-Kapazitätsabonnement (SKUs) | Beliebige Fabric- oder Power BI-Lizenz (einschließlich Microsoft Fabric Free-Lizenzen) | Beliebige Fabric- oder Power BI-Lizenz (einschließlich Microsoft Fabric Free-Lizenzen) |
| Datenquelle | Tabellen einer beliebigen Fabric-Datenquelle, die von Delta-Tabellen unterstützt werden | Nur Lakehouse- oder Warehousetabellen (oder Ansichten) | Jeder Verbinder | Jeder Connector, der den DirectQuery-Modus unterstützt |
| Herstellen einer Verbindung mit SQL Analytics-Endpunktansichten | Nein | Ja – wird aber automatisch auf den DirectQuery-Modus zurückgesetzt | Ja | Ja |
| Zusammengesetzte Modelle | Ja – kann mit Importspeichermodustabellen in Power BI-Webmodellierung und DirectQuery-Tabellen mit XMLA-Tools kombiniert werden. | Nein 1 | Ja – kann mit DirectQuery-, Dual- und Direct Lake-Speichermodustabellen kombiniert werden. | Ja – kann mit Tabellen für den Import-, Dual- und Direct Lake-Speichermodus kombiniert werden. |
| Einmaliges Anmelden (Single Sign-On, SSO) | Ja | Ja | Nicht zutreffend | Ja |
| Berechnete Tabellen | Ja – Aber Berechnungen können nicht auf Tabellenspalten im Direct Lake-Modus verweisen. | Nein – außer Berechnungsgruppen, Was-wäre-wenn-Parameterund Feldparameter, die implizit berechnete Tabellen erstellen | Ja | Nein – Berechnete Tabellen verwenden den Importspeichermodus auch dann, wenn sie auf andere Tabellen im DirectQuery-Modus verweisen |
| Berechnete Spalten | Nein | Nein | Ja | Ja |
| Hybridtabellen | Nein | Nein | Ja | Ja |
| Modelltabellenpartitionen | Nein – Partitionierung kann jedoch auf Delta-Tabellenebene erfolgen | Nein – Partitionierung kann jedoch auf Delta-Tabellenebene erfolgen | Ja – entweder automatisch durch inkrementelle Aktualisierung oder manuell mithilfe des XMLA-Endpunkts erstellt | Nein |
| Benutzerdefinierte Aggregationen | Nein | Nein | Ja – Das Importieren von Aggregationstabellen in DirectQuery-Tabellen wird unterstützt. | Ja |
| Sicherheit auf Sql Analytics-Endpunktebene oder Sicherheit auf Spaltenebene | Nein | Ja – kann jedoch Fehler erzeugen, wenn die Berechtigung verweigert wird | Ja – muss jedoch Berechtigungen mit Sicherheit auf Objektebene auf Semantikmodellebene duplizieren | Ja – Aber Abfragen können Fehler erzeugen, wenn die Berechtigung verweigert wird |
| Sicherheit auf SQL Analytics-Endpunktzeilenebene (RLS) | Nein | Ja – Aber Abfragen werden auf den DirectQuery-Modus zurückgesetzt | Ja – muss jedoch Berechtigungen mit Semantikmodell-RLS duplizieren | Ja |
| Sicherheit auf Semantikmodellzeilenebene (RLS) | Ja – es wird jedoch dringend empfohlen, eine feste Identität Cloudverbindung zu verwenden. | Ja – es wird jedoch dringend empfohlen, eine feste Identität Cloudverbindung zu verwenden. | Ja | Ja |
| Sicherheit auf Semantikmodellobjektebene (OLS) | Ja | Ja | Ja | Ja |
| Große Datenvolumes ohne Aktualisierungsanforderung | Ja | Ja | Nein | Ja |
| Verringern der Datenlatenz | Ja – wenn automatische Updates aktiviert sind oder programmgesteuertes Reframing | Ja – wenn automatische Updates aktiviert sind oder programmgesteuertes Reframing | Nein | Ja |
| Power BI Eingebettet | Ja 2 | Ja 2 | Ja | Ja |
1 Wenn Sie Direct Lake auf SQL-Endpunkten verwenden, können Sie Tabellen im Direct Lake-Speichermodus nicht mit DirectQuery- oder Dual-Speichermodustabellen im selben Semantikmodell kombinieren. Sie können power BI Desktop jedoch verwenden, um ein zusammengesetztes Modell in einem Direct Lake-Semantikmodell zu erstellen und es dann mit neuen Tabellen (mithilfe des Import-, DirectQuery- oder Dual-Speichermodus) oder Berechnungen zu erweitern. Weitere Informationen finden Sie unter Erstellen eines zusammengesetzten Modells auf einem semantischen Modell.
2 Erfordert ein V2-Embed-Token. Wenn Sie einen Dienstprinzipal verwenden, müssen Sie eine Cloudverbindung mit fester Identität verwenden.
Funktionsweise von Direct Lake
In der Regel werden Abfragen, die an ein Direct Lake-Semantikmodell gesendet werden, aus einem Speichercache der Spalten verarbeitet, die aus Delta-Tabellen stammen. Der zugrunde liegende Speicher für eine Delta-Tabelle besteht aus einer oder mehreren Parquet-Dateien in OneLake. Parquet-Dateien organisieren Daten spaltenweise und nicht zeilenweise. Semantische Modelle laden ganze Spalten aus Delta-Tabellen in den Arbeitsspeicher, da sie von Abfragen benötigt werden.
Direct Lake auf OneLake ist nicht mit dem SQL-Endpunkt gekoppelt und bietet eine engere Integration in OneLake-Features wie OneLake-Sicherheit und effizientere DAX-Abfragepläne, da beispielsweise die Überprüfung auf SQL-basierte Sicherheit nicht erforderlich ist. DirectQuery-Fallback wird von Direct Lake auf OneLake nicht unterstützt.
Bei Direct Lake auf SQL-Endpunkten kann eine DAX-Abfrage DirectQuery-Fallback verwenden, was einen nahtlosen Wechsel zum DirectQuery-Modus erfordert. Beim DirectQuery-Fallback werden Daten direkt vom SQL-Analyse-Endpunkt des Lakehouse oder des Warehouse abgerufen. Fallback tritt beispielsweise auf, wenn sql-basierte Sicherheit im SQL-Endpunkt erkannt wird. In diesem Fall sendet ein DirectQuery-Vorgang eine Abfrage an den SQL-Analyseendpunkt. Fallbackvorgänge können zu einer langsameren Abfrageleistung führen.
In den folgenden Abschnitten werden Direct Lake-Konzepte und -Features beschrieben, einschließlich Spaltenladevorgang, Rahmen, automatische Updates und DirectQuery-Fallback.
Laden von Spalten (Transcodierung)
Direct Lake-Semantikmodelle laden Daten aus OneLake nur dann, wenn Spalten zum ersten Mal abgefragt werden. Der Prozess des Ladens von Daten auf Abruf von OneLake wird als Transcodierung bezeichnet.
Wenn das semantische Modell eine DAX-Abfrage (oder eine MDX-Abfrage) empfängt, bestimmt es zuerst, welche Spalten erforderlich sind, um ein Abfrageergebnis zu erzeugen. Jede Spalte, die direkt in der Abfrage verwendet wird, wird benötigt, ebenso wie Spalten, die aufgrund von Beziehungen und Maßnahmen erforderlich sind. In der Regel ist die Anzahl der Spalten, die zum Erstellen eines Abfrageergebnisses erforderlich sind, wesentlich kleiner als die Anzahl der spalten, die im semantischen Modell definiert sind.
Sobald es versteht, welche Spalten benötigt werden, bestimmt das Semantikmodell, welche Spalten sich bereits im Arbeitsspeicher befinden. Wenn spalten, die für die Abfrage benötigt werden, nicht im Arbeitsspeicher enthalten sind, lädt das semantische Modell alle Daten für diese Spalten aus OneLake. Das Laden von Spaltendaten ist in der Regel ein schneller Vorgang, kann jedoch von Faktoren wie der Kardinalität der in den Spalten gespeicherten Daten abhängen.
Spalten, die in den Speicher geladen wurden, residieren dann im Speicher. Zukünftige Abfragen, die nur residente Spalten umfassen, müssen keine weiteren Spalten in den Arbeitsspeicher laden.
Eine Spalte residiert so lange im Speicher, bis es einen Grund gibt, sie aus dem Speicher zu entfernen (zu löschen). Gründe für das Entfernen von Spalten sind:
- Das Modell oder die Tabelle wurde nach einem Delta-Tabellen-Update an der Quelle aktualisiert (siehe Framing im nächsten Abschnitt).
- Die Spalte wurde seit einiger Zeit nicht mehr von Abfragen verwendet.
- Andere Ursachen für die Speicherverwaltung, einschließlich des Speicherdrucks in der Kapazität aufgrund anderer gleichzeitiger Vorgänge.
Die Wahl der Fabric-SKU bestimmt den maximal verfügbaren Arbeitsspeicher für jedes Direct Lake-Semantikmodell innerhalb der Kapazität. Weitere Informationen zu Ressourcenschutzschienen und maximalen Speichergrenzwerten finden Sie weiter unten in diesem Artikel unter Fabric-Kapazitätsanforderungen .
Einrahmung
Framing bietet Modellbesitzern die zeitpunktbezogene Kontrolle darüber, welche Daten in das semantische Modell geladen werden. Framing ist ein Direct Lake-Prozess, der durch die Aktualisierung eines semantischen Modells ausgelöst wird. In den meisten Fällen dauert es nur ein paar Sekunden, bis er abgeschlossen ist. Das liegt daran, dass es sich um einen kostengünstigen Vorgang handelt, bei dem das Semantikmodell die Metadaten der neuesten Version der Delta Lake-Tabellen analysiert und aktualisiert wird, um auf die neuesten Parkettdateien in OneLake zu verweisen.
Wenn Framing auftritt, werden residente Tabellenspaltensegmente und Wörterbücher möglicherweise aus dem Speicher entfernt, wenn sich die zugrunde liegenden Daten geändert haben, und der Zeitpunkt der Aktualisierung zur neuen Baseline für alle zukünftigen Transcodierungsereignisse. Ab diesem Zeitpunkt betrachten Direct Lake-Abfragen nur Daten in den Delta-Tabellen ab dem Zeitpunkt des letzten Rahmenvorgangs. Aus diesem Grund werden Direct Lake-Tabellen abgefragt, um Daten basierend auf dem Status der Delta-Tabelle am Punkt des letzten erfolgreichen Framingvorgangs zurückzugeben. Diese Zeit ist nicht notwendigerweise der neueste Zustand der Delta-Tabellen.
Das semantische Modell analysiert das Delta-Protokoll jeder Delta-Tabelle während des Prozesses, um nur die betroffenen Spaltensegmente zu entfernen und neu hinzugefügte Daten während der Transcodierung neu zu laden. Eine wichtige Optimierung besteht darin, dass Wörterbücher üblicherweise nicht gelöscht werden, wenn die inkrementelle Rahmung wirksam wird. Stattdessen werden neue Werte den vorhandenen Wörterbüchern hinzugefügt. Dieser inkrementelle Rahmenansatz trägt dazu bei, die Nachladebelastung zu reduzieren und die Abfrageleistung zu verbessern. Im idealen Fall, wenn eine Delta-Tabelle keine Aktualisierungen erhalten hat, ist kein Erneutes Laden für Spalten erforderlich, die bereits im Arbeitsspeicher vorhanden sind, und Abfragen zeigen deutlich weniger Leistungseinbußen nach dem Framing, da die inkrementelle Framing im Wesentlichen das Semantikmodell ermöglicht, wesentliche Teile der vorhandenen In-Memory-Daten an Ort und Stelle zu aktualisieren.
Anmerkung
Rahmen kann fehlschlagen, wenn eine Delta-Tabelle die Fabric-Kapazitätsschutzschienen überschreitet, z. B. wenn eine Delta-Tabelle über mehr als 10.000 Parkettdateien verfügt. Weitere Informationen zu Ressourcenschutzschienen finden Sie weiter unten in diesem Artikel unter Fabric-Kapazitätsanforderungen .
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.
Automatische Updates
Es gibt eine Einstellung auf Semantikmodellebene, um Direct Lake-Tabellen automatisch zu aktualisieren. Sie ist standardmäßig aktiviert. Es stellt sicher, dass Datenänderungen in OneLake automatisch im Direct Lake-Semantikmodell widerspiegelt werden. Sie sollten automatische Updates deaktivieren, wenn Sie Datenänderungen durch Framing steuern möchten, die im vorherigen Abschnitt erläutert wurde. Weitere Informationen finden Sie unter Verwalten von Direct Lake-Semantikmodellen.
Tipp
Sie können die automatische Seitenaktualisierung in Ihren Power BI-Berichten einrichten. Es ist eine Funktion, die automatisch eine bestimmte Berichtsseite aktualisiert, sofern der Bericht eine Verbindung mit einem Direct Lake-Semantikmodell (oder anderen Arten von Semantikmodell) verbindet.
DirectQuery-Fallback
Wenn Sie Direct Lake auf SQL-Endpunkten verwenden, kann eine an ein Direct Lake-Semantikmodell gesendete Abfrage auf den DirectQuery-Modus zurückgreifen, in diesem Fall wird die Tabelle nicht mehr im Direct Lake-Modus ausgeführt. Sie ruft Daten direkt vom SQL-Analyseendpunkt des Lakehouses oder Datenlagers ab. Solche Abfragen geben immer die neuesten Daten zurück, da sie nicht auf den Zeitpunkt des letzten Rahmenvorgangs beschränkt sind.
Wenn DirectQuery-Fallback auftritt, verwendet eine Abfrage nicht mehr den Direct Lake-Modus. Eine Abfrage kann den Direct Lake-Modus nicht nutzen, wenn das semantische Modell eine Ansicht im SQL-Analyseendpunkt abfragt, oder eine Tabelle im SQL-Analyseendpunkt, die die Sicherheit auf Zeilenebene (RLS) erzwingt. Außerdem kann eine Abfrage den Direct Lake-Modus nicht nutzen, wenn eine Delta-Tabelle die Grenzwerte der Kapazität überschreitet.
Wichtig
Wenn möglich, sollten Sie Ihre Lösung – oder ihre Kapazität – immer entwerfen, um DirectQuery-Fallback zu vermeiden. Das liegt daran, dass sie zu einer langsameren Abfrageleistung führen kann.
Sie können das Fallback-Verhalten Ihrer Direct Lake-Semantikmodelle steuern, indem Sie die DirectLakeBehavior-Eigenschaft festlegen. Diese Einstellung gilt nur für Direct Lake auf SQL-Endpunkten. Direct Lake auf OneLake unterstützt kein DirectQuery-Fallback. Weitere Informationen finden Sie unter Festlegen der Direct Lake-Verhaltenseigenschaft.
Datensicherheit und Zugriffsberechtigungen
Direct Lake verwendet standardmäßig einmaliges Anmelden (Single Sign-On, SSO), was bedeutet, dass die Identität, die das semantische Modell (häufig ein Berichtsbenutzer) abfragt, für den Zugriff auf die Daten autorisiert werden muss. Alternativ können Sie ein Direct Lake-Modell an eine sharable Cloud-Verbindung (SCC) binden, um eine feste Identität bereitzustellen und SSO zu deaktivieren. In diesem Fall erfordert nur die feste Identität Lesezugriff auf die Daten in der Quelle.
Berechtigungen für Fabric-Elemente
Direct Lake erzwingt ein mehrschichtiges Sicherheitsmodell. Die effektive Autorisierung für jede Abfrage hängt sowohl von Fabric-Elementberechtigungen (Arbeitsbereich- als auch Semantikmodellzugriff) und von Berechtigungen auf Quellebene ab, und davon, wie das Modell für die Authentifizierung konfiguriert ist – entweder SSO oder eine SCC mit fester Identität.
Betriebsleitfaden:
- Der Authentifizierungsmodus bestimmt, ob Abfragen mithilfe einzelner Benutzeridentitäten (SSO) oder einer einzelnen Dienstidentität (Fixed-Identity SCC) ausgeführt werden.
- Verwenden Sie SSO für interaktive Szenarien, in denen die Benutzerautorisierung erforderlich ist.
- Verwenden Sie SCC mit fester Identität für eingebettete oder schreibgeschützte Verbraucherszenarien, in denen der Zugriff auf Quellebene einem einzigen Dienstkonto zugewiesen ist.
- Wenden Sie Die Prinzipien der geringsten Rechte sowohl auf quell- als auch auf Arbeitsbereichsebene an.
- Testen und überprüfen Sie das Verhalten für beide Authentifizierungsmodi – insbesondere für SQL-basierte RLS und alle Fälle, die DirectQuery-Fallback auslösen können – vor der Produktionsbereitstellung.
Weitere Informationen finden Sie unter Integrieren der Direct Lake-Sicherheit.
Berechtigungen für Semantikmodelle
Zusätzlich zu Fabric-Elementberechtigungen müssen Sie Benutzern auch Berechtigungen erteilen, damit sie das Direct Lake-Semantikmodell verwenden oder verwalten können. Kurz gesagt benötigen Berichtsanwender Leseberechtigungen , und Berichtsersteller benötigen zusätzliche Buildberechtigungen . Semantische Modellberechtigungen können direkt oderimplizit mithilfe von Arbeitsbereichsrollen zugewiesen werden. Zum Verwalten der Semantikmodelleinstellungen (für Aktualisierung und andere Konfigurationen) müssen Sie der Semantikmodellbesitzersein.
Berechtigungsanforderungen
Szenarien und Berechtigungsanforderungen finden Sie unter Direct Lake-Benutzer.
Wichtig
Sie sollten die Berechtigungen immer gründlich testen, bevor Sie Ihr semantisches Modell und Berichte in die Produktion freigeben.
Weitere Informationen finden Sie unter Berechtigungen des semantischen Modells.
Anforderungen an die Fabric-Kapazität
Für Direct Lake-Semantikmodelle ist eine Fabric-Kapazitätslizenz erforderlich. Außerdem gibt es Kapazitätsschutzschienen und Einschränkungen, die für Ihr Fabric-Kapazitätsabonnement (Fabric Capacity Subscription, SKU) gelten, wie in der folgenden Tabelle dargestellt.
Wichtig
Die erste Spalte in der folgenden Tabelle enthält auch Power BI Premium-Kapazitätsabonnements (P SKUs). Microsoft konsolidiert Kaufoptionen und setzt die Power BI Premium pro Kapazitäts-SKUs zurück. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F SKUs) in Betracht ziehen.
Weitere Informationen finden Sie unter Wichtige Aktualisierung der Power BI Premium-Lizenzierung und Power BI Premium.
| Fabric-SKU | Parquet-Dateien pro Tabelle | Zeilengruppen pro Tabelle | Zeilen pro Tabelle (Millionen) | Maximale Modellgröße auf Datenträger/OneLake (GB) | Max. Arbeitsspeicher (GB) 1 |
|---|---|---|---|---|---|
| F2 | 1.000 | 1.000 | 300 | 10 | 3 |
| F4 | 1.000 | 1.000 | 300 | 10 | 3 |
| F8 | 1.000 | 1.000 | 300 | 10 | 3 |
| F16 | 1.000 | 1.000 | 300 | 20 | 5 |
| F32 | 1.000 | 1.000 | 300 | 40 | 10 |
| F64/FT1/P1 | 5.000 | 5.000 | 1,500 | Unbegrenzt | 25 |
| F128/P2 | 5.000 | 5.000 | 3,000 | Unbegrenzt | 50 |
| F256/P3 | 5.000 | 5.000 | 6.000 | Unbegrenzt | 100 |
| F512/P4 | 10.000 | 10.000 | 12,000 | Unbegrenzt | 200 |
| F1024/P5 | 10.000 | 10.000 | 24,000 | Unbegrenzt | 400 |
| F2048 | 10.000 | 10.000 | 24,000 | Unbegrenzt | 400 |
1 Für Direct Lake-Semantikmodelle stellt Maximalspeicher das obere Speicherressourcenlimit für, wie viele Daten eingelesen werden können, dar. Aus diesem Grund ist es keine Schutzschiene, da die Überschreitung nicht zu einem Fallback in den DirectQuery-Modus führt; Dies kann jedoch auswirkungen auf die Leistung haben, wenn die Datenmenge groß genug ist, um zu übermäßigem Paging in und aus den Modelldaten aus den OneLake-Daten zu führen.
Wenn die maximale Modellgröße auf der Festplatte/OneLake überschritten wird, werden alle Abfragen an das Semantikmodell in den DirectQuery-Modus zurückfallen. Alle anderen in der Tabelle dargestellten Schutzmaßnahmen werden pro Abfrage ausgewertet. Daher ist es wichtig, dass Sie Ihre Delta-Tabellen und dasDirect Lake-Semantikmodell optimieren, um zu vermeiden, dass Sie unnötig auf eine höhere Fabric-SKU skalieren müssen.
Darüber hinaus gelten die Kapazitätseinheit und der Grenzwert für den maximalen Arbeitsspeicher pro Abfrage für Direct Lake-Semantikmodelle. Weitere Informationen finden Sie unter Kapazitäten und SKUs.
Überlegungen und Einschränkungen
Die semantischen Direct Lake-Modelle stellen einige Überlegungen und Einschränkungen dar.
Anmerkung
Die Funktionen und Features der Direct Lake-Semantikmodelle entwickeln sich schnell weiter. Überprüfen Sie regelmäßig die aktuelle Liste der Überlegungen und Einschränkungen.
Direct Lake auf OneLake-Tabellenspeichermodus befindet sich in der öffentlichen Vorschau. Aktivieren Sie die Mandanteneinstellung Benutzer können Direct Lake auf OneLake-Semantikmodellen (Vorschau) erstellen im Verwaltungsportal, um semantische Modelle mit Direct Lake auf OneLake-Tabellen zu erstellen.
| Berücksichtigung /Einschränkung | Direkter See auf OneLake | Direct Lake für SQL (Analyse-Endpunkt) |
|---|---|---|
| Wenn der SQL-Analyseendpunkt die Sicherheit auf Zeilenebene erzwingt, werden DAX-Abfragen je nach Art des verwendeten Direct Lake-Modus unterschiedlich verarbeitet. Wenn Direct Lake auf OneLake verwendet wird, werden Abfragen erfolgreich ausgeführt, und SQL-basierte RLS wird nicht angewendet. Direct Lake auf OneLake erfordert, dass der Benutzer Zugriff auf die Dateien in OneLake hat, was SQL-basierte RLS nicht beobachtet. |
Abfragen werden erfolgreich sein. | Ja, es sei denn, Fallback ist deaktiviert, in diesem Fall schlagen Abfragen fehl. |
| Wenn eine Tabelle im semantischen Modell auf einer (nicht materialisierten) SQL-Ansicht basiert, werden DAX-Abfragen je nach Art des verwendeten Direct Lake-Modus unterschiedlich verarbeitet. Direct Lake bei SQL-Endpunkten greift in diesem Fall auf DirectQuery zurück. Es wird nicht unterstützt, einen Direct Lake auf OneLake-Tabelle basierend auf einer nicht materialisierten SQL-Ansicht zu erstellen. Sie können stattdessen eine materialisierte Lakehouse-Ansicht verwenden, da Delta-Tabellen erstellt werden. Alternativ können Sie einen anderen Speichermodus wie Import oder DirectLake für Tabellen verwenden, die auf nicht materialisierten SQL-Ansichten basieren. |
Nicht zutreffend | Ja, es sei denn, Fallback ist deaktiviert, in diesem Fall schlagen Abfragen fehl. |
| Zusammengesetzte Modellierung, was bedeutet, dass Direct Lake-Semantikmodelltabellen 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). | Unterstützt | Nicht unterstützt |
| Berechnete Spalten und berechnete Tabellen, die im Direct Lake-Speichermodus auf Spalten oder Tabellen verweisen. 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 in allen Szenarien unterstützt. | Nicht unterstützt | Nicht unterstützt |
| Direct Lake-Speichermodustabellen unterstützen keine komplexen Delta-Tabellenspaltentypen. Binäre und GUID-Semantiktypen werden ebenfalls nicht unterstützt. Sie müssen diese Datentypen in Zeichenfolgen oder andere unterstützte Datentypen konvertieren. | Nicht unterstützt | Nicht unterstützt |
| Tabellenbeziehungen erfordern, dass die Datentypen der verwandten Spalten übereinstimmen. | Ja | Ja |
| Einseitige Beziehungsspalten müssen eindeutige Werte enthalten. Abfragen schlagen fehl, wenn doppelte Werte in einer einseitigen Spalte erkannt werden. | Ja | Ja |
| Automatische Datums-/Uhrzeitintelligenz in Power BI Desktop zum Erstellen von Beziehungen mit nur dem Datumsteil einer Datetime-Spalte. Hinweis: Das Markieren einer eigenen Datumstabelle als Datumstabelle und das Erstellen von Beziehungen mithilfe von Datumsspalten wird unterstützt. | Unterstützt | Nicht unterstützt |
| Die Länge der Zeichenfolgenspaltenwerte ist auf 32.764 Unicode-Zeichen beschränkt. | Ja | Ja |
| Nicht numerische Gleitkommawerte, z. B. NaN (keine Zahl), werden nicht unterstützt. | Ja | Ja |
| Die Veröffentlichung im Web von Power BI mithilfe eines Dienstprinzipals wird nur unterstützt, wenn eine feste Identität für das Direct Lake-Semantikmodell verwendet wird. | Ja | Ja |
| In der Webmodellierungserfahrungist die Validierung für Direct Lake-Semantikmodelle beschränkt. Benutzerauswahlen werden als richtig angenommen, und es werden keine Abfragen ausgegeben, um Kardinalität oder Kreuzfilterauswahlen für Beziehungen oder für die ausgewählte Datumsspalte in einer markierten Datumstabelle zu überprüfen. | Ja | Ja |
| Im Fabric-Portal listet die Registerkarte "Direct Lake " im Aktualisierungsverlauf Direct Lake-bezogene Aktualisierungsfehler auf. Erfolgreiche Aktualisierungsvorgänge (Framing) werden normalerweise nicht aufgelistet, es sei denn, der Aktualisierungsstatus ändert sich, z. B. von keinem vorherigen Vorgang oder einem Aktualisierungsfehler in einen Aktualisierungserfolg oder einen Aktualisierungserfolg mit Warnung. | Ja | Ja |
| Ihre Fabric-SKU bestimmt den maximal verfügbaren Arbeitsspeicher pro Direct Lake-Semantikmodell für die Kapazität. Wenn das Limit überschritten wird, können Abfragen an das Semantikmodell aufgrund übermäßigen Paging in und aus den Modelldaten langsamer sein. | Ja | Ja |
| Das Erstellen eines Direct Lake-Semantikmodells in einem Arbeitsbereich, der sich in einem anderen Bereich des Datenquellenarbeitsbereichs befindet, wird nicht unterstützt. Wenn sich das Lakehouse beispielsweise in West Central US befindet, können Sie nur semantische Modelle aus diesem Lakehouse in derselben Region erstellen. Eine Problemumgehung besteht darin, ein Lakehouse im Arbeitsbereich der anderen Region zu erstellen und eine Verknüpfung zu den Tabellen herzustellen, bevor das Semantikmodelll erstellt wird. Informationen dazu, in welcher Region Sie sich befinden, finden Sie unter Bestimmen Ihrer Fabric-Startregion. | Ja | Ja |
| Das Einbetten von Berichten erfordert ein V2-Einbettungstoken. | Ja | Nicht unterstützt |
| Dienstprinzipalprofile für die Authentifizierung. | Nicht unterstützt | Nicht unterstützt |
| Power BI Direct Lake-Semantikmodelle können von Dienstprinzipalen und bei der Viewer-Rollenmitgliedschaft mit Dienstprinzipalen erstellt und abgefragt werden, aber die standardmäßigen Direct Lake-Semantikmodelle auf dem Lakehouse/Warehouse unterstützen dieses Szenario nicht. | Ja | Ja |
| Shortcuts in einem Lakehouse können als Datenquellen für semantische Modell-Tabellen verwendet werden. | Während der öffentlichen Vorschau nicht unterstützt | Unterstützt |
| Erstellen von Direct Lake-Modellen in persönlichen Arbeitsbereichen (Mein Arbeitsbereich). | Nicht unterstützt | Nicht unterstützt |
| Bereitstellungspipelineregeln zum erneuten Binden der Datenquelle. | Nicht direkt unterstützt – kann einen Parameterausdruck erstellen, der in der Verbindungszeichenfolge verwendet werden soll. | Unterstützt |
| Hinzufügen mehrerer Tabellen aus derselben Datenquellentabelle | Nicht unterstützt in Power BI Desktop oder bei der Webmodellierung. Es ist möglich, mehrere Tabellen aus derselben Datenquellentabelle mithilfe von XMLA-basierten externen Tools hinzuzufügen. Die Verwendung von Bearbeiten von Tabellen in der Power BI-Werkzeugunterstützung und das Aktualisieren führt zu einem Fehler aufgrund mehrerer Tabellen aus derselben Datenquelle im semantischen Modell. | Nicht unterstützt in Power BI Desktop oder bei der Webmodellierung. Es ist möglich, mehrere Tabellen aus derselben Datenquellentabelle mithilfe von XMLA-basierten externen Tools hinzuzufügen. Die Verwendung von Tabellen bearbeiten in Power BI-Tools und Aktualisierung führt zu einem Fehler mit mehreren Tabellen aus derselben Datenquellentabelle im semantischen Modell. |
Die Analyse in Excel-Pivottables (und anderen MDX-Clients) hat die gleichen Einschränkungen wie DirectQuery mit Direct Lake-Tabellen im semantischen Modell. Sitzungsbezogene MDX-Anweisungen, wie benannte Sets, berechnete Mitglieder, Standardmitglieder usw., werden nicht unterstützt. Abfragebereichsbezogene MDX-Anweisungen, z. B. die "WITH"-Klausel, werden unterstützt. Benutzerdefinierte Hierarchien der Direct Lake-Tabelle werden nicht unterstützt. Benutzerdefinierte Hierarchien der Importtabelle werden auch bei Direct Lake-Tabellen im semantischen Modell unterstützt.
Power BI Desktop kann ein semantisches Modell mit Direct Lake-Tabellen bearbeiten und Tabellen importieren. 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, können ebenfalls einbezogen werden.
Power BI-Webmodellierung kann jedes semantische Modell öffnen, einschließlich Direct Lake-Tabellen mit anderen Speichermodustabellen.
DAX-Abfrageansicht, wenn Livebearbeitung oder Liveverbindung besteht und DAX-Abfragen im Web geschrieben werden, werden für Direct Lake auf SQL, Direct Lake auf OneLake und true composite (Direct Lake auf OneLake + Import aus beliebigen Datenquellen)-Semantikmodellen unterstützt.
Die TMDL-Ansicht wird bei der Livebearbeitung in Power BI Desktop unterstützt.
Das Erstellen von Berichten mit einer Liveverbindung wird für alle semantischen Modelle unterstützt, wenn der Berichtsautor mindestens Buildzugriff hat.
Der Direct Lake-Ausdruck der SQL-Verbindung im semantischen Modell muss auf den SQL-Analyseendpunkt mittels GUID verweisen, nicht mittels Anzeigenamen, um Tabellen und Aktualisierungen in Power BI Desktop und der Power BI Webmodellierung zu verwenden. Der Verbindungsausdruck kann in der TMDL-Ansicht oder XMLA-basierten externen Tools aktualisiert werden. Die GUID ist in der URL verfügbar, wenn Sie den SQL-Analyseendpunkt im Browser anzeigen.