Generowanie zdarzeń w czasie zbliżonym do rzeczywistego za pomocą Fleet Engine i rozwiązania referencyjnego zdarzeń floty

Sygnały w czasie zbliżonym do rzeczywistego z floty działającej na ziemi są przydatne dla firm na wiele sposobów. Firmy mogą ich używać na przykład do:

  • monitorować wydajność floty i wcześnie wykrywać potencjalne problemy;
  • Popraw obsługę klienta, podając dokładne szacowane czasy dostawy i informacje o śledzeniu
  • Ograniczanie kosztów przez wykrywanie i eliminowanie nieefektywności
  • Zwiększaj bezpieczeństwo, monitorując zachowania kierowców i wykrywając potencjalne zagrożenia
  • Optymalizowanie tras i harmonogramów kierowców w celu zwiększenia wydajności
  • Zgodność z przepisami dzięki śledzeniu lokalizacji pojazdu i godzin pracy

Z tego dokumentu dowiesz się, jak deweloperzy mogą przekształcać sygnały z „usług mobilnych” Google Maps Platform („rozwiązanie do zarządzania flotą pojazdów dostawczych na ostatnim etapie dostawy” (LMFS) lub „rozwiązanie do zarządzania przejazdami i dostawami na żądanie” (ODRD)) w zdarzenia niestandardowe, które można wykorzystać w praktyce. Omówione są też kluczowe koncepcje i decyzje projektowe dotyczące rozwiązania Fleet Events Reference dostępnego w GitHubie.

Ten dokument dotyczy:

Po przeczytaniu tego dokumentu będziesz mieć podstawową wiedzę o kluczowych elementach i aspektach systemu przesyłania strumieniowego oraz o elementach składowych rozwiązania referencyjnego Fleet Events, które pochodzą z Google Maps Platform i Google Cloud.

Omówienie rozwiązania Fleet Events Reference

Rozwiązanie referencyjne Fleet Events to rozwiązanie typu open source, które umożliwia klientom i partnerom Mobility generowanie kluczowych zdarzeń na podstawie komponentów Fleet Engine i Google Cloud. Obecnie rozwiązanie referencyjne obsługuje klientów korzystających z rozwiązania ostatniej mili Fleet Engine, a wkrótce będzie obsługiwać też przejazdy i dostawy na żądanie.

Rozwiązanie automatycznie generuje zdarzenia na podstawie zmian określonych danych powiązanych z zadaniami lub podróżami. Możesz używać tych zdarzeń do wysyłania powiadomień, np. takich jak poniższe, do zainteresowanych osób lub do wywoływania innych działań dotyczących Twojej floty.

  • Zmiana szacowanego czasu dotarcia do miejsca wykonania zadania
  • Względna zmiana szacowanego czasu dotarcia do miejsca docelowego zadania
  • Czas pozostały do pojawienia się zadania
  • Odległość do pokonania do miejsca docelowego
  • Zmiana stanu TaskOutcome

Każdy komponent rozwiązania referencyjnego można dostosować do potrzeb Twojej firmy.

Logiczne elementy składowe

Diagram : poniższy diagram przedstawia ogólne elementy składowe, które tworzą rozwiązanie referencyjne dotyczące zdarzeń związanych z flotą.

Omówienie zdarzeń floty i logiczne bloki konstrukcyjne

Rozwiązanie referencyjne zawiera te komponenty:

  • Źródło zdarzeń: miejsce, z którego pochodzi pierwotny strumień zdarzeń. Zarówno rozwiązanie Last Mile Fleet, jak i rozwiązanie On-demand Rides and Deliveries są zintegrowane z Cloud Logging, co pomaga przekształcać logi wywołań RPC Fleet Engine w strumienie zdarzeń dostępne dla deweloperów. Jest to podstawowe źródło do wykorzystania.
  • Przetwarzanie: w tym bloku, który przetwarza strumień zdarzeń dziennika, surowe logi wywołań RPC są przekształcane w zdarzenia zmiany stanu. Aby wykryć taką zmianę, ten komponent wymaga magazynu stanu, aby nowe zdarzenia przychodzące można było porównać z poprzednimi i wykryć zmianę. Wydarzenia nie zawsze mogą zawierać wszystkie interesujące Cię informacje. W takich przypadkach ten blok może w razie potrzeby wykonywać wywołania do backendów.
    • Pamięć stanu: niektóre platformy przetwarzania udostępniają dane pośrednie, które są przechowywane oddzielnie. Jeśli nie, aby samodzielnie przechowywać stan, ponieważ powinien on być unikalny dla pojazdu i typu zdarzenia, dobrym rozwiązaniem jest usługa utrwalania danych typu K-V.
  • Sink (zdarzenia niestandardowe): wykryta zmiana stanu powinna być udostępniana każdej aplikacji lub usłudze, która może z niej skorzystać. Dlatego naturalnym wyborem jest opublikowanie tego zdarzenia niestandardowego w systemie dostarczania zdarzeń do dalszego wykorzystania.
  • Usługa podrzędna: kod, który wykorzystuje wygenerowane zdarzenia i podejmuje działania unikalne dla Twojego przypadku użycia.

Wybór usługi

W przypadku wdrażania rozwiązania referencyjnego „Rozwiązanie ostatniej mili Fleet Engine” lub „Rozwiązanie do przewozów i dostaw na żądanie” (dostępne pod koniec III kwartału 2023 r.) wybór technologii dla „Źródła” i „Ujścia” jest prosty. Z kolei „Przetwarzanie” ma szeroki zakres opcji. W rozwiązaniu referencyjnym wybrano te usługi Google:

Diagram : poniższy diagram przedstawia usługę Google Cloud, która umożliwia wdrożenie rozwiązania referencyjnego.

Bloki konstrukcyjne rozwiązania referencyjnego Fleet Events

Układ projektu w chmurze

Zalecamy domyślne wdrażanie w wielu projektach. Dzięki temu zużycie usług Google Maps Platform i Google Cloud będzie można wyraźnie rozdzielić i powiązać z wybraną przez Ciebie formą rozliczeń.

Źródło zdarzeń

„Rozwiązanie ostatniej mili Fleet” i „Rozwiązanie do przejazdów i dostaw na żądanie” zapisują ładunki żądań i odpowiedzi interfejsu API w Cloud Logging. Cloud Logging dostarcza logi do co najmniej 1 wybranej usługi. Routing do Cloud Pub/Sub to w tym przypadku idealne rozwiązanie, które umożliwia przekształcanie logów w strumień zdarzeń bez konieczności pisania kodu.

Ujście

W Google Cloud Cloud Pub/Sub to preferowany system dostarczania wiadomości w czasie zbliżonym do rzeczywistego. Podobnie jak zdarzenia ze źródła były dostarczane do Pub/Sub, zdarzenia niestandardowe są również publikowane w Pub/Sub na potrzeby dalszego wykorzystania.

Przetwarzam

W przetwarzaniu zdarzeń biorą udział te komponenty: Podobnie jak inne elementy składowe, komponenty przetwarzania są w pełni bezserwerowe i można je łatwo skalować w górę i w dół.

  • Cloud Functions jako platforma obliczeniowa w pierwszej wersji (*)
    • Bezserwerowa, skalowana w górę i w dół z kontrolą skalowania, która umożliwia zarządzanie kosztami
    • Java jako język programowania ze względu na dostępność bibliotek klienta interfejsów API związanych z Fleet Engine, które ułatwiają implementację.
  • Cloud Firestore jako magazyn stanu
    • Bezserwerowy magazyn klucz-wartość
  • Cloud Pub/Sub jako punkt integracji z komponentami nadrzędnymi i podrzędnymi
    • Luźno sprzężona integracja w czasie zbliżonym do rzeczywistego

Funkcji można używać w domyślnej konfiguracji, ale można je też ponownie skonfigurować. Parametry konfiguracji są ustawiane za pomocą skryptów wdrażania i szczegółowo opisane w plikach README odpowiednich modułów Terraform.

*Uwaga: w ramach tego rozwiązania referencyjnego planujemy udostępnić alternatywne implementacje, które mogą pomóc w spełnieniu różnych wymagań.

Wdrożenie

Aby proces wdrażania rozwiązania referencyjnego był powtarzalny, konfigurowalny, kontrolowany pod względem kodu źródłowego i bezpieczny, jako narzędzie do automatyzacji wybrano Terraform. Terraform to popularne narzędzie IaC (Infrastructure as Code) z bogatą obsługą Google Cloud.

Moduły Terraform

Zamiast tworzyć jeden duży, monolityczny moduł wdrażania rozwiązania referencyjnego, wdrażamy bloki automatyzacji wielokrotnego użytku jako moduły Terraform, których można używać niezależnie. Moduły udostępniają szeroki zakres konfigurowalnych zmiennych, z których większość ma wartości domyślne, dzięki czemu możesz szybko zacząć, ale też dostosować je do swoich potrzeb i preferencji.

Moduły uwzględnione w rozwiązaniu referencyjnym:

  • Konfiguracja logowania w Fleet Engine: automatyzuje konfiguracje związane z Cloud Logging do użycia z Fleet Engine. W rozwiązaniu referencyjnym służy do kierowania logów związanych z Fleet Engine do określonego tematu Pub/Sub.
  • Wdrożenie funkcji Cloud Fleet Events: zawiera wdrożenie przykładowego kodu funkcji, a także automatyzuje ustawienia uprawnień wymagane do bezpiecznej integracji między projektami.
  • Wdrożenie całego rozwiązania referencyjnego: wywołuje 2 poprzednie moduły i obejmuje całe rozwiązanie.

Bezpieczeństwo

IAM jest stosowany w celu wdrożenia zasady najmniejszych uprawnień oraz sprawdzonych metod bezpieczeństwa Google Cloud, takich jak podszywanie się pod konto usługi. Zapoznaj się z tymi artykułami, aby lepiej zrozumieć, co Google Cloud oferuje w zakresie większej kontroli nad bezpieczeństwem:

Dalsze działania

Możesz teraz uzyskać dostęp do rozwiązania Fleet Events Reference i je dokładniej poznać. Aby rozpocząć, wejdź na stronę GitHub.

Dodatek

Zbierz wymagania

Zalecamy zebranie wymagań na wcześniejszym etapie procesu.

Najpierw opisz, dlaczego interesują Cię zdarzenia w czasie zbliżonym do rzeczywistego lub dlaczego musisz ich używać. Oto kilka pytań, które pomogą Ci określić Twoje potrzeby.

  • Jakie informacje są potrzebne, aby strumień zdarzeń był przydatny?
    • Czy wynik można uzyskać wyłącznie na podstawie danych zarejestrowanych lub wygenerowanych w usługach Google? Czy wymagane jest wzbogacanie danych za pomocą zintegrowanych systemów zewnętrznych? Jeśli tak, jakie to systemy i jakie interfejsy integracji oferują?
    • Jakie dane chcesz mierzyć w swojej firmie? Jak są one definiowane?
    • Jeśli chcesz obliczać dane na podstawie zdarzeń, jakiego rodzaju agregacji będziesz potrzebować? Spróbuj rozplanować logiczne kroki. (np. Porównywanie szacowanego i rzeczywistego czasu przybycia z poziomami usług w przypadku podzbioru floty w godzinach szczytu w celu obliczenia wydajności przy ograniczonych zasobach).
  • Dlaczego interesuje Cię model oparty na zdarzeniach, a nie na przetwarzaniu wsadowym? Czy chodzi o mniejsze opóźnienie (czas do wykonania działania), czy o luźno powiązaną integrację (elastyczność)?
    • Jeśli chodzi o małe opóźnienie, zdefiniuj wartość „low”. Minuty? Sekundy? Poniżej sekundy? A jakie opóźnienie?
  • Czy Twój zespół zainwestował już w technologie i powiązane umiejętności? Jeśli tak, to jakie i jakie punkty integracji udostępnia?
    • Czy są jakieś wymagania, których obecne systemy nie mogą spełnić lub z którymi mogą mieć problemy podczas przetwarzania zdarzeń pochodzących z floty?

Zasady projektowania

