Direct Lake in Power BI Desktop: schneller auf Fabric-Daten arbeiten

Definition

Direct Lake ist ein Storage Mode für ein Semantic model in Microsoft Fabric, bei dem Power BI direkt auf Delta-Tabellen im OneLake zugreift, statt Daten klassisch vollständig zu importieren.

Es ist weder reines Import mode (VertiPaq nur aus importierten Daten) noch reines DirectQuery (jede Visualisierung als SQL-Query gegen die Quelle).

Einleitung

Wenn ihr Daten in Microsoft Fabric zentralisiert, wollt ihr sie nicht für jedes Dataset wieder kopieren und refreshen. Genau hier setzt direct lake in power bi desktop an: schnelle Analysen auf Lakehouse-Daten, ohne dass ihr euch zwischen „Import ist schnell“ und „DirectQuery ist aktuell“ komplett entscheiden müsst.

Welche Varianten es gibt (und warum das wichtig ist)

In Power BI stehen praktisch drei Modi zur Wahl. Der Modus entscheidet über Performance, Aktualität, Risiko und Wartungsaufwand.

• Import mode: Daten landen im VertiPaq-Cache. Sehr schnell im Report, dafür Refresh-Prozesse und Datenkopien.
• DirectQuery: Abfragen laufen live per Query/SQL gegen die Quelle. Aktueller, aber oft langsamer und empfindlicher bei Last.
• Direct Lake: Daten bleiben im Lake storage (OneLake/Delta). Power BI liest „direkt“, ohne den klassischen Vollimport.

Merksatz für Entscheider: Import optimiert das Nutzererlebnis, DirectQuery optimiert Aktualität, Direct Lake versucht beides mit weniger Duplikaten zu verbinden.

Wie Direct Lake in Power BI Desktop funktioniert

In Power BI Desktop erstellst oder bearbeitest du ein Semantic model, das auf einem Fabric Lakehouse oder Warehouse basiert. Technisch relevant sind dabei der Zugriff auf die Delta table-Strukturen und das „Framing“: Power BI hält Metadaten und nutzt sie, um Abfragen effizient über Columns und Partitionen auszuführen.

Wichtig für die Praxis: Das Modell ist ein Fabric-Artefakt im Workspace. Desktop ist hier weniger „lokales PBIX-Basteln“ und mehr „Modell-Editor“ für ein zentral gespeichertes Modell.

Für Teams ist das der Hebel: Ein Semantikmodell kann als stabile Schicht dienen, auf der viele Reports aufsetzen, ohne dass jeder Bericht ein eigenes Datenmodell und eigene Refresh-Logik pflegt.

Setup in Power BI Desktop (Preview-Funktionen) kompakt

Direct Lake ist eng an Fabric gekoppelt. Damit das Arbeiten in Desktop klappt, braucht es typischerweise aktivierte Preview-Funktionen und passende Berechtigungen im Workspace.

• Preview-Funktionen für das Bearbeiten/Erstellen von Fabric-Semantikmodellen in Desktop aktivieren und Desktop neu starten.
• Im Datenhub das Lakehouse/ Warehouse auswählen und ein Semantic model erstellen oder ein bestehendes Modell im Workspace bearbeiten.
• Veröffentlichen/Speichern im Workspace und testen, wie sich Queries im Report verhalten (Performance und Fallbacks).

Empfehlung: Erst in einer Test-Workspace-Struktur starten. Preview heißt: Änderungen können kommen, und du willst keine produktive Berichtskette ohne Sicherheitsnetz.

Architektur-Überblick: OneLake, Delta, VertiPaq

Das Zusammenspiel ist der Kernnutzen: OneLake ist der gemeinsame Speicher, in dem Daten einmal sauber bereitgestellt werden. Im Lakehouse liegen sie als Delta-Tabellen (Delta/Parquet files). Power BI nutzt diese Tabellen direkt, während VertiPaq weiterhin die Engine bleibt, die schnelle Analytics und DAX-Auswertung ermöglicht.

Für Anwender heißt das: „Gold-Daten“ können zentral gepflegt werden, und auch weniger IT-affine Kolleg:innen können darauf in Power BI (und je nach Setup auch in Excel) aufsetzen, ohne ständig neue Datenkopien anzulegen oder Excel-Schattenwelten zu bauen.

Direct Lake vs. Import/DirectQuery: Vor- und Nachteile

Direct Lake ist besonders attraktiv, wenn viele Reports auf dieselbe Lakehouse-Basis zugreifen sollen und Refresh-Fenster zum Engpass werden. Trotzdem ist es kein Freifahrtschein.

• Performance: oft näher an Import als an DirectQuery, wenn der Lake sauber strukturiert und optimiert ist.
• Aktualität: näher an „nahezu aktuell“, ohne dass jeder Report einen kompletten Import-Refresh braucht.
• Betrieb: weniger Datenkopien, aber dafür stärkere Abhängigkeit von Fabric-Architektur, Governance und Capacity.

DirectQuery bleibt sinnvoll, wenn Live-Anforderungen wirklich Priorität haben oder Daten nicht in Fabric/OneLake liegen. Import bleibt sinnvoll, wenn ihr maximale Stabilität und Planbarkeit pro Dataset wollt.

Wichtige Einschränkungen und Überlegungen

Die wichtigsten Risiken sind selten „Feature fehlt“, sondern „Betrieb passt nicht“.

• Fallback-Verhalten: Unter bestimmten Bedingungen kann das Modell auf andere Zugriffswege zurückfallen, was Performance und Kosten beeinflusst.
• Modell-Features: Bestimmte Modellierungsfunktionen (z. B. einige Calculated columns/Calculated tables-Szenarien) können eingeschränkt sein oder wirken anders als im klassischen Import.
• Governance: Ohne klare Ownership für Semantic models, Namenskonventionen und Freigabeprozesse entsteht schneller Wildwuchs.

Das Risiko ist damit gut steuerbar: mit einem klar abgegrenzten Use Case, definierten Performance-Zielen und einem sauberen Operating Model.

Datenaktualisierung und Wartung

Auch bei Direct Lake gibt es Wartung: Metadaten, Modell-Änderungen und Datenpipelines müssen zusammenpassen. Statt „Dataset-Refresh zieht alle Rows neu“ geht es stärker um stabile Pipelines, saubere Delta-Strukturen und kontrollierte Änderungen am Modell.

Praktisch heißt das: Wenn die Fachlichkeit (KPIs, Definitionen, DAX) im Semantikmodell stabil ist, reduziert ihr wiederkehrende Report-Rebuilds. Messbar wird das über weniger manuelle Refresh-Feuerwehr, weniger Excel-Konsolidierung und schnellere Time-to-Answer im Management.

Praxisbeispiel (1 Mini-Story)

Ein Finance-Team konsolidiert Umsatz, Offene Posten und Cashflow bisher in Excel und importiert die Dateien alle zwei Wochen ins Power BI Dataset. Mit einem Fabric-Lakehouse als zentrale Schicht und Direct Lake im Semantikmodell arbeiten mehrere Reports auf derselben Gold-Tabelle, ohne dass jede Berichtsversion ihre eigene Importkopie pflegt. Ergebnis: weniger Abstimmungsaufwand durch unterschiedliche Zahlenstände und schnelleres Drilldown-Reporting bis auf Belegebene, weil die Datenbasis konsistent bleibt.

Empfohlene Ressourcen und nächste Schritte

Für einen sauberen Start helfen drei Schritte mehr als lange Feature-Listen: erst Architektur klären, dann Modell, dann Betrieb.

• Microsoft Learn/Docs zu Direct Lake, Storage Mode und Semantic models in Fabric.
• Tests mit klaren Kriterien: Query-Performance, Datenaktualität, Fallback/Fehlerbilder, Betriebsaufwand.
• Ein KPI-klares MVP: 1 Bericht, 1 Semantikmodell, 1 Lakehouse-Domäne, danach skalieren.

So wird Direct Lake nicht zum Experiment, sondern zu einer Entscheidung mit messbarem Nutzen.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn ihr schnell Klarheit für Budget, Risiko und Zeit braucht: Welche Daten müssen ins Lakehouse, wie sieht die Zielarchitektur aus, und welchen Storage Mode nutzt ihr pro Use Case?

Typische Auslöser sind Performance-Probleme, unklare Governance, ein geplanter Fabric-Rollout oder wenn ihr vermeiden wollt, dass jedes Team sein eigenes Semantic model „irgendwie“ baut. Dann ist ein kurzer, strukturierter Architektur- und Betriebsplan oft der schnellste Weg zu belastbarer Messbarkeit.