Oracle Cloud Infrastructure - Dokumentation

ML-Anwendungsfälle als ML-Anwendungspakete implementieren

Provider, die eine neue ML-Anwendungsimplementierung entwickeln, müssen ein neues Anwendungspaket erstellen, das der Implementierung entspricht.

Mit dem Anwendungspaket kann die Standardverpackung der ML-Funktionalität umgebungsunabhängig und regionsunabhängig erfolgen. Dies macht es zu einer portablen Lösung, die in jedem Mandanten, jeder Region oder jeder Umgebung verwendet werden kann. Infrastrukturabhängigkeiten (z.B. VCN- und Log-OCIDs), die für eine Region oder Umgebung spezifisch sind, werden während des Uploadprozesses als Packageargumente bereitgestellt.

Packages enthalten alle Implementierungsdetails für eine ML-Anwendung, wie Terraform, z.B. Komponenten und Anwendungskomponenten, einen Deskriptor mit Informationen zur Implementierungsversion, ein Konfigurationsschema und mehr. Diese Packages können in vorhandene ML-Anwendungsimplementierungsressourcen hochgeladen oder bereitgestellt werden. Wenn eine neue Version eines Packages hochgeladen wird, erstellt der ML-Anwendungsimplementierungsservice automatisch eine neue ML-Anwendungsimplementierungsversion und startet ein Upgrade aller ML-Anwendungsinstanzen, die das Package verwenden.

Das Paket enthält Komponenten, die den ML-Anwendungsfall implementieren. Es gibt zwei Komponententypen:
Anwendungskomponenten
Diese Ressourcen müssen pro ML-Anwendungsimplementierung erstellt werden. Beim Provisioning neuer ML-Anwendungsimplementierungen müssen entsprechende Anwendungskomponenten erstellt werden. Anwendungskomponenten sind für alle Instanzen der ML-Anwendungsimplementierung üblich und werden nicht erstellt oder neu erstellt, wenn neue ML-Anwendungsinstanzen bereitgestellt werden.
Instanzkomponenten
Diese Ressourcen müssen pro ML-Anwendungsinstanz erstellt werden. Beim Provisioning neuer ML-Anwendungsinstanzen müssen entsprechende Instanzkomponenten erstellt werden. Instanzkomponenten sind für alle Instanzen der ML-Anwendungsimplementierung unterschiedlich.

Die Terraform-Konfiguration für alle Anwendungskomponenten ist im Verzeichnis application_components im Anwendungspaket vorhanden. Ebenso ist das Terraform für alle Instanzkomponenten im Verzeichnis instance_components vorhanden.

Um die Unterscheidung zwischen Anwendungskomponenten und Instanzkomponenten klarer zu machen, sollten Sie bedenken, dass die Provider eine Lösung (ML Application Implementation) für einige ML Applications-Anwendungsfälle entwickeln möchten, die folgende Teile umfasst:
Modell trainieren und bereitstellen
Anbieter schreiben einen Algorithmus für maschinelles Lernen, der ein ML-Modell basierend auf einigen Trainingsdaten trainiert. Provider verwenden Jobs, um das Modell zu trainieren, es im Modellkatalog zu speichern und dann das Modell bereitzustellen.
Für das Training zu verwendende Daten
Das Modell wird für die Kundendaten (Verbraucherdaten) trainiert, die sich in einem Objektspeicher-Bucket im Verbrauchermandanten befinden. Der ML-Job lädt Daten aus dem Consumer-BS-Bucket in den Object Storage-Bucket des Providers.

In diesem Beispiel ist der ML-Job eine Anwendungskomponente, und die Terraform-Konfiguration zum Erstellen des ML-Jobs ist Teil des Verzeichnisses application_components im Anwendungspackage. Während das eigentliche Training zu Verbraucherdaten stattfindet, wird das Training ausgelöst, wenn eine neue ML-Anwendungsinstanz der ML-Anwendungsimplementierung bereitgestellt wird. Wenn eine neue ML-Anwendungsinstanz erstellt wird, wird ein neuer Joblauf erstellt und ausgelöst. Dieser lädt Daten aus dem Consumer-Objektspeicher-Bucket in den Provider-Objektspeicher-Bucket, trainiert das Modell, speichert das Modell im Modellkatalog und stellt das Modell dann bereit. Für jede Instanz (Kunde) muss ein neuer Joblauf erstellt werden. Der Joblauf ist eine Instanzkomponente. Außerdem wird der Object Storage-Ziel-Bucket für jede Instanz erstellt. Daher handelt es sich um eine Instanzkomponente. Ebenso ist das Modell-Deployment auch eine Instanzkomponente.

Die Terraform-Konfiguration für Anwendungskomponenten und Instanzkomponenten kann parametrisiert werden. Alle Parameter, die für das Provisioning von ML-Anwendungen und ML-Anwendungsinstanzen erforderlich sind, können in der Datei descriptor.yaml angegeben werden. Beispiel: Das Docking-Image, das mit dem Joblauf verwendet werden soll, kann parametrisiert werden. Das Data Science-Projekt, unter dem der Job erstellt werden muss, kann parametrisiert werden. Alle Parameter, die zu den Anwendungskomponenten gehören und beim Provisioning neuer Implementierungen erforderlich sind, können unter packageArguments in der Datei descriptor.yaml angegeben werden. Im Allgemeinen kann packageArguments verwendet werden, um umgebungsspezifische Werte bereitzustellen, wie Infrastruktur-OCIDs und einige umgebungsspezifische Skalierungswerte.

Ebenso wird der Name des Quell-BS-Buckets (aus dem Consumer-Mandanten) beim Erstellen einer ML-Anwendungsinstanz benötigt und kann sich von Instanz zu Instanz unterscheiden (Verbraucher zu Consumer). Dies kann also ein Parameter sein, dessen Wert vom Consumer während der Erstellung der ML-Anwendungsinstanz angegeben wird. Alle diese Parameter können unter configurationSchema in der Datei descriptor.yaml definiert werden.

So sieht die endgültige Struktur eines Anwendungspaketverzeichnisses ähnlich aus:

  • <ml-app-package-name>-<version>.zip
    • application_components: Das Verzeichnis mit allen Anwendungskomponentendefinitionen.
    • instance_components: Das Verzeichnis mit allen Instanzkomponentendefinitionen.
    • descriptor.yaml: Die Paket-Deskriptordatei.
    • *.trigger.yaml: Die Triggerdefinitionsdatei.

Wichtige Hinweise zur Anwendungspaketstruktur:

  • Sowohl Anwendungskomponenten als auch Instanzkomponenten müssen in den entsprechenden Verzeichnissen definiert sein.
  • Die Verzeichnisse application_components und instance_components sind optional. Ein Anwendungspaket ohne Verzeichnis application_components oder instance_components ist gültig.
  • Die Verzeichnisse müssen genau (in Kleinbuchstaben) als application_components und instance_components benannt werden.
  • Komponenten, deren Terraform-Konfiguration nicht im Verzeichnis application_components vorhanden ist, werden nicht als Anwendungskomponenten betrachtet.
  • Komponenten, deren Terraform-Konfiguration nicht im Verzeichnis instance_components vorhanden ist, werden nicht als Instanzkomponenten betrachtet.
  • Derzeit werden nicht alle OCI-Ressourcen als Anwendungs- oder Instanzkomponenten unterstützt.
  • Ein Data Science-Job ist die unterstützte Anwendungskomponente, während Data Science-Modell, Modell-Deployment, Joblauf, Objektspeicher-Bucket und Objekt die unterstützten Instanzkomponenten sind.

Im nächsten Abschnitt wird das Schema der Package-Deskriptordatei ausführlicher beschrieben.

ML-Anwendungsbausteine

ML-Anwendungen werden mit anderen OCI-Ressourcen erstellt. In der folgenden Tabelle werden die zulässigen Ressourcentypen aufgeführt:
Zulässige Ressourcentypen
Komponententyp Zulässige OCI-Ressourcen Hinweise
Anwendungskomponenten Data Science
  • Job
  • Pipeline
  • Modellieren
Data Flow
  • Datenflussanwendung

Mehrmandantenkomponenten werden in allen ML-Anwendungsinstanzen innerhalb einer Implementierung gemeinsam verwendet.

Data Science:

  • Jobs und Pipelines werden häufig als Anwendungskomponenten verwendet und definieren Workflows oder Aufgaben, die von der Anwendung ausgeführt werden. Wenn ein Workflow oder eine Aufgabe für einen Kunden ausgelöst wird, wird eine neue Pipelineausführung oder Jobausführung erstellt, in der Regel mit kundenspezifischen Parametern, die vom Trigger bereitgestellt werden.
  • Modelle werden als Anwendungskomponenten verwendet, wenn ein vortrainiertes Out-of-the-box-Modell für die Verwendung durch die Anwendung verfügbar ist.

Mit Data Flow-Anwendungen können große Datenmengen transformiert werden

Sie können als Schritte innerhalb einer Pipeline verwendet werden.

Wenn eine Pipeline mit einem Datenflussschritt ausgeführt wird, erstellt und verwaltet sie automatisch eine neue Ausführung der mit diesem Schritt verknüpften Datenflussanwendung. Die Datenflussausführung wird wie jeder andere Schritt in der Pipeline behandelt. Wenn die Pipeline erfolgreich abgeschlossen wurde, setzt sie ihre Ausführung fort und beginnt spätere Schritte als Teil der Orchestrierung der Pipeline.

Weitere Informationen finden Sie unter Data Flow-Integration.
Instanzkomponenten Data Science
  • Modellieren
  • Modell-Deployment
  • Scheduler
    • Ausführungspläne
Object Storage
  • Bucket
  • Objekt
Hinweis:

ML-Anwendungstrigger können als Instanzkomponenten verwendet werden.

ML-Anwendungs-Trigger sind keine OCI-Ressourcen, können jedoch als Instanzkomponenten verwendet werden.

Trigger sind die Einstiegspunkte für Workflows (wie Schulungen), die in Ihren Anwendungen definiert sind. Sie definieren, unter welchen Bedingungen ein Workflow gestartet wird, und stellen sicher, dass der Workflow mit der Identität der ML-Anwendungsinstanz (datasciencemlappinstance Resource Principal) gestartet wird.

Einzelmandantenressourcen werden für jede ML-Anwendungsinstanz (SaaS-Kunde) eindeutig erstellt.

  • Modelle werden als Instanzkomponenten verwendet, wenn ein neues Modell speziell für jeden Kunden anhand seiner Daten trainiert wird.
  • Modell-Deployments dienen als Instanzkomponenten, um kundenspezifische Modelle als Services bereitzustellen.
  • Buckets fungieren als kundenspezifischer Speicher für aufgenommene, transformierte oder verarbeitete Daten.
  • Objekte werden in der Regel zum Speichern kundenspezifischer Konfigurationen verwendet.
  • Schedules ermöglichen die regelmäßige Ausführung von Workflows basierend auf einem definierten Intervall. Sie sind mit ML-Anwendungstriggern verknüpft, die sie in geplanten Intervallen aufrufen.
Hinweis

ML-Anwendungen setzen keine Grenzen für die Anzahl der Komponenten, die Sie verwenden können. Während eine Anwendung möglicherweise eine Pipeline, einen Trigger, ein Modell und ein Modell-Deployment erfordert, können Sie komplexere Anwendungen erstellen, z. B. Anwendungen mit mehreren Pipelines, Triggern, Modellen und Modell-Deployments. Beispiel: fünf Pipelines mit fünf Triggern, drei Modellen und drei Modell-Deployments. Außerdem können ML-Anwendungen ohne Pipelines oder Modell-Deployments erstellt werden, wenn sie nicht benötigt werden.

Paketdeskriptordatei

Folgendes ist ein Schema für den Deskriptor:
descriptorSchemaVersion
  • Beschreibung: Die Schemaversion für den Package-Deskriptor, mit der das Schema weiterentwickelt werden kann. Es hat eine Haupt- und eine Nebenversion (z. B. "1.0"), in der die Hauptversion für inkompatible Abwärtsänderungen und die Nebenversion für abwärtskompatible Änderungen erhöht wird.
  • Erforderlich: true
  • Typ: Zeichenfolge
Beschreibung
  • Beschreibung: Die Beschreibung der ML-Anwendungsimplementierung, die als spezifisches ML-Anwendungspaket verpackt ist. Dieser Wert wird als Beschreibungsfeld in der ML-Anwendungsimplementierung angezeigt.
  • erforderlich: false
  • Typ: Zeichenfolge
mlApplicationVersion
  • Beschreibung: Die Version des ML-Anwendungsvertrags (das Versionsfeld der ML-Anwendungsversionsressource), der vom jeweiligen Paket implementiert wird.
    Hinweis

    Dies ist ein Platzhalter, der für die zukünftige Verwendung reserviert ist, wenn die Ressource "ML-Anwendungsversion" eingeführt wird. Der angegebene Wert wird ignoriert.
  • Erforderlich: true
  • Typ: Zeichenfolge
packageVersion
  • Beschreibung: die Version des ML-Anwendungspakets. Dieser Wert wird in der ML-Anwendungsimplementierung als Feld Package version angezeigt.
  • Erforderlich: true
  • Typ: Zeichenfolge
packageArguments
  • Beschreibung: Die Liste der unterstützten Argumente. Argumente können verwendet werden, um umgebungsspezifische Werte wie Infrastruktur-OCIDs und einige umgebungsspezifische Skalierungswerte bereitzustellen.
  • type: map (der Argumentname entspricht den Eigenschaften des Arguments)
  • erforderlich: false
  • Argumenteigenschaften:
    • Typ
      • Obligatorisch
      • Typ:
        • Typ: enum (String oder OCID)
        • Erforderlich: true
        • Beschreibung: Der Typ des Argumentwerts.
      • Boolean (true oder false)
      • Erforderlich: false (Standard ist true)
      • Beschreibung: Gibt an, ob das spezifische Argument obligatorisch ist.
    • description
      • Typ: Zeichenfolge
      • Erforderlich: true
      • Beschreibung: Die Argumentbeschreibung.
    • validationRegexp
      • Typ: Zeichenfolge
      • erforderlich: false
      • Beschreibung: Der reguläre Ausdruck für die Validierung des Argumentwerts.
    • defaultValue
      • Typ: Zeichenfolge
      • erforderlich: false
      • Beschreibung: Der Wert, der verwendet wird, wenn die Eigenschaft des Arguments oder des Konfigurationsschemas nicht angegeben ist (er kann nur angegeben werden, wenn mandatory false ist).
configurationSchema
  • Beschreibung: Das Schema der Konfiguration, die der Consumer als Metadaten der ML-Anwendungsinstanz angeben muss. Dieser Wert wird in der ML-Anwendungsimplementierung als Feld configurationSchema angezeigt.
  • type: map (der Name der Konfigurationseigenschaft ist den Eigenschaften der Konfigurationseigenschaft zugeordnet)
  • erforderlich: false
  • Argumenteigenschaften:
    • Typ
      • Typ: enum (String oder Secret)
      • Erforderlich: true
      • Beschreibung: Der Typ des Konfigurationswerts.
    • Obligatorisch
      • Typ: Boolescher Wert (true oder false)
      • Erforderlich: false (Standard ist true)
      • Beschreibung: Gibt an, ob die spezifische Konfigurationseigenschaft obligatorisch ist.
    • description
      • Typ: Zeichenfolge
      • Erforderlich: true
      • Beschreibung: Beschreibung der Konfigurationseigenschaft.
    • validationRegexp
      • Typ: Zeichenfolge
      • erforderlich: false
      • Beschreibung: Der reguläre Ausdruck für die Validierung des Konfigurationswerts.
    • sampleValue
      • Typ: Zeichenfolge
      • Erforderlich: true
      • Beschreibung: Der Beispielwert für die Validierung von Instanzkomponenten.
    • defaultValue
      • Typ: Zeichenfolge
      • erforderlich: false
      • Beschreibung: Der Wert, der verwendet wird, wenn keine Eigenschaft für Argument oder Konfigurationsschema angegeben ist (erforderlich muss "false" sein).

Erforderliche Terraform-Attribute

Alle Terraform-Definitionen von Data Science-Jobs müssen sicherstellen, dass die zugehörigen Jobläufe beim Löschen des Jobs automatisch gelöscht werden.
resource oci_datascience_job ingestion_job {
  ...
  delete_related_job_runs = true
  ...
}
Alle Terraform-Definitionen von Data Science-Pipelines müssen sicherstellen, dass die zugehörigen Pipelineausführungen beim Löschen der Pipeline automatisch gelöscht werden.
resource oci_datascience_pipeline ingestion_pipeline {
  ...
  delete_related_pipeline_runs = true
  ...
}
Hinweis

Wenn Sie die Attribute delete_related_xxx_runs nicht korrekt angeben, wird das Löschen der Version der ML-Anwendungsimplementierung blockiert. Der Provider muss die Ausführungsressourcen entfernen, um die Sperre des Löschvorgangs aufzuheben.

Mandantenisolation und OCI-SDK-Version

Durch die Mandantenisolierung wird die Trennung von Daten und Workloads für jeden Kunden sichergestellt. Der ML-Anwendungsservice propagiert den Resource Principal (Identität) von ML-Anwendungsinstanzen an Workloads (Pipeline oder Jobläufe), die von ML-Anwendungs-Triggern gestartet werden.

Die Propagierung des Resource Principals der ML-Anwendungsinstanz erfordert entsprechende Unterstützung in den OCI-SDKs:

  • Python-SDK: Version 2.126.4 oder höher
  • Java-SDK: Version 3.44.4 oder höher