Architektur und Design der Vorhersage des Customer Lifetime Value mit Kubeflow Pipelines

Dieses Dokument ist das erste einer zweiteiligen Reihe, in der die Verwendung von Kubeflow Pipelines zum Orchestrieren des Trainings, des Deployments und der Inferenz von CLV-Vorhersagemodellen (Custerom Lifetime Value) erläutert wird. In diesem Dokument werden die Architektur- und Designmuster beschrieben, die zur Implementierung von CLV-Trainings- und Inferenzpipelines verwendet werden. Eine begleitende Anleitung zeigt, wie Sie die Pipeline-Codebeispiele im zugehörigen GitHub-Repository bereitstellen, verwenden und anpassen.

Eine allgemeine Übersicht über die Verwendung von Kubeflow Pipelines zum Entwerfen, Orchestrieren und Automatisieren eines integrierten ML-Systems sowie zur Verwendung von Cloud Build für die Konfiguration einer CI/CD-Einrichtung (Continuous Integration/Continuous Deployment) finden Sie unter Architektur für CI/CD- und ML-Pipelines mit Kubeflow und Cloud Build.

Überblick

Dieses Dokument hat zwei Ziele:

  • Veranschaulichung von Architektur- und Designmustern für Kubeflow Pipelines, die von Google Cloud verwaltete ML- und Datenanalysedienste orchestrieren
  • Bereitstellung eines Starterkits für die Operationalisierung von Trainings, das Deployment und die Bewertung von CLV-Vorhersagemodellen

Die in diesem Dokument beschriebene Architektur und das Design stellen einen Anwendungsfall aus dem Vertrieb dar, bei dem Sie ein Vorhersagemodell häufig optimieren und neu trainieren müssen. Da ein ständiger Fluss neuer Verkaufstransaktionen der Kern der Trainingsdaten ist, müssen Sie die Modelle mit den sich ändernden Kaufmustern abgleichen. Die Automatisierung von Trainings- und Deployment-Workflows ist hier von entscheidender Bedeutung.

Dieses Dokument basiert auf Datenvorverarbeitungs- und Modellierungstechniken, die in der Reihe Customer Lifetime Value mit AI Platform vorhersagen behandelt werden. Diese Reihe hilft Ihnen, die CLV-Konzepte und Algorithmen besser zu verstehen.

Dieses Dokument richtet sich an Data Scientists und ML-Entwickler. Im Dokument und in der zugehörigen Anleitung wird davon ausgegangen, dass Sie grundlegende Kenntnisse über die folgenden Konzepte und Dienste von Google Cloud haben:

Kubeflow Pipelines ist eine wichtige Komponente des Kubeflow-Projekts. Das Kubeflow-Projekt ist eine auf Kubernetes basierende Open-Source-Plattform zum Entwickeln, Orchestrieren, Bereitstellen und Ausführen von skalierbaren und portablen ML-Arbeitslasten. Weitere Informationen zu Kubeflow Pipelines finden Sie in der Kubeflow-Dokumentation.

Kubeflow Pipelines werden normalerweise als Teil einer Kubeflow-Installation installiert. Sie können Kubeflow Pipelines auch als eigenständige Gruppe von Diensten und ohne Abhängigkeiten von anderen Kubeflow-Komponenten installieren.

Sie können Kubeflow Pipelines auf verschiedenen Kubernetes-Distributionen hosten. Dieses Dokument konzentriert sich auf das Ausführen von Kubeflow Pipelines in GKE.

Kubeflow Pipelines als Orchestrator

In diesem Dokument wird ein Architekturmuster gezeigt, bei dem Sie Kubeflow Pipelines als Orchestrator für von Google Cloud verwaltete ML- und Datenanalysedienste verwenden. In diesem Fall führt Kubeflow Pipelines nur den Workflow aus, nimmt aber keine anderen Berechnungen in einem Kubernetes-Cluster als Host vor.

Das folgende Diagramm zeigt die Gesamtarchitektur der CLV-Lösung, die in diesem Dokument beschrieben wird.

Übersicht über die wichtigsten Kubeflow Pipelines- und Google Cloud-Komponenten für die CLV-Lösung

Die Kubeflow Pipelines-Dienste werden in GKE gehostet. Die hier und in der Anleitung beschriebenen Pipelines werden in Kubeflow Pipelines erstellt. Diese Pipelines sind über eine Reihe von Kubeflow Pipelines-Komponenten mit Cloud Storage, BigQuery und AutoML Tables verbunden, die die jeweiligen Cloud APIs umschließen. Mit Container Registry verwalten Sie die Container-Images für die von den Pipelines verwendeten Komponenten.

Die zugehörige GitHub-Lösung enthält zwei Beispielpipelines:

  • Die Trainings- und Deployment-Pipeline
  • Die Batchvorhersagepipeline

Beide Pipelines folgen einem Datenverarbeitungs-, Trainings- und Bewertungsprozess, der dem unter Customer Lifetime Value mit AutoML Tables vorhersagen beschriebenen Ablauf ähnelt. In diesem Workflow gehen Sie so vor:

  • Sie verwenden BigQuery für die Datenbereinigung und das Feature Engineering.
  • Sie verwenden AutoML Tables für das Training, das Deployment und die Bewertung des Modells.

Trainings- und Deployment-Workflow

Die Trainings- und Deployment-Pipeline verwendet historische Verkaufstransaktionsdaten, um ein ML-Regressionsmodell zu trainieren und optional bereitzustellen. Das Modell wird trainiert, um den Wert zukünftiger Käufe eines Kunden basierend auf dessen bisherigen Käufen vorherzusagen. Weitere Informationen zur Modellierung für CLV-Vorhersagen finden Sie unter Customer Lifetime Value mit AI Platform vorhersagen: Einführung.

Das folgende Diagramm zeigt den Workflow, den die Pipeline ausführt.

Komponenten im Trainings- und Deployment-Workflow.

In diesem Workflow gehen Sie so vor:

  1. Laden Sie bisherige Verkaufstransaktionen aus Cloud Storage in eine BigQuery-Staging-Tabelle. Wenn sich die Daten bereits in BigQuery befinden, wird dieser Schritt übersprungen.
  2. Bereiten Sie eine BigQuery-Abfrage vor. Die Abfrage wird aus einer Abfragevorlage und aus Laufzeitargumenten generiert, die an die Pipeline übergeben werden.
  3. Führen Sie eine BigQuery-Abfrage aus, um aus den bisherigen Verkaufstransaktionen Features zu erstellen. Die Engineered Features werden in einer BigQuery-Tabelle gespeichert.
  4. Importieren Sie die Features in ein AutoML-Dataset.
  5. Lösen Sie das AutoML-Modelltraining aus.
  6. Rufen Sie nach Abschluss des Trainings die Bewertungsmesswerte des Modells ab.
  7. Vergleichen Sie die Leistung des Modells mit dem Leistungsschwellenwert.
  8. Wenn das Modell den Leistungsschwellenwert erreicht oder überschreitet, stellen Sie das Modell für Onlinevorhersagen bereit.

Weitere Informationen zum Design und zur Verwendung der Trainingspipeline finden Sie in der Dokumentation im zugehörigen GitHub-Repository für diese Lösung.

Workflow der Batchvorhersage

Die Pipeline verwendet dieselben Vorverarbeitungs- und Feature Engineering-Schritte wie die Trainingspipeline. Für Batchvorhersagen verwenden Sie die AutoML Tables-Methode batchPredict.

Das folgende Diagramm zeigt den Workflow, den die Pipeline ausführt.

Pipeline-Workflow für die Vorverarbeitungs- und Engineering-Schritte

  1. Laden Sie bisherige Verkaufstransaktionen aus Cloud Storage in eine BigQuery-Staging-Tabelle. Wenn sich die Daten bereits in BigQuery befinden, wird dieser Schritt übersprungen.
  2. Bereiten Sie eine BigQuery-Abfrage vor. Die Abfrage wird aus einer Abfragevorlage und aus Laufzeitargumenten generiert, die an die Pipeline übergeben werden.
  3. Führen Sie eine BigQuery-Abfrage aus, um aus den bisherigen Verkaufstransaktionen Features zu erstellen. Die Engineered Features werden in einer BigQuery-Tabelle gespeichert.
  4. Rufen Sie die AutoML Tables-Methode batchPredict auf, um die Daten zu bewerten. Die AutoML Tables-Methode batchPredict speichert die resultierenden Vorhersagen entweder in Cloud Storage oder in BigQuery.

Designmuster für Kubeflow Pipelines

Die in diesem Dokument beschriebenen Pipelines lassen sich einfach verwalten, bereitstellen und anpassen.

Allgemeine oder Pipeline-spezifische Kubeflow Pipelines-Komponenten verwenden

Im Allgemeinen können Sie Kubeflow-Komponenten in zwei Typen einteilen:

  • Allgemeine Komponenten: Eine allgemeine Komponente hat eine Funktionsweise, die nicht spezifisch für einen von einer bestimmten Pipeline implementierten Workflow ist. Eine Komponente, die einen BigQuery-Job sendet, ist beispielsweise eine allgemeine Komponente. Da die Komponente keine spezifische Logik für eine bestimmte Pipeline enthält, können Sie sie in mehreren Szenarien verwenden.
  • Pipeline-spezifische Komponenten: Eine Pipeline-spezifische Komponente ist in der Regel eine Hilfskomponente mit spezifischen Funktionen für eine bestimmte Pipeline oder eine Gruppe verwandter Pipelines. Dies kann zum Beispiel eine Komponente für die Berechnung und Protokollierung eines benutzerdefinierten Leistungsmesswerts sein, der für einen bestimmten Trainingsworkflow spezifisch ist. Eine Pipeline-spezifische Komponente ist für andere Zwecke nicht selbstverständlich wiederverwendbar.

Allgemeine Komponenten können Sie unabhängig von den Pipelines, die sie verwenden, entwickeln, erstellen, bereitstellen und verwalten.

In der Regel ist das Entwickeln, Erstellen und Bereitstellen einer Pipeline-spezifischen Komponente eng mit dem Lebenszyklus der Pipeline verknüpft, die diese Komponente verwendet. Eine praktische und gängige Methode zur Implementierung von Pipeline-spezifischen Komponenten ist die Verwendung einfacher Python-Komponenten.

Die Pipelines verwenden sowohl allgemeine als auch Pipeline-spezifische Komponenten.

Zum Ausführen von Datenvorverarbeitungs- und Feature Engineering-Aufgaben verwenden die Pipelines die BigQuery-Komponente, die in der Kubeflow Pipelines-Distribution enthalten ist. Die Komponente verarbeitet eine beliebige BigQuery-Abfrage und speichert die Ergebnisse in einer BigQuery-Tabelle oder einem Cloud Storage-Blob.

Für das Modelltraining, das Deployment und die Inferenz verwenden die Pipelines eine Reihe benutzerdefinierter AutoML Tables-Komponenten, die mit den GitHub-Codebeispielen bereitgestellt werden. Die AutoML Tables-Komponenten umfassen einen Teil der AutoML Tables APIs.

Die Pipelines verwenden auch die folgenden Hilfskomponenten, die als einfache Python-Komponenten implementiert sind:

  • Die Komponente Load transactions: Die Komponente Load transactions lädt die Verlaufsdaten der Verkaufstransaktionen aus CSV-Dateien in Cloud Storage in eine Staging-Tabelle in BigQuery.
  • Die Komponente Prepare query: Die Komponente Prepare query (gutes Beispiel für eine Pipeline-spezifische Komponente) generiert eine BigQuery SQL-Abfragevorlage. BigQuery unterstützt jedoch keine Parametrisierung von Kennungen, Spaltennamen oder Tabellennamen. Damit diese Teile der Vorverarbeitungs- und Feature-Engineering-Abfrage nicht hartcodiert werden, ersetzt Prepare query Platzhalter in der Abfragevorlage durch die Werte, die als Laufzeitparameter an die Komponente übergeben werden.

Ausführliche Informationen zum Design und zur Verwendung der in den Pipelines verwendeten Komponenten finden Sie in der Dokumentation zu dieser Lösung auf GitHub.

Pipeline-Einstellungen verwalten

Ein wichtiger Aspekt beim Pipelinedesign ist die Verwaltung von Konfigurationseinstellungen. Wir empfehlen, diese Einstellungen nicht direkt in der domainspezifischen Sprache einer Pipeline hart zu codieren. Hartcodierte Einstellungen können zu Problemen führen, wenn Sie Pipelines in verschiedenen Umgebungen bereitstellen.

Die Namen und Speicherorte der Container-Images für die von einer Pipeline verwendeten Komponenten können sich beispielsweise in Entwicklungs-, Staging- und Produktionsumgebungen unterscheiden. Ebenso können sich die URLs der Assets, die von den Komponenten verwendet werden (z. B. die von der Komponente Prepare query verwendete Abfragevorlage) von Umgebung zu Umgebung unterscheiden.

Die zugehörige GitHub-Lösung zeigt einen Ansatz für die Verwaltung der Einstellungen. In der Lösung verwaltet eine einzelne YAML-Konfigurationsdatei alle Pipeline-Einstellungen. Die Einstellungsdatei besteht aus den zwei Sektionen argument_defaults und compiler_settings.

In der Sektion argument_defaults definieren Sie die Standardwerte für die Laufzeitargumente der Pipelines. In der Sektion compiler_settings definieren Sie die Einstellungen, mit denen gesteuert wird, wie der DSP-Compiler das Python-DSP in das resultierende YAML-Format konvertiert. Ein Beispiel für eine Compilereinstellung ist ein Flag, das steuert, ob eine Pipeline so kompiliert werden soll, dass sie das spezifische Pipeline-Nutzerdienstkonto verwendet, oder so, dass sie das standardmäßige Compute Engine-Dienstkonto verwendet, wenn die Pipeline auf von Google Cloud verwaltete Dienste zugreift.

Während der Kompilierung wird die Einstellungsdatei mit dem DSL-Code der Pipelines zusammengeführt.

Ergebnisse einer ausgeführten Pipeline im Kubeflow Pipelines-Dashboard visualisieren

Die Kubeflow Pipelines-Plattform unterstützt nativ das Logging und die Visualisierung von Artefakten. Dies kann für das Tracking, Verstehen, Bewerten und Vergleichen einer Reihe von Ausführungen hilfreich sein. Diese Unterstützung ist besonders wichtig, wenn Sie während der Test- und Trainingsphasen des ML-Lebenszyklus eine potenziell große Anzahl von Ausführungen verwalten.

Das Kubeflow Pipelines-Dashboard unterstützt zwei Arten von Visualisierungen:

  • Pipeline-Messwerte: Ein Pipeline-Messwert ist ein skalarer Messwert, der im Kubeflow Pipeline-Dashboard auf der Seite Ausführungen für einen bestimmten Test als Visualisierung dargestellt wird. Der Hauptzweck eines Pipeline-Messwerts besteht darin, einen schnellen Überblick über die Leistung einer Ausführung zu geben und mehrere Ausführungen zu vergleichen.
  • Ausgabeansichten: Ausgabeansichten werden verwendet, um ausführlichere Informationen zu einer Ausführung zu protokollieren und zu rendern. Im Kubeflow Pipelines-Dashboard finden Sie die Artefakte, die von einer bestimmten Komponente ausgegeben werden, im Aufgabenbereich unter Artefakte. Eine Zusammenfassung aller Ausgaben finden Sie im Bereich Ausgabe ausführen der jeweiligen Ausführung.

Derzeit unterstützt das Kubeflow Pipelines-Dashboard folgende Typen von Ausgabeansichten:

  • Wahrheitsmatrix
  • ROC-Kurve
  • TensorBoard
  • Web-App
  • Table
  • Markdown

Die drei letztgenannten Ansichten sind flexibel, da Sie beliebige Informationen erfassen und visualisieren können.

Eine Pipelinekomponente kann Ausgabeansichten im Kubeflow Pipelines-Dashboard verwenden. Dazu schreibt sie Metadaten für die Ausgabeansichten in eine JSON-Datei. Die Metadaten müssen dem in der Dokumentation zu Kubeflow Pipelines beschriebenen Schema entsprechen.

Die meisten allgemeinen Komponenten, die mit Kubeflow Pipelines verteilt werden, generieren Metadaten, die ihre Aktionen widerspiegeln. Wir empfehlen dringend, alle benutzerdefinierten Komponenten, die im Rahmen der Kubeflow Pipelines-Lösung entwickelt wurden, für die Metadatengenerierung zu instrumentieren.

Wenn Sie Informationen erfassen müssen, die nicht automatisch von einer der vordefinierten Komponenten generiert werden, die Ihre Pipeline verwendet, können Sie die flexible Infrastruktur einfacher Python-Komponenten verwenden, um zusätzliche Artefakte auszugeben.

Die AutoML Tables-Komponenten zeigen, wie Sie mit Dashboard-Artefakten von Kubeflow Pipelines die Ergebnisse von AutoML Tables API-Aufrufen verfolgen können.

Die Komponente log_evalutation_metrics ruft die neuesten Bewertungsmesswerte eines bestimmten AutoML-Modells ab und gibt sie als Markdown-Artefakt aus.

Die Komponente protokolliert auch den als Eingabeargument angegebenen primären Messwert als Pipeline-Messwert.

Build- und Deployment-Automatisierung

Produktionspipelines können komplex werden. Dies kann folgende Gründe haben:

  • Sie verwenden verschiedene Komponenten aus verschiedenen Quellen. Sie können beispielsweise allgemeine vordefinierte Kubeflow Pipelines-Komponenten und benutzerdefinierte Komponenten verwenden, die für eine bestimmte Lösung entwickelt wurden.
  • Sie verwenden externe Assets und Ressourcen. Dies können beispielsweise SQL-Skripts und -Vorlagen, PySpark-Skripts oder Vorlagen für Ausgabeansichten sein.
  • Je nach Ziellaufzeitumgebung sind für die Laufzeitparameter oder Compilereinstellungen andere Werte als die Standardwerte erforderlich. In einigen Umgebungen müssen Sie beispielsweise eine Pipeline kompilieren, um ein benutzerdefiniertes Dienstkonto zu verwenden, während in anderen Umgebungen das Standard-Compute Engine-Konto verwendet werden kann.

Außer in den einfachsten Fällen ist es nicht möglich, die Erstellung und das Deployment von Kubeflow Pipelines-Lösungen mithilfe von Build Books oder manuellen Schritt-für-Schritt-Anleitungen zu verwalten. Daher ist die Automatisierung der Build- und Deployment-Prozesse von entscheidender Bedeutung. In Kombination mit der flexiblen Verwaltung von Konfigurationseinstellungen, wie im Abschnitt Pipeline-Einstellungen verwalten beschrieben, bildet die Automatisierung die Grundlage für eine robuste, wiederholbare und nachverfolgbare Konfigurationsverwaltung von Kubeflow Pipelines-Lösungen.

Die Codebeispiele im zugehörigen GitHub-Repository zeigen einen Ansatz zur Automatisierung des Build-Prozesses mit Cloud Build. In diesem Szenario führt Cloud Build folgende Schritte aus:

  1. Erstellt das Basis-Image für die einfachen Python-Komponenten
  2. Erstellt das Image, auf dem AutoML Tables-Komponenten gehostet werden
  3. Stellt die Images in der Container Registry Ihres Projekts bereit
  4. Kompiliert die Pipelines
  5. Stellt die kompilierten Pipelines in Cloud Storage bereit
  6. Stellt die Artefakte der Pipelines in Cloud Storage bereit
  7. Kopiert das in der Anleitung verwendete Beispiel-Dataset in Cloud Storage

Eine ausführlichere Beschreibung des Build-Prozesses finden Sie im GitHub-Repository der Lösung.

Nächste Schritte