Direct Lake, Import oder DirectQuery? Nicht jeder Bericht muss live am Datentropf hängen.

„Wir brauchen Echtzeit“ ist selten eine vollständige Anforderung. Oft bedeutet es nur: Der tägliche Refresh ist zu langsam. Wer darauf reflexartig DirectQuery einschaltet, tauscht ein planbares Ladeproblem gegen dauerhafte Abhängigkeit von Quelle, Netzwerk und Abfragequalität.

Die bessere Frage lautet: Wo soll die Arbeit stattfinden – beim Refresh, beim Laden aus OneLake oder bei jeder einzelnen Benutzerabfrage?

Die drei Modelle in einem Satz

Die Entscheidungsmatrix

Wann Import die richtige langweilige Antwort ist

Import ist der Standardmodus in Power BI – und das ist kein historischer Unfall. Das Modell kann Daten komprimieren, optimieren und im Speicher sehr schnell abfragen. Modellierer erhalten breite DAX- und Feature-Unterstützung, während Berichte nicht bei jedem Klick auf eine entfernte Quelle warten.

Import passt, wenn …

• ein Refresh alle 15 Minuten, stündlich oder täglich fachlich ausreicht,
• das komprimierte Modell in die vorgesehenen Größen- und Kapazitätsgrenzen passt,
• du eine breite Modellierungsfunktionalität ohne DirectQuery-Einschränkungen brauchst,
• die operative Quelle vor interaktiver Berichtslast geschützt werden soll,
• ein klarer, überwachbarer Refreshprozess einfacher ist als permanente Quellabhängigkeit.

Der Preis ist die Datenkopie. Ein Importrefresh liest, transformiert, komprimiert und speichert Daten erneut. Bei sehr großen Modellen kann das viel Zeit, Quellleistung und Kapazität verbrauchen. Dann ist nicht automatisch DirectQuery die Antwort. In Fabric sollte Direct Lake zuerst auf die Prüfliste.

Wann Direct Lake seinen Vorteil ausspielt

Direct Lake ist für große Fabric-Datenbestände gedacht, die bereits als Delta-Tabellen in OneLake liegen. Statt beim Refresh eine vollständige Modellkopie zu erzeugen, aktualisiert das Modell seine Sicht auf die Delta-Metadaten. Benötigte Spalten werden bei Abfragen in den Speicher geladen.

Direct Lake passt, wenn …

• Lakehouse, Warehouse oder andere Fabric-Quellen bereits kuratierte Delta-Tabellen bereitstellen,
• eine vollständige Importkopie unpraktisch oder unnötig ist,
• interaktive VertiPaq-Performance ohne klassischen Vollrefresh gewünscht ist,
• Datenaufbereitung bewusst vor dem semantischen Modell in Fabric stattfindet,
• Fabric-Kapazität und OneLake ohnehin Teil der Zielarchitektur sind.

Framing ist kein klassischer Importrefresh

Beim Framing analysiert das Modell die Metadaten der aktuellen Delta-Tabellenversion und aktualisiert seine Dateireferenzen. Das ist normalerweise deutlich leichter als ein vollständiger Import. Trotzdem braucht auch dieser Pfad ein Betriebsmodell: Wann werden neue Daten sichtbar? Sind automatische Updates aktiviert? Was passiert bei Schemaänderungen? Wie wird nach einer fehlgeschlagenen Datenladung verhindert, dass ein fachlich unvollständiger Stand sichtbar wird?

Transcoding: warm ist nicht dasselbe wie kalt

Direct Lake lädt nicht vorsorglich jede Modellspalte vollständig in den Speicher. Benötigte Spalten werden bei der ersten Abfrage aus den Delta-Dateien in ein VertiPaq-taugliches Format überführt und geladen. Microsoft bezeichnet diesen Vorgang als Transcoding. Bereits residente Spalten können sehr schnell reagieren; nach Verdrängung durch Speicherdruck, Änderungen oder Capacity-Guardrails muss erneut geladen werden. Ein belastbarer Test misst deshalb kalte und warme Abfragen sowie typische Parallelität – nicht nur den zweiten Klick eines einzelnen Entwicklers.

Fallback bewusst behandeln

