Dataflows Gen1 vs. Gen2 in Microsoft Fabric: Die richtige Staging- und Compute-Architektur wählen

Von Mirko Peters · 2026-10-28

Vergleichen Sie Dataflows Gen1 und Gen2 in Microsoft Fabric. Erfahren Sie, wie sich Speicher, Staging-Compute und Kapazität auf Ihre Cloud-ETL-Strategie auswirken.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Beim Migrieren von ETL-Workloads zu Microsoft Fabric wirkt sich die Wahl der richtigen Staging- und Compute-Architektur zwischen Dataflows Gen1 und Gen2 direkt auf Ihre Pipeline-Performance, Ressourcenkosten und die Vertrauenswürdigkeit Ihrer Daten aus. Wer die grundlegenden Unterschiede bei der Compute-Zuweisung und der Speicherverarbeitung versteht, vermeidet kostspielige architektonische Engpässe, bevor Ihr Team seine Berichte skaliert.

Das Wichtigste in Kürze

• Dataflows Gen2 bringt eine native Integration mit OneLake mit, die die Art, wie Daten im Vergleich zu Gen1 gestaged und gespeichert werden, grundlegend verändert.
• Die Wahl einer ungeeigneten Compute-Option bei der Erstellung kann zu unerwarteter Kapazitätsdrosselung und Leistungseinbußen in Ihrem Fabric-Arbeitsbereich führen.
• Gen1 setzte stark auf externe Speichermechanismen, während Gen2 standardmäßig direkt in Fabric-Lakehouse-Tabellen schreibt.
• Eine korrekte Staging-Konfiguration verhindert redundante Transformationen und optimiert die Aktualisierungen Ihres Power BI-Semantikmodells.
• Wenn Sie Ihre ETL-Strategie an den Fabric-Kapazitätseinheiten ausrichten, vermeidet Ihre Organisation unkontrollierte Compute-Kosten.

Den architektonischen Wandel in Fabric verstehen

Der Übergang von klassischen Power BI-Dataflows zu Microsoft Fabric-Dataflows ist nicht nur eine Umbenennung, sondern eine vollständige architektonische Neuausrichtung, wie Cloud-Daten aufgenommen, transformiert und gespeichert werden. In der bisherigen Welt von Gen1 dienten Dataflows vor allem dazu, Power BI-Semantikmodelle zu speisen. Sie arbeiteten in einem eher isolierten Ökosystem: Die Datentransformationen fanden in Power Query Online statt, und die Ergebnisse wurden in einem internen Speicher abgelegt, der vollständig vom Power BI-Dienst verwaltet wurde.

Mit der Einführung von Microsoft Fabric wurden Dataflows Gen2 von Grund auf so entwickelt, dass sie OneLake als zentrales Datenrepository nutzen. Das heißt, jede Transformation, die Sie in Power Query Online anwenden, ist nicht länger in einem proprietären Modellcontainer gefangen. Stattdessen schließt Gen2 die Lücke zwischen klassischer Self-Service-Datenaufbereitung und Data Engineering auf Unternehmensebene, indem es direkt in offenen Delta-Parquet-Tabellen in einem Fabric-Lakehouse schreibt. Diese grundlegende Veränderung beeinflusst, wie Cloud-Architekten Staging, Compute-Auslastung und die Verlässlichkeit nachgelagerter Berichte angehen.

Der Paradigmenwechsel beim Speicher

In klassischen Umgebungen mussten Fachanalysten, die einen Excel-Export bereinigen, leere Zeilen entfernen und Datumswerte formatieren wollten, diese Daten innerhalb der Speichergrenze des Datenflusses belassen. Wollte eine andere Abteilung denselben bereinigten Datensatz nutzen, musste sie ihn oft aus dem Bericht beziehen oder die Abfrage neu erstellen. Dataflows Gen2 löst dieses Problem, indem das Lakehouse als vollwertiges Zielsystem behandelt wird. Sobald Ihr Datenfluss ausgeführt wird, stehen die bereinigten Daten sofort als Delta-Tabellen zur Verfügung, bereit für Spark-Notebooks, SQL-Analyseendpunkte und direktes DirectLake-Reporting, ohne dass zusätzliche Datenverschiebungen nötig sind.

Die Entscheidung zu Compute und Staging, die die meisten Teams übersehen

Eine der wichtigsten architektonischen Entscheidungen beim Aufbau von Dataflows Gen2 betrifft die Steuerung der Compute- und Staging-Phasen. Anders als bei Gen1, wo die Compute-Verwaltung weitgehend abstrahiert und mitunter undurchsichtig war, läuft Gen2 auf den zugrunde liegenden Fabric-Kapazitätseinheiten (CUs). Wenn Ihre Organisation nicht sorgfältig überwacht, wie und wann Daten während der Abfrageauswertung zwischengespeichert werden, riskieren Sie, Ihre Kapazitätskontingente schneller aufzubrauchen als erwartet.

Wenn Sie komplexe Transformationen anwenden, prüft Power Query, ob Schritte zur Datenquelle zurückgefaltet werden können oder lokal in der Dataflow-Engine ausgeführt werden müssen. In Gen2 fungiert der Staging-Bereich als Zwischenspeicher. Bei fehlerhafter Konfiguration können große Datenmengen wiederholt in den Speicher geladen, verarbeitet und zurückgeschrieben werden, was unnötigen Rechenaufwand verursacht. Architekten müssen Quellsysteme, Netzwerklatenz und Komplexität der Transformationen bewerten, um zu entscheiden, ob die Verarbeitung an die Quelldatenbank delegiert oder die schwere Arbeit Fabric überlassen werden soll.

Kapazitätseinheiten für ETL-Workloads optimieren

Fabric-Kapazität ist ein gemeinsam genutzter Pool für die gesamte Organisation. Wenn ein schlecht optimierter Dataflow Gen2 geplante Aktualisierungen während der Geschäftszeiten ausführt, kann er so viel Kapazität verbrauchen, dass es zu Drosselungen kommt, die das Rendering von Power BI-Berichten für Führungskräfte beeinträchtigen. Um das zu verhindern, sollten Teams aufwendige ETL-Aufträge in eigene Arbeitsbereiche mit passenden Kapazitätsreservierungen auslagern oder außerhalb der Stoßzeiten planen. Zu verstehen, wie Hintergrundberechnungen mit interaktiven Workloads interagieren, ist entscheidend für eine stabile Fabric-Umgebung.

Vertrauen durch konsistente Architektur aufbauen

Das eigentliche Ziel bei der Modernisierung Ihrer Datenpipelines ist es, die manuellen Excel-Korrekturen zu beseitigen, die das Berichtswesen belasten. Wenn Berichte scheitern, liegt das selten an fehlenden Daten, sondern fast immer an fehlendem Vertrauen. Wenn Nutzer widersprüchliche Zahlen sehen, weil ein Bericht aus einer rohen CSV-Datei und ein anderer aus einem älteren Dataflow stammt, sinkt die Akzeptanz rapide.

Durch die Standardisierung auf Dataflows Gen2 und die Nutzung der Lakehouse-Architektur schaffen Organisationen eine einzige Quelle der Wahrheit. Bereinigte Datumswerte, standardisierte Spaltennamen und validierte Geschäftslogik werden einmal im Dataflow festgelegt und automatisch an nachgelagerte Systeme weitergegeben. Das reduziert menschliche Fehler, macht die Abhängigkeit von einzelnen Desktop-Rechnern überflüssig und sorgt dafür, dass die Zahlen hinter einem Dashboard verlässlich und prüfbar sind, wenn die Geschäftsführung es öffnet.

Fazit

Die Migration zu Dataflows Gen2 und der Aufbau damit erfordern ein Umdenken in Bezug auf Cloud-Speicher, Compute-Budgets und Data Governance. Wenn Sie mit einem wiederkehrenden, unübersichtlichen Tabellenkalkulationsprozess beginnen und diesen korrekt in ein Fabric-Lakehouse überführen, kann Ihr Team skalierbare Pipelines aufbauen, die langfristig Bestand haben. Um die grundlegenden Konzepte hinter dieser Entwicklung kennenzulernen und Expertenmeinungen zu modernen Microsoft-Cloud-Strategien zu hören, hören Sie sich die vollständige Folge des M365 FM Podcasts an.

Häufige Fragen

Was ist der Hauptunterschied zwischen Dataflows Gen1 und Gen2 in Bezug auf die Speicherung?

Dataflows Gen1 speichern transformierte Daten innerhalb der internen Speichergrenzen von Power BI, während Dataflows Gen2 nativ in offenen Delta-Parquet-Tabellen innerhalb eines Microsoft Fabric Lakehouse über OneLake schreiben.

Welche Auswirkungen haben Dataflows Gen2 auf Fabric-Kapazitätseinheiten?

Dataflows Gen2 verbrauchen während ihrer Compute- und Staging-Phasen die zugrunde liegende Fabric-Kapazität. Schlecht optimierte Transformationen oder schwere Aktualisierungen während der Stoßzeiten können das Kapazitätskontingent erschöpfen und andere Workloads drosseln.

Können Dataflows Gen2 traditionelle Azure Data Factory-Pipelines ersetzen?

Für Self-Service-Datenaufbereitung, schlanke ETL-Prozesse und Low-Code-Datentransformation sind Dataflows Gen2 eine hervorragende Alternative. Für komplexe Unternehmensorchestrierung, verzweigte Logik und anspruchsvolle Data-Engineering-Aufgaben bleiben Azure Data Factory oder Fabric Pipelines jedoch die bevorzugten Werkzeuge.

Warum ist die Staging-Phase in Dataflows Gen2 wichtig?

Die Staging-Phase dient als Zwischenspeicher für Datentransformationen. Eine korrekte Staging-Konfiguration verhindert redundante Datenverarbeitung, optimiert das Query Folding und sorgt für effiziente Schreibvorgänge in das Ziel-Lakehouse.

Wie verbessern Dataflows Gen2 die Datenvertrauenswürdigkeit im Reporting?

Indem Gen2 die Bereinigung manuell erstellter Exporte automatisiert und Transformationen in wiederverwendbaren Lakehouse-Tabellen zentralisiert, beseitigt es manuelle Excel-Umwege und sorgt für konsistente, verlässliche Daten in allen nachgelagerten Berichten.