Freigeben über


Bewährte Methoden für Data Science-Projekte mit Analysen auf Cloudebene in Azure

Wir empfehlen diese bewährten Methoden, um Data Science-Projekte mithilfe von Analysen auf Cloudebene in Microsoft Azure zu verwenden.

Entwickeln einer Vorlage

Entwickeln Sie eine Vorlage, die eine Reihe von Diensten für Ihre Data Science-Projekte bündelt. Anhand einer Vorlage, die eine Reihe von Diensten bündelt, können Sie in den Anwendungsfällen verschiedener Data Science-Teams die Konsistenz wahren. Wir empfehlen Ihnen die Entwicklung einer konsistenten Blaupause in Form eines Vorlagenrepositorys. Sie können dieses Repository für verschiedene Data Science-Projekte in Ihrem Unternehmen verwenden und dadurch die Bereitstellungszeiten verkürzen.

Richtlinien für Data Science-Vorlagen

Entwickeln Sie nach den folgenden Richtlinien eine Data Science-Vorlage für Ihre Organisation:

  • Entwickeln Sie eine Reihe von Vorlagen für Infrastructure-as-Code (IaC) und schaffen Sie sich damit einen Azure Machine Learning-Arbeitsbereich. Beziehen Sie Ressourcen wie einen Schlüsseltresor, ein Speicherkonto, eine Containerregistrierung und Application Insights mit ein.

  • Berücksichtigen Sie die Einrichtung von Datenspeichern und Computezielen in diesen Vorlagen, z. B. Compute-Instanzen, Computecluster und Azure Databricks.

Best Practices für die Bereitstellung

Echtzeit

  • Fügen Sie eine Azure Data Factory- oder Azure Synapse-Bereitstellung in Vorlagen und Azure Cognitive Services ein.
  • Die Vorlagen sollten alle erforderlichen Tools bieten, um die Data Science-Untersuchungsphase und die anfängliche Operationalisierung des Modells vorzunehmen.

Überlegungen zu einer anfänglichen Einrichtung

In einigen Fällen benötigen Datenwissenschaftler*innen in Ihrer Organisation möglicherweise eine Umgebung für schnelle Analysen nach Bedarf. Diese Situation entsteht häufig, wenn ein Data Science-Projekt nicht formell eingerichtet ist. Beispielsweise fehlen vielleicht Projektmanager*innen, ein Kostencode oder eine Kostenstelle für die interne Verrechnung in Azure, und diese Dinge fehlen, weil es dazu eine Genehmigung braucht. Benutzer in Ihrer Organisation oder Ihrem Team müssen evtl. auf eine Data Science-Umgebung zugreifen, um die Daten zu verstehen und zu schauen, ob ein Projekt durchführbar ist. Manche Projekte haben auch nur wenige Datenprodukte und brauchen deshalb keine vollständige Data Science-Umgebung.

In anderen Fällen braucht man u. U. ein vollständiges Data Science-Projekt mit einer dedizierten Umgebung, einem Projektmanagement, einem Kostencode und einer Kostenstelle. Vollständige Data Science-Projekte sind nützlich, wenn mehrere Teammitglieder zusammenarbeiten und Ergebnisse teilen möchten bzw. Modelle operationalisieren müssen, nachdem die Untersuchungsphase erfolgreich war.

Der Einrichtungsvorgang

Vorlagen sollten pro Projekt bereitgestellt werden, nachdem sie eingerichtet wurden. Jedes Projekt sollte mindestens zwei Instanzen empfangen, damit Entwicklungs- und Produktionsumgebungen voneinander getrennt werden können. In der Produktionsumgebung sollte keine einzelne Person Zugriff haben, und alles sollte über Pipelines für Continuous Integration oder fortlaufende Entwicklung und einen Dienstprinzipal bereitgestellt werden. Diese Prinzipien für Produktionsumgebungen sind wichtig, da Azure Machine Learning keine präzise rollenbasierte Zugriffssteuerung innerhalb eines Arbeitsbereichs bereitstellt. Sie können den Benutzerzugriff nicht auf bestimmte Experimente, Endpunkte oder Pipelines beschränken.

Die gleichen Zugriffsrechte gelten in der Regel für verschiedene Arten von Artefakten. Es ist wichtig, die Entwicklung von der Produktion zu trennen, um zu verhindern, dass Produktionspipelines oder Endpunkte innerhalb eines Arbeitsbereichs gelöscht werden. Zusammen mit der Vorlage muss ein Prozess aufgebaut werden, um Datenproduktteams die Möglichkeit zu geben, neue Umgebungen anzufordern.

Es wird empfohlen, verschiedene KI-Dienste wie Azure Cognitive Services pro Projekt einzurichten. Durch das Einrichten verschiedener KI-Dienste pro Projekt erfolgen Bereitstellungen für jede Datenprodukt-Ressourcengruppe. Diese Richtlinie sorgt für eine klare Trennung vom Datenzugriffsstandpunkt und verringert das Risiko, dass falsche Teams unberechtigt Zugriff auf die Daten erhalten.

Streamingszenario

Bei Echtzeit- und Streaminganwendungsfällen sollten Bereitstellungen auf einem verkleinerten Azure Kubernetes Service (AKS) getestet werden. Das Testen kann man in der Entwicklungsumgebung vornehmen, um Kosten zu sparen, bevor Sie für AKS-Produktion oder Azure App Service für Container bereitstellen. Sie sollten einfache Eingabe- und Ausgabetests ausführen, um zu prüfen, ob die Dienste wie erwartet reagieren.

Als Nächstes können Sie Modelle für den gewünschten Dienst bereitstellen. Dieses Computeziel für die Bereitstellung ist das einzige, das allgemein verfügbar ist und für Produktionsworkloads in einem AKS-Cluster empfohlen wird. Dieser Schritt ist noch wichtiger, wenn Unterstützung für GPU (Graphics Processing Unit) oder feldprogrammierbare Gatearrays erforderlich ist. Andere native Bereitstellungsoptionen, die diese Hardwareanforderungen unterstützen, sind derzeit in Azure Machine Learning nicht verfügbar.

Azure Machine Learning erfordert eine Eins-zu-Eins-Zuordnung zu AKS-Clustern. Jede neue Verbindung mit einem Azure Machine Learning-Arbeitsbereich unterbricht die vorherige Verbindung zwischen AKS und Azure Machine Learning. Sobald diese Einschränkung behoben ist, wird empfohlen, zentrale AKS-Cluster als freigegebene Ressourcen bereitzustellen und an ihre jeweiligen Arbeitsbereiche anzufügen.

Eine weitere zentrale AKS-Testinstanz sollte gehostet werden, wenn Belastungstests durchgeführt werden sollen, bevor Sie ein Modell in die AKS-Produktionsinstanz verschieben. Die Testumgebung sollte die gleiche Computeressource wie die Produktionsumgebung bereitstellen, damit die Ergebnisse der Produktionsumgebung so ähnlich wie möglich sind.

Batchszenario

Nicht für alle Anwendungsfälle sind AKS-Clusterbereitstellungen erforderlich. Ein Anwendungsfall erfordert keine AKS-Clusterbereitstellung, wenn große Datenmengen nur regelmäßig bewertet werden müssen oder auf einem Ereignis basieren. Beispielsweise können große Datenmengen darauf basieren, wann Daten in einem bestimmten Speicherkonto abgelegt werden. Für die Bereitstellung in diesen Szenarien sollten Azure Machine Learning-Pipelines und Azure Machine Learning- Computecluster verwendet werden. Diese Pipelines sollten in Data Factory orchestriert und ausgeführt werden.

Bestimmen Sie die richtigen Computeressourcen

Bevor Sie ein Modell in Azure Machine Learning zu einem AKS bereitstellen, muss der Benutzer die Ressourcen wie CPU, RAM und GPU angeben, die dem jeweiligen Modell zugeteilt werden sollen. Diese Parameter zu definieren, kann ein komplexer und anstrengender Vorgang sein. Sie müssen Belastungstests mit unterschiedlichen Konfigurationen ausführen, um einen geeigneten Satz von Parametern zu bestimmen. Sie können diesen Vorgang mit der Funktion Erstellung von Modellprofilen in Azure Machine Learning vereinfachen. Das ist ein länger dauernder Vorgang, mit dem verschiedene Ressourcenzuordnungen getestet werden. Er verwendet eine bestimmte Wartezeit und RTT, um eine optimale Kombination zu empfehlen. Diese Informationen können die tatsächliche Modellimplementierung in AKS unterstützen.

Um Modelle in Azure Machine Learning gefahrlos zu aktualisieren, sollten Teams das Merkmal Kontrollierter Rollout (Vorschau) verwenden, um Ausfallzeiten zu minimieren und den REST-Endpunkt des Modells konstant zu halten.

Bewährte Methoden und Workflow für MLOps

Einfügen von Beispielcode in Data Science-Repositorys

Sie können Data Science-Projekte vereinfachen und beschleunigen, wenn Ihre Teams über bestimmte Artefakte und bewährte Methoden verfügen. Es wird empfohlen, Artefakte zu erstellen, die alle Data Science-Teams bei der Arbeit mit Azure Machine Learning und den entsprechenden Tools der Datenproduktumgebung verwenden können. Daten- und Machine Learning-Fachkräfte sollten die Artefakte erstellen und bereitstellen.

Diese Artefakte sollten Folgendes umfassen:

  • Beispielnotebooks, die zeigen, wie man:

    • Datenprodukte lädt, einbindet und damit arbeitet.
    • Metriken und Parameter protokolliert.
    • Trainingsaufträge an Computecluster übermittelt.
  • Artifacts, die für die Operationalisierung erforderlich sind:

    • Muster von Azure Machine Learning-Pipelines
    • Muster von Azure Pipelines
    • Weitere Skripts, die zum Ausführen von Pipelines erforderlich sind
  • Dokumentation

Verwenden Sie gut entworfener Artefakte zum Operationalisieren von Pipelines

Artifacts können die Untersuchungs- und Operationalisierungsphase von Data Science-Projekten beschleunigen. Eine DevOps-Forking-Strategie kann dabei helfen, diese Artefakte in allen Projekten zu skalieren. Da diese Einrichtung die Verwendung von Git fördert, können Benutzer*innen und der gesamte Automatisierungsprozess von den bereitgestellten Artefakten profitieren.

Tipp

Azure Machine Learning-Musterpipelines sollten mit dem Python Software Developer Kit (SDK) oder basierend auf der YAML-Sprache erstellt werden. Die neue YAML-Erfahrung wird zukunftsfähiger, da das Azure Machine Learning-Produktteam derzeit an einem neuen SDK und einer neuen Befehlszeilenschnittstelle (Command Line Interface, CLI) arbeitet. Das Azure Machine Learning-Produktteam ist sich sicher, dass YAML die Definitionssprache für alle Artefakte in Azure Machine Learning sein wird.

Beispielpipelines funktionieren nicht für jedes Projekt ohne Konfiguration, können aber als Ausgangspunkt verwendet werden. Sie können Beispielpipelines für Projekte anpassen. Eine Pipeline sollte die relevantesten Aspekte jedes Projekts enthalten. Beispielsweise kann eine Pipeline auf ein Computeziel verweisen, Datenprodukte referenzieren, Parameter definieren, Eingaben definieren und die Ausführungsschritte definieren. Dieser Prozess sollte auch für Azure Pipelines ausgeführt werden. Azure Pipelines sollten auch das Azure Machine Learning SDK oder CLI verwenden.

Pipelines sollten veranschaulichen, wie man:

  • Aus einer DevOps-Pipeline in einen Arbeitsbereich verbindet.
  • Prüft, ob das erforderliche Compute verfügbar ist.
  • Einen Auftrag übermittelt.
  • Modelle registriert und bereitstellt.

Artefakte eignen sich nicht immer für alle Projekte und müssen ggf. angepasst werden, aber wenn Sie eine Grundlage haben, kann die Operationalisierung und Bereitstellung eines Projekts schneller gehen.

Struktur des MLOps-Repositorys

Möglicherweise haben Sie Situationen, in denen Benutzer*innen den Überblick darüber verlieren, wo sie Artefakte finden und speichern können. Um diese Situationen zu vermeiden, sollten Sie um mehr Zeit bitten, um eine Ordnerstruktur der obersten Ebene für das Standardrepository zu kommunizieren und zu erstellen. Alle Projekte sollten der Ordnerstruktur folgen.

Hinweis

Die in diesem Abschnitt erwähnten Konzepte können in lokalen, Amazon Web Services-, Palantir- und Azure-Umgebungen verwendet werden.

Die vorgeschlagene Ordnerstruktur auf oberster Ebene für ein MLOps-Repository (Machine Learning Operations) wird im folgenden Diagramm veranschaulicht:

Diagramm der Repositorystruktur für MLOps.

Die folgenden Zwecke gelten für jeden Ordner im Repository:

Ordner Zweck
.cloud Speichern Sie cloudspezifischen Code und Artefakte in diesem Ordner. Die Artefakte enthalten Konfigurationsdateien für den Azure Machine Learning-Arbeitsbereich, einschließlich Computezieldefinitionen, Aufträgen, registrierten Modellen und Endpunkten.
.ado/.github Speichern Sie Azure DevOps- oder GitHub-Artefakte wie YAML-Pipelines oder Codebesitzer in diesem Ordner.
code Nehmen Sie den tatsächlichen Code, der als Teil des Projekts entwickelt wird, in diesen Ordner auf. Dieser Ordner kann Python-Pakete und einige Skripts enthalten, die für die jeweiligen Schritte der Machine Learning-Pipeline verwendet werden. Es wird empfohlen, einzelne notwendige Schritte in diesem Ordner voneinander zu trennen. Häufige Schritte sind die Vorverarbeitung, das Modelltraining und die Modellregistrierung. Definieren Sie Abhängigkeiten wie Conda-Abhängigkeiten, Docker-Images oder andere für jeden Ordner.
docs Verwenden Sie diesen Ordner für Dokumentationszwecke. In diesem Ordner werden Markdowndateien und Bilder gespeichert, um das Projekt zu beschreiben.
pipelines Speichern Sie Azure Machine Learning Pipelinedefinitionen in YAML oder Python in diesem Ordner.
tests Schreiben Sie Komponenten- und Integrationstests, die ausgeführt werden müssen, um Fehler und Probleme frühzeitig während des Projekts zu erkennen, in diesen Ordner.
notebooks Trennen Sie mit diesem Ordner Jupyter-Notebooks vom tatsächlichen Python-Projekt. Innerhalb des Ordners sollte jede Person über einen Unterordner verfügen, um ihre Notebooks einzuchecken und Git-Merge-Konflikte zu verhindern.

Nächster Schritt

Datenprodukte für Analysen auf Cloudebene in Azure