Bei Direct Lake on SQL können nicht direkt unterstützte Szenarien – beispielsweise Tabellen auf Basis bestimmter SQL-Views – auf DirectQuery zurückfallen, sofern das Verhalten so konfiguriert ist. Das kann korrekt sein, verändert aber das Performance- und Betriebsprofil einer Abfrage. Direct Lake on OneLake verfolgt dagegen einen Pfad ohne diesen DirectQuery-Fallback und unterstützt zusammengesetzte Modelle mit anderen Speichermodi.

Wann DirectQuery wirklich notwendig ist

DirectQuery hält Daten in der Quelle und sendet Abfragen zur Laufzeit dorthin. Das ist sinnvoll, wenn Daten aus regulatorischen oder technischen Gründen nicht importiert werden dürfen, wenn eine unterstützte externe Quelle bewusst führend bleibt oder wenn eine sehr geringe Datenlatenz tatsächlich fachlich erforderlich ist.

DirectQuery passt, wenn …

• Daten nicht in das semantische Modell kopiert werden dürfen,
• die Quelle eine ausreichende Abfrageleistung und Nebenläufigkeit garantiert,
• Abfragen sauber gefaltet beziehungsweise in native Quellabfragen übersetzt werden können,
• die geforderte Aktualität den zusätzlichen Betriebsaufwand rechtfertigt,
• Quellzugriff und Berechtigungen bewusst bei jeder Abfrage durchgesetzt werden sollen.

DirectQuery verschiebt Verantwortung. Ein langsames Visual ist dann möglicherweise kein Power-BI-Problem, sondern ein Index-, Netzwerk-, Gateway-, SQL- oder Nebenläufigkeitsproblem. Diese Kette muss gemeinsam überwacht werden.

Betrieb und Kapazität

Import

• Refreshdauer, Speicherspitzen und Fehler müssen überwacht werden.
• Inkrementelle Aktualisierung und Partitionierung können große Modelle beherrschbar machen.
• Die Quelle wird planbar beim Refresh belastet, nicht bei jedem Berichtsklick.

Direct Lake

• Delta-Tabellen, Dateigrößen, Row Groups, Datentypen und Datenqualität bleiben Teil des BI-Betriebs.
• Viele kleine Dateien, hohe Kardinalität und ungünstige Ladeverfahren können kalte Abfragen verteuern; Dateiwartung und die aktuellen Microsoft-Empfehlungen zu V-Order gehören deshalb in den Pilot.
• Framing beziehungsweise automatische Updates müssen zum Ladeprozess passen.
• SKU-abhängige Speicher- und Capacity-Guardrails müssen mit repräsentativen Modellen, kalten und warmen Abfragen sowie typischer Parallelität geprüft werden.
• Bei Direct Lake on SQL muss unerwarteter DirectQuery-Fallback sichtbar gemacht werden.

DirectQuery

• Quelle, Gateway, Netzwerk und Power BI bilden gemeinsam den Laufzeitpfad.
• Viele gleichzeitige Benutzer erzeugen echte Nebenläufigkeit auf der Quelle.
• Transformationen und DAX müssen auf Übersetzbarkeit und resultierende Abfragen geprüft werden.
• Aggregationen oder hybride Muster können häufige Abfragen entlasten.

Fünf Fehlentscheidungen

Die sieben Fragen vor der Wahl

1. Wo liegen die kuratierten Daten? Bereits in OneLake, in einer externen Datenbank oder nur in Quellextrakten?
2. Welche maximale Datenlatenz ist fachlich notwendig? Nicht „möglichst aktuell“, sondern eine messbare Grenze.
3. Wie groß ist das komprimierte Modell? Mit realistischen Daten messen.
4. Kann die Quelle interaktive Last tragen? Einschließlich Nebenläufigkeit und Spitzenzeiten.
5. Welche Modellfunktionen werden benötigt? DAX, berechnete Tabellen, Sicherheit und zusammengesetzte Modelle konkret prüfen.
6. Wo soll Transformation stattfinden? Im Refresh, in Fabric vor dem Modell oder bei jeder Quellabfrage?
7. Wer betreibt den gesamten Pfad? Monitoring, Fehleranalyse, Kapazität und Wiederanlauf brauchen Besitzer.

Transparenz: Empfehlungen und Formulierungen sind redaktionelle Einordnung. Produktverhalten ist mit Microsoft-Primärquellen belegt. Es wurden keine pauschalen Performancewerte oder erfundenen Benchmarks verwendet.