Diese Referenzarchitektur veranschaulicht die Erstellung einer skalierbarer Lösung für die Batchbewertung eines Apache Spark-Klassifizierungsmodells nach einem Zeitplan mithilfe von Azure Databricks. Azure Databricks ist eine Apache Spark-basierte Analyseplattform, die für Azure optimiert ist. Azure Databricks bietet drei Umgebungen für die Entwicklung datenintensiver Anwendungen: Databricks SQL, Databricks Data Science & Engineering und Databricks Machine Learning. Databricks Machine Learning ist eine integrierte End-to-End-Machine Learning-Umgebung mit verwalteten Diensten für Experimentnachverfolgung, Modelltraining, Featureentwicklung und -verwaltung sowie für die Bereitstellung von Features und Modellen. Diese Referenzarchitektur kann als Vorlage verwendet und für andere Szenarien generalisiert werden. Eine Referenzimplementierung für diese Architektur ist auf GitHub verfügbar.
Apache® und Apache Spark® sind entweder eingetragene Marken oder Marken der Apache Software Foundation in den USA und/oder anderen Ländern. Die Verwendung dieser Markierungen impliziert kein Endorsement durch die Apache Software Foundation.
Architektur
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
Die Architektur definiert einen vollständig in Azure Databricks enthaltenen Datenfluss basierend auf einem Satz sequenziell ausgeführter Notebooks. Die Architektur umfasst die folgenden Komponenten:
Datendateien . Bei der Referenzimplementierung wird ein simuliertes Dataset verwendet, das in fünf statischen Datendateien enthalten ist.
Erfassung . Das Datenerfassungsnotebook lädt die Eingabedatendateien in eine Sammlung von Databricks-Datasets herunter. In einem realen Szenario würden Daten von IoT-Geräten in einen für Databricks zugänglichen Speicher wie Azure SQL oder Azure Blob Storage streamen. Databricks unterstützt mehrere Datenquellen.
Trainingspipeline: Dieses Notebook führt das Featureentwicklungsnotebook aus, um ein Analysedataset aus den erfassten Daten zu erstellen. Dann führt es ein Modellerstellungsnotebook aus, das das Machine Learning-Modell mithilfe der skalierbaren Machine Learning-Bibliothek Apache Spark MLlib trainiert.
Bewertungspipeline: Dieses Notebook führt das Featureentwicklungsnotebook aus, um ein Bewertungsdataset aus den erfassten Daten zu erstellen, und dann führt es das Bewertungsnotebook aus. Das Bewertungsnotebook verwendet das trainierte Spark MLlib-Modell, um Vorhersagen für die Beobachtungen im Bewertungsdataset zu generieren. Die Vorhersagen werden im Ergebnisspeicher gespeichert. Dabei handelt es sich um ein neues Dataset für den Databricks-Datenspeicher.
Scheduler: Ein geplanter Databricks-Auftrag verarbeitet die Batchbewertung mit dem Spark-Modell. Der Auftrag führt das Bewertungspipelinenotebook aus, wobei variable Argumente durch Notebookparameter übergeben werden, um die Details für das Erstellen des Bewertungsdatasets und den Speicherort für das Ergebnisdataset anzugeben.
Details zur Lösung
Das Szenario ist als Pipelineflow konzipiert. Jedes Notebook ist für die Ausführung in einer Batcheinstellung für jeden der folgenden Vorgänge optimiert: Erfassung, Featureentwicklung, Modellerstellung und Modellbewertung. Das Featureentwicklungsnotebook ist so konzipiert, dass es ein allgemeines Dataset für alle Trainings-, Kalibrierungs-, Test- oder Bewertungsvorgänge generiert. In diesem Szenario verwenden wir für diese Vorgänge eine temporale Aufteilungsstrategie, sodass die Notebookparameter zum Festlegen der Datumsbereichsfilterung verwendet werden.
Weil in dem Szenario eine Batchpipeline erstellt wird, stellen wir eine Reihe optionaler Überprüfungsnotebooks bereit, um die Ausgabe der Pipelinenotebooks zu untersuchen. Diese Notebooks befinden sich im Ordner „notebooks“ des GitHub-Repositorys:
1a_raw-data_exploring.ipynb2a_feature_exploration.ipynb2b_model_testing.ipynb3b_model_scoring_evaluation.ipynb
Mögliche Anwendungsfälle
Ein Unternehmen in einer ressourcenlastigen Branche möchte die mit unerwarteten mechanischen Fehlern verbundenen Kosten und Ausfallzeiten minimieren. Mithilfe der von den Maschinen gesammelten IoT-Daten kann das Unternehmen ein Predictive Maintenance-Modell (Modell für die vorbeugende Wartung) erstellen. Dieses Modell ermöglicht es dem Unternehmen, Komponenten proaktiv zu warten und zu reparieren, bevor sie ausfallen. Durch Maximieren der Verwendung der mechanischen Komponenten können Kosten kontrolliert und Ausfallzeiten reduziert werden.
Ein Predictive Maintenance-Modell sammelt Daten von den Maschinen und speichert historische Beispiele von Komponentenausfällen. Das Modell kann dann verwendet werden, um den aktuellen Zustand der Komponenten zu überwachen und vorherzusagen, ob eine bestimmte Komponente bald ausfällt. Allgemeine Anwendungsfälle und Modellierungsansätze finden Sie im Azure KI-Leitfaden für Predictive Maintenance-Lösungen.
Diese Referenzarchitektur ist für Workloads konzipiert, die durch das Vorhandensein neuer Daten der Komponentenmaschinen ausgelöst werden. Die Verarbeitung umfasst die folgenden Schritte:
Erfassen Sie die Daten aus dem externen Datenspeicher in einem Azure Databricks-Datenspeicher.
Trainieren Sie ein Machine Learning-Modell, indem Sie die Daten in ein Trainingsdataset transformieren, und erstellen Sie dann ein Spark MLlib-Modell. MLlib besteht aus den am häufigsten verwendeten Machine Learning-Algorithmen und -Dienstprogrammen, die für die Nutzung von Spark-Datenskalierbarkeitsfunktionen optimiert sind.
Wenden Sie das trainierte Modell an, um Komponentenausfälle vorherzusagen (zu klassifizieren), indem Sie die Daten in ein Bewertungsdataset transformieren. Bewerten Sie die Daten mit dem Spark MLLib-Modell.
Speichern Sie die Ergebnisse im Databricks-Datenspeicher zur Nachbearbeitung.
Auf GitHub werden Notebooks für die Ausführung dieser Aufgaben bereitgestellt.
Empfehlungen
Databricks ist so eingerichtet, dass Sie Ihre trainierten Modelle laden und bereitstellen können, um Vorhersagen mit neuen Daten zu treffen. Aber Databricks bietet noch weitere Vorteile:
- Unterstützung für einmaliges Anmelden mit Microsoft Entra-Anmeldeinformationen.
- Auftragsplaner zum Ausführen von Aufträgen für Produktionspipelines
- Vollständig interaktives Notebook mit Zusammenarbeitsfunktionen, Dashboards und REST-APIs
- Unbegrenzte Cluster, die auf eine beliebige Größe skaliert werden können
- Erweiterte Sicherheit, rollenbasierte Zugriffssteuerungen und Überwachungsprotokolle
Verwenden Sie für die Interaktion mit dem Azure Databricks-Dienst die Benutzeroberfläche des Databricks-Arbeitsbereichs in einem Webbrowser oder die Databricks-Befehlszeilenschnittstelle (Command-Line Interface, CLI). Auf die Databricks-CLI können Sie über jede Plattform zugreifen, die Python 2.7.9 bis 3.6 unterstützt.
Bei der Referenzimplementierung werden Notebooks verwendet, um Aufgaben nacheinander auszuführen. Jedes Notebook speichert Zwischendatenartefakte (Trainings-, Test-, Bewertungs- oder Ergebnisdatasets) im gleichen Datenspeicher wie die Eingabedaten. Ziel ist es, Ihnen die Verwendung nach Bedarf in Ihrem bestimmten Anwendungsfall zu erleichtern. In der Praxis würden Sie Ihre Datenquelle mit Ihrer Azure Databricks-Instanz verbinden, damit die Notebooks direkt in Ihren Speicher lesen und schreiben können.
Überwachen Sie die Auftragsausführung je nach Bedarf über die Databricks-Benutzeroberfläche, den Datenspeicher oder die Databricks-CLI. Überwachen Sie den Cluster mithilfe des Ereignisprotokolls und anderer Metriken, die Databricks bereitstellt.
Ü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.
Leistung
Für einen Azure Databricks-Cluster ist die automatische Skalierung standardmäßig aktiviert, sodass Databricks während der Laufzeit Worker dynamisch neu zuordnen kann, um die Eigenschaften Ihres Auftrags zu berücksichtigen. Bestimmte Teile der Pipeline sind möglicherweise anspruchsvoller und rechenintensiver als andere. Databricks fügt während dieser Phasen Ihres Auftrags zusätzliche Worker hinzu (und entfernt sie wieder, wenn sie nicht mehr benötigt werden). Durch die automatische Skalierung kann eine hohe Clusterauslastung einfacher erreicht werden, weil Sie den Cluster nicht gemäß einer Workload bereitstellen müssen.
Entwickeln Sie komplexere geplante Pipelines mithilfe von Azure Data Factory und Azure Databricks.
Storage
Bei dieser Referenzimplementierung werden die Daten der Einfachheit halber direkt im Databricks-Speicher gespeichert. In einer Produktionsumgebung können die Daten jedoch in einem Clouddatenspeicher wie Azure Blob Storage gespeichert werden. Databricks unterstützt auch Azure Data Lake Store, Azure Synapse Analytics, Azure Cosmos DB, Apache Kafka und Apache Hadoop.
Kostenoptimierung
Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.
Im Allgemeinen sollten Sie den Azure-Preisrechner verwenden, um Ihre Kosten zu ermitteln. Weitere Überlegungen finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.
Azure Databricks ist ein Spark-Premiumangebot, das mit Kosten verbunden ist. Darüber hinaus gibt es Tarife für Databricks Standard und Databricks Premium.
In diesem Szenario ist der Tarif „Standard“ ausreichend. Wenn Ihre spezielle Anwendung jedoch eine automatische Skalierung von Clustern zur Bewältigung größerer Workloads oder für interaktive Databricks-Dashboards erfordert, könnten sich die Kosten durch die Stufe „Premium“ weiter erhöhen.
Die Lösungsnotebooks können auf jeder Spark-basierten Plattform mit minimalen Änderungen zum Entfernen der Databricks-spezifischen Pakete ausgeführt werden.
Bereitstellen dieses Szenarios
Führen Sie zum Bereitstellen dieser Referenzarchitektur die im GitHub-Repository beschriebenen Schritte aus, um eine skalierbare Lösung für die Batchbewertung von Spark-Modellen in Azure Databricks zu erstellen.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- John Ehrlinger | Senior Applied Scientist
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.