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 pochodzące 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;
  • poprawić obsługę klienta dzięki podawaniu dokładnych szacowanych czasów dostawy i informacji o śledzeniu;
  • Ograniczanie kosztów przez wykrywanie i eliminowanie nieefektywności
  • Zwiększanie bezpieczeństwa dzięki monitorowaniu zachowań kierowców i wykrywaniu potencjalnych zagrożeń
  • Optymalizowanie tras i harmonogramów kierowców w celu zwiększenia wydajności
  • Zgodność z przepisami dzięki śledzeniu lokalizacji pojazdu i godzin pracy

Ten dokument pokazuje, jak deweloperzy mogą przekształcać sygnały z usług „Mobilność” Google Maps Platform („Rozwiązanie do zarządzania flotą pojazdów dostawczych na ostatniej mili” (LMFS) lub „Rozwiązanie do realizacji przejazdów i dostaw na żądanie” (ODRD)) w działania wywoływane przez zdarzenia niestandardowe. Omówione są też kluczowe koncepcje i decyzje projektowe dotyczące rozwiązania Fleet Events Reference dostępnego w GitHubie.

Ten dokument dotyczy:

  • Architekci znający „usługi mobilności” Google Maps Platform i jeden z jej podstawowych komponentów, czyli „Fleet Engine”. Jeśli dopiero zaczynasz korzystać z „usług mobilności”, zapoznaj się z rozwiązaniem ostatniej mili lub rozwiązaniem do przejazdów i dostaw na żądanie w zależności od swoich potrzeb.
  • Architekci znający Google Cloud. Jeśli dopiero zaczynasz korzystać z Google Cloud, zalecamy przeczytanie artykułu Tworzenie potoków danych strumieniowych w Google Cloud.
  • Jeśli kierujesz reklamy na inne środowiska lub stosy oprogramowania, skup się na zrozumieniu punktów integracji i kluczowych kwestii związanych z Fleet Engine, które powinny być nadal aktualne.
  • Osoby zainteresowane tym, jak można generować i wykorzystywać zdarzenia z flot.

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 Solution

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 w określonych danych powiązanych z zadaniami lub przejazdami. Możesz używać tych zdarzeń do wysyłania powiadomień, np. takich jak poniżej, 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 zadania
  • 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 ich logiczne elementy składowe

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 główne źródło danych do wykorzystania.
  • Przetwarzanie: w tym bloku, który przetwarza strumień zdarzeń logów, 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 przechowywać stan samodzielnie, ponieważ powinien on być unikalny dla pojazdu i typu zdarzenia, dobrym rozwiązaniem jest usługa utrwalania danych typu klucz-wartość.
  • 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 dla rozwiązania ostatniej mili Fleet Engine lub rozwiązania do przewozów i dostaw na żądanie (dostępnego pod koniec III kwartału 2023 r.) wybór technologii dla „Źródła” i „Miejsca docelowego” 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 do wdrożenia 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 Engine” i „Rozwiązanie 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. Przekierowywanie 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, aby zarządzać kosztami
    • Język Java 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, bezpieczny i umożliwiał kontrolowanie kodu źródłowego, jako narzędzie do automatyzacji wybrano Terraform. Terraform to popularne narzędzie IaC (infrastruktura jako kod) 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 rozpocząć pracę, 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ń wraz ze sprawdzonymi metodami bezpieczeństwa Google Cloud, takimi 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ąć, otwórz 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 rozłożyć proces na 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 niskie opóźnienie, zdefiniuj wartość „low”. Minuty? sekund? 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 istnieją 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órego można się trzymać. 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ś na etapie, na którym możesz 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ć na późniejszym etapie, gdy będziesz mieć pewność, że jest ona 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.
  • Na koniec: bezpieczeństwo nie może być słabe. 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 opartego na zdarzeniach lub strumieniowego, 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” w ramach osi czasu, aby wykonywać obliczenia na tych jednostkach. 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 należy wybrać jedną. 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ć do samego końca okna, aby wygenerować zdarzenia, ale raczej emitować wyniki pośrednie. Można to wykorzystać w przypadkach, gdy ważniejsze jest szybkie zwrócenie wyników, a dopiero potem ich poprawienie. 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ń różnie obsługują te opcje. 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 możliwość 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

Google prowadzi ten dokument. Autorzy oryginalnego tekstu:

Główni autorzy: