DataOps für das moderne Data Warehouse

Azure Data Factory
Azure Databricks
Azure DevOps
Azure Key Vault
Azure Synapse Analytics

In diesem Artikel wird beschrieben, wie ein fiktives Stadtplanungsbüro diese Lösung nutzen könnte. Die Lösung bietet eine End-to-End-Datenpipeline, die dem MDW-Architekturmuster folgt, zusammen mit entsprechenden DevOps- und DataOps-Prozessen, um die Nutzung von Parkplätzen zu bewerten und fundierte Geschäftsentscheidungen zu treffen.

Architecture

Das folgende Diagramm zeigt die allgemeine Architektur der Lösung.

Architekturdiagramm mit DataOps für das moderne Data Warehouse

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

Azure Data Factory orchestriert und Azure Data Lake Storage Gen2 speichert die Daten.

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

  1. Die Webdienst-API für Stadtparkplätze von Contoso steht zum Übertragen von Daten von den einzelnen Parkplätzen zur Verfügung.

  2. Es gibt einen Data Factory-Kopierauftrag, der die Daten in das Landing-Schema überträgt.

  3. Als Nächstes bereinigt Azure Databricks die Daten und standardisiert die Daten. Dabei werden die Rohdaten übernommen und so aufbereitet, dass sie von Data Scientists verwendet werden können.

  4. Falls bei der Validierung ungültige Daten entdeckt werden, werden diese in das Schema für falsch formatierte Daten (Malformed) ausgesondert.

    Important

    Die Benutzer haben gefragt, warum die Daten nicht überprüft werden, bevor sie in Data Lake Storage gespeichert werden. Der Grund dafür ist, dass sich durch die Validierung ein Fehler ergeben könnte, der das Dataset beschädigt. Wenn Sie in diesem Schritt einen Fehler einführen, können Sie den Fehler beheben und Ihre Pipeline erneut ausführen. Wenn Sie die fehlerhaften Daten entfernt haben, bevor Sie sie zu Data Lake Storage hinzugefügt haben, sind die fehlerhaften Daten nutzlos, da Sie Ihre Pipeline nicht wiederholen können.

  5. Es gibt einen zweiten Azure Databricks Transformationsschritt, der die Daten in ein Format konvertiert, das Sie im Data Warehouse speichern können.

  6. Zum Schluss werden die Daten von der Pipeline auf zwei verschiedene Arten bereitgestellt:

    1. Databricks stellt die Daten dem Data Scientist zur Verfügung, damit er Modelle trainieren kann.

    2. Polybase verschiebt die Daten vom Data Lake in Azure Synapse Analytics und Power BI greift auf die Daten zu und stellt sie dem Geschäftsbenutzer vor.

Components

  • Azure Data Factory ist ein cloudbasierter Datenintegrationsdienst, der Datenbewegungen und -orchestrierung ermöglicht. In dieser Architektur wird die Pipeline initiiert, indem Daten aus der Contoso City Park-Webdienst-API in die Zielzone des Datensees kopiert werden.

  • Azure Data Lake Storage Gen2 ist ein skalierbarer und sicherer Datensee, der auf Azure Blob Storage basiert, die mehrstufige Speicher- und wiedergabefähige Pipelines unterstützt. In dieser Architektur dient sie als zentrales Repository für Rohdaten und verarbeitete Daten in Lande-, fehlerhaften und validierten Datenzonen.

  • Azure Databricks ist eine Apache Spark-basierte Analyseplattform, die für Big Data und maschinelles Lernen entwickelt wurde. In dieser Architektur werden zwei wichtige Transformationsschritte ausgeführt. Zunächst werden rohe Daten bereinigt und standardisiert, während falsch formatierte Datensätze in ein separates Schema gefiltert werden. Anschließend werden validierte Daten in ein Format konvertiert, das für die Speicherung von Data Warehouse geeignet ist und verarbeitete Daten für Datenwissenschaftler zur Modellschulung zur Verfügung stellt.

  • Azure Key Vault ist ein sicherer Clouddienst zum Verwalten von Geheimschlüsseln, Schlüsseln und Zertifikaten. In dieser Architektur werden vertrauliche Konfigurationseinstellungen und Anmeldeinformationen gespeichert, die in der gesamten Pipeline verwendet werden, wodurch die zentrale und sichere Konfigurationsverwaltung bereitgestellt wird.

  • Azure Synapse Analytics ist ein integrierter Analysedienst, der Big Data- und Data Warehouse-Funktionen kombiniert. In dieser Architektur dient sie als Data Warehouse, das transformierte Daten aus Data Lake Storage über PolyBase zum Abfragen und Melden erfasst.

  • Power BI ist ein Business Analytics-Tool, das interaktive Visualisierungen und Dashboards bereitstellt. In dieser Architektur verbindet es sich mit Azure Synapse Analytics, um Parknutzungsdaten für Stadtplaner für fundierte Entscheidungsfindung zu präsentieren.

Szenariodetails

Mit einem modernen Data Warehouse (MDW) können Sie problemlos alle Ihre Daten in beliebigem Umfang zusammenführen. Dabei spielt es keine Rolle, ob es sich um strukturierte, unstrukturierte oder teilweise strukturierte Daten handelt. Sie können Einblicke in ein MDW über Analysedashboards, Betriebsberichte oder erweiterte Analysen für alle Ihre Benutzer erhalten.

Das Einrichten einer MDW-Umgebung für eine Entwicklungsumgebung (dev) und eine Produktionsumgebung (prod) ist komplex. Die Automatisierung des Prozesses ist entscheidend. Dadurch wird die Produktivität gesteigert und gleichzeitig das Fehlerrisiko minimiert.

In diesem Artikel wird beschrieben, wie ein fiktives Stadtplanungsbüro diese Lösung nutzen könnte. Die Lösung bietet eine End-to-End-Datenpipeline, die dem MDW-Architekturmuster folgt, zusammen mit entsprechenden DevOps- und DataOps-Prozessen, um die Nutzung von Parkplätzen zu bewerten und fundierte Geschäftsentscheidungen zu treffen.

Lösungsanforderungen

  • Möglichkeit zum Sammeln von Daten aus verschiedenen Quellen oder Systemen.

  • "Infrastruktur als Code: Neue Entwicklungs- und Staging-Umgebungen automatisiert bereitstellen."

  • Bereitstellen von Anwendungsänderungen in verschiedenen Umgebungen auf automatisierte Weise:

    • Implementieren von CI/CD-Pipelines (Continuous Integration und Continuous Delivery).

    • Verwenden Sie Bereitstellungsgates für manuelle Genehmigungen.

  • Pipeline-as-Code: Sicherstellen, dass die CI/CD-Pipelinedefinitionen in der Quellcodeverwaltung vorliegen.

  • Durchführen von Integrationstests für Änderungen mithilfe eines Beispieldatasets.

  • Ausführen von Pipelines nach einem Zeitplan.

  • Unterstützen der zukünftigen agilen Entwicklung, einschließlich Hinzufügen von Data Science-Workloads.

  • Unterstützung für Sicherheit auf Zeilen- und Objektebene:

    • Das Sicherheitsfeature ist in SQL-Datenbank verfügbar.

    • Sie finden sie auch in Azure Synapse Analytics, Azure Analysis Services und Power BI.

  • Unterstützung für zehn gleichzeitige Dashboardbenutzer und zwanzig gleichzeitige Hauptbenutzer.

  • Die Datenpipeline sollte eine Datenvalidierung durchführen und falsch formatierte Datensätze in einen angegebenen Speicher herausfiltern.

  • Unterstützung der Überwachung.

Mögliche Anwendungsfälle

In diesem Artikel wird die fiktive Stadt Contoso zur Beschreibung des Anwendungsfallszenarios verwendet. Hierbei besitzt und verwaltet Contoso die Parksensoren für die Stadt. Contoso verfügt auch über die APIs, die eine Verbindung mit den Sensoren herstellen und Daten daraus abrufen. Es wird eine Plattform benötigt, mit der Daten aus vielen verschiedenen Quellen gesammelt werden. Die Daten müssen dann validiert, bereinigt und in ein bekanntes Schema transformiert werden. Contoso-Stadtplaner können dann Berichtsdaten zur Nutzung von Parkplätzen mit Datenvisualisierungstools wie Power BI untersuchen und bewerten, um zu bestimmen, ob sie mehr Parkplätze oder verwandte Ressourcen benötigen.

Verfügbarkeit von Straßenparkplätzen

Considerations

Diese Überlegungen implementieren die Säulen des Azure Well-Architected Frameworks, bei dem es sich um eine Reihe von Leitsätzen handelt, die verwendet werden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Die Überlegungen in diesem Abschnitt fassen wichtige Erkenntnisse und bewährte Methoden zusammen, die durch diese Lösung veranschaulicht werden:

  • Verwenden Sie Daten-Tiering in Ihrem Data Lake. Bewahren Sie unveränderte Quelldaten in der Landing Zone auf, leiten Sie Datensätze, die die Validierung nicht bestehen, in die Malformed Zone weiter, und überführen Sie validierte Daten in ein für das Data Warehouse geeignetes Format. Durch das Aufbewahren von Quelldaten können Sie sie erneut verarbeiten, ohne zum Quellsystem zurückzukehren. Für das analoge Bronze-, Silber- und Goldseehausmuster siehe Medaillenarchitektur.

  • Machen Sie Ihre Datenpipelines wiederverwendbar und idempotent. Entwerfen Sie Transformationsschritte so, dass sie bei erneuter Ausführung mit derselben Eingabe dasselbe Ergebnis liefern. Durch die Wiedergabe einer Pipeline können Sie einen Fehler in der Transformationslogik beheben und historische Daten neu verarbeiten, anstatt sie zu verwerfen.

Security

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

  • Sichere und zentrale Konfiguration. Speichern Sie Verbindungszeichenfolgen, Schlüssel und andere geheime Schlüssel in Key Vault anstelle von Notizbüchern, Pipelinedefinitionen oder Quellcodeverwaltungen. Referenzieren Sie sie in verknüpften Diensten in Data Factory und in Azure Databricks-Geheimnisbereichen, sodass jede Umgebung ihre eigenen Werte auflöst.

Operative Exzellenz

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie in der Checkliste zur Designüberprüfung für operationale Exzellenz.

  • Validieren Sie die Daten früh in Ihrer Pipeline. Wenden Sie Schema- und Qualitätsprüfungen im ersten Transformationsschritt an, und leiten Sie Datensätze weiter, die in das falsch formatierte Schema fehlschlagen. Bei der frühen Validierung werden fehlerhafte Datensätze aus nachgelagerten Ebenen entfernt und erhalten Sie einen Überblick darüber, was abgelehnt wurde und warum.

  • Stellen Sie sicher, dass datentransformationscode testbar ist. Gliedern Sie die Transformationslogik in Funktionen und Module aus, die außerhalb eines Notebooks ausgeführt werden, damit Sie sie in der Pull-Request-Validierungspipeline mit Unit-Tests abdecken können.

  • Verfügen Sie über eine CI/CD-Pipeline. Erstellen und freigeben Sie jede Umgebung aus der Quellcodeverwaltung und nicht von Hand. Die technologiespezifischen Mechaniken finden Sie unter CI/CD in Azure Data Factory und CI/CD auf Azure Databricks.

  • Überwachen sie Infrastruktur, Pipelines und Daten. Sammeln Sie Metriken und Protokolle von jeder Ebene, sodass ein Fehler als Warnung anstelle eines veralteten Berichts angezeigt wird. Weitere Informationen finden Sie unter Monitor Data Factory.

Implementieren dieses Szenarios

Die folgende Liste enthält die allgemeinen Schritte, die zum Einrichten dieser Lösung mit entsprechenden Build- und Releasepipelines erforderlich sind.

Einrichtung und Bereitstellung

  1. Anfängliches Setup: Installieren Sie alle erforderlichen Komponenten, erstellen Sie das Git-Repository, das die Infrastruktur, das Notizbuch und den Pipelinecode enthält, und legen Sie erforderliche Umgebungsvariablen fest.

  2. Azure-Ressourcen bereitstellen: Verwenden Sie eine Infrastructure-as-Code-Bereitstellung, z. B. Bicep oder Terraform, um die Azure-Ressourcen und Microsoft Entra-Dienstprinzipale für jede Umgebung bereitzustellen. Konfigurieren Sie separat die Azure Pipelines Definitionen, Variablengruppen und Dienstverbindungen, die die Infrastrukturbereitstellung aufrufen.

  3. Richten Sie die Git-Integration in der Entwicklungs-Data-Factory ein: Konfigurieren Sie die Git-Integration, sodass die Entwicklungs-Data-Factory Commits in Ihrem Repository speichert.

  4. Ausführen eines ersten Builds und Releases: Erstellen Sie ein Beispiel für eine Änderung in Data Factory, zum Beispiel das Aktivieren eines Zeitplantriggers, und beobachten Sie, wie die Änderung automatisch in allen Umgebungen bereitgestellt wird.

Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD)

Das folgende Diagramm veranschaulicht den CI/CD-Prozess und die Sequenz für die Build- und Releasepipelines.

Diagramm des Prozesses und der Reihenfolge für Build und Release.

Laden Sie eine Visio-Datei dieser Architektur herunter.

  1. Entwickler nehmen die Entwicklung in eigenen Sandbox-Umgebungen innerhalb der Ressourcengruppe „dev“ vor und führen einen Commit der Änderungen in die eigenen kurzlebigen Git-Branches aus. Beispiel: <developer_name>/<branch_name>.

  2. Wenn die Änderungen abgeschlossen sind, lösen die Entwickler einen Pull Request (PR) an den Mainbranch zur Überprüfung aus. Dadurch wird die PR-Validierungspipeline automatisch gestartet, die Komponententests durchführt, die Linting-Vorgänge ausführt und DACPAC-Builds der Anwendungspakete auf der Datenebene erstellt.

  3. Nach Abschluss der PR-Validierung löst der Commit zum Mainbranch eine Buildpipeline aus, die alle erforderlichen Buildartefakte veröffentlicht.

  4. Der Abschluss einer erfolgreichen Build-Pipeline löst die erste Phase der Release-Pipeline aus. Dadurch werden die Buildartefakte für die Veröffentlichung in der Entwicklungsumgebung mit Ausnahme von Data Factory bereitgestellt.

    Die Entwickler nehmen eine manuelle Veröffentlichung in der Data Factory für die Entwicklung aus dem Kollaborationsbranch (Mainbranch) vor. Die manuelle Veröffentlichung aktualisiert die Azure Resource Manager-Vorlagen im Branch adf_publish.

  5. Der erfolgreiche Abschluss der ersten Stufe löst einen manuellen Genehmigungsschritt aus.

    Nach der Genehmigung fährt die Release-Pipeline mit der zweiten Phase fort und stellt Änderungen für die Staging-Umgebung bereit.

  6. Führen Sie Integrationstests aus, um Änderungen in der Staging-Umgebung zu testen.

  7. Nach erfolgreichem Abschluss der zweiten Phase löst die Pipeline einen zweiten manuellen Genehmigungsschritt aus.

    Nach der Genehmigung fährt die Release-Pipeline mit der dritten Phase fort und implementiert Änderungen in der Produktionsumgebung.

Weitere Informationen zur Implementierung dieser Phasen finden Sie unter CI/CD in Azure Data Factory.

Testing

Die Lösung bietet Unterstützung sowohl für Komponententests als auch Integrationstests. Unit-Tests decken die Python-Transformationsmodule ab, und Integrationstests lösen eine Data-Factory-Pipeline aus und überprüfen deren Ausgabe im Rahmen der Bereitstellung in die Staging-Umgebung. Weitere Informationen finden Sie unter Komponententests für Notizbücher.

Observierbarkeit und Systemüberwachung

Die Lösung unterstützt Beobachtbarkeit und Überwachung für Databricks und Data Factory. Verwenden Sie für Databricks die integrierte Auditprotokollierung der Plattform (die Tabelle system.access.audit) und die Überwachung von Auftragsausführungen, statt standardmäßig alle Diagnosedaten zu exportieren. Wenn Sie Databricks-Diagnoseprotokolle an einen Log Analytics Arbeitsbereich für zentralisierte Warnungen übermitteln müssen, erfordert diese Funktion den Premium-Plan, gilt für Protokolle anstelle von Metriken und erfordert eine sorgfältige Zugriffssteuerung, da Überwachungsprotokolle vertrauliche Details zu Ihrer Bereitstellung enthalten können. Leiten Sie Diagnoseprotokolle und Metriken für Data Factory an einen Log Analytics Arbeitsbereich weiter und richten Sie Warnungen zu Pipelinefehlern und Auftragslatenz ein. Weitere Informationen finden Sie unter Monitor Data Factory.

Nächste Schritte

Die folgenden Ressourcen helfen Ihnen bei der Implementierung der in diesem Artikel beschriebenen DataOps-Methoden.

Kontinuierliche Integration und Auslieferung

Observability/monitoring

Azure Databricks

Data Factory

Azure Synapse Analytics

Azure Storage

Resilienz und Notfallwiederherstellung

Azure Databricks

Data Factory

Azure Synapse Analytics

Azure Storage

Detaillierte Übersicht

Eine detaillierte Übersicht über die Lösung und die wichtigsten Konzepte finden Sie in der folgenden Videoaufzeichnung: DataDevOps for the Modern Data Warehouse on Microsoft Azure