Azure Data Factory: Was es ist und wie es funktioniert

Azure Data Factory ist der Cloud-Dienst von Microsoft, um Datenpipelines zu bauen, zu planen und zu überwachen, die Daten zwischen Quellen bewegen und transformieren. Er ersetzt manuelle, skriptbasierte Integrationsarbeit durch eine verwaltete, visuelle Pipeline, die Sie an einer Stelle automatisieren, versionieren und überwachen. Microsoft Fabric enthält eine eigene Data Factory, die auf großen Teilen derselben Pipeline-Engine aufbaut, für Teams, die bereits in einem Fabric-Workspace arbeiten.

Was Azure Data Factory leistet

Eine Data-Factory-Pipeline ist eine Abfolge von Aktivitäten. Die häufigste ist Copy Data. Sie liest aus einem Quell-Dataset und schreibt in ein Ziel-Dataset (Sink). Ein Dataset verweist auf eine bestimmte Quelle oder ein bestimmtes Ziel, etwa einen Containerpfad oder eine Datenbanktabelle. Eine Pipeline kann auch eine gespeicherte Prozedur ausführen, eine Azure Function aufrufen, ein Databricks-Notebook auslösen oder einen Mapping Data Flow für Transformationslogik auf Zeilenebene ausführen.

Drei Bausteine lassen eine Pipeline von selbst laufen:

• Datasets verweisen auf eine bestimmte Quelle oder ein bestimmtes Ziel, etwa einen Containerpfad oder eine Datenbanktabelle.

• Linked Services enthalten die Verbindungsdaten, die ein Dataset braucht, etwa Servername und Authentifizierungsmethode.

• Trigger bestimmen, wann eine Pipeline läuft: nach Zeitplan, in einem wiederkehrenden Fenster oder als Reaktion auf ein Ereignis, etwa eine Datei, die im Speicher ankommt.

Eine Integration Runtime ist die Rechenleistung, die die Daten tatsächlich bewegt. Die Azure IR übernimmt die Bewegung von Cloud zu Cloud. Eine Self-hosted IR, installiert auf einem Rechner in Ihrem Netzwerk, ermöglicht einer Cloud-Pipeline den Zugriff auf einen lokalen SQL Server oder eine Dateifreigabe.

Ein konkretes Pipeline-Beispiel

Eine Pipeline, die eine tägliche CSV-Datei mit Verkäufen aus dem Azure Blob Storage in eine Tabelle einer Azure SQL Database kopiert, sieht so aus, vereinfacht aus dem JSON, das Data Factory erzeugt:

{
  "name": "CopyDailySalesPipeline",
  "properties": {
    "activities": [
      {
        "name": "CopySalesCsvToSql",
        "type": "Copy",
        "inputs": [
          { "referenceName": "BlobSalesCsv", "type": "DatasetReference" }
        ],
        "outputs": [
          { "referenceName": "SqlSalesTable", "type": "DatasetReference" }
        ],
        "typeProperties": {
          "source": { "type": "DelimitedTextSource" },
          "sink": { "type": "AzureSqlSink" }
        }
      }
    ]
  }
}

Ein Schedule-Trigger startet sie jeden Morgen:

{
  "name": "DailyAt6amTrigger",
  "properties": {
    "type": "ScheduleTrigger",
    "typeProperties": {
      "recurrence": {
        "frequency": "Day",
        "interval": 1,
        "startTime": "2026-01-01T06:00:00Z",
        "timeZone": "UTC"
      }
    },
    "pipelines": [
      {
        "pipelineReference": {
          "referenceName": "CopyDailySalesPipeline",
          "type": "PipelineReference"
        }
      }
    ]
  }
}

Im Data Factory Studio bauen Sie beides visuell: Ziehen Sie eine Copy-Aktivität auf die Arbeitsfläche, richten Sie Quelle und Sink auf die beiden Datasets und hängen Sie dann im Menü Add trigger der Pipeline einen Schedule-Trigger an. Das JSON oben schreibt der visuelle Editor im Hintergrund. Müssen die Daten unterwegs umgeformt und nicht nur kopiert werden, kann eine Pipeline statt einer einfachen Copy-Aktivität einen Mapping Data Flow ausführen. Für leichtere Transformationen im Stil von Power Query direkt in Power BI lesen Sie unseren Leitfaden zu Power-BI-Dataflows.

Wann stattdessen Data Factory in Fabric sinnvoll ist

Azure Data Factory ist weiterhin ein unterstützter, aktiv weiterentwickelter Dienst, und bestehende Pipelines müssen nirgendwohin umziehen. Data Factory in Fabric ist die bessere Wahl, wenn:

• Ihre Pipelines ein Fabric Lakehouse oder Warehouse speisen und Sie sie im selben Workspace wie diese Elemente haben wollen, statt sie als eigene Azure-Ressource zu verwalten.

• Ihr Team ohnehin Fabric-Kapazität bezahlt und Pipeline- und Dataflow-Arbeit über diese Kapazität abrechnen will, nicht als separaten Azure-Dienst.

• Sie Dataflows Gen2, Notebooks, Pipelines und Power-BI-Reports in einem Workspace mit gemeinsamen Berechtigungen haben wollen.

Azure Data Factory bleibt die bessere Wahl, wenn Ihre Pipelines Azure-Dienste außerhalb von Fabric speisen oder wenn bestehende CI/CD-Pipelines und Infrastructure as Code bereits darauf ausgerichtet sind und eine Migration keinen klaren Nutzen bringt. Lokale Quellen sind kein Grund zu bleiben: Azure Data Factory erreicht sie über eine Self-hosted Integration Runtime, Fabric-Pipelines über das On-premises Data Gateway. Den vollständigen Funktionsvergleich finden Sie in unserem Data Factory Showdown: Fabric vs. Azure und unter Warum Microsoft Fabric.

FAQs

Gibt es Azure Data Factory noch, seit es Microsoft Fabric gibt?

Ja. Azure Data Factory und Data Factory in Fabric sind beide aktuelle Microsoft-Produkte. Fabric hat Azure Data Factory weder ersetzt noch abgekündigt.

Müssen bestehende Azure-Data-Factory-Pipelines nach Fabric umziehen?

Nein. Es gibt keine erzwungene Migration. Eine Pipeline zu verschieben ist eine bewusste Entscheidung, die Sie treffen, wenn die oben genannten Gründe auf Ihren Workspace zutreffen.

Quellen

• Introduction to Azure Data Factory - Microsoft Learn