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

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

  • Die Leistung ihrer Flotte überwachen und potenzielle Probleme frühzeitig erkennen
  • Kundenservice durch genaue voraussichtliche Ankunftszeiten und Trackinginformationen verbessern
  • Kosten senken, indem Sie Ineffizienzen identifizieren und beheben
  • Sicherheit durch Überwachung des Fahrerverhaltens und Erkennung potenzieller Gefahren verbessern
  • Fahrerrouten und ‑pläne optimieren, um die Effizienz zu steigern
  • Vorschriften einhalten, indem Sie den Standort von Fahrzeugen und die Arbeitszeiten erfassen

In diesem Dokument wird veranschaulicht, wie Entwickler Signale aus den Mobility Services der Google Maps Platform („Last Mile Fleet Solution“ (LMFS) oder „On-demand Rides and Deliveries Solution“ (ODRD)) in benutzerdefinierte Ereignisse umwandeln können, die sich für Maßnahmen nutzen lassen. Außerdem werden die wichtigsten Konzepte und Designentscheidungen der Fleet Events Reference Solution auf GitHub behandelt.

Dieses Dokument ist relevant für:

Am Ende dieses Dokuments sollten Sie ein grundlegendes Verständnis der wichtigsten Elemente und Überlegungen eines Streamingsystems sowie der Bausteine der Google Maps Platform und Google Cloud haben, aus denen die Referenzlösung für Flottenereignisse besteht.

Übersicht über die Referenzlösung für Flottenereignisse

Die Referenzlösung für Flottenereignisse ist eine Open-Source-Lösung, mit der Mobilitätskunden und ‑partner Schlüsselereignisse auf Basis von Fleet Engine- und Google Cloud-Komponenten generieren können. Derzeit unterstützt die Referenzlösung Kunden, die die Last Mile Fleet Solution verwenden. Die Unterstützung für On-Demand-Fahrten und ‑Lieferungen folgt.

Die Lösung generiert automatisch Ereignisse basierend auf Änderungen an bestimmten Daten, die mit Aufgaben oder Fahrten verknüpft sind. Sie können diese Ereignisse verwenden, um Benachrichtigungen wie die folgenden an Stakeholder zu senden oder andere Aktionen für Ihre Flotte auszulösen.

  • Änderung der voraussichtlichen Ankunftszeit für Aufgabe
  • Relative Änderung der geschätzten Ankunftszeit für die Aufgabe
  • Verbleibende Zeit bis zum Eintreffen der Aufgabe
  • Verbleibende Entfernung bis zum Ziel der Aufgabe
  • Statusänderung von „TaskOutcome“

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

Logische Bausteine

Diagramm : Das folgende Diagramm zeigt die wichtigsten Bausteine der Referenzlösung für Flottenereignisse.

Flottenereignisse – Übersicht und logische Bausteine

Die Referenzlösung enthält die folgenden Komponenten:

  • Ereignisquelle: Hier wird angegeben, woher der ursprüngliche Ereignisstream stammt. Sowohl die Last Mile Fleet Solution als auch die On-demand Rides and Deliveries Solution lassen sich in Cloud Logging einbinden. So können Entwickler Logs von Fleet Engine-RPC-Aufrufen in Ereignisstreams umwandeln. Dies ist die Hauptquelle, die verwendet wird.
  • Verarbeitung: Roh-RPC-Aufruflogs werden in diesem Block, in dem ein Stream von Logereignissen verarbeitet wird, in Statusänderungsereignisse umgewandelt. Um solche Änderungen zu erkennen, benötigt diese Komponente einen Status-Speicher, damit neue eingehende Ereignisse mit vorherigen verglichen werden können. Ereignisse enthalten möglicherweise nicht immer alle relevanten Informationen. In solchen Fällen kann dieser Block dazu führen, dass bei Bedarf Look-up-Aufrufe an Back-Ends erfolgen.
    • Status-Speicher: Einige Verarbeitungsframeworks stellen Zwischendaten von selbst persistent zur Verfügung. Wenn nicht, ist ein K-V-Datenspeicherdienst eine gute Lösung, um den Status selbst zu speichern, da dieser für ein Fahrzeug und einen Ereignistyp eindeutig sein sollte.
  • Senke (benutzerdefinierte Ereignisse): Die erkannte Statusänderung sollte für alle Anwendungen oder Dienste verfügbar gemacht werden, die davon profitieren können. Daher ist es naheliegend, dieses benutzerdefinierte Ereignis in einem Ereignisbereitstellungssystem für die nachgelagerte Nutzung zu veröffentlichen.
  • Downstream-Dienst: Code, der die generierten Ereignisse verarbeitet und für Ihren Anwendungsfall spezifische Aktionen ausführt.

Dienstauswahl

Bei der Implementierung der Referenzlösung für die Fleet Engine-Lösung für Flotte für die letzte Meile oder die On-demand Rides and Deliveries Solution (verfügbar ab Ende des 3. Quartals 2023) ist die Technologieauswahl für „Quelle“ und „Ziel“ unkompliziert. „Verarbeitung“ bietet dagegen eine Vielzahl von Optionen. In der Referenzlösung wurden die folgenden Google-Dienste ausgewählt.

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

Referenz für Fleet Events-Lösungsbausteine

Cloud-Projektlayout

Wir empfehlen, standardmäßig eine Bereitstellung mit mehreren Projekten zu verwenden. So können die Nutzung von Google Maps Platform und Google Cloud sauber getrennt und an Ihre bevorzugte Abrechnungsvereinbarung gebunden werden.

Ereignisquelle

Die Flottenlösung für die letzte Meile und die On-Demand-Fahrten und -Lieferungen schreiben API-Anfrage- und Antwortnutzlasten in Cloud Logging. Cloud Logging kann Logs an einen oder mehrere Dienste Ihrer Wahl senden. Die Weiterleitung an Cloud Pub/Sub ist hier die perfekte Wahl und ermöglicht es, Logs ohne Programmierung in einen Ereignisstream umzuwandeln.

Senke

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

In Bearbeitung

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

  • Cloud Functions als Compute-Plattform für die erste Version (*)
    • Serverlos, mit Skalierungssteuerungen zum Verwalten von Kosten
    • Java als Programmiersprache aufgrund der Verfügbarkeit von Clientbibliotheken für Fleet Engine-bezogene APIs, die die Implementierung erleichtern
  • Cloud Firestore als Zustandsspeicher
    • Serverloser Schlüssel/Wert-Speicher
  • Cloud Pub/Sub als Integrationspunkt mit Upstream- und Downstream-Komponenten
    • Lose gekoppelte Integration nahezu in Echtzeit

Die Funktionen können mit den Standardeinstellungen verwendet oder neu konfiguriert werden. Konfigurationsparameter werden über Bereitstellungsskripts festgelegt und sind in den entsprechenden README-Dateien der Terraform-Module detailliert dokumentiert.

*Hinweis: Für diese Referenzlösung sind alternative Implementierungen geplant, die bei der Erfüllung unterschiedlicher Anforderungen helfen können.

Bereitstellung

Damit die Bereitstellung der Referenzlösung wiederholbar, anpassbar, quellcodekontrollierbar und sicher ist, wird Terraform als Automatisierungstool verwendet. Terraform ist ein weit verbreitetes IaC-Tool (Infrastructure as Code) mit umfassender Unterstützung für Google Cloud.

Terraform-Module

Anstelle eines großen monolithischen Bereitstellungsmoduls für Referenzlösungen werden wiederverwendbare Automatisierungsblöcke als Terraform-Module implementiert, die unabhängig voneinander verwendet werden können. Module bieten eine Vielzahl konfigurierbarer Variablen, von denen die meisten Standardwerte haben. So können Sie schnell loslegen, haben aber auch die Flexibilität, die Variablen an Ihre Anforderungen und Vorlieben anzupassen.

Module in der Referenzlösung:

  • Fleet Engine-Logging-Konfiguration: Automatisieren Sie die Cloud Logging-bezogenen Konfigurationen für die Verwendung mit Fleet Engine. In der Referenzlösung wird sie verwendet, um Fleet Engine-bezogene Logs an ein bestimmtes Pub/Sub-Thema weiterzuleiten.
  • Bereitstellung der Cloud-Funktion für Flottenereignisse: Enthält die Bereitstellung des Beispiel-Funktionscodes und übernimmt auch die Automatisierung der Berechtigungseinstellungen, die für eine sichere projektübergreifende Integration erforderlich sind.
  • Bereitstellung der gesamten Referenzlösung: Ruft die beiden vorherigen Module auf und umschließt die gesamte Lösung.

Sicherheit

IAM wird verwendet, um das Prinzip der geringsten Berechtigung zusammen mit den bewährten Sicherheitsmethoden von Google Cloud wie der Identitätsübernahme von Dienstkonten anzuwenden. In den folgenden Artikeln erfahren Sie mehr darüber, was Google Cloud bietet, um Ihnen mehr Kontrolle über die Sicherheit zu geben.

Nächste Aktionen

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

Anhang

Anforderungen zusammenstellen

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

Erfassen Sie zuerst die Gründe, warum Sie sich für Near-Realtime-Ereignisse interessieren oder diese verwenden müssen. Die folgenden Fragen können Ihnen dabei helfen, 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 generiert wurden? Oder ist eine Datenanreicherung mit integrierten externen Systemen erforderlich? Wenn 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 planen. (z. B. Vergleichen Sie die geschätzte Ankunftszeit (ETA) und die tatsächliche Ankunftszeit (ATA) mit den SLOs für einen Teil der Flotte während der Stoßzeiten, um die Leistung bei Ressourcenbeschränkungen zu berechnen.
  • Warum interessieren Sie sich für ein ereignisbasiertes Modell und nicht für Batch? Geht es um eine geringere Latenz (Time-to-Action) oder um eine lose gekoppelte Integration (Agilität)?
    • Wenn Sie eine niedrige Latenz wünschen, geben Sie „low“ an. Minuten? Sekunden? Unter einer Sekunde? Und welche Latenz?
  • Haben Sie als Team bereits in einen Technologiestack und die entsprechenden Fähigkeiten investiert? Wenn ja, was ist es und welche Integrationspunkte bietet es?
    • Gibt es Anforderungen, die Ihre aktuellen Systeme nicht erfüllen können oder bei denen es Probleme geben könnte, wenn Ereignisse aus Ihrer Flotte verarbeitet werden?

Designprinzipien

Es ist immer hilfreich, einen bestimmten Denkprozess zu verfolgen. So können Sie einheitliche Designentscheidungen treffen, insbesondere wenn Sie aus einer Vielzahl von Optionen auswählen müssen.

  • Einfachere Optionen bevorzugen.
  • Standardmäßig wird eine kürzere Zeit bis zur Wertschöpfung verwendet. Weniger Code, geringere Lernkurve.
  • Bei Latenz und Leistung sollten Sie das von Ihnen festgelegte Ziel erreichen, nicht die maximale Optimierung anstreben. Vermeiden Sie auch extreme Optimierungen, da sie oft zu einer höheren Komplexität führen.
  • Dasselbe gilt für die Kosten. Kosten im Rahmen halten. Möglicherweise sind Sie noch nicht so weit, dass Sie sich für die Nutzung hochwertiger, aber relativ teurer Dienste entscheiden können.
  • In der Testphase kann das Herunterskalieren genauso wichtig sein wie das Hochskalieren. Wählen Sie eine Plattform, die Ihnen die Flexibilität bietet, die Kapazität zu erhöhen und auch zu verringern (idealerweise auf null), damit Sie keine Kosten haben, wenn Sie nichts tun. Eine leistungsstarke Always-on-Infrastruktur kann später in Betracht gezogen werden, wenn Sie sich sicher sind, dass Sie sie benötigen.
  • Beobachten und messen Sie, damit Sie später feststellen können, wo Sie weiterarbeiten müssen.
  • Dienste lose gekoppelt lassen So lassen sich die einzelnen Teile später leichter austauschen.
  • Zu guter Letzt: Sicherheit darf nicht nachlässig sein. Da es sich um einen Dienst handelt, der in einer öffentlichen Cloud-Umgebung ausgeführt wird, darf es keine ungesicherten Zugänge zum System geben.

Streamingkonzepte

Wenn Sie noch nicht so viel Erfahrung mit ereignisbasierten oder Streaming-Daten haben, sollten Sie sich mit einigen wichtigen Konzepten vertraut machen, die sich zum Teil stark von der Batchverarbeitung unterscheiden.

  • Skalierung : Im Gegensatz zur Batchverarbeitung, bei der Sie in der Regel eine gute Vorstellung davon haben, wie viele Daten verarbeitet werden müssen, ist dies beim Streaming nicht der Fall. Ein Stau in einer Stadt kann plötzlich viele Ereignisse in einem bestimmten Gebiet auslösen, die Sie trotzdem verarbeiten müssen.
  • Fensterung : Anstatt Ereignisse einzeln zu verarbeiten, möchten Sie sie oft über einen Zeitraum hinweg in kleinere „Fenster“ als Recheneinheit gruppieren. Es gibt verschiedene Windowing-Strategien wie „feste Zeitfenster (z. B. jeder Kalendertag)“, „gleitende Zeitfenster (letzte 5 Minuten)“ und „Sitzungszeitfenster (während dieser Fahrt)“, aus denen Sie auswählen können. Je länger der Zeitraum, desto länger dauert es, bis Ergebnisse generiert werden. Wählen Sie das richtige Modell und die richtige Konfiguration aus, die Ihren Anforderungen entsprechen.
  • Auslöser : In einigen Fällen haben Sie keine andere Wahl, als relativ lange Zeiträume zu verwenden. Sie möchten jedoch nicht bis zum Ende des Fensters warten, um Ereignisse zu generieren, sondern Zwischenergebnisse ausgeben. Dieses Konzept kann für Anwendungsfälle implementiert werden, in denen es sinnvoll ist, zuerst schnelle Ergebnisse zurückzugeben und sie dann später zu korrigieren. Stellen Sie sich vor, Sie geben den Zwischenstatus bei 25%, 50 % und 75% der Auslieferung aus.
  • Reihenfolge : Ereignisse erreichen das System nicht unbedingt in der Reihenfolge, in der sie generiert wurden. Dies 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 der „Ereigniszeit“ verarbeiten.
  • Nachrichtenzustellung – „Mindestens einmal“ im Vergleich zu „Genau einmal“: Verschiedene Eventplattformen bieten unterschiedliche Unterstützung für diese Optionen. Je nach Anwendungsfall müssen Sie Strategien für Wiederholungsversuche oder die Deduplizierung in Betracht ziehen.
  • Vollständigkeit : Wie bei der Änderung der Reihenfolge von Nachrichten besteht die Möglichkeit, dass Nachrichten verloren gehen. Das kann daran liegen, dass die Anwendung und das Gerät aufgrund des Akkustands des Geräts heruntergefahren wurden, das Smartphone versehentlich beschädigt wurde, die Verbindung in einem Tunnel unterbrochen wurde oder eine Nachricht empfangen wurde, aber erst außerhalb eines akzeptablen Zeitfensters. Wie würde sich Unvollständigkeit auf Ihre Ergebnisse auswirken?

Dies ist keine vollständige Liste, sondern nur eine Einführung. Hier sind einige sehr empfehlenswerte Artikel, die dir helfen können, die einzelnen Themen besser zu verstehen.

Beitragende

Dieses Dokument wird von Google verwaltet. Die folgenden Mitwirkenden haben den Artikel ursprünglich geschrieben.

Hauptautoren: