Wenn Daten aus ERP, CRM, Dateien und verschiedenen Datenbanken zusammenkommen, scheitert die Analyse selten an fehlenden Informationen. Das eigentliche Problem ist meist, dass die Daten nicht im richtigen Format, zur richtigen Zeit und am richtigen Ort vorliegen. Azure Data Factory hilft dabei, solche Quellen zu verbinden, Daten zu verschieben und wiederholbare Workflows für die Datenanalyse aufzubauen.
Die wichtigsten Punkte auf einen Blick
- Azure Data Factory ist ein cloudbasierter Dienst für Datenintegration, ETL und Workflow-Orchestrierung.
- Pipelines verbinden Quellen, Transformationen und Zieldatenbanken zu automatisierten Abläufen.
- ETL und ELT eignen sich für unterschiedliche Architekturen und Analyseanforderungen.
- Für lokale Systeme ist meist eine Self-hosted Integration Runtime erforderlich.
- Die Kosten hängen vor allem von Aktivitätsausführungen, Laufzeit und Datenflüssen ab.
Was Azure Data Factory eigentlich leistet
Azure Data Factory ist ein verwalteter Cloud-Dienst für Datenintegration. Er verbindet Datenquellen wie SQL Server, Oracle, PostgreSQL, Azure Blob Storage, APIs oder SaaS-Anwendungen mit Zielsystemen für Reporting und Analyse.
Der Dienst speichert die Daten nicht automatisch selbst. Seine Hauptaufgabe besteht darin, Datenbewegungen und Verarbeitungsschritte zu koordinieren. Eine Pipeline kann beispielsweise morgens Verkaufsdaten aus einem Warenwirtschaftssystem laden, Datensätze bereinigen und das Ergebnis in ein Data Warehouse schreiben.
Ich sehe den größten Nutzen deshalb nicht in einer einzelnen Kopierfunktion, sondern in der Automatisierung. Ein einmal sauber gebauter Ablauf kann täglich, stündlich oder durch ein Ereignis ausgelöst laufen, ohne dass jemand Dateien manuell verschieben oder SQL-Skripte starten muss.
ETL, ELT und Orchestrierung verständlich erklärt
Bei ETL werden Daten extrahiert, transformiert und anschließend geladen. Das ist sinnvoll, wenn die Daten bereits vor dem Speichern bereinigt, vereinheitlicht oder anonymisiert werden sollen.
Bei ELT landen die Rohdaten zunächst im Zielsystem. Die Transformation erfolgt dort, etwa in Azure Synapse, einer SQL-Datenbank oder einer Spark-Umgebung. ELT passt oft besser zu modernen Data-Lake- und Data-Warehouse-Architekturen, weil leistungsfähige Analyseplattformen die Verarbeitung selbst übernehmen.
Die Orchestrierung ist die Ablaufsteuerung dahinter. Sie legt fest, welcher Schritt wann und unter welcher Bedingung ausgeführt wird. Genau hier unterscheidet sich ein produktiver Datenprozess von einem einfachen Dateitransfer.
Aus welchen Bausteinen ein Datenworkflow besteht
Die Oberfläche wirkt zunächst übersichtlich, doch die einzelnen Begriffe sollten klar getrennt werden. Eine Pipeline ist nicht dasselbe wie ein Dataset, und ein Connector ersetzt nicht automatisch die notwendige Datenmodellierung.
| Baustein | Aufgabe | Beispiel |
|---|---|---|
| Pipeline | Gruppiert mehrere Verarbeitungsschritte | Tagesabschluss für Verkaufsdaten |
| Activity | Führt eine konkrete Aktion aus | Daten kopieren, SQL ausführen, Datei prüfen |
| Linked Service | Beschreibt die Verbindung zu einem Dienst | Verbindung zu SQL Server oder Blob Storage |
| Dataset | Beschreibt die Struktur oder den Speicherort von Daten | Tabelle, Ordner oder CSV-Datei |
| Trigger | Startet eine Pipeline automatisch | Zeitplan, Dateiankunft oder Ereignis |
| Integration Runtime | Stellt Rechenleistung und Netzwerkzugriff bereit | Azure- oder lokale Laufzeitumgebung |
Eine Copy Activity verschiebt Daten zwischen Quellen und Zielen. Für einfache Szenarien reicht das oft aus. Sobald Spalten umbenannt, Datumswerte vereinheitlicht, Dubletten entfernt oder mehrere Tabellen zusammengeführt werden müssen, kommen Data Flows oder externe Dienste wie Databricks und SQL zum Einsatz.
Die Pipeline kann Schritte nacheinander oder parallel ausführen. Das spart Zeit, verlangt aber eine saubere Abhängigkeitslogik. Wenn ein Bericht erst nach erfolgreicher Datenprüfung erstellt werden darf, muss diese Bedingung ausdrücklich im Workflow hinterlegt sein.
So sieht ein typischer Ablauf in der Praxis aus
Ein realistischer Datenprozess beginnt nicht mit dem Designer, sondern mit der Frage, welche Entscheidung durch die Daten besser werden soll. Für ein Vertriebsdashboard genügt es nicht, Verkaufsdaten irgendwie in die Cloud zu kopieren. Es muss feststehen, welche Kennzahlen gelten, wie Stornos behandelt werden und wann ein Datensatz als vollständig gilt.
- Quellen erfassen: Datenbanken, Dateien, APIs und lokale Anwendungen werden dokumentiert.
- Ziel festlegen: Das Ziel kann ein Data Warehouse, ein Data Lake, eine relationale Datenbank oder ein Analysemodell sein.
- Verbindung einrichten: Zugangsdaten, Netzwerkregeln und Berechtigungen werden als Linked Services angelegt.
- Pipeline bauen: Aktivitäten werden verbunden und mit Parametern wie Datum, Mandant oder Dateipfad versehen.
- Datenqualität prüfen: Fehlende Werte, falsche Datentypen und Dubletten werden erkannt oder protokolliert.
- Ausführung automatisieren: Ein Zeitplan oder ein Ereignis startet die Pipeline.
- Überwachen und verbessern: Fehler, Laufzeiten und Datenmengen werden regelmäßig kontrolliert.
Ein gutes Beispiel ist die tägliche Übernahme von Bestellungen. Die Pipeline liest neue Datensätze aus dem ERP-System, schreibt sie zunächst in einen Staging-Bereich, prüft die Schlüssel und lädt anschließend bereinigte Daten in ein Analysemodell. Staging bedeutet dabei eine Zwischenablage, in der Rohdaten kontrolliert werden, bevor sie in produktive Tabellen gelangen.
Lesen Sie auch: Eclipse Dataspace Connector - Souveräner Datenaustausch erklärt
Warum inkrementelles Laden meistens besser ist
Anstatt jeden Tag die komplette Datenbank zu kopieren, lädt ein inkrementeller Prozess nur neue oder veränderte Datensätze. Dafür kann ein Änderungszeitpunkt, eine fortlaufende ID oder Change Data Capture verwendet werden.
Das reduziert Laufzeit, Netzwerkverkehr und Kosten. Ein vollständiger Ladevorgang bleibt trotzdem sinnvoll, wenn die Datenmenge klein ist oder die Quelle keine zuverlässige Änderungsinformation liefert. Ich würde nicht versuchen, jedes System um jeden Preis inkrementell anzubinden. Ein komplizierter Mechanismus, der regelmäßig falsche Daten übersieht, ist schlechter als ein kontrollierter Vollabgleich.
Welche Rolle Datenbanken und Datenanalyse spielen
Data Factory erzeugt keine aussagekräftigen Erkenntnisse aus chaotischen Quellen. Der Dienst schafft die Verbindung und den Ablauf, während Datenmodell, Datenqualität und Analysewerkzeuge über die Aussagekraft entscheiden.
Für relationale Datenbanken ist es wichtig, Primärschlüssel, Fremdschlüssel und Datentypen sauber zu behandeln. Eine als Text gespeicherte Kundennummer kann beim Laden anders sortiert werden als eine numerische ID. Auch Zeitzonen, Dezimaltrennzeichen und unterschiedliche Datumsformate führen in internationalen Systemen schnell zu falschen Auswertungen.
| Analyseziel | Geeignete Zielstruktur | Worauf es ankommt |
|---|---|---|
| Operatives Reporting | Azure SQL Database oder vergleichbare relationale Datenbank | Aktualität, einfache Abfragen, stabile Tabellen |
| Historische Auswertungen | Data Warehouse | Saubere Dimensionen, Kennzahlen und Historisierung |
| Große Rohdatenmengen | Data Lake | Skalierbarer Speicher, Dateiformate und Metadaten |
| Flexible Exploration | Lakehouse oder Analyseplattform | SQL, Spark und unterschiedliche Datenformate |
Ein häufiger Fehler ist, die gesamte Transformation in Data Factory zu erzwingen. Mapping Data Flows sind praktisch für visuelle, wiederholbare Aufbereitung. Bei sehr komplexen Berechnungen, umfangreicher Statistik oder maschinellem Lernen sind spezialisierte Engines oft besser geeignet.
Für ein Dashboard sollten außerdem nicht nur Rohdaten, sondern fachlich definierte Kennzahlen bereitgestellt werden. „Umsatz“ kann beispielsweise Brutto- oder Nettoumsatz bedeuten. Wenn diese Definition nicht dokumentiert ist, liefert auch eine technisch fehlerfreie Pipeline am Ende unzuverlässige Ergebnisse.
Integration Runtime, Sicherheit und lokale Systeme
Die Integration Runtime ist die technische Umgebung, in der Kopiervorgänge, Datenflüsse und bestimmte Aktivitäten ausgeführt werden. Microsoft unterscheidet dabei im Wesentlichen zwischen Azure Integration Runtime, Self-hosted Integration Runtime und Azure-SSIS Integration Runtime.
Die Azure-Variante eignet sich für cloudbasierte Quellen und Ziele. Sie wird von Microsoft verwaltet und kann Rechenleistung für Datenbewegung und Data Flows bereitstellen. Auf lokale Datenbanken hinter einer Firewall kann sie nicht ohne weitere Netzwerkkonfiguration direkt zugreifen.
Für einen lokalen SQL Server wird häufig eine Self-hosted Integration Runtime auf einem Rechner im eigenen Netzwerk installiert. Diese Variante ist flexibel, bringt aber zusätzlichen Betriebsaufwand mit sich. Der Rechner, seine Updates, Verfügbarkeit und Netzwerkverbindung bleiben in der Verantwortung des Unternehmens.
Bei sensiblen Daten sollten Microsoft Entra ID, rollenbasierte Berechtigungen, Managed Identities und private Netzwerkverbindungen bevorzugt werden. Zugangsschlüssel in Pipeline-Definitionen zu hinterlegen, ist bequem, aber langfristig eine schlechte Sicherheitsentscheidung.
Ein wichtiger Praxispunkt wird leicht unterschätzt: Netzwerkdesign und Datenzugriff müssen vor dem Pipelinebau geklärt werden. Private Endpoints, VPN, ExpressRoute, Firewall-Freigaben und DNS können den eigentlichen Projektaufwand stärker beeinflussen als die Gestaltung der Pipeline.
Was die Nutzung kostet und wo Grenzen liegen
Azure Data Factory hat keinen einfachen Festpreis pro Pipeline. Die Abrechnung richtet sich unter anderem nach Orchestrierung, Aktivitätsausführung, Integration-Runtime-Zeit, Datenflüssen und Überwachungsvorgängen. Zusätzlich können Kosten für Speicher, Netzwerkübertragung, Synapse, Databricks oder die Ziel-Datenbank entstehen.
Die Kosten werden bei vielen Ausführungen schnell sichtbar. Eine Pipeline, die einmal täglich läuft, ist meist deutlich günstiger als ein Prozess, der alle 15 Minuten zahlreiche Aktivitäten startet. Auch Debugging und Datenfluss-Cluster sollten nicht dauerhaft aktiv bleiben, wenn sie nur gelegentlich benötigt werden.
| Kostenfaktor | Typischer Einfluss | Praktische Maßnahme |
|---|---|---|
| Pipeline-Orchestrierung | Anzahl der Aktivitäts- und Triggerausführungen | Unnötige Kleinstaktivitäten reduzieren |
| Datenbewegung | Datenmenge, Laufzeit und Rechenkapazität | Inkrementell laden und Daten komprimieren |
| Mapping Data Flow | Clustergröße und Laufzeit | Cluster nur bei Bedarf starten |
| Netzwerk | Ausgehende Übertragungen und private Verbindungen | Datenwege möglichst innerhalb derselben Region planen |
| Zusatzdienste | SQL, Storage, Synapse oder Databricks | Gesamtkosten statt nur Data Factory betrachten |
Ich würde vor einer produktiven Einführung immer mit einer kleinen Testpipeline beginnen und die tatsächlichen Laufzeiten messen. Eine theoretische Schätzung sagt wenig aus, wenn sich herausstellt, dass ein Connector langsam arbeitet oder ein Data Flow wegen eines einzigen Joins einen großen Cluster benötigt.
Für einfache Dateiimporte kann ein Skript, eine Datenbankprozedur oder ein günstigerer Integrationsdienst ausreichend sein. Die Stärke der Plattform zeigt sich dort, wo viele Quellen, Zeitpläne, Abhängigkeiten und Überwachungsanforderungen zusammenkommen. Für einen einzelnen manuellen Import wäre sie häufig überdimensioniert.
Azure Data Factory oder Data Factory in Microsoft Fabric
Im Jahr 2026 begegnen Teams zwei eng verwandten Varianten. Azure Data Factory ist der etablierte Azure-Dienst für Datenintegration. Data Factory in Microsoft Fabric ist stärker in OneLake, Lakehouse, Data Warehouse, Power BI und weitere Fabric-Komponenten eingebunden.
Wer bereits eine Azure-Landschaft mit Synapse, Azure SQL und Blob Storage betreibt, findet in der klassischen Azure-Variante oft die naheliegende Lösung. Wer eine integrierte Analyseplattform mit zentralem Speicher, Reporting und Data Engineering aufbauen möchte, sollte Fabric zumindest vergleichen.
Die Entscheidung hängt weniger vom Namen als von der vorhandenen Architektur ab. Entscheidend sind Datenquellen, Governance, Netzwerk, Teamkenntnisse, bestehende Verträge und die Frage, ob das Unternehmen eher einzelne Integrationsprozesse oder eine umfassende Analyseplattform benötigt.
Für beide Varianten gilt dasselbe Grundprinzip: Die technische Plattform ersetzt kein Datenkonzept. Ohne klare Verantwortlichkeiten, Qualitätsregeln und ein sinnvolles Zielmodell bleibt auch die modernste Pipeline nur ein automatisierter Transportweg.
Wann ein Data-Factory-Projekt wirklich erfolgreich ist
Ein belastbarer Workflow ist nachvollziehbar, testbar und wiederholbar. Dazu gehören sprechende Namen, parametrisierte Pipelines, getrennte Entwicklungs- und Produktionsumgebungen sowie eine Versionsverwaltung für Änderungen.
- Fehlerbehandlung: Fehlgeschlagene Aktivitäten müssen protokolliert und kontrolliert wiederholbar sein.
- Datenqualität: Regeln für Pflichtfelder, Datentypen und Dubletten gehören in den Prozess.
- Monitoring: Laufzeiten, Datenmengen und Fehlerraten sollten regelmäßig geprüft werden.
- Sicherheit: Identitäten und Berechtigungen müssen nach dem Prinzip der geringsten Rechte vergeben werden.
- Dokumentation: Quelle, Ziel, Ladefrequenz und fachliche Bedeutung jeder Pipeline sollten festgehalten werden.
Mein wichtigster Rat lautet, zuerst einen kleinen, aber vollständigen Anwendungsfall umzusetzen. Eine Pipeline mit Quelle, Qualitätsprüfung, Ziel und Monitoring zeigt schneller, ob Architektur und Verantwortlichkeiten funktionieren, als ein riesiges Konzept mit Dutzenden theoretischen Schnittstellen.
Wer die Plattform so einsetzt, erhält nicht bloß eine Sammlung automatisierter Jobs. Es entsteht eine verlässliche Grundlage, auf der Datenbanken, Berichte und analytische Anwendungen mit konsistenten Informationen arbeiten können.
