Fabric Data Factory: Datenpipelines in Microsoft Fabric
Du willst ETL/ELT, Scheduling und Data Integration in Microsoft Fabric sauber aufsetzen – ohne Pipeline-Chaos und ohne Blindflug bei Kosten und Governance.
- ETL/ELT mit Data Pipelines
- Dataflow Gen2 mit Power Query
- OneLake, Lakehouse, Warehouse integrieren
- Hybride Quellen sicher anbinden
- Monitoring, Control, Deployment sauber lösen
.png)
Wenn eure Pipelines wackeln, wackelt euer Reporting
Viele BI-Teams bauen Power BI-Dashboards, aber die Datenbasis dahinter ist ein Flickenteppich aus Excel, SQL-Servern, Files und manuell gestarteten Jobs.
Die Folge: verzögerte Aktualisierung, unklare Datenherkunft und steigender Aufwand für „Feuerwehr-Einsätze“ statt echte Analytics.
Was Data Factory in Microsoft Fabric wirklich ist
Data Factory (Microsoft Fabric) ist die Stelle im Fabric-Ökosystem, an der du Data Integration praktisch umsetzt: Daten anbinden, laden, transformieren, planen und überwachen – mit Fokus auf Pipelines und Dataflows (Dataflow Gen2).
Abgrenzung zu Azure Data Factory
Azure Data Factory ist ein eigenständiger Azure-Service. In Microsoft Fabric ist Data Factory in OneLake, Lakehouse und Fabric Data Warehouse eingebettet. Das macht Integration und Governance einfacher, wenn du sowieso im Fabric-Stack arbeitest.
ETL / ELT mit klarer Zielarchitektur
Du definierst, wo Daten landen: OneLake (z. B. Lakehouse) für Rohdaten, dann Transformation und Ausleitung in ein Fabric Data Warehouse oder in Azure SQL Database. So wird aus „Load“ eine wartbare Pipeline-Architektur.
Low Code, aber nicht „No Control“
Dataflows (Dataflow Gen2) nutzen Power Query und M language für Transformation. Gleichzeitig brauchst du Design-Regeln, Monitoring, Security und Governance – sonst wird low code schnell unübersichtlich.
Ehrliche Partnerschaften führen zu erfolgreichen Datenprojekten.
Seit Jahren realisieren wir skalierbare Lösungen mit Microsoft Power BI, Fabric und Copilot.
Zertifizierungen
Projekte
zufriedenheit
Für wen lohnt sich Fabric Data Factory besonders?
Wenn du mehrere Datenquellen (SQL, Files, SaaS, On-Prem) stabil zusammenführen willst und Power BI gerade an manueller Datenaufbereitung oder fragilen Refreshes scheitert.
Und wenn IT und Fachbereich endlich dieselbe „eine“ Datenbasis wollen: OneLake als gemeinsamer Datenspeicher, plus nachvollziehbare ETL/ELT-Prozesse für BI und Analytics.
Was steckt im Paket?
Ein sauberer Einstieg in Fabric Data Factory – vom Use Case bis zur laufenden Ausführung.
Definition & Abgrenzung
Wir klären, was Data Factory in Microsoft Fabric abdeckt (Data Pipelines, Dataflows) und was eher in andere Fabric-Workloads gehört (Lakehouse, Fabric Data Warehouse). Ergebnis: klare Architektur statt Tool-Hopping.
Connectors, Quellen & Ziele
Wir prüfen Data connectors, hybride Szenarien (on-prem über Gateway) und Zielsysteme wie OneLake/Lakehouse, Warehouse oder Azure SQL Database. So weißt du früh, wo Integration realistisch ist.
Transformation & Scheduling
Wir setzen Dataflow Gen2 (Power Query, M language) und/oder Pipelines für ELT/ETL auf, inklusive Scheduling, Parametrisierung und Wiederholbarkeit. Fokus: robuste Updates statt „manuell starten“.
Security, Governance & Monitoring
Wir definieren Rollen, Namenskonventionen, Workspace-Struktur und Monitoring für Pipelines (Control, Fehlerhandling, Alerts). Optional binden wir Governance mit Microsoft Purview an, damit Lineage und Compliance nicht fehlen.
Willst du wissen, ob Fabric Data Factory bei euch Sinn ergibt?
- Einordnung: Data Factory vs. Azure Data Factory
- Quick-Check: Quellen, Pipeline, Kostenmodell
- Nächste Schritte als klare Route
Gemeinsam erzielte Ergebnisse.
Zwei Beispiele aus der Praxis – typische Use Cases für Data Factory in Microsoft Fabric.
Hybride Finance-Daten: von SQL-Server & Files nach OneLake
Ausgangslage
- Manuelle Excel-Konsolidierung für Power BI-Reports
- Mehrere On-Prem SQL Server und Fileserver-Exports
- Refresh-Probleme durch fragile Pipeline-Schritte
- Unklare Governance und fehlende Data Lineage
Ergebnis
- Data Pipelines mit Scheduling und Monitoring etabliert
- Landing in OneLake (Lakehouse) als zentrale Basis
- Standardisierte Transformationen via Dataflow Gen2
- Governance-Regeln und Purview-Lineage eingeführt
SaaS + ERP integrieren: Dataflows für Sales & Controlling
Ausgangslage
- CRM-Daten und ERP-Auszüge ohne gemeinsame Schlüssel
- Viele lokale Power Query-Skripte ohne Wiederverwendung
- Kein einheitlicher Transform-Standard (Design-Wildwuchs)
- Ad-hoc Anforderungen blockieren das BI-Team
Ergebnis
- Dataflows (Dataflow Gen2) als zentraler Transform-Layer
- ELT-Pattern: Laden nach OneLake, dann Modellierung
- Power BI-Datasets auf konsistenter Datenbasis
- Copilot in Fabric für schnelle Analytics-Abfragen pilotiert
Unser Ansatz: In vier Phasen zum Erfolg
So gehen wir vor – pragmatisch, strukturiert, mit klaren Entscheidungen entlang des Polarsterns.
Erstgespräch
Wir klären Use Case, Datenquellen, Zielbild (Lakehouse vs. Fabric Data Warehouse) und ob Data Factory (Microsoft Fabric) oder Azure Data Factory besser passt. Du bekommst eine realistische Einordnung zu Risiko, Zeit und Messbarkeit.
Setup
Wir setzen eine erste Ende-zu-Ende Pipeline auf: Data connectors, Data Pipelines, Dataflow Gen2 (Power Query/M language) und Ziel in OneLake. Dazu kommen Fehlerhandling, Monitoring und ein simples Betriebsmodell.
Training
Wir übertragen Know-how: wie ihr Transformationen strukturiert, wie Scheduling und Deployment funktionieren und welche Governance-Regeln ihr braucht. Ziel: weniger Abhängigkeit, mehr Kontrolle im Betrieb.
Skalierung
Wir skalieren von „eine Pipeline“ zu „Plattform“: Standards, Namenskonventionen, RBAC, Datenzonen (z. B. Bronze/Silver/Gold im Lakehouse) und saubere Integration in Power BI.
Von Bastellösungen zur skalierbaren Datenintegration
Mit Fabric Data Factory bekommst du eine wiederholbare Route: anbinden, laden, transformieren, überwachen – und damit eine stabile Basis für Power BI.
- Refresh abhängig von Einzelpersonen
- Excel- und File-Workarounds im Prozess
- Transformation verteilt in vielen Power Queries
- Unklare Data Lineage und Ownership
- Fehler werden spät im Reporting sichtbar
- Pipelines mit Scheduling und Monitoring
- OneLake als gemeinsame Datenbasis
- Wiederverwendbare Dataflows (Gen2) Standards
- RBAC, Governance und Compliance geregelt
- Power BI auf nachvollziehbaren Datenmodellen
Wir lassen unsere Kunden für uns sprechen
SANHA GmbH & Co. KG
- Absatz- und Produktionsplanung auf Basis von Erfahrung statt Daten
- Unzureichende Transparenz über Nachfrageentwicklung am Markt führte zu Planungsunsicherheit
Ergebnis:
- KI-basierte Absatzprognosen als Grundlage für die Produktionssteuerung
- Effiziente Ressourcennutzung und frühzeitig erkennbare Nachfrageentwicklung
GBG Unternehmensgruppe
- Fragmentierte BI-Landschaft mit Tools wie Snowflake und Tableau
- Strategischer Wunsch nach Microsoft-Integration zur Vereinheitlichung
Ergebnis:
- Integration in das Microsoft-Ökosystem reduziert Systembrüche und vereinfacht die Datenarchitektur
- Unternehmensweite Migration von Tableau und Snowflake zu Power BI und Fabric
EW GROUP GmbH
- Daten aus zahlreichen internationalen Tochtergesellschaften waren verteilt und schwer vergleichbar
- Management hatte keinen konsolidierten Überblick über zentrale KPIs der einzelnen Gesellschaften.
Ergebnis:
- Zentrale Daten- und Reportingplattform schafft Transparenz über Kennzahlen aller Gesellschaften.
- Fundierte Managemententscheidungen auf Basis konsolidierter Daten statt isolierter Einzelreports.
Preise: Einstieg, der sich an Business Value orientiert
Die Pakete unterscheiden sich nach Anzahl Datenquellen, Komplexität der Transformation und Betriebsanforderungen.
- Use-Case- und Architektur-Klärung
- 1–2 Quellen via Data connectors
- Pipeline + Dataflow Gen2 Grundsetup
- Monitoring- und Scheduling-Basics
- Mehrquellen-Integration (hybrid/cloud möglich)
- Transformations-Standard (Power Query, M language)
- OneLake/Lakehouse + optional Warehouse-Ziel
- Governance, RBAC, Betriebsdoku
- Pipelining-Standards über mehrere Teams
- Fehlerhandling, Alerts, erweitertes Monitoring
- Purview-Anbindung für Lineage/Compliance
- Rollout-Plan + Enablement für Betrieb
Willst du wissen, ob Fabric Data Factory bei euch Sinn ergibt?
- Einordnung: Data Factory vs. Azure Data Factory
- Quick-Check: Quellen, Pipeline, Kostenmodell
- Nächste Schritte als klare Route
Häufige Fragen
Was ist Fabric Data Factory – und was ist der Unterschied zu Azure Data Factory?
Data Factory (Microsoft Fabric) ist die Fabric-Umsetzung für Data Integration: Data Pipelines und Dataflows (Dataflow Gen2) sind direkt mit OneLake, Lakehouse und dem Fabric Data Warehouse verzahnt. Azure Data Factory ist ein eigenständiger Azure-Service, der auch ohne Fabric genutzt wird und oft stärker „standalone“ in Azure-Architekturen eingebaut ist.
Kann ich Dataflow Gen2 wie Power Query nutzen?
Ja. Dataflows (Dataflow Gen2) basieren auf Power Query und nutzen die M language für Transformation. Der große Vorteil: Transformationen laufen zentral, wiederverwendbar und geplant – statt verteilt in vielen einzelnen Power BI-Dateien.
Welche Datenquellen kann ich anbinden (Cloud und On-Prem)?
Über Data connectors kannst du viele Services und Datenbanken anbinden (z. B. Azure SQL Database, Files, verschiedene Cloud-Services). Hybride Szenarien sind möglich, typischerweise mit Gateway/Netzwerkanbindung. Wichtig ist ein früher Integrations-Check, damit spätere Pipeline-Blocker (Server-Zugriff, Auth, Durchsatz) nicht erst im Betrieb auffallen.
Wie setzt ihr Security und Governance in Fabric Data Factory um?
Wir kombinieren technische Security (z. B. Role-based access control (RBAC) im Microsoft-Umfeld) mit Governance-Regeln: Workspace-Struktur, Namenskonventionen, Ownership, Deployment-Logik und Monitoring. Wenn ihr Data Lineage und Compliance sauber dokumentieren wollt, ist Microsoft Purview oft der passende Baustein.