Bearbeiten

Orchestrieren von MLOps mithilfe von Azure Databricks

Azure Databricks

Lösungsmöglichkeiten

Dieser Artikel ist ein Lösungsvorschlag. Wenn Sie möchten, dass wir diesen Artikel um weitere Informationen ergänzen, z. B. potenzielle Anwendungsfälle, alternative Dienste, Überlegungen zur Implementierung oder Preisempfehlungen, lassen Sie es uns über Feedback auf GitHub wissen.

In diesem Artikel finden Sie eine Architektur für MLOps (Machine Learning Operations) und einen von Azure Databricks genutzten Prozess. Dieser Prozess bestimmt eine standardisierte Möglichkeit, Machine Learning-Modelle und -Pipelines von der Entwicklung in die Produktion zu überführen, wobei es Optionen für automatisierte und manuelle Prozesse gibt.

Aufbau

Diagram that shows a solution for using Azure Databricks for MLOps.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Diese Lösung bietet einen robusten MLOps-Prozess, der Azure Databricks verwendet. Alle Elemente der Architektur sind miteinander kombinierbar, sodass Sie bei Bedarf weitere Azure-Dienste und Dienste von Drittanbietern in die Architektur integrieren können. Diese Architektur und Beschreibung wurden dem E-Book The Big Book of MLOps entnommen. In diesem E-Book wird die hier beschriebene Architektur detaillierter erkundet.

  • Quellcodeverwaltung: Im Coderepository dieses Projekts sind die Notebooks, Module und Pipelines organisiert. Data Scientists erstellen Branches für die Entwicklung, um Aktualisierungen und neue Modelle zu testen. Code wird in Notebooks oder IDEs mit Unterstützung durch Git entwickelt, mit Databricks Repos-Integration zur Synchronisierung mit Ihren Azure Databricks Arbeitsbereichen. In der Quellcodeverwaltung werden Machine Learning-Pipelines von der Entwicklung über das Staging (für Tests) bis zur Produktion (für die Bereitstellung) höher gestuft.

  • Lakehouse – Produktionsdaten: Data Scientists arbeiten in der Entwicklungsumgebung, in der sie nur Lesezugriff auf Produktionsdaten haben. (Alternativ können Daten gespiegelt oder bearbeitet werden.) Sie haben außerdem Lese-/Schreibzugriff auf eine Speicherumgebung für Entwicklung und Experimente. Wir empfehlen eine Lakehouse-Architektur für Daten, in der Daten im Delta Lake-Format gespeichert in Azure Data Lake Storage werden. Zugriffssteuerungen werden mit Passthrough von Microsoft Entra-Anmeldeinformationen oder Tabellenzugriffssteuerungen definiert.

Entwicklung

In der Entwicklungsumgebung entwickeln Data Scientists und Entwickler Machine Learning-Pipelines.

  1. Explorative Datenanalyse (EDA): Data Scientist erkunden Daten in einem interaktiven, iterativen Prozess. Diese Ad-hoc-Aufgabe wird möglicherweise nicht für Staging oder Produktion bereitgestellt. Tools dafür sind beispielsweise Databricks SQL, dbutils.data.summarize und AutoML.

  2. Modelltrainings-und andere Machine Learning-Pipelines: Machine Learning-Pipelines werden als modularer Code in Notebooks und/oder IDEs entwickelt. Die Modelltrainingspipeline liest zum Beispiel Daten aus dem Feature Store und anderen Lakehouse-Tabellen. Bei Training und Optimierung werden Modellparameter und Metriken auf dem MLflow-Nachverfolgungsserver protokolliert. Die Feature Store-API protokolliert das endgültige Modell. Über diese Protokolle werden das Modell, seine Eingaben und der Trainingscode miteinander verknüpft.

  3. Committen von Code: Um den Maschine Learning-Workflow in Richtung Produktion zu entwickeln, übergibt der Data Scientist den Code für die Featurisierungs-, Trainings- und andere Pipelines an die Quellcodeverwaltung.

Staging

In der Stagingumgebung testet die Continuous Integration-Infrastruktur Änderungen an Pipelines für maschinelles Lernen in einer Umgebung, die die Produktionsumgebung nachbildet.

  1. Merge Request:Wenn ein Merge (oder Pull) Request für den Stagingbranch (Main) des Projekts in der Quellcodeverwaltung erfolgt, werden Tests von einem Tool für Continuous Integration und Continuous Delivery (CI/CD) wie Azure DevOps durchgeführt.

  2. Komponenten- und CI-Tests: Komponententests erfolgen in der CI-Infrastruktur. Für Integrationstests werden lückenlose Workflows in Azure Databricks ausgeführt. Wenn Tests bestanden werden, werden die Codeänderungen gemergt.

  3. Erstellen eines Releasebranches: Wenn Machine Learning-Entwickler bereit sind, die aktualisierten Pipelines für maschinelles Lernen in der Produktion bereitzustellen, können sie ein neues Release erstellen. Eine Bereitstellungspipeline im CI/CD-Tool stellt die aktualisierten Pipelines als neue Workflows erneut bereit.

Bereitstellung

Maschine Learning-Entwickler verwalten die Produktionsumgebung, in der Pipelines für maschinelles Lernen direkt für Endanwendungen bereitgestellte werden. Die zentralen Pipelines in der Produktion dienen zum Aktualisieren von Featuretabellen, Trainieren und Bereitstellen neuer Modelle, Ausführen von des Rückschlusses oder Bereitstellen und Überwachen der Modellleistung.

  1. Aktualisieren von Featuretabellen: Diese Pipeline liest Daten, berechnet Features und schreibt Daten in Feature Store-Tabellen. Sie wird kontinuierlich im Streamingmodus ausgeführt, entweder nach einem Zeitplan oder nach Auslösung.

  2. Modelltraining: In der Produktion wird die Pipeline für Modelltraining oder erneutes Training entweder ausgelöst oder zeitlich so geplant, dass ein aktuelles Modell anhand der neuesten Produktionsdaten trainiert wird. Modelle werden in der MLflow-Modellregistrierung registriert.

  3. Continuous Deployment: Bei der Registrierung neuer Modellversionen wird die CD-Pipeline ausgelöst, die Tests durchführt, um sicherzustellen, dass das Modell in der Produktion gut funktioniert. Sobald das Modell Tests besteht, wird sein Status in der Registrierung anhand der Übergänge der Modellphasen nachverfolgt. Registrierungswebhooks können für die Automatisierung verwendet werden. Tests können Complianceprüfungen, A/B-Tests zum Vergleichen des neuen Modells mit dem aktuellen Produktionsmodell und Infrastrukturtests umfassen. Testergebnisse und Metriken werden in Lakehouse-Tabellen aufgezeichnet. Sie können optional manuelle Genehmigungen verlangen, ehe Modelle in die Produktion überführt werden.

  4. Modellbereitstellung: Wenn ein Modell in die Produktion übergeht, wird es zur Bewertung oder Bereitstellung eingesetzt. Es folgen die gängigsten Bereitstellungsmodi:

    • Batch- oder Streamingbewertung: Für Latenz in Form von Minuten oder länger sind die Batch- oder Streamingbewertung die wirtschaftlichsten Optionen. Die Bewertungspipeline liest die neuesten Daten aus dem Feature Store, lädt die neueste Produktionsmodellversion aus der Modellregistrierung und führt in einem Databricks-Auftrag den Rückschluss aus. Die Pipeline kann Vorhersagen in Lakehouse-Tabellen, einer JDBC-Verbindung (Java Database Connectivity), Flatfiles, Nachrichtenwarteschlangen oder anderen nachgelagerten Systemen veröffentlichen.
    • Onlinebereitstellung (REST-APIs): Für Anwendungsfälle mit geringer Latenz ist im Allgemeinen eine Onlinebereitstellung erforderlich. MLflow kann Modelle in MLflow-Modellbereitstellung in Azure Databricks, Bereitstellungssystemen von Cloudanbietern und anderen Systemen bereitstellen. In allen Fällen wird das Bereitstellungssystem mit dem neuesten Produktionsmodell in der Modellregistrierung initialisiert. Für jede Anforderung werden Features aus einem Online-Feature Store abgerufen und Vorhersagen getroffen.

  5. Überwachung: Laufende oder regelmäßige Workflows überwachen Eingabedaten und Modellvorhersagen auf Drift, Leistung und andere Metriken. Deltalivetabellen können die Automatisierung von Überwachungspipelines vereinfachen, die Metriken in Lakehouse-Tabellen speichern. Databricks SQL, Power BI und andere Tools können Daten dieser Tabellen lesen, um Dashboards und Warnungen zu erstellen.

  6. Erneutes Training: Diese Architektur unterstützt sowohl manuelles als auch automatisches erneutes Training. Geplante Aufträge für erneutes Training sind die einfachste Möglichkeit, Modelle aktuell zu halten.

Komponenten

  • Data Lakehouse. Eine Lakehouse-Architektur vereint die besten Elemente von Data Lakes und Data Warehouses, indem die für Data Warehouses typische Datenverwaltung und Leistung mit den kostengünstigen, flexiblen Objektspeichern von Data Lakes kombiniert wird.
    • Delta Lake ist die empfohlene Wahl für ein Open-Source-Datenformat für ein Lakehouse. Azure Databricks speichert Daten in Data Lake Storage und bietet ein leistungsstarkes Abfragemodul.
  • MLflow ist ein Open-Source-Projekt für die lückenlose Verwaltung des Machine Learning-Lebenszyklus. Es folgen die wichtigsten Komponenten:
    • Die Nachverfolgung ermöglicht das Nachverfolgen von Experimenten zum Aufzeichnen und Vergleichen von Parametern, Metriken und Modellartefakten.
    • Mit dem MLflow-Modell können Sie Modelle einer beliebigen Machine Learning-Bibliothek speichern und für verschiedene Modellbereitstellungs- und Rückschlussplattformen bereitstellen.
    • Die Modellregistrierung bietet einen zentralen Modellspeicher für die Verwaltung der Phasenübergänge im Modelllebenszyklus von der Entwicklung bis zur Produktion.
    • Die Modellbereitstellung ermöglicht das Hosten von MLflow-Modellen als REST-Endpunkte.
  • Azure Databricks. Azure Databricks bietet einen vollständig verwaltete MLflow-Dienst mit Features für Unternehmenssicherheit, Hochverfügbarkeit und Integrationen mit anderen Features von Azure Databricks-Arbeitsbereichen.
    • Databricks Runtime für Machine Learning automatisiert die Erstellung eines Clusters, der für maschinelles Lernen optimiert ist. Dabei werden beliebte Machine Learning-Bibliotheken wie TensorFlow, PyTorch und XGBoost zusätzlich zu den Azure Databricks für Machine Learning-Tools wie AutoML und Feature Store-Clients vorinstalliert.
    • Der Feature Store ist ein zentrales Repository mit Features. Er ermöglicht die Freigabe und Ermittlung von Features und hilft, Datenschiefe zwischen Modelltraining und Rückschluss zu vermeiden.
    • Databricks SQL. Databricks SQL bietet eine einfache Umgebung für SQL-Abfragen von Lakehouse-Daten sowie für Visualisierungen, Dashboards und Warnungen.
    • Databricks Repos bietet die Integration Ihres Git-Anbieters in den Azure Databricks-Arbeitsbereich, was die Zusammenarbeit bei der Entwicklung von Notebooks oder Code und die IDE-Integration vereinfacht.
    • Workflows und Aufträge bieten eine Möglichkeit, nicht interaktiven Code in einem Azure Databricks-Cluster auszuführen. Beim maschinellen Lernen ermöglichen Aufträge die Automatisierung von Datenaufbereitung, Featurisierung, Training, Rückschluss und Überwachung.

Alternativen

Sie können diese Lösung an Ihre Azure-Infrastruktur anpassen. Es folgen gängige Anpassungen:

  • Mehrere Entwicklungsarbeitsbereiche, die sich einen gemeinsamen Produktionsarbeitsbereich teilen.
  • Austausch einer oder mehrerer Architekturkomponenten in Ihrer vorhandenen Infrastruktur. Sie können Databricks-Aufträge beispielsweise mit Azure Data Factory orchestrieren.
  • Integration in Ihr vorhandenes CI/CD-Tool über Git und Azure Databricks-REST-APIs.

Szenariodetails

MLOps trägt zur Verringerung des Fehlerrisikos bei maschinellem Lernen und KI-Systemen und Verbesserung der Effizienz von Zusammenarbeit und Tools bei. Eine Einführung in MLOps und Übersicht über diese Architektur finden Sie unter Architecting MLOps on the Lakehouse.

Diese Architektur ermöglicht Folgendes:

  • Verbinden Sie Projektbeteiligte mit Machine Learning- und Data Science-Teams. Diese Architektur ermöglicht Data Scientists, Notebooks und IDEs für die Entwicklung zu verwenden. Sie ermöglicht Projektbeteiligten das Anzeigen aller Metriken und Dashboards in Databricks SQL, und zwar innerhalb derselben Lakehouse-Architektur.
  • Gestalten Sie Ihre Infrastruktur für maschinelles Lernen datenorientiert. In dieser Architektur werden Daten für maschinelles Lernen (aus Feature Engineering, Training, Rückschluss und Überwachung) genauso wie andere Daten behandelt. Dabei werden Tools für Produktionspipelines, die Erstellung von Dashboards und andere allgemeine Datenverarbeitungsprozesse für die Datenverarbeitung für maschinelles Lernen wiederverwendet.
  • Implementieren Sie MLOps in Module und Pipelines. Wie bei jeder Softwareanwendung ermöglichen die modularen Pipelines und der Code in dieser Architektur das Testen der einzelnen Komponenten und Senken der Kosten für künftiges Refactoring.
  • Automatisieren Sie Ihre MLOps-Prozesse nach Bedarf. In dieser Architektur können Sie Schritte automatisieren, um die Produktivität zu steigern und das Risiko menschlicher Fehler zu verringern. Aber nicht jeder Schritt muss automatisiert werden. Azure Databricks lässt neben den APIs zur Automatisierung auch Benutzeroberflächen- und manuelle Prozesse zu.

Mögliche Anwendungsfälle

Diese Architektur eignet sich für alle Arten von maschinellem Lernen, Deep Learning und erweiterten Analysen. Es folgen allgemeine Machine Learning- und KI-Techniken, die in dieser Architektur zum Einsatz kommen:

  • Klassisches maschinelles Lernen wie lineare Modelle, baumbasierte Modelle und Boosting.
  • Modernes Deep Learning wie TensorFlow und PyTorch.
  • Benutzerdefinierte Analysen, z. B. Statistiken, bayessche Methoden und Graphenanalysen.

Die Architektur unterstützt sowohl kleine Datenmengen (Einzelcomputer) als auch große Daten (verteiltes Computing und GPU-beschleunigt). In jeder Phase der Architektur können Sie Computeressourcen und Bibliotheken wählen, die Sie an Ihre Daten und Problemdimensionen anpassen können.

Die Architektur eignet sich für alle Branchen und geschäftlichen Anwendungsfälle. Zu Azure Databricks-Kunden, die diese und ähnliche Architekturen nutzen, zählen kleine und große Unternehmen in Branchen wie den folgenden:

  • Konsumgüter und Dienstleistungen für den Einzelhandel
  • Finanzdienstleistungen
  • Gesundheitswesen und Biowissenschaften
  • IT

Beispiele finden Sie auf der Databricks-Website.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte