Dataflows Gen2 vs. Notebooks: Auswahl in Microsoft Fabric

Nutzen Sie standardmäßig Dataflows Gen2 für strukturierte Quellen. Dort kann Power Query die Arbeit per Query Folding an die Quelle abgeben, und inkrementelle Ladevorgänge halten jeden Lauf klein. Nutzen Sie ein Spark-Notebook, wenn sich Transformationen nicht falten lassen, wenn Sie verteilte Rechenleistung für große Joins oder Aggregationen brauchen, wenn die Daten verschachtelt sind oder als Stream kommen oder wenn Sie Delta-Tabellen im großen Maßstab pflegen müssen. Eine Delta-Tabelle ist ein offenes Tabellenformat mit eingebauten Transaktionen und Versionsverlauf. Beide Wege legen Daten in OneLake ab, dem einzigen zugrunde liegenden Data Lake von Fabric für den gesamten Speicher, und viele Fabric-Setups nutzen beide.

Was ein Dataflow ist und wie sich Gen1 von Gen2 unterscheidet, lesen Sie in Dataflows in Power BI: wie und wann Sie sie nutzen.

So funktioniert es

Dataflows Gen2 führen Power Query in der Cloud aus. Sie lesen Daten aus Hunderten von Konnektoren, transformieren sie und schreiben das Ergebnis in ein Ziel, zum Beispiel eine Lakehouse-Tabelle, Lakehouse-Dateien oder ein Fabric Warehouse. Ihre Stärken sind die Anbindung von Quellen, ein visueller Editor und Query Folding, das die Arbeit an das Quellsystem zurückgibt. Sie laufen auf Ihrer Fabric-Kapazität und lassen sich aus Pipelines steuern.

Notebooks laufen auf verwaltetem Apache Spark. Sie schreiben Transformationen in PySpark, Spark SQL, Scala oder SparkR und lesen und schreiben Dateien und Delta-Tabellen direkt in OneLake. Die Engine ist verteilt, daher verteilen sich Joins, breite Aggregationen und komplexe Transformationen auf den Spark-Cluster. Notebooks decken auch Aufgaben jenseits von ETL ab, etwa Datenqualitätsprüfungen, Feature Engineering und Streaming.

Entscheidungshilfe: Dataflows Gen2 vs. Notebooks

Verstehen Sie die Tabelle als Ausgangspunkt, nicht als feste Regel. Üblich ist diese Aufteilung: Dataflows für die Anbindung der Quellen und leichte Aufbereitung, Notebooks für schwere Joins und die Aufbereitung zu Gold-Tabellen.

Dataflows mit sehr großen Tabellen

Dataflows Gen2 verarbeiten große, strukturierte Fakten- und Dimensionstabellen gut, wenn sie auf Folding und inkrementelle Verarbeitung ausgelegt sind:

• Die Quelle übernimmt die schwere Arbeit. Mit Query Folding laufen Filter, Spaltenauswahl, Joins und Aggregationen in der Quelldatenbank. Der Dataflow bewegt die Daten und übernimmt die letzte Aufbereitung.

• Die Ladevorgänge sind inkrementell. Aktualisieren Sie über eine Datumsspalte nur neue oder geänderte Zeiträume statt der gesamten Historie. Jeder Lauf verarbeitet nur einen kleinen Ausschnitt.

• Transformationen sind mengenbasiert. Vermeiden Sie Schritte, die das Folding brechen, etwa eine eigene Funktion, die auf jede Zeile angewendet wird. Nutzen Sie native Operationen, die sich in SQL übersetzen lassen.

Drei Techniken halten große Tabellen beherrschbar:

1. Filter an die Quelle weitergeben, zum Beispiel bei jedem Lauf nur die letzten Tage laden.

2. Sehr große Tabellen nach Zeitraum oder Fachbereich in getrennte Abfragen aufteilen und parallel aktualisieren.

3. Die Ausgabe in Delta-Tabellen in OneLake schreiben. Das hält das Schema für alles Nachgelagerte vorhersehbar.

Dataflows stoßen an Grenzen, wenn Folding nicht möglich ist oder die Arbeit verteilte Rechenleistung braucht. Falten sich wichtige Schritte nicht, holt Power Query die Daten ab und transformiert sie selbst. Die Leistung hängt dann von der verfügbaren Kapazität ab, und Läufe können gedrosselt werden, in der Warteschlange hängen oder in ein Timeout laufen.

Wann Notebooks das richtige Werkzeug sind

Wählen Sie ein Notebook, wenn eines der folgenden Kriterien zutrifft:

• Schwere Transformationen, die sich nicht falten lassen. Große Joins zwischen Faktentabellen, komplexe Fensterfunktionen oder Deduplizierung über sehr große Tabellen.

• Verschachtelte oder halbstrukturierte Daten. JSON mit Arrays und Structs, XML oder Logs, die aufgeklappt und abgeflacht werden müssen und bei denen sich das Schema ändern kann.

• Dateilastige oder Streaming-Muster. Viele kleine Dateien oder Micro-Batches mit Spark Structured Streaming und Checkpoints im Lakehouse.

• Code-Bibliotheken. Frameworks für Datenqualität, Parsing oder Anreicherung in Python oder Scala.

• Wartung von Delta-Tabellen. Kontrolle über Compaction, Partitionierung und Bereinigung bei großen Tabellen.

• Aufbereitung in Schichten. Daten von Bronze über Silver zu Gold bewegen, nach dem Muster der Medallion-Architektur mit rohen, bereinigten und fachlich nutzbaren Schichten, mit idempotenter Merge-Logik.

Eine typische Notebook-Zelle flacht verschachteltes JSON ab und führt es per Merge in eine Delta-Tabelle ein, sodass ein erneuter Lauf keine Duplikate erzeugt:

from delta.tables import DeltaTable
from pyspark.sql import functions as F

updates = (
    spark.read.format("json").load("Files/raw/orders/")
    .withColumn("item", F.explode("items"))
    .select(
        "orderId",
        "orderDate",
        F.col("item.sku").alias("sku"),
        F.col("item.qty").alias("qty"),
    )
)

target = DeltaTable.forName(spark, "silver_order_lines")

(
    target.alias("t")
    .merge(updates.alias("s"), "t.orderId = s.orderId AND t.sku = s.sku")
    .whenMatchedUpdateAll()
    .whenNotMatchedInsertAll()
    .execute()
)

Das setzt voraus, dass am Notebook ein Standard-Lakehouse angehängt ist und die Tabelle silver_order_lines existiert. Für kuratierte Tabellen, die in einem Warehouse landen müssen, schreibt der Spark-Konnektor für Fabric Data Warehouse sie aus dem Notebook.

Leitfaden zur Umsetzung

1. Quellen und Ziele einordnen. Gruppieren Sie Workloads nach Quellentyp (relational oder halbstrukturiert), Komplexität der Transformation und benötigter Latenz. Entscheiden Sie, ob jedes Ziel eine Lakehouse-Tabelle, ein Warehouse oder beides ist.

2. Früh auf Folding testen. Bauen Sie einen Prototyp in Power Query und nutzen Sie die Folding-Anzeigen an jedem Schritt. Falten sich wichtige Schritte nicht, planen Sie ein Notebook ein.

3. Die inkrementelle Strategie festlegen. Wählen Sie einen Partitionierungsschlüssel, etwa das Ladedatum oder das Geschäftsdatum. Bei Dataflows filtern Sie damit an der Quelle. Bei Notebooks partitionieren Sie die Delta-Tabelle danach und schreiben idempotente Merges.

4. Beide Wege bei realistischem Volumen testen. Messen Sie Laufzeit und Kapazitätsverbrauch mit repräsentativen Daten. Kleine Testdaten verdecken die Unterschiede, auf die es ankommt.

5. Das Muster dokumentieren. Halten Sie fest, wann Sie welches Werkzeug nutzen, dazu Namenskonventionen, Ziele und Monitoring, und machen Sie daraus Vorlagen.

Tipps zu Leistung, Kapazität und Kosten

Dataflows Gen2

Erhalten Sie das Query Folding für möglichst viele Schritte und setzen Sie Schritte, die nicht falten, ans Ende. Geben Sie Filter und Joins an die Quelle weiter und aggregieren Sie vorab, wo der Report es erlaubt. Teilen Sie große Tabellen in getrennte Abfragen auf, damit sie parallel laufen. Legen Sie Spaltentypen einmal und früh fest, statt sie spät in der Abfrage zu ändern.

Notebooks

Partitionieren Sie Delta-Tabellen nach den Spalten, nach denen Abfragen filtern, vermeiden Sie aber so viele Partitionen, dass jede nur winzige Dateien enthält. Steuern Sie die Dateigrößen, indem Sie vor dem Schreiben neu partitionieren. Nutzen Sie idempotente Merges mit eindeutigen Schlüsseln. Planen Sie Compaction und Bereinigung ein:

