Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
GILT FÜR:
Azure Data Factory Azure Synapse Analytics
Tipp
Testen Sie Data Factory in Microsoft Fabric, eine All-in-One-Analyselösung für Unternehmen. Microsoft Fabric deckt alle Aufgaben ab, von der Datenverschiebung bis hin zu Data Science, Echtzeitanalysen, Business Intelligence und Berichterstellung. Erfahren Sie, wie Sie kostenlos eine neue Testversion starten!
Azure Data Factory ist der Datenintegrations- und ETL-Dienst von Microsoft in der Cloud. Dieses Dokument enthält Anleitungen für DataOps in Data Factory. Es ist nicht als vollständiges Tutorial für CI/CD, Git oder DevOps vorgesehen. Stattdessen finden Sie die Anleitung des Data Factory-Teams zum Erreichen von DataOps im Dienst mit Verweisen auf detaillierte Implementierungslinks für bewährte Methoden der Data Factory-Bereitstellung, Factory-Verwaltung und Governance. Am Ende dieses Artikels befindet sich ein Ressourcenabschnitt mit Links zu Tutorials.
Was ist DataOps?
DataOps ist ein Prozess, den Datenorganisationen für die kollaborative Datenverwaltung betreiben, um Entscheidungsträgern einen schnelleren Nutzen zu bieten.
Gartner bietet diese klare Definition von DataOps:
DataOps ist eine kollaborative Datenverwaltungspraxis, die sich auf die Verbesserung der Kommunikation, Integration und Automatisierung von Datenflüssen zwischen Datenmanagern und Datenverbrauchern in einer Organisation konzentriert. Das Ziel von DataOps ist es, durch die Erstellung einer vorhersagbaren Übermittlung und Änderungsverwaltung von Daten, Datenmodellen und verwandten Artefakten einen schnelleren Nutzen zu erzielen. DataOps verwendet Technologie zur Automatisierung von Entwurf, Bereitstellung und Verwaltung der Datenübermittlung mit entsprechenden Governanceebenen und verwendet Metadaten, um die Benutzerfreundlichkeit und den Wert von Daten in einer dynamischen Umgebung zu verbessern.
Wie erreichen Sie DataOps in Azure Data Factory?
Azure Data Factory bietet Datentechnikern ein visuell basiertes Datenpipelineparadigma für die einfache Erstellung von Datenintegrations- und ETL-Projekten auf Cloudebene. Data Factory basiert auf nativen Integrationen mit ausgereiften Versionsverwaltungstools wie GitHub und Azure DevOps sowie dem breiteren Azure-Ökosystem, um viele integrierte Features bereitzustellen, die DataOps ermöglichen und die umfassende Zusammenarbeit, Governance und Artefaktbeziehungen umfassen.
Nachdem Sie Ihr eigenes GitHub- oder Azure DevOps-Repository in Data Factory integriert haben, bietet der Dienst intuitive integrierte Optionen der Benutzeroberfläche für allgemeine Befehle, z. B. Commits, Speichern von Artefakten und Versionskontrolle. Der Dienst bietet auch die Möglichkeit, bewährte Methoden zum Einchecken von CI/CD und Code bereitzustellen, um die Integrität Ihrer Produktionsumgebung zu schützen.
„Code“ in Azure Data Factory
Alle Artefakte in Azure Data Factory, unabhängig davon, ob es sich um Pipelines, verknüpfte Dienste, Auslöser usw. handelt, verfügen über entsprechende „Code“-Darstellungen in JSON hinter der Integration der visuellen Benutzeroberfläche. Diese Artefakte entsprechen den Standards von Azure Resource Manager-Vorlagen. Sie finden den Code, indem Sie auf das Klammersymbol oben rechts auf dem Canvas klicken. JSON-„Beispielcode“ würde wie folgt aussehen:
Livemodus und Git-Versionskontrolle
Jede Factory verfügt über eine einzelne Quelle der Wahrheit: Pipelines, verknüpfte Dienste und Triggerdefinitionen, die im Dienst gespeichert sind. Diese Quelle der Wahrheit ist, was die Pipelineausführungen ausführen und was das Verhalten von Triggern bestimmt. Wenn Sie sich im Livemodus befinden, ändern Sie bei jeder Veröffentlichung direkt die einzelne Quelle der Wahrheit. Die folgende Abbildung zeigt, wie die Schaltfläche Alle veröffentlichen im Livemodus aussieht.
Der Livemodus kann für einzelne Personen, die an Nebenprojekten arbeiten, praktisch sein, da Entwickler die unmittelbaren Auswirkungen ihrer Codeänderungen sehen können. Von der Verwendung für ein Team von Entwicklern, die an Arbeitsprojekten auf Produktionsebene arbeiten, wird aber abgeraten. Zu den Gefahren gehören Fat-Finger-Fehler, versehentliches Löschen kritischer Ressourcen, Veröffentlichung von nicht getestetem Code usw., um nur einige zu nennen. Wenn Sie an unternehmenskritischen Projekten und Plattformen arbeiten, sollten Sie ein Git-Repository einbinden und den Git-Modus in Data Factory verwenden, um den Entwicklungsprozess zu optimieren. Versionskontrolle und Gated-Check-In-Funktionen des Git-Modus helfen Ihnen dabei, die meisten, wenn nicht alle Unfälle zu verhindern, die mit der direkten Arbeit im Livemodus verbunden sind.
Hinweis
Im Git-Modus wird die Schaltfläche Veröffentlichen oder Alle veröffentlichen durch Speichern oder Alle speichern ersetzt, und Ihre Änderungen werden an Ihre eigenen Branches committet (die Livecodebasen werden nicht direkt geändert).
Einrichten der GitHub- und Azure DevOps-Integration
In Azure Data Factory wird dringend empfohlen, Ihr Repository entweder in GitHub oder Azure DevOps zu speichern. Der Dienst unterstützt beide Methoden vollständig, und die Wahl des zu verwendenden Repositorys hängt von Ihren individuellen Organisationsstandards ab. Es gibt zwei Methoden zum Einrichten eines neuen Repositorys oder zum Herstellen einer Verbindung mit einem vorhandenen Repository: Verwenden des Azure-Portals oder Erstellen über die Azure Data Factory Studio-Benutzeroberfläche.
Erstellen einer Factory über das Azure-Portal
Wenn Sie eine neue Data Factory über das Azure-Portal erstellen, ist das Git-Standardrepository Azure DevOps. Sie können auch GitHub als Repository auswählen und Ihre Repositoryeinstellungen konfigurieren.
Wählen Sie im Azure-Portal den Repositorytyp aus, und geben Sie die Repository- und Branchnamen ein, um eine neue, nativ in Git integrierte Factory zu erstellen.
Erzwingen der Verwendung von Git mit Azure Policy in Ihrer Organisation
Die Verwendung von Git in Ihren Azure Data Factory-Projekten ist eine bewährte Methode und wird daher dringend empfohlen. Auch wenn Sie keinen vollständigen CI/CD-Prozess implementieren, ermöglicht die Git-Integration mit ADF das Speichern Ihrer Ressourcenartefakte in Ihrer eigenen Sandboxumgebung (Git-Branch), in der Sie Ihre Änderungen unabhängig von den restlichen Factory-Branches testen können. Sie können Azure Policy verwenden, um die Verwendung von Git in der Factory Ihrer Organisation zu erzwingen.
Azure Data Factory Studio
Nachdem Sie Ihre Data Factory erstellt haben, können Sie auch über Azure Data Factory Studio eine Verbindung mit Ihrem Repository herstellen. Auf der Registerkarte Verwalten wird die Option zum Konfigurieren Ihres Repositorys und der Repositoryeinstellungen angezeigt.
Durch einen geführten Prozess werden Sie durch eine Reihe von Schritten geleitet, die Ihnen beim einfachen Konfigurieren und Herstellen einer Verbindung mit dem Repository Ihrer Wahl helfen. Nach der vollständigen Einrichtung können Sie mit der Zusammenarbeit beginnen und Ihre Ressourcen in Ihrem Repository speichern.
Continuous Integration und Continuous Delivery (CI/CD)
CI/CD ist ein Paradigma der Codeentwicklung, bei dem Änderungen überprüft und getestet werden, während sie sich durch verschiedene Phasen bewegen – Entwicklung, Test, Staging usw. Nachdem sie in jeder Phase überprüft und getestet wurden, werden sie schließlich in Livecodebasen in einer Produktionsumgebung veröffentlicht.
Continuous Integration (CI) ist die Praxis des automatischen Testens und Überprüfens bei jeder Änderung, die ein Entwickler an Ihrer Codebasis vornimmt. Continuous Delivery (CD) bedeutet, dass die Änderungen nach erfolgreichem Continuous Integration-Test kontinuierlich in die nächste Phase gebracht werden.
Wie bereits kurz erwähnt, hat „Code“ in Azure Data Factory die Form von Azure Resource Manager-Vorlagen-JSON. Daher umfassen die Änderungen, die durch den CI/CD-Prozess (Continuous Integration/Delivery) erfolgen, Ergänzungen, Löschungen und Bearbeitungen von JSON-Blobs.
Pipelineausführungen in Azure Data Factory
Bevor wir über CI/CD in Azure Data Factory sprechen, müssen wir zunächst darüber sprechen, wie der Dienst eine Pipeline ausführt. Bevor Data Factory eine Pipeline ausführt, werden folgende Schritte ausgeführt:
- Die neueste veröffentlichte Definition der Pipeline und der zugehörigen Ressourcen wird abgerufen, z. B. Datasets, verknüpfte Dienste usw.
- Diese werden in Aktionen kompiliert; wenn Data Factory sie kürzlich ausgeführt hat, ruft es die Aktionen aus zwischengespeicherten Kompilierungen ab.
- Die Pipeline wird ausgeführt.
Das Ausführen der Pipeline umfasst die folgenden Schritte:
- Der Dienst übernimmt die Momentaufnahme der Pipelinedefinition.
- Während der gesamten Pipelinedauer ändern sich die Definitionen nicht.
- Auch wenn Ihre Pipelines lange ausgeführt werden, bleiben sie von nachfolgenden Änderungen, die nach dem Start vorgenommen wurden, unbetroffen. Wenn Sie während der Ausführung Änderungen am verknüpften Dienst, an Pipelines usw. veröffentlichen, wirken sich diese nicht auf laufende Ausführungen aus.
- Wenn Sie Änderungen veröffentlichen, verwenden nachfolgende Ausführungen, die nach der Veröffentlichung gestartet wurden, die aktualisierten Definitionen.
Veröffentlichen in Azure Data Factory
Unabhängig davon, ob Sie Pipelines mit Azure Release Pipeline zur Automatisierung der Veröffentlichung oder mit der manuellen Bereitstellung von Resource Manager-Vorlagen bereitstellen, ist die Veröffentlichung im Back-End eine Reihe von Erstellungs-/Aktualisierungsvorgängen von Datasets, verknüpften Diensten, Pipelines und Triggern für jedes der Artefakte. Der Effekt ist identisch mit dem direkten Ausführen der zugrunde liegenden Rest-API-Aufrufe.
Einige Dinge ergeben sich aus den Aktionen hier:
- Alle diese API-Aufrufe sind synchron, was bedeutet, dass der Aufruf nur zurückgegeben wird, wenn die Veröffentlichung erfolgreich ist/fehlschlägt. Für das Artefakt gibt es keinen Zustand der teilweisen Bereitstellung.
- API-Aufrufe sind weitgehend sequenziell. Wir versuchen, die Aufrufe zu parallelisieren, während die referenziellen Abhängigkeiten der Artefakte beibehalten werden. Die Reihenfolge der Bereitstellungen ist wie folgt: verknüpfter Dienst –> Dataset/Integration Runtime –> Pipeline –> Trigger. Diese Reihenfolge stellt sicher, dass abhängige Artefakte ordnungsgemäß auf ihre Abhängigkeiten verweisen können. Pipelines sind beispielsweise von Datasets abhängig, sodass Data Factory sie nach Datasets bereitstellt.
- Die Bereitstellung von verknüpften Diensten, Datasets usw. ist unabhängig von den Pipelines. Es gibt Situationen, in denen Data Factory verknüpfte Dienste aktualisiert, bevor eine Pipeline aktualisiert wird. Über diese Situation wird im Abschnitt Wann sollte ein Trigger gestoppt werden? eingegangen.
- Die Bereitstellung löscht keine Artefakte aus den Factorys. Sie müssen explizit Lösch-APIs für jeden Artefakttyp (Pipeline, Dataset, verknüpfter Dienst usw.) aufrufen, um eine Factory zu bereinigen. Beachten Sie als Beispiel das Beispielskript nach der Bereitstellung aus Azure Data Factory.
- Auch wenn Sie keine Pipeline, kein Dataset oder keinen verknüpften Dienst verändert haben, wird dennoch ein Aufruf der Schnellupdate-API für die Factory aufgerufen.
Veröffentlichen von Triggern
- Trigger haben Zustände: gestartet oder gestoppt.
- Sie können keine Änderungen an einem Trigger im Modus gestartet vornehmen. Sie müssen einen Trigger stoppen, bevor Sie Änderungen veröffentlichen.
- Sie können die API zum Erstellen oder Aktualisieren von Triggern für einen Trigger im Modus gestartet aufrufen.
- Wenn sich die Nutzdaten ändern, schlägt die API fehl.
- Wenn die Nutzdaten unverändert bleiben, ist die API erfolgreich.
- Dieses Verhalten hat tiefgreifende Auswirkungen darauf, wann ein Trigger gestoppt werden soll.
Wann sollte ein Trigger gestoppt werden?
Wenn es um die Bereitstellung in einer Produktions-Data Factory geht und Livetrigger andauernd Pipelineausführungen starten, stellt sich die Frage ob sie gestoppt werden sollten.
Die kurze Antwort lautet, dass Sie nur in den folgenden wenigen Szenarien erwägen sollten, den Trigger zu stoppen:
- Sie müssen den Trigger stoppen, wenn Sie die Triggerdefinitionen aktualisieren, einschließlich Feldern wie Enddatum, Häufigkeit und Pipelinezuordnung.
- Es wird empfohlen, den Trigger zu stoppen, wenn Sie die Datasets oder verknüpften Dienste aktualisieren, auf die in einer Livepipeline verwiesen wird. Wenn Sie z. B. die Anmeldeinformationen für SQL Server rotieren.
- Sie können den Trigger stoppen, wenn die zugeordnete Pipeline Fehler auslöst, fehlschlägt und Ihre Server belastet.
Dies sind die wenigen Punkte, die beim Stoppen von Triggern zu berücksichtigen sind:
- Wie im Abschnitt Pipelineausführungen in Azure Data Factory erläutert, erstellt ein Trigger beim Starten einer Pipelineausführung eine Momentaufnahme der Pipeline-, Dataset-, Integration Runtime- und verknüpften Dienstdefinitionen. Wenn die Pipeline ausgeführt wird, bevor die Änderungen im Back-End aufgefüllt werden, startet der Trigger eine Ausführung mit der alten Version. In den meisten Fällen sollte das kein Problem sein.
- Wie im Abschnitt Veröffentlichen von Triggern erläutert. Wenn sich ein Trigger im Status gestartet befindet, kann er nicht aktualisiert werden. Wenn Sie also Details zur Triggerdefinition ändern müssen, stoppen Sie den Trigger, bevor Sie die Änderungen veröffentlichen.
- Wie im Abschnitt Veröffentlichen in Azure Data Factory erläutert, werden Änderungen an den Datasets oder verknüpften Diensten vor Pipelineänderungen veröffentlicht. Um sicherzustellen, dass die Pipelineausführung die richtigen Anmeldeinformationen verwendet und mit den richtigen Servern kommuniziert, wird empfohlen, auch den zugeordneten Trigger zu stoppen.
Vorbereiten von „Code“-Änderungen
Es wird empfohlen, diese bewährten Methoden für die Pull Requests zu befolgen.
- Jeder Entwickler sollte an seinen eigenen einzelnen Branches arbeiten und letzten Endes Pull Requests für den Mainbranch des Repositorys erstellen. Weitere Informationen finden Sie in den Tutorials zu Pull Requests in GitHub und DevOps.
- Wenn Gatekeeper die Pull Requests genehmigen und die Änderungen im Mainbranch zusammenführen, kann der CI/CD-Prozess gestartet werden. Es gibt zwei vorgeschlagene Methoden, um Änderungen in allen Umgebungen zu fördern: automatisiert und manuell.
- Sobald Sie bereit sind, CI/CD-Pipelines zu starten, können Sie dies in der Regel mithilfe von Azure-Pipelinefreigaben tun oder Bereitstellungen bestimmter einzelner Pipelines mithilfe dieses Open Source Hilfsprogramms von Azure Player durchführen.
Automatisierte Bereitstellung von Änderungen
Zur Unterstützung der automatisierten Bereitstellungen empfehlen wir die Verwendung der Azure Data Factory-Hilfsprogramme aus dem npm-Paket. Mithilfe des npm-Pakets können Sie alle Ressourcen in einer Pipeline überprüfen und die ARM-Vorlagen für den Benutzer generieren.
Informationen zu den ersten Schritten mit dem npm-Paket Azure Data Factory-Hilfsprogramme finden Sie unter Automatisiertes Veröffentlichen für Continuous Integration und Delivery.
Manuelle Bereitstellung von Änderungen
Nachdem Sie Ihren Branch wieder mit dem Hauptbranch für die Zusammenarbeit in Ihrem Git-Repository zusammengeführt haben, können Sie Ihre Änderungen manuell im Azure Data Factory-Livedienst veröffentlichen. Der Dienst bietet mit der Option Veröffentlichung deaktivieren (aus ADF Studio) die Benutzeroberflächensteuerung für die Veröffentlichung aus Nichtentwicklungsfactorys.
Selektive Bereitstellung
Die selektive Bereitstellung basiert auf einem Feature von GitHub und Azure DevOps, das als Cherry Picking bezeichnet wird. Mit diesem Feature können Sie nur bestimmte Änderungen bereitstellen und andere ausschließen. Beispielsweise hat ein Entwickler Änderungen an mehreren Pipelines vorgenommen, aber für die heutige Bereitstellung möchten wir möglicherweise nur Änderungen an einer Pipeline bereitstellen.
Befolgen Sie die Tutorials von Azure DevOps und GitHub, um die Commits auszuwählen, die für die benötigte Pipeline relevant sind. Stellen Sie sicher, dass alle Änderungen, einschließlich relevanter Änderungen an den Triggern, verknüpften Diensten und Abhängigkeiten, die der Pipeline zugeordnet sind, ausgewählt wurden.
Nachdem Sie die Änderungen ausgewählt und mit der Hauptpipeline für die Zusammenarbeit zusammengeführt haben, können Sie den CI/CD-Prozess für die vorgeschlagenen Änderungen starten. Weitere Informationen zu Hotfixes, zur Auswahl oder Verwendung externer Frameworks für die selektive Bereitstellung finden Sie im Abschnitt Automatisierte Tests dieses Artikels.
Komponententest
Komponententests sind ein wichtiger Teil des Prozesses der Entwicklung neuer Pipelines oder der Bearbeitung vorhandener Data Factory-Artefakte, der sich auf das Testen von Codekomponenten konzentriert. Data Factory ermöglicht einzelne Komponententests auf Pipeline- und Datenfluss-Artefaktebene mithilfe des Pipeline-Debugfeatures.
Beim Entwickeln von Datenflüssen können Sie Einblicke in jede einzelne Transformation und Codeänderung gewinnen, indem Sie die Daten-Previewfunktion verwenden, um Komponententests durchzuführen, bevor Sie Ihre Änderungen in der Produktion bereitstellen.
Der Dienst bietet Live- und interaktives Feedback zu Ihren Pipelineaktivitäten auf der Benutzeroberfläche beim Debuggen und bei Komponententests in Azure Data Factory.
Automatisiertes Testen
Für automatisierte Tests stehen mehrere Tools zur Verfügung, die Sie mit Azure Data Factory verwenden können. Da der Dienst Objekte im Dienst als JSON-Entitäten speichert, kann es praktisch sein, das Open-Source-Framework für .NET-Komponententests NUnit mit Visual Studio zu verwenden. Informationen finden Sie in dem Beitrag Setup automated testing for Azure Data Factory (Einrichten von automatisierten Tests für Azure Data Factory), der eine ausführliche Erläuterung zum Einrichten einer automatisierten Komponententestumgebung für Ihre Factory enthält. (Besonderer Dank geht an Richard Swinbank für die Erlaubnis, diesen Blog zu nutzen.)
Kunden können auch TEST-Pipelines mit PowerShell oder AZ CLI als Teil des CI/CD-Prozesses für die Schritte vor und nach der Bereitstellung ausführen.
Eine wichtige Stärke der Data Factory liegt in der Parametrisierung von Datasets. Mit diesem Feature können Kunden dieselben Pipelines mit unterschiedlichen Datasets ausführen, um sicherzustellen, dass ihre neue Entwicklung alle Quell- und Zielanforderungen erfüllt.
Andere CI/CD-Frameworks für Azure Data Factory
Wie bereits beschrieben, ist die integrierte Git-Integration nativ über die Azure Data Factory-Benutzeroberfläche verfügbar, einschließlich Zusammenführung, Verzweigung, Vergleich und Veröffentlichung. Es gibt aber auch andere nützliche CI/CD-Frameworks, die in der Azure-Community beliebt sind und alternative Mechanismen für ähnliche Funktionen bereitstellen. Die Azure Data Factory Git-Methodik basiert auf ARM-Vorlagen, während Frameworks wie ADFTools von Kamil Nowinski einen anderen Ansatz verfolgen, indem sie stattdessen einzelne JSON-Artefakte aus Ihrer Factory verwenden. Datentechniker, die mit Azure DevOps vertraut sind und es vorziehen, in dieser Umgebung zu arbeiten (im Gegensatz zu dem ARM-basierten Benutzeroberflächenansatz, den der Dienst standardmäßig anbietet), werden eventuell feststellen, dass dieses Framework für sie und für gängige Szenarien wie Teilbereitstellungen gut funktioniert. Dieses Framework kann auch die Behandlung von Triggern bei der Bereitstellung in Umgebungen mit ausgeführten Triggerzuständen vereinfachen.
Datengovernance in Azure Data Factory
Ein wichtiger Aspekt effektiver DataOps ist die Datengovernance. Bei ETL-Tools für die Datenintegration kann das Bereitstellen von Datenherkunfts- und Artefaktbeziehungen wichtige Informationen für einen Datentechniker bereitstellen, um die Auswirkungen von nachgeschalteten Änderungen zu verstehen. Data Factory bietet integrierte verwandte Artefaktansichten, die Ihre Factoryimplementierung bilden.
Die native Integration in Microsoft Purview bietet außerdem Herkunft, Auswirkungsanalyse und Datenkatalogisierung.
Microsoft Purview stellt eine Lösung für vereinheitlichte Datengovernance zur Verfügung, mit der Sie Ihre lokalen, Multi-Cloud- und SaaS-Daten (Software-as-a-Service) verwalten und steuern können. So können Sie mühelos eine ganzheitliche, aktuelle Übersicht über Ihre Datenlandschaft mit automatisierter Datenermittlung, Klassifizierung vertraulicher Daten und End-to-End-Datenherkunft erstellen. Diese Features ermöglichen Datenverbrauchern den Zugriff auf eine nützliche, vertrauenswürdige Datenverwaltung.
Mit der nativen Integration in Ihren Purview Data Catalog ermöglicht Data Factory eine einfache Suche und Ermittlung von Datenressourcen, die in Ihren Datenintegrationspipelines über die gesamte Bandbreite des Datenbestands Ihrer Organisation hinweg verwendet werden können.
Sie können über die Hauptsuchleiste von Azure Data Factory Studio Datenressourcen in Ihrem Purview-Katalog finden.
