Dataflows Gen1 und Gen2: Speicher, Staging und Fabric-Kapazität
Dataflows Gen2 schreibt nach OneLake und in Fabric-Lakehouse-Tabellen. Falsches Staging kann jedoch gemeinsame Kapazität belasten und Power-BI-Berichte beeinträchtigen.
TL;DR
Dataflows Gen1 speichert transformierte Daten im internen Power-BI-Speicher. Dataflows Gen2 schreibt sie über OneLake in Delta-Parquet-Tabellen eines Fabric Lakehouse. Staging und Transformationen verbrauchen Fabric Capacity Units. Wiederholte Verarbeitung oder Aktualisierungen zu Spitzenzeiten können andere Workloads drosseln und die Berichtsdarstellung beeinträchtigen.
Original auf M365 FM Podcast. Artikel lesen · vorgeschlagen von Mirko Peters
Dies ist unsere eigene Kurzfassung, keine Wiederveröffentlichung oder vollständige Übersetzung.
Bedeutung für Governance
- Makers: Staging und Transformationen sorgfältig konfigurieren, weil wiederholte Verarbeitung unnötigen Rechenaufwand erzeugen kann.
- Admins/CoE: Fabric Capacity Units überwachen und schwere ETL-Aufträge in geeigneten Workspaces oder ausserhalb der Spitzenzeiten ausführen, um gemeinsame Workloads zu schützen.
- Leadership/Business: Bereinigte Daten in Lakehouse-Tabellen standardisieren, um widersprüchliche Zahlen zu reduzieren und das Vertrauen in Dashboards zu stärken.
Häufige Fragen
Wie speichert Dataflows Gen2 bereinigte Daten in Microsoft Fabric?
Dataflows Gen2 schreibt bereinigte Daten über OneLake in Delta-Parquet-Tabellen eines Fabric Lakehouse. Dadurch stehen sie nachgelagerten Fabric-Workloads zur Verfügung.
Welche Folgen kann falsches Staging bei Dataflows Gen2 für Fabric-Kapazität haben?
Falsches Staging kann grosse Datenmengen wiederholt in den Speicher laden und dadurch zusätzlichen Rechenaufwand sowie einen schnelleren Verbrauch der Fabric-Kapazität verursachen.
Wie sollten Teams schwere Dataflows-Gen2-Aktualisierungen planen?
Schwere ETL-Aufträge sollten in geeigneten dedizierten Workspaces oder ausserhalb der Geschäftszeiten laufen, damit interaktive Workloads weniger beeinträchtigt werden.