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

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

  • Leistung ihrer Flotte im Blick behalten und potenzielle Probleme frühzeitig erkennen
  • Kundenservice verbessern, indem sie genaue voraussichtliche Ankunftszeiten und Trackinginformationen bereitstellen
  • Kosten senken, indem sie Ineffizienzen erkennen und beheben
  • Sicherheit verbessern, indem sie das Fahrerverhalten beobachten und potenzielle Gefahren erkennen
  • Fahrerrouten und ‑zeitpläne optimieren, um die Effizienz zu steigern
  • Vorschriften einhalten, indem sie den Standort des Fahrzeugs und die Arbeitszeiten erfassen

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

Dieses Dokument ist relevant für:

  • Architekten, die mit den Mobilitätsdiensten der Google Maps Platform und einer ihrer Kernkomponenten, der Fleet Engine, vertraut sind. Wenn Sie die Mobilitätsdienste noch nicht kennen, empfehlen wir Ihnen, sich je nach Bedarf mit der Last Mile Fleet Solution und/oder der On-demand Rides and Deliveries Solution, vertraut zu machen.
  • Architekten, die mit Google Cloud vertraut sind. Wenn Sie Google Cloud noch nicht kennen, empfehlen wir Ihnen, den Artikel Streamingdaten-Pipelines in Google Cloud erstellen zu lesen.
  • Wenn Sie andere Umgebungen oder Softwarestacks verwenden, sollten Sie sich auf die Integrationspunkte und wichtigsten Überlegungen der Fleet Engine konzentrieren, die weiterhin gelten sollten.
  • Alle, die sich dafür interessieren, wie Ereignisse aus Flotten generiert und genutzt werden können.

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 wichtige Ereignisse 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 Rides and Deliveries 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 die Aufgabe
  • Relative Änderung der voraussichtlichen Ankunftszeit für die Aufgabe
  • Verbleibende Zeit bis zur Ankunft bei der Aufgabe
  • Verbleibende Entfernung bis zur Ankunft bei der Aufgabe
  • Statusänderung von TaskOutcome

Jede Komponente der Referenzlösung kann an Ihre geschäftlichen Anforderungen angepasst werden.

Logische Bausteine

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

Flottenereignisse – Übersicht und logische Bausteine

Die Referenzlösung enthält die folgenden Komponenten:

  • Ereignisquelle: Hier stammt der ursprüngliche Ereignisstream. Sowohl "Last Mile Fleet Solution" als auch "On-demand Rides and Deliveries Solution" sind in Cloud Logging eingebunden, wodurch Logs von Fleet Engine-RPC-Aufrufen in Ereignisstreams umgewandelt werden, die Entwicklern zur Verfügung stehen. Dies ist die Hauptquelle für die Nutzung.
  • Verarbeitung: Rohlogs von RPC-Aufrufen werden in Ereignisse für Statusänderungen umgewandelt in diesem Block, der über einen Stream von Logereignissen berechnet wird. Um solche Änderungen zu erkennen, benötigt diese Komponente einen Statusspeicher, 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 bei Bedarf Aufrufe an Back-Ends senden.
    • Statusspeicher: Einige Verarbeitungsframeworks stellen eigene persistente Zwischendaten bereit. Wenn dies nicht der Fall ist, ist ein Dienst zur Datenpersistenz vom Typ „Schlüssel/Wert“ eine gute Wahl, um den Status selbst zu speichern, da dieser für ein Fahrzeug und einen Ereignistyp eindeutig sein sollte.
  • Senke (benutzerdefinierte Ereignisse): Erkannte Statusänderungen sollten für alle Anwendungen oder Dienste verfügbar sein, die davon profitieren können. Daher ist es eine naheliegende Wahl, dieses benutzerdefinierte Ereignis in einem System zur Ereignisübermittlung für die nachgelagerte Nutzung zu veröffentlichen.
  • Nachgelagerter 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 „Last Mile Fleet Solution“ oder „On-demand Rides and Deliveries Solution“ (verfügbar ab Ende des dritten Quartals 2023) ist die Auswahl der Technologie für „Quelle“ und „Senke“ unkompliziert. Für die „Verarbeitung“ gibt es jedoch 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 der Google Maps Platform und Google Cloud sauber getrennt und mit der Abrechnungsvereinbarung Ihrer Wahl verknüpft werden.

Ereignisquelle

"Last Mile Fleet Solution" und "On-demand Rides and Deliveries Solution" schreiben API-Anfrage- und ‑Antwortnutzlasten in Cloud Logging. Cloud Logging liefert Logs an einen oder mehrere ausgewählte Dienste. Die Weiterleitung an Cloud Pub/Sub ist hier eine 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 nahezu in Echtzeit. So wie die Ereignisse aus der Quelle an Pub/Sub gesendet wurden, werden auch benutzerdefinierte Ereignisse zur nachgelagerten Nutzung in Pub/Sub veröffentlicht.

Verarbeitung

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

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 unterschiedliche Anforderungen erfüllen können.

Bereitstellung

Um den Bereitstellungsprozess der Referenzlösung wiederholbar, anpassbar, quellcodekontrollierbar und sicher zu gestalten, wurde 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 Vielzahl konfigurierbarer Variablen, von denen die meisten Standardwerte haben, sodass Sie schnell loslegen können, aber auch die Flexibilität haben, sie an Ihre Anforderungen und Vorlieben anzupassen.

In der Referenzlösung enthaltene Module:

  • Fleet Engine-Logging-Konfiguration: Automatisieren Sie die Cloud Logging-bezogenen Konfigurationen für die Verwendung mit der 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 Beispielfunktions codes und automatisiert auch die Berechtigungseinstellungen, die für die sichere projektübergreifende Integration erforderlich sind.
  • Bereitstellung der gesamten Referenzlösung: Ruft die beiden vorherigen Module auf und umfasst die gesamte Lösung.

Sicherheit

IAM wird verwendet, um die Prinzipien der geringsten Berechtigung sowie die Best Practices für die Sicherheit von Google Cloud wie die Identitätswechsel 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 Schritte

Sie können jetzt auf die Referenzlösung für Flottenereignisse zugreifen und sie weiter erkunden. Gehen Sie zu GitHub um loszulegen.

Anhang

Anforderungen erfassen

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

Erfassen Sie zuerst die Details dazu, warum Sie sich für Ereignisse nahezu in Echtzeit interessieren oder diese verwenden müssen. Hier sind einige Fragen, die Ihnen 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 erstellt 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?
    • Wenn Sie Messwerte für Ereignisse berechnen müssen, welche Art von Aggregation ist dafür erforderlich? Versuchen Sie, die logischen Schritte zu planen. Beispiel: Vergleichen Sie die voraussichtliche und tatsächliche Ankunftszeit mit den SLAs für einen Teil der Flotte während der Hauptverkehrszeiten, um die Leistung unter Ressourcenbeschränkungen zu berechnen.
  • Warum interessieren Sie sich für ein ereignisbasiertes Modell anstelle von Batch? Geht es um eine geringere Latenz (Zeit bis zur Aktion) oder um eine lose gekoppelte Integration (Agilität)?
    • Wenn es um eine geringe Latenz geht, definieren Sie „gering“. Minuten? Sekunden? Weniger als eine Sekunde? Und welche Latenz?
  • Haben Sie als Team bereits in einen Technologiestack und entsprechende Fähigkeiten investiert? Wenn ja, welcher Stack ist das und welche Integrationspunkte bietet er?
    • Gibt es Anforderungen, die Ihre aktuellen Systeme nicht erfüllen können oder mit denen sie bei der Verarbeitung von Ereignissen aus Ihrer Flotte Schwierigkeiten haben könnten?

Designprinzipien

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

  • Verwenden Sie standardmäßig einfachere Optionen.
  • Verwenden Sie standardmäßig eine kürzere Zeit bis zur Wertschöpfung. Weniger Code, geringere Lernkurve.
  • Bei Latenz und Leistung sollten Sie versuchen, die von Ihnen festgelegte Messlatte zu erreichen, nicht die maximale Optimierung. Vermeiden Sie auch extreme Optimierungen, da sie oft zu mehr Komplexität führen.
  • Gleiches gilt für die Kosten. Halten Sie die Kosten angemessen. Möglicherweise sind Sie noch nicht so weit, dass Sie sich für hochwertige, aber relativ teurere Dienste entscheiden können.
  • In der Testphase kann das Herunterskalieren genauso wichtig sein wie das Hochskalieren. Verwenden Sie eine Plattform, die Flexibilität beim Hochskalieren mit einer Obergrenze und auch beim Herunterskalieren (idealerweise auf null) bietet, damit Sie keine Kosten verursachen, 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 sie benötigen.
  • Beobachten und messen Sie, damit Sie später feststellen können, wo Sie weiterarbeiten müssen.
  • Halten Sie die Dienste lose gekoppelt. So können Sie sie später einfacher einzeln austauschen.
  • Zu guter Letzt: Die Sicherheit darf nicht vernachlässigt werden. 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 viel Erfahrung mit ereignisbasierten Systemen oder Streaming haben, sollten Sie sich mit einigen wichtigen Konzepten vertraut machen, die sich von der Batchverarbeitung unterscheiden können.

  • Skalierung : Im Gegensatz zur Batchverarbeitung, bei der Sie in der Regel eine gute Vorstellung von der zu verarbeitenden Datenmenge haben, ist das beim Streaming nicht der Fall. Ein Stau in einer Stadt kann plötzlich viele Ereignisse aus dem jeweiligen Gebiet generieren, die Sie trotzdem verarbeiten müssen.
  • Fensterung : Anstatt Ereignisse einzeln zu verarbeiten, möchten Sie sie oft über einen Zeitraum in kleinere „Fenster“ als Einheit für die Berechnung gruppieren. Es gibt verschiedene Fensterungsstrategien wie „feste Fenster“ (z. B. jeder Kalendertag), „gleitende Fenster“ (letzte 5 Minuten) und „Sitzungsfenster“ (während dieser Fahrt), aus denen Sie auswählen können. Je länger das Fenster ist, desto länger dauert es, bis Ergebnisse vorliegen. Wählen Sie das richtige Modell und die richtige Konfiguration für Ihre Anforderungen aus.
  • Auslösen : In einigen Fällen haben Sie keine andere Wahl, als relativ lange Fenster zu verwenden. Sie möchten aber nicht bis zum Ende des Fensters warten, um Ereignisse zu generieren, sondern stattdessen Zwischenergebnisse ausgeben. Dieses Konzept kann für Anwendungsfälle implementiert werden, bei 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 Lieferung aus.
  • Reihenfolge : 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 der „Ereigniszeit“ (Zeitpunkt, zu dem das Ereignis tatsächlich stattgefunden hat) und der „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.
  • Nachrichtenübermittlung – mindestens einmal vs. genau einmal: Verschiedene Ereignis plattformen bieten unterschiedliche Unterstützung für diese Optionen. Je nach Anwendungsfall müssen Sie Strategien für Wiederholungen oder Deduplizierung in Betracht ziehen.
  • Vollständigkeit : Wie bei der Änderung der Reihenfolge können auch Nachrichten verloren gehen. Das kann an der Akkulaufzeit des Geräts, unbeabsichtigten Schäden am Smartphone, Verbindungsverlusten 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 nur eine Einführung. Wir empfehlen Ihnen, die folgenden Artikel zu lesen, um Ihr Verständnis der einzelnen Konzepte zu vertiefen.

Beitragende

Dieses Dokument wird von Google verwaltet. Die folgenden Personen haben es ursprünglich verfasst.

Hauptautoren: