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.
Architektur
Das folgende Diagramm zeigt die allgemeine Architektur der Lösung.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Datenfluss
Azure Data Factory orchestriert und Azure Data Lake Storage Gen2 speichert die Daten:
Die Webdienst-API für Stadtparkplätze von Contoso steht zum Übertragen von Daten von den einzelnen Parkplätzen zur Verfügung.
Es ist ein Data Factory-Kopierauftrag vorhanden, der die Daten in das Zielschema (Landing) überträgt.
Im nächsten Schritt werden die Daten von Azure Databricks bereinigt und standardisiert. Dabei werden die Rohdaten übernommen und so aufbereitet, dass sie von Data Scientists verwendet werden können.
Falls bei der Validierung ungültige Daten entdeckt werden, werden diese in das Schema für falsch formatierte Daten (Malformed) ausgesondert.
Wichtig
Es wurde die Frage gestellt, warum die Daten nicht vor dem Speichern in Data Lake Storage validiert werden. Der Grund dafür ist, dass sich durch die Validierung ein Fehler ergeben könnte, der das Dataset beschädigt. Wenn sich in diesem Schritt ein Fehler ergibt, kann dieser behoben und die Pipeline erneut wiedergegeben werden. Werden die ungültigen Daten vor dem Hinzufügen zu Data Lake Storage ausgesondert, sind die beschädigten Daten nutzlos, da die Pipeline nicht erneut wiedergegeben werden kann.
Es findet ein zweiter Transformationsschritt in Azure Databricks statt, in dem die Daten in ein Format konvertiert werden, das im Data Warehouse gespeichert werden kann.
Zum Schluss werden die Daten von der Pipeline auf zwei verschiedene Arten bereitgestellt:
Databricks stellt die Daten dem Data Scientist zur Verfügung, damit er Modelle trainieren kann.
PolyBase verschiebt die Daten aus dem Data Lake in Azure Synapse Analytics, und Power BI greift auf die Daten zu und stellt Sie für den Geschäftsbenutzer dar.
Komponenten
Die Lösung verwendet die folgenden Komponenten:
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.
Infrastructure-as-Code: Bereitstellen neuer Entwicklungs- (dev) und Stagingumgebungen (stg) auf automatisierte Weise.
Bereitstellen von Anwendungsänderungen in verschiedenen Umgebungen auf automatisierte Weise:
Implementieren von CI/CD-Pipelines (Continuous Integration und Continuous Delivery).
Verwenden von 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.
Es ist auch in Azure Synapse Analytics, Azure Analysis Services und Power BI enthalten.
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ützen der Überwachung.
Zentralisierte Konfiguration in einem sicheren Speicher wie Azure Key Vault.
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 besitzt auch die APIs, die eine Verbindung mit den Sensoren herstellen und Daten daraus erhalten. 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. Mithilfe von Datenvisualisierungstools wie Power BI können die Stadtplaner von Contoso dann die Berichtsdaten zur Nutzung von Parkplätzen untersuchen und bewerten, um festzustellen, ob mehr Parkplätze oder zugehörige Ressourcen benötigt werden.
Überlegungen
Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. 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:
Hinweis
Jede Überlegung in diesem Abschnitt verweist auf den zugehörigen Abschnitt "Key Learnings " in den Dokumenten für das Beispiel für die Parksensorlösung auf GitHub.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.
Optimaler Betrieb
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 unter Erstellen einer Checkliste zur Überprüfung des optimalen Betriebs.
Bereitstellen dieses Szenarios
Die folgende Liste enthält die allgemeinen Schritte, die zum Einrichten der Lösung für Parksensoren mit entsprechenden Build- und Releasepipelines erforderlich sind. Ausführliche Einrichtungsschritte und Voraussetzungen finden Sie in diesem Repository für Azure-Beispiele.
Einrichtung und Bereitstellung
Erste Einrichtung: Installieren Sie alle erforderlichen Komponenten, importieren Sie das GitHub-Repository mit Azure-Beispielen in Ihr eigenes Repository, und legen Sie erforderliche Umgebungsvariablen fest.
Bereitstellen von Azure-Ressourcen: Die Lösung enthält ein Skript für die automatisierte Bereitstellung. Hiermit werden alle erforderlichen Azure-Ressourcen und Microsoft Entra-Dienstprinzipale pro Umgebung bereitgestellt. Das Skript stellt außerdem Azure Pipelines, Variablengruppen und Dienstverbindungen bereit.
Einrichten der Git-Integration in der Data Factory für die Entwicklung: Konfigurieren Sie die Git-Integration für das Arbeiten mit dem importierten GitHub-Repository.
Ausführen eines ersten Build und Release: Erstellen Sie eine Beispieländerung in Data Factory, z. B. das Aktivieren eines Zeitplantriggers, und beobachten Sie, wie die Änderung automatisch in allen Umgebungen bereitgestellt wird.
Bereitgestellte Ressourcen
Wenn die Bereitstellung erfolgreich ist, sollten in Azure drei Ressourcengruppen vorhanden sein, die drei Umgebungen darstellen: „dev“, „stg“ und „prod“. Es sollten auch End-to-End-Build- und Releasepipelines in Azure DevOps vorhanden sein, die Änderungen in diesen drei Umgebungen automatisch bereitstellen können.
Eine ausführliche Liste aller Ressourcen finden Sie im Abschnitt Bereitgestellte Ressourcen in der Infodatei zur DataOps – Parksensor-Demo.
Continuous Integration und Continuous Delivery (CI/CD)
Das folgende Diagramm zeigt den CI/CD-Prozess und die Reihenfolge für die Build- und Releasepipelines.
Laden Sie eine Visio-Datei dieser Architektur herunter.
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>.Wenn die Änderungen abgeschlossen sind, lösen die Entwickler einen Pull Request (PR) an den Mainbranch zur Überprüfung aus. Dadurch wird automatisch die PR-Validierungspipeline gestartet, die die Komponententests, Linting- und Datenebenen-Anwendungspaketbuilds (DACPAC) ausführt.
Nach Abschluss der PR-Validierung löst der Commit zum Mainbranch eine Buildpipeline aus, die alle erforderlichen Buildartefakte veröffentlicht.
Der Abschluss einer erfolgreichen Buildpipeline löst die erste Phase der Releasepipeline 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. Durch die manuelle Veröffentlichung werden die ARM-Vorlagen (Azure Resource Manager) im
adf_publish-Branch aktualisiert.Der erfolgreiche Abschluss der ersten Phase löst ein manuelles Genehmigungsgate aus.
Nach der Genehmigung fährt die Releasepipeline mit der zweiten Phase fort und stellt Änderungen für die Stagingumgebung bereit.
Führen Sie Integrationstests aus, um Änderungen in der Stagingumgebung zu testen.
Nach erfolgreichem Abschluss der zweiten Phase löst die Pipeline ein zweites manuelles Genehmigungsgate aus.
Nach der Genehmigung fährt die Releasepipeline mit der dritten Phase fort und stellt Änderungen für die Produktionsumgebung bereit.
Weitere Informationen finden Sie im Abschnitt Build- und Releasepipeline in der Infodatei.
Testen
Die Lösung bietet Unterstützung sowohl für Komponententests als auch Integrationstests. Dabei werden pytest-Data Factory und das Nutter-Testframework verwendet. Weitere Informationen finden Sie im Abschnitt Tests in der Infodatei.
Einblick und Überwachung
Die Lösung unterstützt Einblick und Überwachung für Databricks und Data Factory. Weitere Informationen finden Sie im Abschnitt Einblick/Überwachung in der Infodatei.
Nächste Schritte
Wenn Sie die Lösung bereitstellen möchten, folgen Sie den Schritten im Abschnitt Verwenden des Beispiels in der Infodatei zur DataOps – Parksensor-Demo.
Lösungscodebeispiele auf GitHub
Einblick/Überwachung
Azure Databricks
- Überwachen von Azure Databricks mit Azure Monitor
- Überwachen von Azure Databricks-Aufträgen mit Application Insights
Data Factory
- Überwachen von Azure Data Factory mit Azure Monitor
- Erstellen von Warnungen zum proaktiven Überwachen der Data Factory-Pipelines
Azure Synapse Analytics
- Überwachen der Ressourcennutzung und Abfrageaktivität in Azure Synapse Analytics
- Überwachen der Workload Ihres SQL-Pools von Azure Synapse Analytics mit DMVs
Azure Storage
Resilienz und Notfallwiederherstellung
Azure Databricks
Data Factory
Azure Synapse Analytics
Azure Storage
- Notfallwiederherstellung und Speicherkontofailover
- Bewährte Methoden zur Verwendung von Azure Data Lake Storage Gen2: Hochverfügbarkeit und Notfallwiederherstellung
- Azure Storage-Redundanz
Ausführliche exemplarische Vorgehensweise
Eine ausführliche exemplarische Vorgehensweise für die Lösung sowie die wichtigsten Konzepte enthält die folgende Videoaufzeichnung: DataDevOps für das moderne Data Warehouse in Microsoft Azure