OPTIMIZE silver_order_lines;
VACUUM silver_order_lines RETAIN 168 HOURS;

OPTIMIZE fasst kleine Dateien zu größeren zusammen. VACUUM entfernt Dateien, die älter als die Aufbewahrungsfrist sind und auf die die Tabelle nicht mehr verweist. 168 Stunden ist der Delta-Standard von sieben Tagen.

Beide

Steuern Sie beides über Pipelines, damit Wiederholungen, Abhängigkeiten und Warnungen an einer Stelle liegen. Beobachten Sie die Kapazitätsnutzung in der Microsoft Fabric Capacity Metrics App und verschieben Sie Zeitpläne oder ändern Sie die Kapazitätsgröße, wenn Jobs anfangen zu warten.

Governance und Sicherheit

• Nutzen Sie die Lineage-Ansicht und den Monitoring-Hub, um Quellen, Transformationen und Verbraucher über Dataflows und Notebooks hinweg nachzuverfolgen.

• Vergeben Sie Workspace-Rollen und Berechtigungen auf Item-Ebene einheitlich und beschränken Sie den Schreibzugriff auf kuratierte Schichten (Silver und Gold).

• Hinterlegen Sie keine Secrets im Notebook-Code. Nutzen Sie in Fabric verwaltete Verbindungen und Anmeldedaten.

• Trennen Sie Workspaces für Entwicklung, Test und Produktion. Nutzen Sie die Git-Integration, die neue Dataflow-Gen2-Items und Notebooks unterstützen, mit Freigaben vor dem Deployment.

• Vereinbaren Sie pro Tabelle Data Contracts: Verantwortliche, Erwartungen an die Aktualisierung und Schema.

• Planen Sie bei Delta-Tabellen, wie sich Spalten ändern dürfen, und validieren Sie beim Schreiben.

Häufige Fehler

• Anzunehmen, dass allein die Datenmenge das Werkzeug bestimmt. Wichtiger ist, wie sich die Transformationen verhalten und ob sie falten.

• Das Query Folding früh mit einem bequemen Schritt zu brechen und dann Dataflows für langsam zu halten.

• Aus Spark viele winzige Delta-Dateien zu schreiben. Das Schreiben ist schnell, das Lesen langsam, also planen Sie Compaction ein.

• Mehrere Schreiber auf einer Delta-Tabelle ohne Abstimmung, was zu Konflikten bei gleichzeitigem Zugriff führt. Halten Sie sich an die VACUUM-Empfehlung zur Aufbewahrung, damit Leser nicht scheitern.

• OPTIMIZE aus einem Notebook auf eine Lakehouse-Tabelle auszuführen, die ein Dataflow Gen2 mit inkrementeller Aktualisierung füllt. Diese Kombination wird nicht unterstützt.

• Keine inkrementelle Strategie, sodass vollständige Neuladungen großer Tabellen langsam und teuer werden.

• Kein Monitoring und keine Warnungen, sodass ein Fehler erst Tage später auffällt, wenn jemand die Zahlen braucht.

• Jedes Team löst dasselbe Problem anders, weil nichts zu einer Vorlage gemacht wurde.

FAQs

Werden Dataflows Gen2 in Fabric durch Notebooks ersetzt?

Nein. Sie dienen unterschiedlichen Zwecken und sind beide aktuelle Fabric-Items. Dataflows Gen2 sind der schnellste Weg für die Anbindung strukturierter Daten, wo Query Folding greift. Notebooks sind für verteilte Verarbeitung, komplexe Logik sowie dateilastige oder Streaming-Aufgaben gedacht.

Können Dataflows „sehr große“ Tabellen verarbeiten?

Ja, wenn sie auf Folding und inkrementelle Ladevorgänge ausgelegt sind. Kann die Quelle filtern und aggregieren und lädt jeder Lauf nur aktuelle Daten, hält ein Dataflow eine große Faktentabelle aktuell. Zwingt die Logik Power Query dazu, alles selbst zu verarbeiten, oder braucht sie große Joins, ist ein Notebook meist zuverlässiger.

Wann sollte ich standardmäßig Notebooks nutzen?

Nehmen Sie standardmäßig ein Notebook bei verschachteltem JSON, großen Joins zwischen Faktentabellen, Deduplizierung über sehr große Tabellen, komplexen Fensterfunktionen oder wenn Sie Spark-Bibliotheken sowie Kontrolle über Partitionierung und Delta-Wartung brauchen.

Können wir beides auf derselben Tabelle mischen?

Das geht, aber geben Sie jeder Tabelle pro Schicht nur einen Schreiber. Zum Beispiel schreibt ein Dataflow Bronze oder Silver, und ein Notebook bereitet Silver zu Gold auf. Vermeiden Sie gleichzeitige Schreibzugriffe auf dieselbe Tabelle und lassen Sie die Schritte über Pipelines nacheinander laufen. Das gilt vor allem für die inkrementelle Aktualisierung von Dataflow Gen2 in ein Lakehouse: Microsoft rät dort von weiteren Schreibern auf der Tabelle ab, und OPTIMIZE wird nicht unterstützt.

Wie migrieren wir einen Dataflow in ein Notebook?

Eine automatische Umwandlung gibt es nicht. Übersetzen Sie jeden Power-Query-Schritt in Spark SQL oder PySpark und vergleichen Sie das Ergebnis mit dem des Dataflows. Nutzen Sie die Migration, um Partitionierung, Joins und das Delta-Layout zu überdenken, und lassen Sie den Dataflow weiterlaufen, bis die Ergebnisse übereinstimmen.

Was ist mit Lizenzierung und Kapazität?

Beide verbrauchen Fabric Capacity Units (CUs) aus der Kapazität des Workspaces. Wie viel Sie ausführen können und was es kostet, hängt von der Kapazitätsgröße ab und davon, wie viele Jobs gleichzeitig laufen. Nutzen Sie die Capacity Metrics App, um über Zeitplanung oder Skalierung zu entscheiden.

Unterstützen Dataflows CDC?

Teilweise. Dataflows Gen2 haben eine Einstellung für inkrementelle Aktualisierung, die auf Basis einer Datumsspalte nur aktuelle Zeiträume neu lädt, sofern die Quelle danach filtern kann. Für Change Data Capture über mehrere Quellen, für Watermark-Tracking oder für Merge-Logik, die Löschungen behandelt, bieten Notebooks mehr Kontrolle.

Können Notebooks in Warehouses schreiben?

Ja. Der Spark-Konnektor für Fabric Data Warehouse schreibt einen DataFrame in eine Warehouse-Tabelle. Alternativ schreiben Sie kuratierte Delta-Tabellen in ein Lakehouse und fragen sie über dessen SQL-Analyseendpunkt ab. Wählen Sie die Bereitstellungsschicht danach, wer die Daten nutzt.

Glossar

• Dataflows Gen2: Power Query in Data Factory von Fabric, mit Ergebnissen in OneLake, einem Lakehouse, einem Warehouse oder anderen Zielen.

• Notebook: Eine interaktive Spark-Umgebung in Fabric für Python, SQL, Scala oder R.

• OneLake: Der einzige Data Lake von Fabric, der Speicher unter Lakehouses und Warehouses.

• Lakehouse: Ein Fabric-Item, das Delta-Tabellen und Dateien speichert, mit einem SQL-Analyseendpunkt.

• Warehouse: Das SQL Data Warehouse von Fabric.

• Query Folding: Power Query gibt Transformationen an die Quelle zurück, damit sie dort laufen.

• Delta Lake: Ein offenes Tabellenformat mit Transaktionen, Schemaentwicklung und Time Travel.

• Partitionierung: Daten nach einem Schlüssel, etwa dem Datum, aufteilen, um Ladevorgänge und Abfragen zu beschleunigen.

• Inkrementelles Laden: Nur neue oder geänderte Daten laden statt der ganzen Tabelle.

• Orchestrierung: Jobs mit ihren Abhängigkeiten und Wiederholungen planen, meist mit Fabric-Pipelines.

Wie sich Data Factory in Fabric von Azure Data Factory unterscheidet, lesen Sie unter Fabric vs. Azure Data Factory. Was für die Plattform spricht, steht in Warum Microsoft Fabric und Microsoft Fabric und Power BI.

Fazit

Wenn Sie eine funktionierende Vorlage für „Dataflows als Standard, Notebooks bei Bedarf“ möchten, einschließlich Kapazitätsplanung und Leitplanken, sprechen Sie CaseWhen an.

Quellen

• Differences between Dataflow Gen1 and Dataflow Gen2 - Microsoft Learn

• Incremental refresh in Dataflow Gen2 - Microsoft Learn

• Spark connector for Microsoft Fabric Data Warehouse - Microsoft Learn

• Delta Lake table maintenance - Microsoft Learn