Ereignisse in Echtzeit mit Fleet Engine und der Referenzlösung für Flottenereignisse generieren

Signale in nahezu Echtzeit von der Flotte, die vor Ort eingesetzt wird, sind für Unternehmen in vielerlei Hinsicht nützlich. Unternehmen können sie beispielsweise für Folgendes verwenden:

  • die Leistung ihrer Flotte im Blick behalten und potenzielle Probleme frühzeitig erkennen
  • Kundenservice verbessern, indem Sie genaue geschätzte Lieferzeiten und Informationen zur Sendungsverfolgung angeben
  • Kosten senken, indem Ineffizienzen identifiziert und behoben werden
  • Sicherheit verbessern, indem das Fahrerverhalten beobachtet und potenzielle Gefahren erkannt werden
  • Fahrerrouten und -pläne optimieren, um die Effizienz zu steigern
  • Einhaltung der Vorschriften durch Standort- und Öffnungszeiten des Fahrzeugs

In diesem Dokument wird veranschaulicht, wie Entwickler Signale aus den Mobilitätsdiensten der Google Maps Platform (Last Mile Fleet Solution (LMFS) oder On-Demand Rides and Deliveries Solution (ODRD)) in umsetzbare benutzerdefinierte Ereignisse umwandeln können. Außerdem werden die wichtigsten Konzepte und Designentscheidungen der Referenzlösung für Fahrzeugereignisse auf GitHub behandelt.

Dieses Dokument ist relevant für:

  • Architekten, die mit den Mobilitätsdiensten der Google Maps Platform und einer ihrer Hauptkomponenten, der „Fleet Engine“, vertraut sind. Wenn Sie neu in der Branche für Mobilitätsdienste sind, empfehlen wir Ihnen, sich je nach Bedarf mit der Lösung für die Flotte für die letzte Meile und/oder der Lösung für Fahrten und Lieferungen auf Abruf vertraut zu machen.
  • Architekten, die mit Google Cloud vertraut sind Wenn Sie neu bei Google Cloud sind, sollten Sie sich vorab den Artikel Streaming-Datenpipelines in Google Cloud erstellen durchlesen.
  • Wenn Sie andere Umgebungen oder Softwarestacks verwenden, konzentrieren Sie sich auf die Integrationspunkte und wichtigen Aspekte der Fleet Engine, die weiterhin gelten sollten.
  • Nutzer, die sich allgemein dafür interessieren, wie Ereignisse von Flotten generiert und genutzt werden können.

Am Ende dieses Dokuments sollten Sie grundlegende Kenntnisse über die wichtigsten Elemente und Aspekte eines Streamingsystems sowie über die Bausteine der Google Maps Platform und Google Cloud haben, aus denen die Referenzlösung für Fahrzeugereignisse besteht.

Lösungsübersicht für die Referenz für Flotenereignisse

Die Referenzlösung für Fleet-Ereignisse ist eine Open-Source-Lösung, mit der Mobilitätskunden und ‑partner wichtige Ereignisse auf der Grundlage der Fleet Engine und Google Cloud-Komponenten generieren können. Derzeit unterstützt die Referenzlösung Kunden, die die Lösung „Last Mile Fleet“ verwenden. Unterstützung für On-Demand-Fahrten und -Lieferungen wird folgen.

Die Lösung generiert automatisch Ereignisse basierend auf Änderungen an bestimmten Daten, die mit Aufgaben oder Fahrten verknüpft sind. Mit diesen Ereignissen können Sie Stakeholdern Benachrichtigungen wie die folgenden senden oder andere Aktionen für Ihre Flotte auslösen.

  • Änderung der geschätzten Ankunftszeit für eine Aufgabe
  • Relative Änderung der geschätzten Ankunftszeit für eine Aufgabe
  • Verbleibende Zeit bis zur Aufgabe
  • Verbleibende Entfernung bis zur Ankunft der Aufgabe
  • Statusänderung für den TaskOutcome

Jede Komponente der Referenzlösung kann an die Anforderungen Ihres Unternehmens angepasst werden.

Logische Bausteine

Diagramm : Das folgende Diagramm zeigt die allgemeinen Bausteine, aus denen die Referenzlösung für Fahrzeugereignisse besteht.

Übersicht über Flotereignisse und logische Bausteine

Die Referenzlösung enthält die folgenden Komponenten:

  • Ereignisquelle: Hier sehen Sie, woher der ursprüngliche Ereignisstream stammt. Sowohl die Last Mile Fleet-Lösung als auch die On-Demand-Fahrdienst- und Lieferlösung sind in Cloud Logging eingebunden. So lassen sich Fleet Engine-RPC-Aufrufprotokolle in Ereignisstreams umwandeln, die für Entwickler verfügbar sind. Dies ist die Hauptquelle, die verwendet werden soll.
  • Verarbeitung: Rohe RPC-Anrufprotokolle werden in diesem Block in Statusänderungsereignisse umgewandelt, die über einen Stream von Protokollereignissen berechnet werden. Um solche Änderungen zu erkennen, benötigt diese Komponente einen Statusspeicher, damit neue eingehende Ereignisse mit früheren verglichen werden können. Ereignisse enthalten möglicherweise nicht immer alle relevanten Informationen. In solchen Fällen kann dieser Block bei Bedarf Suchanfragen an Backends stellen.
    • Statusspeicher: Einige Verarbeitungsframeworks stellen Zwischendaten zur Verfügung, die von sich aus persistent sind. Wenn nicht, eignet sich ein Dienst zur Datenspeicherung vom Typ „Schlüssel/Wert“, um den Status selbst zu speichern, da dieser für ein Fahrzeug und einen Ereignistyp eindeutig sein sollte.
  • Senke (benutzerdefinierte Ereignisse): Der erkannte Statuswechsel sollte allen Anwendungen oder Diensten zur Verfügung gestellt werden, die davon profitieren können. Daher ist es sinnvoll, dieses benutzerdefinierte Ereignis in einem Ereignisübermittlungssystem für die nachgelagerte Nutzung zu veröffentlichen.
  • Downstream-Dienst: Code, der die generierten Ereignisse nutzt und Aktionen ausführt, die für Ihren Anwendungsfall spezifisch sind.

Dienstauswahl

Bei der Implementierung der Referenzlösung für die Lösung für die Flotte für die letzte Meile oder die Lösung für Fahrten und Lieferungen auf Abruf (veröffentlicht Ende Q3 2023) ist die Technologieauswahl für „Source“ und „Sink“ recht einfach. „Verarbeitung“ bietet dagegen eine breite Palette von Optionen. Für die Referenzlösung wurden die folgenden Google-Dienste ausgewählt.

Diagramm : Das folgende Diagramm zeigt den Google Cloud-Dienst zur Implementierung der Referenzlösung.

Referenzlösung für Fleet Events – Bausteine

Cloud-Projektlayout

Wir empfehlen, standardmäßig eine Bereitstellung mit mehreren Projekten zu verwenden. So können die Nutzung der Google Maps Platform und die Nutzung von Google Cloud klar voneinander getrennt und an die von Ihnen gewählte Abrechnungsvereinbarung gebunden werden.

Ereignisquelle

Die Flottenlösung für die letzte Meile und die On-Demand-Fahrten- und -Lieferlösung schreiben API-Anfrage- und Antwortnutzlasten in Cloud Logging. Cloud Logging sendet Logs an einen oder mehrere ausgewählte Dienste. Das Weiterleiten an Cloud Pub/Sub ist hier die perfekte Wahl und ermöglicht es, Protokolle ohne Programmieren in einen Ereignisstream umzuwandeln.

Spülbecken

In Google Cloud ist Cloud Pub/Sub das bevorzugte System für die Nachrichtenübermittlung in nahezu Echtzeit. Genau wie die Ereignisse aus der Quelle an Pub/Sub gesendet wurden, werden benutzerdefinierte Ereignisse auch für die Downstream-Nutzung in Pub/Sub veröffentlicht.

In Bearbeitung

Die folgenden Komponenten spielen eine Rolle bei der Ereignisverarbeitung. Wie die anderen Blöcke sind auch die Verarbeitungskomponenten vollständig serverlos und lassen sich sowohl nach oben als auch nach unten skalieren.

  • Cloud Functions als Compute-Plattform für die Erstveröffentlichung (*)
    • Serverlos, mit Skalierungssteuerungen nach oben und unten skaliert, um die Kosten zu verwalten
    • Java als Programmiersprache, da es Clientbibliotheken für Fleet Engine-bezogene APIs gibt, die die Implementierung erleichtern
  • Cloud Firestore als Speicher für den Status
    • Serverloser Schlüssel/Wert-Speicher
  • Cloud Pub/Sub als Integrationspunkt mit vorgelagerten und nachgelagerten Komponenten
    • Locker gekoppelte Echtzeitnahe Integration

Die Funktionen können mit den Standardeinstellungen verwendet, aber auch neu konfiguriert werden. Konfigurationsparameter werden über Bereitstellungsscripts festgelegt und in den entsprechenden Terraform-Modul-READMEs ausführlich dokumentiert.

*Hinweis: Für diese Referenzlösung sind alternative Implementierungen geplant, die zur Erfüllung verschiedener Anforderungen beitragen können.

Bereitstellung

Um den Bereitstellungsprozess der Referenzlösung wiederholbar, anpassbar, steuerbar und sicher zu machen, wird Terraform als Automatisierungstool ausgewählt. Terraform ist ein weit verbreitetes IaC-Tool (Infrastructure as Code) mit umfassender Unterstützung für Google Cloud.

Terraform-Module

Anstatt ein großes monolithisches Bereitstellungsmodul für die Referenzlösung zu erstellen, werden wiederverwendbare Automatisierungsblöcke als Terraform-Module implementiert, die unabhängig voneinander verwendet werden können. Module bieten eine breite Palette an konfigurierbaren Variablen, die meisten davon haben Standardwerte, damit Sie schnell loslegen können. Sie haben aber auch die Möglichkeit, sie an Ihre Anforderungen und Vorlieben anzupassen.

In der Referenzlösung enthaltene Module:

  • Fleet Engine-Logging-Konfiguration: Automatisieren Sie die Cloud Logging-Konfigurationen für die Verwendung mit der Fleet Engine. In der Referenzlösung wird es verwendet, um Fleet Engine-bezogene Protokolle an ein bestimmtes Pub/Sub-Thema weiterzuleiten.
  • Bereitstellung der Cloud-Funktion für Fleet Events: Enthält die Bereitstellung des Beispielfunktionscodes und übernimmt auch die Automatisierung der Berechtigungseinstellungen, die für eine sichere projektübergreifende Integration erforderlich sind.
  • Ganze Bereitstellung der Referenzlösung: Hier werden die beiden vorherigen Module aufgerufen und die gesamte Lösung umhüllt.

Sicherheit

IAM wird verwendet, um das Prinzip der geringsten Berechtigung zusammen mit den Sicherheitsbest Practices von Google Cloud wie der Dienstkonto-Identitätsdiebstahl anzuwenden. In den folgenden Artikeln erfahren Sie, wie Sie mit Google Cloud die Sicherheit besser im Griff haben.

Nächste Schritte

Sie können jetzt auf die Referenzlösung für Flottenereignisse zugreifen und sie genauer untersuchen. Rufe GitHub auf, um loszulegen.

Anhang

Anforderungen zusammenstellen

Wir empfehlen, die Anforderungen bereits früher im Prozess zu erfassen.

Geben Sie zuerst an, warum Sie an Ereignissen in nahezu Echtzeit interessiert sind oder diese verwenden müssen. Hier sind einige Fragen, die Ihnen helfen können, Ihre Anforderungen zu konkretisieren.

  • Welche Informationen sind erforderlich, damit ein Ereignisstream nützlich ist?
    • Kann das Ergebnis ausschließlich aus Daten abgeleitet werden, die in den Google-Diensten erfasst oder erstellt wurden? Oder ist eine Datenanreicherung mit integrierten externen Systemen erforderlich? Falls ja, welche Systeme sind das und welche Integrationsschnittstellen bieten sie?
    • Welche Messwerte möchten Sie als Unternehmen erfassen? Wie werden sie definiert?
    • Welche Art der Aggregation ist erforderlich, wenn Sie Messwerte für mehrere Ereignisse berechnen möchten? Versuchen Sie, die logischen Schritte zu skizzieren. (z. B. Vergleichen Sie die geschätzte Ankunfts-/Abfahrtszeit mit den SLOs für einen Teil der Flotte während der Stoßzeiten, um die Leistung bei Ressourceneinschränkungen zu berechnen.)
  • Warum sind Sie an einem ereignisbasierten Modell interessiert und nicht an einem Batch-Modell? Geht es um eine geringere Latenz (Time-to-Action) oder um eine lockere Verknüpfung (Agilität)?
    • Wenn Sie eine niedrige Latenz benötigen, geben Sie „low“ an. Minuten? Sekunden? Unter einer Sekunde? Und wie hoch ist die Latenz?
  • Haben Sie als Team bereits in einen Technologie-Stack und zugehörige Kompetenzen investiert? Wenn ja, was ist das und welche Integrationspunkte bietet es?
    • Gibt es Anforderungen, die Ihre aktuellen Systeme nicht erfüllen können oder bei denen Probleme bei der Verarbeitung von Ereignissen aus Ihrer Flotte auftreten können?

Designprinzipien

Es ist immer hilfreich, einen bestimmten Denkprozess zu verfolgen. So können Sie einheitliche Designentscheidungen treffen, insbesondere wenn Sie eine Vielzahl von Optionen zur Auswahl haben.

  • Einfachere Optionen als Standard festlegen
  • Standardmäßig wird eine kürzere Zeit bis zur Wertschöpfung festgelegt. Weniger Code, geringere Lernkurve.
  • Achten Sie bei Latenz und Leistung darauf, den von Ihnen festgelegten Wert zu erreichen, nicht die maximale Optimierung. Vermeiden Sie auch extreme Optimierungen, da dies oft zu mehr Komplexität führt.
  • Dasselbe gilt für die Kosten. Die Kosten sollten angemessen sein. Möglicherweise sind Sie noch nicht so weit, dass Sie sich zu hochwertigen, aber relativ teuren Dienstleistungen verpflichten können.
  • In der Testphase kann das Herunterskalieren genauso wichtig sein wie das Heraufskalieren. Wählen Sie eine Plattform, die eine flexible Skalierung mit Obergrenze und auch eine Skalierung nach unten (idealerweise auf null) ermöglicht, damit Sie keine Kosten haben, wenn Sie nichts tun. Eine hohe Leistung mit einer Always-On-Infrastruktur kann später in Betracht gezogen werden, wenn Sie sich sicher sind, dass sie erforderlich ist.
  • Beobachten und messen Sie, damit Sie später feststellen können, wo Sie noch weiterarbeiten müssen.
  • Die Dienste sollten locker gekoppelt sein. So lässt sich später leichter Stück für Stück austauschen.
  • Zu guter Letzt darf die Sicherheit nicht vernachlässigt werden. Da der Dienst in einer öffentlichen Cloud-Umgebung ausgeführt wird, dürfen keine ungesicherten Zugriffsmöglichkeiten auf das System vorhanden sein.

Streamingkonzepte

Wenn Sie noch nicht so lange mit ereignisbasierten oder Streaming-Daten arbeiten, sollten Sie sich mit einigen wichtigen Konzepten vertraut machen. Einige davon können sich stark von der Batchverarbeitung unterscheiden.

  • Skalierung : Im Gegensatz zur Batchverarbeitung, bei der Sie in der Regel eine gute Vorstellung von der zu verarbeitenden Datenmenge haben, ist dies beim Streaming nicht der Fall. Ein Stau in einer Stadt kann plötzlich viele Ereignisse in diesem Bereich verursachen, die Sie trotzdem verarbeiten müssen.
  • Fensterung : Anstatt Ereignisse einzeln zu verarbeiten, ist es oft sinnvoll, Ereignisse über eine Zeitachse in kleinere „Fenster“ als Berechnungseinheit zu gruppieren. Es gibt verschiedene Zeitfensterstrategien, z. B. „feste Zeitfenster (z. B. jeder Kalendertag)“, „gleitende Zeitfenster (letzte 5 Minuten)“ und „Sitzungszeitfenster (während dieser Sitzung)“. Je länger der Zeitraum, desto länger dauert es, bis Ergebnisse erzielt werden. Wählen Sie das richtige Modell und die richtige Konfiguration aus, die Ihren Anforderungen entspricht.
  • Trigger : In einigen Fällen haben Sie keine andere Wahl, als relativ längere Zeiträume zu verwenden. Sie sollten jedoch nicht bis zum Ende des Zeitraums warten, um Ereignisse zu generieren, sondern stattdessen Zwischenergebnisse senden. Dieses Konzept kann für Anwendungsfälle implementiert werden, in denen es sinnvoll ist, zuerst schnelle Ergebnisse zurückzugeben und sie später zu korrigieren. Angenommen, Sie senden bei 25%, 50 % und 75% der Übermittlung einen Zwischenstatus.
  • Sortierung : Ereignisse erreichen das System nicht unbedingt in der Reihenfolge, in der sie generiert wurden. Das gilt insbesondere für Anwendungsfälle, bei denen die Kommunikation über Mobilfunknetze erfolgt, was zu Verzögerungen und komplexen Routingpfaden führt. Sie müssen den Unterschied zwischen „Ereigniszeit“ (Zeitpunkt, zu dem das Ereignis tatsächlich stattgefunden hat) und „Verarbeitungszeit“ (Zeitpunkt, zu dem das Ereignis das System erreicht hat) kennen und Ereignisse entsprechend verarbeiten. Im Allgemeinen sollten Sie Ereignisse basierend auf „event_time“ verarbeiten.
  • Nachrichtenübermittlung – mindestens einmal oder genau einmal: Für verschiedene Ereignisplattformen gibt es unterschiedliche Unterstützung. Je nach Anwendungsfall müssen Sie Strategien für Wiederholungen oder Deduplizierung berücksichtigen.
  • Vollständigkeit : Wie bei der Änderung der Reihenfolge besteht die Gefahr, dass Nachrichten verloren gehen. Das kann an einem Herunterfahren der App und des Geräts aufgrund der Akkulaufzeit des Geräts, einer unbeabsichtigten Beschädigung des Smartphones, einem Verbindungsverlust in einem Tunnel oder einer Nachricht liegen, die zwar empfangen wurde, aber außerhalb eines akzeptablen Zeitfensters. Wie würde sich Unvollständigkeit auf Ihre Ergebnisse auswirken?

Dies ist keine vollständige Liste, sondern eine Einführung. Hier sind einige empfehlenswerte Lesematerialien, mit denen Sie Ihr Wissen vertiefen können.

Beitragende

Dieses Dokument wird von Google gepflegt. Die folgenden Mitwirkenden haben den Artikel ursprünglich verfasst.

Hauptautoren: