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ących na ziemi są przydatne dla firm na wiele sposobów. Mogą one na przykład:

  • Monitorowanie wydajności floty urządzeń i wczesne identyfikowanie potencjalnych problemów
  • popraw jakość obsługi klienta, podając dokładne informacje o szacowanym czasie dotarcia i śledzeniu przesyłki.
  • Zmniejszanie kosztów przez identyfikowanie i eliminowanie nieskuteczności
  • Zwiększ bezpieczeństwo, monitorując zachowania kierowców i identyfikując potencjalne zagrożenia
  • Optymalizuj trasy kierowców i rozkłady jazdy, aby zwiększyć wydajność
  • Przestrzegaj przepisów, śledząc lokalizację pojazdu i godziny eksploatacji

Ten dokument pokazuje, w jaki sposób deweloperzy mogą przekształcać sygnały z „usług mobilnych” platformy Google Maps Platform („Rozwiązanie ostatniej mili” (LMFS) lub „rozwiązanie dotyczące przejazdów i dostawek na żądanie” (ODRD) w przydatne zdarzenia niestandardowe. Omówiliśmy również kluczowe pojęcia i decyzje projektowe rozwiązania referencyjnego zdarzeń floty dostępnego na GitHubie.

Ten dokument dotyczy:

  • Architekci zaznajomieni z „usługami mobilnymi” Google Maps Platform i jednym z jej podstawowego komponentu – „Fleet Engine”. Jeśli dopiero zaczynasz korzystać z usług mobilnych, zalecamy zapoznanie się z rozwiązaniem ostatniej mili lub rozwiązaniem typu Przejazdy i dostawy na żądanie (w zależności od potrzeb).
  • Architekci znający Google Cloud. Jeśli jesteś nowym użytkownikiem Google Cloud, zapoznaj się z tym artykułem: 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 Fleet Engine i najważniejszych kwestii, które nadal powinny mieć zastosowanie.
  • Osoby zainteresowane generowaniem i wykorzystywaniem zdarzeń z flot.

W tym dokumencie znajdziesz podstawowe informacje na temat najważniejszych elementów i kwestii związanych z systemem strumieniowania, a także elementów składowych z Google Maps Platform i Google Cloud, które składają się na rozwiązanie referencyjne zdarzeń floty.

Omówienie rozwiązania referencyjnego zdarzeń floty

Fleet Event Reference Solution to rozwiązanie typu open source, które umożliwia klientom i partnerom Mobility generowanie kluczowych zdarzeń przy użyciu komponentów Fleet Engine i Google Cloud. Obecnie rozwiązanie referencyjne obsługuje klientów korzystających z rozwiązania Last Mile Fleet Solution z obsługą Przejazdów na żądanie i dostawy.

To rozwiązanie automatycznie generuje zdarzenia na podstawie zmian określonych danych związanych z zadaniami lub podróżami. Za pomocą tych zdarzeń możesz wysyłać do zainteresowanych osoby powiadomienia takie jak opisane poniżej, a także uruchamiać inne działania związane z flotą.

  • Zmiana szacowanego czasu dotarcia na miejsce
  • Zmiana względnego czasu dotarcia na miejsce
  • Czas pozostały do osiągnięcia zadania
  • Odległość do osiągnięcia celu
  • Zmiana stanu elementu TaskResult

Każdy komponent rozwiązania referencyjnego można dostosować do własnych potrzeb biznesowych.

Logiczne elementy składowe

Diagram : poniższy diagram przedstawia ogólne elementy składowe, które składają się na rozwiązanie referencyjne dotyczące zdarzeń floty

omówienie zdarzeń floty i logiczne elementy składowe

Rozwiązanie referencyjne zawiera następujące komponenty:

  • Źródło zdarzeń: skąd pochodzi oryginalny strumień zdarzeń. „Rozwiązanie ostatniej mili floty” lub „rozwiązanie dotyczące przejazdów i dostawek na żądanie” umożliwia integrację z usługą Cloud Logging, która ułatwia przekształcanie logów wywołań RPC Fleet Engine w strumienie zdarzeń dostępne dla deweloperów. Jest to podstawowe źródło do wykorzystania.
  • Przetwarzanie: nieprzetworzone logi wywołań RPC są w ramach tego bloku konwertowane na zdarzenia zmiany stanu, które są obliczane na podstawie strumienia zdarzeń z dziennika. Aby wykryć taką zmianę, ten komponent wymaga magazynu stanów, które pozwolą na porównywanie nowych zdarzeń przychodzących z poprzednimi w celu wykrycia zmiany. Zdarzenia nie zawsze zawierają wszystkie interesujące Cię informacje. W takich przypadkach blok może w razie potrzeby wyszukiwać wywołania backendów.
    • Magazyn stanu: niektóre platformy przetwarzania same dostarczają trwałe dane pośrednie. Jeśli jednak nie chcesz tego robić, ponieważ dane te powinny być unikalne dla konkretnego pojazdu i typu zdarzenia, dobrym rozwiązaniem będzie usługa przechowywania danych typu K-V.
  • Ujście (zdarzenia niestandardowe): wykryta zmiana stanu powinna być dostępna dla każdej aplikacji lub usługi, która może z niej korzystać. Dlatego publikowanie tego zdarzenia niestandardowego w systemie dostarczania zdarzeń jest oczywistą opcją.
  • Usługa na żądanie: kod, który pozyskuje wygenerowane zdarzenia i pobiera działania unikalne dla Twojego przypadku użycia.

Wybór usługi

Jeśli chodzi o wdrożenie rozwiązania referencyjnego dla „rozwiązania floty ostatniej mili” lub „rozwiązania do obsługi przejazdów i dostaw na żądanie” (pod koniec III kwartału 2023 r.), wybór technologii dla opcji „Źródło” i „Ujście” jest prosty. Z drugiej strony „Przetwarzanie” oferuje szeroki zakres opcji. Rozwiązanie referencyjne wybrało te usługi Google.

Diagram : poniższy diagram przedstawia usługę Google Cloud do wdrożenia rozwiązania referencyjnego

Zdarzenia floty odwołują się do elementów składowych rozwiązań

Układ projektu Cloud

Zalecamy domyślne wdrożenie obejmujące wiele projektów. Dzięki temu wykorzystanie Google Maps Platform i Google Cloud może być wyraźnie oddzielone i powiązane z wybraną przez Ciebie metodą rozliczeń.

Źródło zdarzeń

„Last Mile Fleet Solutions” i „On-demand Rides and Deliveries Solutions” to rozwiązanie do zapisywania żą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 doskonały wybór, który pozwala przekonwertować logi na strumień zdarzeń bez kodowania.

Umywalka

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

Przetwarzam

Podane niżej komponenty odgrywają rolę w przetwarzaniu zdarzeń. Podobnie jak inne elementy składowe, komponenty przetwarzania są całkowicie bezserwerowe i można skalować je zarówno w górę, jak i w dół.

  • Cloud Functions jako platforma obliczeniowa na potrzeby pierwszej wersji (*)
    • Bezserwerowe, skalowalne w górę i w dół dzięki sterowaniu skalowaniem w celu zarządzania kosztami
    • Java jako język programowania ze względu na dostępność bibliotek klienckich dla interfejsów API związanych z Fleet Engine, które ułatwiają ich wdrożenie
  • Cloud Firestore jako magazyn stanu;
    • Bezserwerowy magazyn par klucz-wartość
  • Cloud Pub/Sub jako punkt integracji z komponentami nadrzędnymi i przychodzącymi.
    • luźno sprzężona integracja w czasie zbliżonym do rzeczywistego;

Funkcji tych możesz używać w niezmienionej postaci z ustawieniami domyślnymi, ale można je też skonfigurować. Parametry konfiguracji są ustawiane za pomocą skryptów wdrożeniowych i szczegółowo udokumentowane w odpowiednich plikach README modułu Terraform.

*Uwaga: w ramach tego rozwiązania referencyjnego planujemy opublikować alternatywne implementacje, które mogą pomóc spełnić różne wymagania.

Wdrażanie

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

Moduły Terraform

Zamiast tworzyć jeden duży, monolityczny moduł wdrażania rozwiązań referencyjnych, bloki automatyzacji wielokrotnego użytku są implementowane jako moduły Terraform, których można używać niezależnie. Moduły zapewniają szeroki zakres konfigurowalnych zmiennych, z których większość ma wartości domyślne, dzięki czemu możesz szybko rozpocząć pracę, ale możesz też dostosowywać je do własnych potrzeb i preferencji.

Moduły zawarte w rozwiązaniu referencyjnym:

  • Konfiguracja logowania Fleet Engine: zautomatyzuj konfiguracje związane z Cloud Logging na potrzeby Fleet Engine. W rozwiązaniu referencyjnym służy on do kierowania logów związanych z Fleet Engine do określonego tematu Pub/Sub.
  • Wdrożenie funkcji zdarzeń floty: obejmuje wdrożenie przykładowego kodu funkcji i obsługuje automatyzację ustawień uprawnień wymaganych do bezpiecznej integracji między projektami.
  • Wdrożenie rozwiązania z całego pliku referencyjnego: wywołuje 2 poprzednie moduły i otacza całe rozwiązanie.

Bezpieczeństwo

Uprawnienia są wykorzystywane w celu stosowania zasad jak najmniejszych uprawnień wraz ze sprawdzonymi metodami zapewniania bezpieczeństwa w Google Cloud, takimi jak podszywanie się pod inne konta usługi. Zapoznaj się z tymi artykułami, aby lepiej zrozumieć, jakie funkcje Google Cloud oferuje i daje Ci większą kontrolę nad bezpieczeństwem.

Kolejne działania

Możesz teraz uzyskać dostęp do rozwiązania referencyjnego zdarzeń floty i dokładnie zapoznać się z nim. Otwórz GitHub, aby rozpocząć.

Dodatek

Przygotuj wymagania

Zalecamy zebranie informacji o wymaganiach wcześniej w ramach tego procesu.

Najpierw napisz, dlaczego Cię to interesuje lub dlaczego potrzebujesz zdarzeń w czasie zbliżonym do rzeczywistego. Oto kilka pytań, które pomogą Ci sprecyzować swoje potrzeby.

  • Jakie informacje są niezbędne, aby strumień zdarzeń był przydatny?
    • Czy wynik można uzyskać wyłącznie na podstawie danych zarejestrowanych lub wytwarzanych przez usługi Google? A może wymagane jest wzbogacanie danych za pomocą zintegrowanych systemów zewnętrznych? Jeśli tak, jakie to systemy i jakie interfejsy integracji oferują?
    • Jakie dane chce Pan/Pani mierzyć jako firma? Jak są definiowane?
    • Jakiego rodzaju agregacji będzie to wymagać, aby obliczać dane dotyczące różnych zdarzeń? Postaraj się układać logiczne kroki. (np. Porównaj szacowany czas dotarcia i szacowany czas dotarcia z docelowym poziomem usług w podsekcie floty w godzinach szczytu, aby obliczyć wydajność przy ograniczeniach zasobów.
  • Dlaczego interesuje Cię model oparty na zdarzeniach, a nie na zbiorze danych? Czy chodzi o mniejsze opóźnienia (czas do działania) czy luźno sprzężoną integrację (elastyczność)?
    • Jeśli opóźnienie jest niewielkie, określ „niski”. Minuty? Sekundy? Podsekunda? Jakie opóźnienie?
  • Czy inwestowałeś już w stos technologiczny i powiązane umiejętności jako zespół? Jeśli tak, co to jest i jakie punkty integracji zapewnia?
    • Czy Twoje obecne systemy nie spełniają określonych wymagań podczas przetwarzania zdarzeń pochodzących z Twojej floty?

Zasady dotyczące projektowania

Zawsze warto opracować pewien proces myślowy. Pomaga to w podejmowaniu spójnych decyzji projektowych, zwłaszcza gdy masz do wyboru różne opcje.

  • Domyślnie korzystaj z prostszych opcji.
  • Domyślnie ustaw krótszy czas do uzyskania wartości. Mniej kodowania, tym krótsza krzywa uczenia się
  • Jeśli chodzi o czas oczekiwania i skuteczność, staramy się osiągnąć ustawiony próg, a nie maksymalną optymalizację. Unikaj też ekstremalnej optymalizacji, ponieważ często prowadzi to do zwiększenia złożoności.
  • To samo dotyczy kosztów. Utrzymuj rozsądne koszty. Być może nie jesteś jeszcze w stanie, w którym można zobowiązać się do korzystania z usług o wysokiej wartości, ale stosunkowo droższych.
  • Na etapie eksperymentu skalowanie w dół może być równie ważne jak skalowanie w górę. Warto rozważyć platformę, która umożliwia skalowanie w górę z limitem oraz w dół (najlepiej do zera), dzięki czemu nie płacisz, nie robiąc nic. Wysoka wydajność z zawsze aktywną infrastrukturą można rozważyć na późniejszym etapie, gdy będziesz mieć pewność co do jej potrzeb.
  • Obserwuj i mierz, aby później ustalić, nad czym warto popracować.
  • Dopilnuj, aby usługi były luźno połączone. Ułatwia to późniejsze podmiany kawałków.
  • Nie należy lekceważyć zabezpieczeń. Usługa działająca w publicznej chmurze nie może mieć żadnych niezabezpieczonych drzwi do systemu.

Pojęcia związane ze strumieniowym przesyłaniem danych

Jeśli dopiero zaczynasz korzystać z opartych na zdarzeniach lub strumieniowaniu danych, musisz znać kilka kluczowych koncepcji, z których część może się bardzo różnić od przetwarzania wsadowego.

  • Skalowanie : w przeciwieństwie do przetwarzania wsadowego, które zwykle dobrze sprawdza się w przypadku ilości danych do przetworzenia, w przypadku strumieniowania nie jest to możliwe. Korki w mieście mogą nagle generować wiele zdarzeń z danego obszaru i nadal trzeba to robić.
  • Okna : zamiast przetwarzać zdarzenia pojedynczo, często zdarza się, że chcesz pogrupować zdarzenia na osi czasu w mniejsze „okna” służące do obliczeń. Dostępne są różne strategie określania okien, takie jak „stałe okna (np. codziennie kalendarz”, „przesuwne okna (ostatnie 5 minut)” czy „okna sesji (podczas tej podróży)”. Im dłuższy okres, tym większe opóźnienia w generowaniu wyników. Wybierz właściwy model i konfigurację, które spełniają Twoje wymagania.
  • Reguły : w przypadku pozostałych przypadków nie ma innego wyjścia niż ustawienie dłuższego okresu przechowywania. Nie warto jednak czekać na wygenerowanie zdarzeń na samym końcu okna, a zamiast tego generować wyniki pośrednie. Tę koncepcję można zastosować w przypadkach, w których jest to wartość, która najpierw zwraca szybkie wyniki, a potem je poprawia. Wyobraź sobie, że w przypadku realizacji wyświetleń na poziomie średnio 25%, 50% lub 75%.
  • Kolejność : zdarzenia niekoniecznie docierają do systemu w kolejności, w jakiej zostały wygenerowane. Szczególnie sprawdza się on w komunikacji w sieciach komórkowych, która zwiększa opóźnienie i złożone ścieżki kierowania. Musisz mieć świadomość różnicy między „czasem zdarzenia” (czasem, w którym zdarzenie faktycznie miało miejsce) a „czasem przetwarzania” (w przypadku, gdy zdarzenie dotrze do systemu) i odpowiednio obsługiwać zdarzenia. Zasadniczo chodzi o przetwarzanie zdarzeń na podstawie „czasu zdarzenia”.
  • Dostarczanie wiadomości – co najmniej raz lub „dokładnie raz”: różne platformy zdarzeń obsługują je w różny sposób. W zależności od przypadku użycia warto rozważyć ponawianie lub usuwanie duplikatów.
  • Kompletność : tak jak w przypadku zmiany kolejności wiadomości, istnieje ryzyko, że wiadomości zostaną utracone. Może to być spowodowane wyłączeniem aplikacji i urządzenia z powodu żywotności baterii, niezamierzonego uszkodzenia telefonu, utraty połączenia w tunelu lub wiadomości otrzymanej tylko poza dopuszczalnym okresem. W jaki sposób niekompletność wpływa na uzyskane wyniki?

To nie jest pełna lista, ale wprowadzenie do programu. Oto kilka lektur, które pomogą Ci lepiej zrozumieć każdy z tych zjawisk.

Współtwórcy

Google przechowuje ten dokument. Następujący współtwórcy napisali go pierwotnie.

Główne autorzy:

  • Mary Pishny | Menedżerka produktu Google Maps Platform
  • Ethel Bao| Inżynier oprogramowania, Google Maps Platform
  • Mohanad Almiski | Inżynier oprogramowania, Google Maps Platform
  • Naoya Moritani | inżynier ds. rozwiązań, Google Maps Platform