Zawsze warto mieć jakiś proces myślowy, którym można się kierować. Ułatwia to podejmowanie spójnych decyzji projektowych, zwłaszcza gdy masz do wyboru wiele opcji.

  • Domyślnie wybieraj prostsze opcje.
  • Domyślnie krótszy czas uzyskania wartości. Mniej kodu, mniejsza krzywa uczenia się.
  • W przypadku opóźnienia i wydajności staraj się osiągnąć ustawiony próg, a nie maksymalną optymalizację. Unikaj też ekstremalnej optymalizacji, ponieważ często prowadzi ona do zwiększenia złożoności.
  • To samo dotyczy kosztów. Utrzymuj rozsądne koszty. Może jeszcze nie jesteś w stanie zobowiązać się do korzystania z usług o wysokiej wartości, ale stosunkowo droższych.
  • W fazie eksperymentalnej zmniejszenie skali może być równie ważne jak jej zwiększenie. Wybierz platformę, która umożliwia skalowanie w górę z limitem, a także skalowanie w dół (najlepiej do zera), aby nie ponosić kosztów, gdy nic nie robisz. Wysoką wydajność dzięki infrastrukturze działającej przez cały czas można rozważyć później, gdy będziesz mieć pewność, że jest Ci potrzebna.
  • Obserwuj i mierz, aby później określić, nad czym jeszcze musisz popracować.
  • Utrzymuj luźne powiązanie usług. Ułatwi to późniejszą wymianę poszczególnych elementów.
  • Ostatnia, ale nie mniej ważna kwestia to bezpieczeństwo. Jako usługa działająca w środowisku chmury publicznej nie może mieć żadnych niezabezpieczonych punktów dostępu do systemu.

Pojęcia związane ze strumieniowaniem

Jeśli dopiero zaczynasz korzystać z przetwarzania strumieniowego lub opartego na zdarzeniach, warto poznać kluczowe pojęcia, z których niektóre mogą się znacznie różnić od przetwarzania wsadowego.

  • Skala : w przeciwieństwie do przetwarzania wsadowego, w przypadku którego zwykle masz dobre pojęcie o ilości danych do przetworzenia, w przypadku przetwarzania strumieniowego nie masz takiej możliwości. Korek w mieście może nagle generować wiele zdarzeń z określonego obszaru, a Ty musisz być w stanie je przetworzyć.
  • Okresy : zamiast przetwarzać zdarzenia pojedynczo, często warto grupować zdarzenia w mniejsze „okresy” na osi czasu, aby móc je obliczać jako jednostkę. Istnieją różne strategie okienkowania, takie jak „stałe okna (np. każdy dzień kalendarzowy)”, „okna przesuwne (ostatnie 5 minut)” czy „okna sesji (podczas tej podróży)”, z których możesz wybierać. Im dłuższe okno, tym większe opóźnienia w uzyskiwaniu wyników. Wybierz odpowiedni model i konfigurację, które spełniają Twoje wymagania.
  • Wywoływanie : w niektórych przypadkach nie masz innego wyjścia, jak tylko zastosować stosunkowo dłuższe okna. Nie chcesz jednak czekać z generowaniem zdarzeń do samego końca okna, ale raczej emitować wyniki pośrednie. Można to wykorzystać w przypadkach, gdy warto najpierw zwrócić szybkie wyniki, a potem je poprawić. Wyobraź sobie, że emitujesz stan pośredni po ukończeniu 25%, 50% i 75% dostawy.
  • Kolejność : zdarzenia niekoniecznie docierają do systemu w kolejności, w jakiej zostały wygenerowane. Dotyczy to zwłaszcza przypadków użycia, w których komunikacja odbywa się w sieciach komórkowych, co powoduje opóźnienia i złożone ścieżki routingu. Musisz znać różnicę między „czasem zdarzenia” (kiedy zdarzenie faktycznie miało miejsce) a „czasem przetwarzania” (kiedy zdarzenie dotarło do systemu) i odpowiednio obsługiwać zdarzenia. Zwykle zdarzenia przetwarza się na podstawie „event time”.
  • Dostarczanie wiadomości – co najmniej raz a dokładnie raz: różne platformy zdarzeń mają różną obsługę tych funkcji. W zależności od przypadku użycia musisz rozważyć strategie ponawiania lub usuwania duplikatów.
  • Kompletność : podobnie jak w przypadku zmiany kolejności istnieje ryzyko utraty wiadomości. Może to być spowodowane wyłączeniem aplikacji i urządzenia z powodu wyczerpania baterii, przypadkowym uszkodzeniem telefonu, utratą połączenia w tunelu lub otrzymaniem wiadomości poza dopuszczalnym przedziałem czasu. Jak niekompletność danych wpłynie na wyniki?

To nie jest pełna lista, tylko wprowadzenie. Oto kilka polecanych artykułów, które pomogą Ci lepiej zrozumieć te tematy.

Współtwórcy

Ten dokument jest utrzymywany przez Google. Oryginalni autorzy:

Główni autorzy: