Infrastrukturoptionen für Datenpipelines in der Werbung (Teil 2)

Im Mittelpunkt dieses Artikels stehen Datenpipelines und Aufgaben des maschinellen Lernens, die auf den verschiedenen Werbeplattformen gängig sind. Der Artikel ergänzt den Artikel Infrastrukturoptionen für die Bereitstellung von Werbearbeitslasten (Teil 1). Beide Artikel liefern den nötigen Kontext für die Reihe.

Dieser Artikel ist Teil der folgenden Reihe:

Einen Überblick über das Zusammenspiel dieser Plattformen und der in dieser Reihe verwendeten Begriffe der Anzeigentechnologie finden Sie unter Werbeplattformen erstellen (Übersicht).

Die in den Datenpipelines verwendeten Datenspeicher (in Teil 1) sind der (eindeutige) Nutzerprofilspeicher, der Kontextspeicher (in Teil 1) und der Berichts-/Dashboardspeicher (in Teil 1). Diese Datenspeicher werden aus zwei Hauptquellen gespeist: Ereignissen und Daten von Drittanbietern. Der Schwerpunkt dieses Artikels liegt auf der Ereignisverwaltung. Weitere Informationen zu Daten von Drittanbietern und deren Verwendung zum Anreichern von Nutzerdaten finden Sie unter Daten anreichern (in Teil 4).

Ereignislebenszyklus

Die Datenpipeline – von Rohereignissen bis zu brauchbaren Daten – lässt sich in folgende Phasen unterteilen:

  • Erfassen und Speichern (Datenaufnahme): Über ein Nachrichtensystem oder wiederholte Uploads von Dateien in ein Speichersystem
  • Verarbeiten: Entweder in Batches oder im Streamingmodus zur Echtzeitverarbeitung, wenn die Datenaktualität wichtig ist
  • Exportieren (oder Laden): Entweder direkt aus dem Datenverarbeitungstool oder über einen benutzerdefinierten Workflow. Die Ziele sind meist die oben genannten Speicher

Die häufigsten Ereignisse in der Anzeigentechnologie sind:

  • Anzeigen- und Gebotsanfragen: Gehen im Allgemeinen von einem externen System ein. Die in den Anfragen enthaltenen Details bilden einen Teil der Eingabe für die Anzeigenauswahl
  • Impressionen: Auf einer Webseite geladene Creatives, die jedoch nicht immer sichtbar sind
  • Abrechnungsfähige Impressionen: Gerenderte und/oder sichtbare Impressionen
  • Klicks: Aktionen, die ein Nutzer durch Klicken auf ein Creative ausführen kann
  • Conversions: Aktionen, die ein Zielnutzer auf der Website des Werbetreibenden ausführt

Mit Echtzeitgeboten verknüpfte Ereignisse werden in Infrastrukturoptionen für RTB-Gebotsfunktionen (Teil 4) behandelt.

Erfassen

Ereignisse können erstellt werden durch:

  • Anzeigen- oder Gebotsanfrageinstanzen: Instanzen, die eine Anfrage erhalten, geben entweder eine URL für das Creative oder eine Gebotsantwort zurück
  • Erfassungsmodulinstanzen: Instanzen, die ein unsichtbares Pixel zurückgeben, um Impressionen zu protokollieren und/oder Aktionen zu erfassen, die ein Zielnutzer für eine Anzeige ausgeführt hat, z. B. Aktionen wie Klicks oder Videowiedergaben
  • Stackdriver Logging: In einigen Fällen kann dieses Logging Erfassungsmodulinstanzen und Server-Log-Dateien ersetzen

Ereignisse können erfasst werden durch:

  • Benutzerdefinierten Code, der das Ereignis in einem Nachrichtensystem wie Cloud Pub/Sub veröffentlicht oder in eine lokale Log-Datei schreibt
  • Drittanbietertools oder native Logging-Funktionen auf Ihrem Webserver
  • Einen GCP-Logging-Agent, der ausgewählte Drittanbietersoftware unterstützt und in Stackdriver Logging integriert ist.

Die Aufnahme von Ereignissen kann folgendermaßen ausgeführt werden:

  • In beinahe Echtzeit, wenn Log-Dateien lokal geschrieben und dann zur Verarbeitung regelmäßig in einen produktübergreifenden Speicher wie Cloud Storage oder BigQuery Capacitor kopiert werden. Der BigQuery-Speicher wird in der Regel verwendet, wenn für diese Verarbeitung analytische Abfragen benötigt werden.
  • In Echtzeit, wenn Sie Stackdriver Logging verwenden oder Ihre Erfassungsmodule direkt in einen Datenspeicher mit niedriger Latenz oder in ein Nachrichtensystem wie Cloud Pub/Sub, Apache Kafka oder RabbitMQ schreiben. Diese Option wird häufig von Echtzeitverarbeitungssystemen genutzt.

Stackdriver Logging kann viele dieser Aufgaben erleichtern, da Daten direkt aus GCP-Produkten wie Compute Engine, Google Kubernetes Engine und sogar dem HTTP-Load-Balancing erfasst werden können. Mit Logging lassen sich Daten auch direkt für Ad-hoc-Analysen in BigQuery exportieren, zu Warnzwecken und zur Echtzeitverarbeitung an Cloud Pub/Sub streamen und für Sicherungen oder föderierte Analysen batchweise in Cloud Storage exportieren.

Hier einige Beispiele, die die vorherigen Punkte unter Berücksichtigung der Vorgänge, Kosten und Datenaktualität veranschaulichen:

Option Kosten Operativer Aufwand Datenaktualität
Log-Dateien alle x Sekunden in Cloud Storage kopieren, dann mithilfe von bq load in BigQuery laden Keine Kosten für Traffic, der bei Cloud Storage eingeht

Keine Kosten für die Datenaufnahme in BigQuery

BigQuery-Speicherkosten
Dateien, Fehler, Wiederholungen und Synchronisierung müssen verwaltet werden. Echtzeitnah
Log-Dateien alle x Sekunden in Cloud Storage kopieren, dann mithilfe von Cloud Functions in BigQuery laden Keine Kosten für Traffic, der bei Cloud Storage eingeht

Keine Kosten für die Datenaufnahme in BigQuery

Zusatzkosten mit Cloud Functions

BigQuery-Speicherkosten
Cloud Functions vereinfacht die Ladeverwaltung. Die Logik muss noch codiert werden. Echtzeitnah
Stackdriver Logging mit Export in Cloud Pub/Sub verwenden Cloud Pub/Sub-Kosten Gering Echtzeit
Logs mit lokalem Daemon an Kafka streamen Speicher- und Rechenkosten für die Ausführung von Kafka Einrichten und Verwalten von Kafka, sofern keine von der GCP verwaltete Option verwendet wird Echtzeitnah oder in Echtzeit, je nach Einrichtung von Kafka

Tipp: Wenn Ereignisse mithilfe von Compute-Instanzen erfasst werden, sollten Sie zur Kosteneinsparung immer die Verwendung von VMs auf Abruf prüfen, wie im Abschnitt zur Computing-Plattform erläutert.

Daten speichern

Wo Sie Ihre Daten speichern, wird durch das Format der Daten, den Zugriff auf die Daten und deren Verwendung sowie die Kosten für die Datenspeicherung beeinflusst. Wenn das Datenformat unstrukturiert ist oder vor der Verarbeitung gespeichert werden muss, sollten Sie wie bereits empfohlen Cloud Storage verwenden. Bei strukturierten Daten müssen Sie auch den Aufwand berücksichtigen, der beim Zugriff auf die Datensätze anfällt. Das folgende Diagramm kann Ihnen bei der Einschätzung helfen, welches Zugriffsmuster die Anzahl der Vorgänge und die Kosten minimiert.

Empfehlungen zum Exportieren von Daten

Unter Speicherungsmuster für hohe Lesegeschwindigkeit (in Teil 1) werden Speicher- und Bereitstellungsoptionen erläutert. Der Rest des vorliegenden Abschnitts behandelt analytische Datenspeicher, die sowohl für das Streaming als auch die Batchverarbeitung verwendet werden.

Beim Streaming verarbeiten Sie Rohdaten, bevor Sie sie speichern. Wenn Sie die Daten außerdem sofort für Ad-hoc-Abfragen verfügbar machen möchten, sollten Sie Streaming an BigQuery erwägen. Dies lässt sich leicht mithilfe dieser Cloud Dataflow-Vorlage von Cloud Pub/Sub an BigQuery umsetzen.

Bei der periodischen Batchverarbeitung konsolidieren Sie Daten durch ihre Speicherung in einer gemeinsamen und skalierbaren Umgebung. Ein gängiges Muster besteht darin, Log-Dateien in minütlichen Intervallen von ihrem lokalen Speicherort in den Objektspeicher zu verschieben. Dateinamen werden oft Präfixe und Suffixe voran- bzw. nachgestellt, beispielsweise logs_serverABC_timestamp123.txt.

Sie können Ihre Analysearbeitslasten auf folgenden Speichersystemen ausführen:

  • Cloud Storage: Mit den Storage-Klassen "Standard", Nearline und Coldline können Sie Daten für einen schnellen Zugriff bzw. zum Sichern oder Archivieren speichern. Richten Sie den Standardspeicher – die bevorzugte Option für Analysen – möglichst als regionalen Bucket ein. Erstellen Sie den Speicher außerdem in derselben Region wie die Computing-Ressourcen, die die Daten verarbeiten. Auf Cloud Storage kann von den meisten GCP-Produkten aus zugegriffen werden, einschließlich Cloud Dataproc, Cloud Dataflow, Cloud Dataprep von Trifacta und BigQuery
  • BigQuery: BigQuery ist nicht nur eine leistungsstarke Abfrage-Engine, sondern bietet auch einen eigenen Speicher namens Capacitor. Mit Capacitor haben Sie die Möglichkeit, Exabyte an Daten zu speichern. Auf BigQuery-Speicher kann über Cloud Dataproc, Cloud Dataflow und die BigQuery-Abfrage-Engine zugegriffen werden. Mit der Langzeitspeicherung in BigQuery sinken Ihre Speicherkosten für Partitionen, die 90 Tage nicht bearbeitet werden, um etwa 50 %
  • Cloud Bigtable: Angesichts der Milliarden von Ereignissen, die jeden Tag erfasst werden, ist Cloud Bigtable ein hervorragendes Tool, wenn hohe Schreib- und Lesegeschwindigkeiten im einstelligen Millisekundenbereich erforderlich sind. Der Zugriff kann über die HBase API und andere Clients erfolgen. Sie können Cloud Bigtable auch mit der Big Data-Plattform zur Erstellung von Grafiken, Zeitachsen und Analysen verwenden

Empfehlungen:

  • Speichern Sie Rohdaten parallel zu anderen Verarbeitungsschritten in BigQuery. Von dort aus lassen sich auf einfache Weise stündliche, tägliche, wöchentliche oder monatliche Rollups ausführen. Die Ladeoptionen hängen von Ihren Anforderungen ab. Weitere Informationen finden Sie in der BigQuery-Dokumentation zum Laden von Daten
  • Wenn Kosten eine Rolle spielen, können Sie in Cloud Storage gespeicherte Daten mit bq load, Cloud Functions, der Job API oder föderierten Abfragen kostenlos bzw. kostengünstiger als durch Streaming in BigQuery laden. Für die ersten beiden Optionen gelten Kontingente
  • Verwenden Sie BigQuery-Speicherfunktionen wie Partitionen und Clustering zur Minimierung von Abfragezeit und -kosten

Ereignisse verarbeiten

Berücksichtigen Sie bei der Auswahl einer Technologie zum Erstellen Ihrer Verarbeitungspipelines Folgendes:

  • Latenz: Legen Sie fest, welche Daten in Echtzeit verarbeitet werden müssen. Beispielsweise kann es sein, dass der Budgetzähler so schnell wie möglich berechnet werden muss
  • Genauigkeit: Einige Werte wie Abrechnungsbeträge müssen exakt berechnet werden, auch wenn es nicht sofort erforderlich ist
  • Hohe Verfügbarkeit: Angesichts der Milliarden von Dateneingaben pro Tag können einige Minuten Ausfallzeit erhebliche finanzielle Auswirkungen haben
  • Operativer Aufwand: Die ausschließliche Aufrechterhaltung des Betriebs ist eventuell nicht die beste Nutzung Ihrer technischen Ressourcen

Dazu ein Beispiel:

  • HTTP-Load-Balancing-Logs werden mithilfe von Stackdriver Logging in Echtzeit aufgenommen
  • Einige Logs müssen für die Berechnung des verbleibenden Budgets sofort verarbeitet werden
  • Die zusammengefasste Anzahl der Impressionen wird stündlich benötigt, das Frequency Capping für Kampagnen dagegen täglich

Üblicherweise verwenden Unternehmen die Lambda-Architektur zum Ausgleich ihrer Datenverarbeitungspipelines:

  • Schnelle Näherungswerte durch eine Echtzeit-Verarbeitungspipeline.
  • Genauigkeit durch eine zusätzliche Offline-Batchverarbeitungspipeline

Lambda-Datenverarbeitungspipeline

In diesem Abschnitt wird neben Cloud Dataflow auf einige GCP-Produkte eingegangen, die Sie zum Implementieren von Lambda- und Kappa-Architekturen zur Datenverarbeitung verwenden können:

  • Cloud Dataproc (Batch und Stream): Wenn Sie bereits Hadoop- oder Spark-Jobs und -Skripts haben, können Sie diese unverändert zu Cloud Dataproc, GCP-verwaltetem Spark oder Hadoop migrieren
  • Cloud Dataflow (Batch und Stream): Wenn Sie neue Arbeitslasten haben, eventuell erweiterte Streamingfunktionen benötigen oder ein einheitliches Programmiermodell verwenden möchten, bietet Cloud Dataflow einen vollständig verwalteten Dienst, der das von Google als Open Source freigegebene Apache Beam ausführt. Cloud Dataflow unterstützt auch viele Ein- und Ausgaben wie Cloud Pub/Sub und Kafka und bietet ein einheitliches Programmiermodell für Streaming- und Batchdaten, das die "genau einmalige" Verarbeitung unterstützt
  • BigQuery (Batch): Wenn Sie einen ELT-Ansatz (Extrahieren, Laden und Transformieren) verwenden oder nach dem Laden der Daten in das Data Warehouse Folgetransformationen ausführen möchten, können Sie für die SQL-Transformationen BigQuery verwenden. BigQuery ist verwaltet und bietet auch benutzerdefinierte Funktionen. Für die Orchestrierung dieser Abfragen ist Cloud Composer zu empfehlen, das von Apache Airflow verwaltet wird
  • Drittanbietertools: Sie können Tools aus dem Hadoop-Framework oder Tools wie Storm in Compute Engine oder Google Kubernetes Engine (GKE) installieren und verwalten

Die folgende Architektur veranschaulicht eine Empfehlung, die auf diesen Anforderungen basiert:

  • Die Aufnahme der Ereignisse erfolgt in Echtzeit
  • Manche Zähler werden pro Sekunde berechnet
  • Der Rollup von Impressionszählern erfolgt stündlich
  • Die Klickrate (Click-through-Rate, CTR) der Anzeigen wird täglich berechnet

Eine Datenverarbeitungspipeline, die Cloud Pub/Sub verwendet

Der Datenverarbeitungsablauf sieht so aus:

  1. Ereignisse werden in Cloud Pub/Sub geschrieben.
  2. Dataflow schreibt die Daten auf Ereignisebene direkt in BigQuery.
  3. Außerdem teilt Dataflow die Daten für die erforderlichen Zusammenfassungen in 1-Sekunden-Intervalle ein und schreibt die Zähler in regionale Cloud Bigtable-Instanzen.
  4. BigQuery führt wiederholt eine Abfrage aus, um ein Rollup für die Daten auszuführen und die Ergebnisse zu erfassen. Dies kann entweder über Cronjobs oder mithilfe von Apache Airflow-Planungsoptionen über Cloud Composer geplant werden.
  5. Nutzer-Front-Ends können BigQuery als OLAP-Datenbank verwenden. Weitere Informationen finden Sie unter Berichterstellung (in Teil 1).
  6. Regionale Ad-Server fragen für einen schnellen Abruf von Zählern in der Nähe befindliche Cloud Bigtable-Instanzen ab.

Orientieren Sie sich beim Erstellen einer Datenverarbeitungspipeline an den folgenden allgemeinen Empfehlungen:

  • Minimieren Sie den operativen Aufwand mithilfe von Cloud Pub/Sub oder führen Sie Apache Kafka als verwalteten Dienst auf der GCP aus
  • Schreiben Sie Ihre Pipeline gegebenenfalls mit Apache Beam, um Batches und Streaming mit einem einheitlichen Programmiermodell auszuführen
  • Führen Sie Apache Beam in Cloud Dataflow aus, um die Vorteile eines vollständig verwalteten Dienstes zu nutzen. Dieser kann die Anzahl der Worker während der gesamten Lebensdauer des Jobs automatisch skalieren sowie die Arbeitslast dynamisch ausgleichen und so die Gesamtverarbeitungszeit des Jobs reduzieren

Wenn Sie Ereignisse oder andere Daten visuell untersuchen, bereinigen und für die Analyse vorbereiten möchten, empfiehlt sich Cloud Dataprep. Sie müssen dafür keinen Code schreiben. Cloud Dataprep ermöglicht den Export von Cloud Dataflow-Vorlagen, die Sie wiederverwenden und einplanen können.

Exporte

Wenn Ereignisse aufgenommen und verarbeitet wurden, können die Ergebnisse exportiert werden in:

  • Offlinespeicher wie BigQuery oder Cloud Storage zur Offlineverarbeitung, einschließlich Rollups und Analysen
  • Speicher zur Bereitstellung wie Cloud Bigtable, Cloud Datastore, Cloud Memorystore und Drittanbieterspeicher. Front-End-Server verwenden diese Speicher beispielsweise, um Informationen zu Nutzerprofilen abzurufen und Zähler zu aktualisieren, wenn Anzeigen ausgewählt werden
  • Nachrichtensysteme wie Cloud Pub/Sub oder Kafka, wenn die Daten nachgelagert weiterverarbeitet werden müssen oder als Benachrichtigung gesendet werden sollen, z. B. beim Verwalten von Budgets

Die Datenreplikation ist ein weiterer Anwendungsfall für den Export. Wenn sich Daten beispielsweise in der Nähe Ihrer Front-End-Server oder vielleicht sogar auf den Servern befinden müssen, gibt es zwei Ansätze:

  • In manchen Fällen können Sie native Replikationsfunktionen verwenden, sofern die ausgewählte Technologie dies unterstützt. Einige Technologien wie Redis und Aerospike unterstützen eine Replikation innerhalb von Regionen. Die überregionale Replikation ist damit dagegen oft ein Problem
  • Andere Technologien unterstützen unter Umständen keine Replikation. In diesem Fall können Sie sie mit einem Nachrichtensystem und mit Prozessoren implementieren, die in Compute Engine oder in Cloud Pub/Sub ausgeführt werden

Das folgende Diagramm veranschaulicht einige unterschiedliche Ansätze:

Struktur der Datenreplikation mit GCP-Speichern

Daten werden in Echtzeit mit Cloud Dataflow und offline mit BigQuery verarbeitet. Danach geschieht Folgendes:

  • Cloud Dataflow schreibt Daten mithilfe der Apache Beam Redis IO direkt in einen Redis-Cluster, der wiederum Daten an seine lokalen Worker repliziert
  • Cloud Dataflow veröffentlicht Nachrichten an Cloud Pub/Sub. Die Nachrichten werden dann von einem automatisch skalierten Pool von Abonnenten, der in Compute Engine erstellt wird, gelesen und anschließend in einen Aerospike-Cluster geschrieben, der in Compute Engine ausgeführt wird
  • Datensätze von BigQuery-Offlinejobs, die über Cloud Composer geplant wurden, werden in die Redis- und Aerospike-Cluster exportiert

Für den Export von Daten wird Folgendes empfohlen:

  • Achten Sie darauf, dass der ausgewählte Datenspeicher sowohl Ihre Lese- als auch Ihre Schreibmuster verarbeiten kann. Ist dies nicht der Fall, sollten Sie die Leseinfrastruktur entkoppeln, wie unter Speicherungsmuster für hohe Lesegeschwindigkeit (in Teil 1) ausführlich erläutert
  • Verwenden Sie für Analysen BigQuery mit Clustering und Partitionierung zur Minimierung von Kosten und Dauer von Abfragen
  • Prüfen Sie für Lese- und Schreibvorgänge im einstelligen Millisekundenbereich die Verwendung von Cloud Bigtable. Aktivieren Sie die Replikation für eine hohe Verfügbarkeit
  • Verwenden Sie für Echtzeit-Schreibvorgänge in BigQuery die standardmäßige Streaming API der Apache Beam BigQuery IO. Mit dem Apache Beam Java SDK können Sie mithilfe von FILE_LOADS über Cloud Storage in Mikrobatches schreiben, um die Kosten zu senken
  • Prüfen Sie bei schnellen Schreibvorgängen, die weniger als eine Millisekunde dauern, die Verwendung eines in Compute Engine oder Cloud Pub/Sub installierten externen Datenspeichers

Automatisierung

Ihre Datenpipeline umfasst unter Umständen einen von mehreren Offlineabläufen zum:

Ziehen Sie für die End-to-End-Automatisierung und Fehlerverwaltung die Verwendung von Cloud Composer für Apache Airflow in Betracht. Airflow ist die empfohlene Open-Source-Technologie zum Verwalten von Workflows auf der GCP. Gerichtete azyklische Graphen (Directed Acyclic Graphs, DAGs) können manuell oder durch ein Ereignis ausgelöst oder zur wiederholten Ausführung geplant werden.

Wenn Sie eine einfachere ereignisgesteuerte Aktion benötigen, können Sie Cloud Functions für neue, in Cloud Storage erstellte Dateien oder für neue, in Cloud Pub/Sub veröffentlichte Ereignisse auslösen. Cloud Functions ist vollständig verwaltet, sodass kein operativer Aufwand entsteht. Wenn Sie an weiteren benutzerdefinierten, serverlosen Optionen interessiert sind, lesen Sie die Informationen über Knative, einem vielversprechenden, auf Kubernetes basierenden Add-on zum Erstellen, Bereitstellen und Verwalten von serverlosen Arbeitslasten.

Analyse

Für die analytische Verarbeitung und Ad-hoc-Abfragen empfiehlt sich BigQuery als Data Warehouse, da es:

Tipps:

Erwägen Sie die Verwendung autorisierter BigQuery-Ansichten. Mit einer autorisierten Ansicht können Sie Abfrageergebnisse freigeben, ohne Zugriff auf die zugrunde liegenden Tabellen zu gewähren, und die Spalten einschränken, die Nutzer abfragen können.

Wenn Sie an einer Migration von Hive interessiert sind, sollten Sie Parquet-Dateien in BigQuery laden.

Obwohl die Verwendung von BigQuery für die Analyse und SQL-basierte Offlineverarbeitung empfohlen wird, bietet die GCP auch andere Optionen:

  • Prüfen Sie für Hadoop-Arbeitslasten, einschließlich Apache Spark, Hive und Pig, die Verwendung von Cloud Dataproc. Mit dem Cloud Dataproc-Connector können Sie Apache Spark- und Hadoop-Jobs über Cloud Storage ausführen. Dies bietet eine Reihe von Vorteilen wie hohe Datenverfügbarkeit, Interoperabilität mit anderen GCP-Diensten und HDFS-Kompatibilität
  • In Compute Engine oder Cloud Pub/Sub lassen sich Drittanbietertools installieren und verwalten. Neben BigQuery wird häufig das Tool "Druid" als OLAP-Datenbank mit niedriger Latenz für Front-End-Nutzer verwendet

Funktionen für maschinelles Lernen einbinden

Bei der Verarbeitung von Ereignissen geht es nicht nur um das Bereinigen und Zusammenfassen von Daten. Wenn Sie Ihre Datenpipeline um Funktionen für maschinelles Lernen ergänzen, können Sie diese auch intelligenter machen und bessere Anzeigen empfehlen oder virtuelle Nutzersegmente erstellen, die als Modellmerkmale dienen können. Die GCP bietet eine umfassende Palette von KI-Bausteinen für maschinelles Lernen, zum Beispiel:

In Ihrem Data Lake oder Warehouse – sei es Cloud Storage oder BigQuery – werden täglich Milliarden von Ereignissen erfasst und gespeichert. Mit diesen Daten können Sie leistungsstarke Modelle für Gebote trainieren, um beispielsweise:

  • zu entscheiden, ob ein Gebot abgegeben werden soll oder nicht,
  • die CTR zu schätzen,
  • den Gebotspreis zu optimieren,
  • Kunden zu segmentieren,
  • Customer Lifetime Values (LTVs) zu berechnen und
  • eine Anzeige zur Auswahl zu empfehlen.

Beim Auswählen der Plattform für maschinelles Lernen müssen Sie einige Fragen beantworten:

  • Wie gut kenne ich meine Daten?
  • Wie viele Daten habe ich?
  • Wie viele Daten werden für das Training verwendet?
  • Findet das Training online oder offline statt?
  • Werden Vorhersagen online oder offline getroffen?
  • Kann das Bereitstellen unabhängig von der Vorhersage erfolgen?

Das folgende Diagramm zeigt einen allgemeinen Ablauf im maschinellen Lernen mit folgenden Schritten:

  1. Datasets mit BigQuery bereinigen/vorbereiten.
  2. Trainings- und Evaluierungs-Datasets in Cloud Storage exportieren.
  3. Modell mit Cloud Machine Learning Engine trainieren.
  4. Modell in Cloud Storage exportieren.
  5. Modell aus Cloud Storage importieren, wenn ein Worker initialisiert wird.
  6. Vorhersagen mithilfe des Tensorflow-Modells lokal mit niedriger Latenz treffen.

Ein allgemeiner Ablauf des maschinellen Lernens

Daten vorbereiten und Feature Engineering

Bevor Sie Daten in ein Modell für maschinelles Lernen einspeisen können, müssen Sie folgende Schritte ausführen:

  1. Untersuchen Sie das Dataset, um die Eignung der Daten für die vorliegende Aufgabe zu prüfen.
  2. Bereinigen Sie das Dataset und bereiten Sie es vor. Verknüpfen Sie dazu Daten aus mehreren Tabellen und filtern Sie nicht geeignete Datensätze heraus.
  3. Extrahieren, erstellen und wählen Sie Merkmale aus, um informative unterschiedliche Attribute des beobachteten Gegenstands zu erstellen.

Diese Aufgaben lassen sich bestens mit BigQuery für Daten ausführen, die in BigQuery gespeichert sind oder aus externen Verbunddatenquellen stammen. Sie können die Daten mit BigQuery abfragen und untersuchen, bevor Sie Ihre gefilterten, ausgewählten Datasets in Cloud Storage für das Feature Engineering exportieren.

Tipp: Sie können BigQuery nicht nur zur Untersuchung der Daten verwenden. In Verbindung mit Cloud Dataprep haben Sie damit die Möglichkeit, Stichproben und ein visuelles Profil der Daten zu erstellen.

Beim nächsten Schritt müssen Sie normalerweise überlegen, ob die Vorhersagen online oder offline getroffen werden. Bei Onlinevorhersagen ist es wichtig, dass Sie sich Gedanken über die Methode machen, mit der die Merkmale aus den Anfragedaten der Vorhersage extrahiert werden:

  • Bei Onlinevorhersagen müssen Sie während des Trainings und der Vorhersage die gleichen Schritte zum Erstellen von Merkmalen ausführen, um eine Verzerrung zu vermeiden. Mit tf.Transform können Sie diese Vorverarbeitungsschritte definieren und die Ausführung während des Trainings und der Evaluierung dann in vollem Umfang an Apache Beam übergeben. Außerdem haben Sie die Möglichkeit, die Schritte als Teil einer Tensorflow-Grafik zur Eingabe für die Vorhersagen zu exportieren. Dieser Blog bietet aufschlussreiche zusätzliche Einblicke in die Funktionsweise dieses Vorgangs
  • Bei Offlinevorhersagen können Sie in den Trainings- und Vorhersagephasen genauso vorgehen. BigQuery bietet sich dabei für die Erstellung der Merkmale im Rahmen der Batch-Vorverarbeitung an. Sie können beispielsweise Merkmale mithilfe einer Hash-Funktion vektorisieren oder einen assoziativen Wert über einen Join abrufen

Training und Evaluierung

Die GCP bietet eine Reihe von verschiedenen Optionen zum Trainieren und Evaluieren eines Modells. Beispiele:

  • Verwendung von Cloud Machine Learning Engine zur Ausführung von XGboost-, Scikit-Learn- und Tensorflow-Trainings- und -Evaluierungsaufgaben in einer vollständig verwalteten Umgebung. ML Engine bietet auch zusätzliche Funktionen wie automatisierte Hyperparameter-Abstimmung und verteiltes Training

  • Direkte Ausführung der Trainings- und Evaluierungsaufgaben auf Compute Engine-Instanzen. Dazu müssen Sie die gewünschten Softwarepakete installieren. Sie können gegebenenfalls auch GPUs, TPUs oder VMs auf Abruf nutzen, um Kosten und Verarbeitungszeit zu reduzieren

  • Verwendung von Kubeflow, um Tensorflow und viele Tools für maschinelles Lernen wie Notebook in einer containerisierten Umgebung in Kubernetes zu installieren und auszuführen

  • Direkte Verwendung von BigQuery ML über die SQL-Schnittstelle, um das Training offline mit strukturierten Daten auszuführen

Welche ML-Plattform Sie auswählen, hängt von Ihren Anforderungen ab:

  • Verwenden Sie Compute Engine mit VMs auf Abruf, um Kosten zu minimieren
  • Verwenden Sie Cloud ML Engine, wenn Sie eine vollständig verwaltete Umgebung für Training und Deployment benötigen
  • Verwenden Sie Kubeflow für das Erstellen reproduzierbarer, erweiterter ML-Umgebungen, die Sie in jedem Kubernetes-Cluster ausführen können
  • Verwenden Sie BigQuery ML, wenn Sie bei Nutzung von strukturierten Daten Vorhersagen offline erstellen und eine lineare oder logistische Regression implementieren möchten

Vorhersagen

Vorhersagen erfolgen entweder offline oder online mit denselben Produkten, die im Abschnitt "Training und Evaluierung" genannt wurden. Compute Engine, Kubeflow und Cloud ML Engine können jeweils Tensorflow Serving für Vorhersagen anwenden. Die Unterschiede zwischen diesen Optionen sind der operative Aufwand, die Optimierungsoptionen und der Preis.

Wenn niedrige Latenz eine wichtige Anforderung ist, können Sie das serialisierte oder kompilierte Modell auch direkt verwenden, was auch in Datenpipelines hilfreich sein kann. Unter Weitere Informationen finden Sie zusätzliche Links.

Bereitstellen

Das Treffen von Vorhersagen und deren Bereitstellung werden manchmal als ein und derselbe Arbeitsschritt betrachtet, was auf Onlinevorhersagen auch zutrifft. Wenn Sie die Vorhersagen jedoch offline treffen und die Ergebnisse dann in einem Datenspeicher ablegen, müssen Sie sie aus diesem Speicher bereitstellen, sobald sie angefordert werden.

Die Bereitstellung von schnellen Vorhersagen ist ein Kompromiss zwischen Effektivität und Effizienz. Sie können verschiedene Ansätze oder eine Kombination davon verwenden. Wenn Sie Tensorflow Serving für die Vorhersage in Echtzeit verwenden, sollten Sie Beschleuniger wie GPUs oder TPUs in Betracht ziehen und eine der folgenden Methoden verwenden, um Ihr Modell für die Bereitstellung zu optimieren:

Wenn Sie fertige Vorhersagen aus einem schnellen Schlüssel/Wert-Speicher verwenden möchten, müssen Sie Schlüssel basierend auf Permutationen von Merkmalen erstellen. Angenommen, Sie möchten vorhersagen, ob auf Basis des Kontinents und Gerätetyps ein Gebot abgegeben wird oder nicht:

  1. Erstellen Sie alle möglichen Kombinationen von Kontinentnamen und Mobil-/Webtypen.
  2. Speichern Sie das Ergebnis der Vorhersagen für diese Kombinationen.

    Schlüssel Vorhersage
    antarctica_mobile 0
    antarctica_web 1
    asia_mobile 1
    asia_web 0
    europe_mobile 1
    europe_web 0
    northamerica_mobile 1
    northamerica_web 1
    southamerica_mobile 1
    southamerica_web 0
    oceania_mobile 1
    oceania_web 0

    Wenn Sie eine Anfrage erhalten, können Sie dann am richtigen Schlüssel einen schnellen Abruf ausführen. Redis, Aerospike und Cloud Bigtable sind gute Kandidaten für diesen Anwendungsfall.

Achten Sie vor der Implementierung auf Folgendes:

  • Bei einer großen Anzahl von Merkmalen kann die Größe der Kombination die maximal zulässige Größe für einen Schlüssel überschreiten
  • Wenn Sie eine große Anzahl von Anfragen und Schlüsseln unterstützen müssen, sollten Sie die Schlüsselverteilung prüfen und einen Teil des Schlüssels gegebenenfalls hashen, um Hotspots in bestimmten Zeilen zu vermeiden. Cloud Bigtable enthält das Key Visualizer-Tool zur Diagnose solcher Probleme
  • Wenn Sie keine kategorischen Daten für einen solchen kontinuierlichen Wert haben, müssen Sie eine Einteilung in Gruppen vornehmen. Die Bestimmung der Gruppengröße für jedes Merkmal ist eine Aufgabe für sich
  • Verwenden Sie Einbettungen, um die Entfernung zwischen Schlüsseln zu berechnen. Wenn der Schlüssel nicht vorhanden ist, können Sie den nächsten Nachbarn ermitteln. Es sind verschiedene Techniken für das Erstellen eines ortsabhängigen Hashing vorhanden. Das Berechnen dieser Hashes ist eine Aufgabe des maschinellen Lernens

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...