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 flot działających na ziemi są przydatne dla firm na wiele sposobów. Na przykład firmy mogą ich używać, aby:

  • monitorować wydajność swojej floty i wcześnie wykrywać potencjalne problemy;
  • Popraw obsługę klienta, podając dokładne informacje o szacowanym czasie dotarcia na miejsce i śledzeniu danych.
  • obniżyć koszty przez identyfikowanie i rozwiązywanie problemów z nieefektywnością,
  • zwiększyć bezpieczeństwo, monitorując zachowanie kierowców i wykrywając potencjalne zagrożenia,
  • Optymalizowanie tras i harmonogramów kierowców w celu zwiększenia efektywności
  • Zadbaj o zgodność z przepisami, śledząc lokalizację pojazdu i godziny pracy

Ten dokument pokazuje, jak deweloperzy mogą przekształcać sygnały z platformy Mapy Google dotyczące „usług mobilności” (czyli „rozwiązania Last Mile Fleet” lub „rozwiązania On-demand Rides and Deliveries”), w działające zdarzenia niestandardowe. Omówione są też kluczowe koncepcje i rozwiązania dotyczące źródeł danych Fleet Events, które znajdziesz w GitHub.

Ten dokument dotyczy:

Kończymy ten dokument, aby poznać najważniejsze elementy i kwestie związane z systemem strumieniowania, a także elementy składowe Google Maps Platform i Google Cloud, które składają się na rozwiązanie referencyjne dotyczące zdarzeń floty.

Omówienie rozwiązania referencyjnego zdarzeń floty

Rozwiązanie Fleet Events Reference Solution to rozwiązanie typu open source, które umożliwia klientom i partnerom mobilnym generowanie kluczowych zdarzeń poza komponentami Fleet Engine i Google Cloud. Obecnie rozwiązanie referencyjne obsługuje klientów korzystających z rozwiązania ostatniej mili dla floty, a w przyszłości będzie obsługiwać również przejazdy i dostawy na żądanie.

To rozwiązanie automatycznie generuje zdarzenia na podstawie zmian określonych danych związanych z zadaniami lub podróżami. Z tych zdarzeń możesz korzystać, aby wysyłać powiadomienia, takie jak te, do zainteresowanych osób lub wywoływać inne działania w Twojej flocie.

  • Zmiana szacowanego czasu dotarcia
  • Zmiana względnego szacowanego czasu dotarcia do zadania
  • Czas pozostały do rozpoczęcia zadania
  • Odległość do pokonania do zadania
  • Zmiana stanu TaskOutcome

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

Elementy składowe logiczne

Diagram : diagram ten przedstawia ogólne elementy składowe, z których składa się rozwiązanie referencyjne Zdarzenia floty.

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

Rozwiązanie referencyjne zawiera te komponenty:

  • Źródło zdarzenia: miejsce pochodzenia pierwotnego strumienia zdarzeń. Zarówno rozwiązanie „Last Mile Fleet Solution”, jak i „On-demand Rides and Deliveries Solution” są zintegrowane z Cloud Logging, co ułatwia przekształcanie logów wywołań RPC Fleet Engine w strumienie zdarzeń dostępne dla deweloperów. To główne źródło danych do analizowania.
  • Przetwarzanie: w tym bloku nieprzetworzone logi wywołań RPC są przekształcane w zdarzenia zmiany stanu. Blok ten wykonuje obliczenia na podstawie strumienia zdarzeń logowania. Aby wykryć taką zmianę, ten komponent wymaga magazynu stanu, który umożliwia porównanie nowych i poprzednich zdarzeń w celu wykrycia zmiany. Zdarzenia nie zawsze zawierają wszystkich istotnych informacji. W takich przypadkach blok ten może w razie potrzeby wyszukiwać wywołania backendów.
    • Stan pamięci: niektóre platformy przetwarzania zapewniają dane pośrednie, które są trwałe same w sobie. Jeśli nie, możesz przechowywać stan samodzielnie, ponieważ stan powinien być unikalny dla pojazdu i typu zdarzenia. W takim przypadku odpowiednia będzie usługa trwałego przechowywania danych typu klucz-wartość.
  • Sink (Custom Events): wykryty stan powinien być udostępniany każdej aplikacji lub usłudze, która może z niego korzystać. Dlatego naturalnym wyborem jest opublikowanie tego zdarzenia niestandardowego w systemie dostarczania zdarzeń do dalszego przetwarzania.
  • Usługa w dół łańcucha: kod, który wykorzystuje wygenerowane zdarzenia i podejmuje działania odpowiednie do Twojego przypadku użycia.

Wybór usługi

Jeśli chodzi o wdrożenie rozwiązania referencyjnego dla „rozwiązania „Last Mile Fleet” lub „przejazdów i dostaw na żądanie” (dostępnego pod koniec III kwartału 2023 r.), wybór technologii dla opcji „Źródło” i „Ujście” jest prosty. Natomiast w sekcji „Przetwarzanie” masz do wyboru szeroką gamę opcji. Rozwiązanie referencyjne korzysta z tych usług Google:

Diagram : przedstawia usługę Google Cloud, która wdraża rozwiązanie referencyjne

Elementy składowe rozwiązania referencyjnego Fleet Events

Układ projektu w Cloud

Zalecamy domyślne wdrożenie wielu projektów. Dzięki temu zużycie Google Maps Platform i Google Cloud można wyraźnie rozdzielić i powiązać z wybranym przez Ciebie sposobem rozliczeń.

Źródło zdarzeń

Rozwiązanie dotyczące ostatniej milirozwiązanie dotyczące przejazdów i dostaw na żądanie zapisują żądania interfejsu API i ładunki odpowiedzi w Cloud Logging. Cloud Logging dostarcza logi do co najmniej 1 wybranej usługi. Przekierowywanie do Cloud Pub/Sub to idealny wybór w tym przypadku, ponieważ pozwala przekształcać logi w strumień zdarzeń bez konieczności kodowania.

Ujście

W Google Cloud usługa Cloud Pub/Sub jest preferowanym systemem do 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 do dalszego przetwarzania.

Przetwarzam

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

  • Cloud Functions jako platforma obliczeniowa w przypadku wersji początkowej (*)
    • bezserwerowe, skalowane w górę i w dół za pomocą ustawień skalowania, aby zarządzać 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 przyczyniają się do łatwości implementacji
  • Cloud Firestore jako pamięć stanu
    • Bezserwerowy magazyn klucz-wartość
  • Cloud Pub/Sub jako punkt integracji z komponentami w górę i w dół
    • Integracja luźno sprzężona w czasie zbliżonym do rzeczywistego

Funkcji można używać w postaci domyślnej z ustawieniami domyślnymi, ale można je też ponownie skonfigurować. Parametry konfiguracji są ustawiane za pomocą skryptów wdrożenia i dokładnie udokumentowane w odpowiednich plikach README modułu Terraform.

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

Wdrożenie

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 (infrastruktura jako kod) z bogatym wsparciem dla Google Cloud.

Moduły Terraform

Zamiast tworzyć jeden duży, monolityczny moduł wdrażania rozwiązania referencyjnego, można zaimplementować powtarzalne bloki automatyzacji jako moduły Terraform, które można stosować niezależnie. Moduł zawiera wiele zmiennych, które można konfigurować. Większość z nich ma wartości domyślne, dzięki czemu możesz szybko rozpocząć pracę, ale masz też możliwość dostosowania ich do swoich potrzeb i preferencji.

Modułach zawartych w rozwiązaniu referencyjnym:

  • Konfiguracja logowania Fleet Engine: zautomatyzuj konfiguracje związane z Cloud Logging do użytku 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 w chmurze Fleet Events: zawiera przykładowe wdrożenie kodu funkcji, a także automatyzuje ustawienia uprawnień wymagane do bezpiecznej integracji między projektami.
  • Wdrożenie rozwiązania referencyjnego w całości: wywołuje poprzednie 2 moduły i pakuje całe rozwiązanie.

Bezpieczeństwo

System zarządzania dostępem jest stosowany do stosowania zasady jak najmniejszych uprawnień wraz ze sprawdzonymi metodami zapewniania bezpieczeństwa Google Cloud, takimi jak podszywanie się pod konto usługi. Aby dowiedzieć się więcej o tym, co Google Cloud oferuje, aby zapewnić Ci większą kontrolę nad bezpieczeństwem, zapoznaj się z poniższymi artykułami.

Następne działania

Możesz teraz uzyskać dostęp do rozwiązania referencyjnego Zdarzenia floty i jeszcze lepiej je poznać. Aby rozpocząć, otwórz GitHub.

Dodatek

Gromadzenie wymagań

Zalecamy zebranie wymagań na wcześniejszym etapie procesu.

Najpierw podaj szczegóły dotyczące tego, dlaczego chcesz używać zdarzeń w zbliżonym czasie rzeczywistym lub dlaczego Ci to odpowiada. Oto kilka pytań, które pomogą Ci określić Twoje potrzeby.

  • Jakie informacje są wymagane, aby strumień zdarzeń był przydatny?
    • Czy wynik może być uzyskany wyłącznie na podstawie danych zarejestrowanych lub wygenerowanych w usługach Google? Czy wzbogacanie danych z integrowanych systemów zewnętrznych jest wymagane? Jeśli tak, jakie to systemy i jakie interfejsy integracji oferują?
    • Jakie dane chcesz mierzyć w swojej firmie? Jak są one zdefiniowane?
    • Chcesz obliczać wskaźniki dotyczące wielu zdarzeń. Jakiej agregacji potrzebujesz? Spróbuj ułożyć sekwencję działań. (np. Porównaj ETA/ATA z wartościami SLO w podgrupie floty w godzinach szczytowego zapotrzebowania na zasoby, aby obliczyć wydajność przy ograniczonych zasobach.
  • Dlaczego bardziej interesuje Cię model oparty na zdarzeniach, a nie wsadowy? Czy jest to spowodowane krótszym czasem oczekiwania (czasem do działania) czy luźno sprzężoną integracją (elastycznością)?
    • Jeśli opóźnienie ma być niskie, określ je jako „low”. minut? Sekundy? Krótka? Jaki czas oczekiwania?
  • Czy Twój zespół zainwestował już w pakiet technologii i powiązane umiejętności? Jeśli tak, to co i jakie punkty integracji zapewnia?
    • Czy istnieją jakieś wymagania, których nie spełniają Twoje obecne systemy lub z którymi mogą mieć problemy podczas przetwarzania zdarzeń pochodzących z Twojej floty?

Zasady projektowania

Zawsze warto znać proces myślenia. Pomaga to w podejmowaniu spójnych decyzji projektowych, zwłaszcza gdy masz do wyboru wiele opcji.

  • Domyślnie wybierz prostsze opcje.
  • Domyślnie krótszy czas do wartości. Mniej kodowania, krótsza krzywa uczenia się
  • W przypadku opóźnień i wydajności staraj się osiągnąć ustawiony próg, a nie maksymalną optymalizację. Unikaj też nadmiernej optymalizacji, ponieważ często prowadzi ona do zwiększenia złożoności.
  • To samo dotyczy kosztów. Utrzymaj koszty na rozsądnym poziomie. Możliwe, ż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 zmniejszanie skali może być równie ważne jak zwiększanie. Rozważ platformę, która umożliwia elastyczne skalowanie w górę z limitem oraz skalowanie w dół (najlepiej do zera), aby nie ponosić kosztów, gdy nic się nie dzieje. Wysoką wydajność z infrastrukturą działającą w trybie ciągłym można rozważyć w późniejszej fazie, gdy będziesz mieć pewność, że spełnia ona Twoje potrzeby.
  • Obserwuj i mierz, aby później móc określić, nad czym należy jeszcze popracować.
  • Utrzymywanie luźnego sprzężenia usług. Ułatwia to późniejszą wymianę poszczególnych elementów.
  • Ważną kwestią jest też bezpieczeństwo. Usługa działa w środowisku chmury publicznej, więc nie może być żadnych niezabezpieczonych drzwi do systemu.

Pojęcia związane ze strumieniowaniem

Jeśli dopiero zaczynasz korzystać ze zdarzeń lub strumieniowania, warto znać kluczowe koncepcje, z których niektóre mogą się bardzo różnić od przetwarzania wsadowego.

  • Skala : w odróżnieniu od przetwarzania wsadowego, w którym zwykle masz dobrą orientację w ilości danych do przetworzenia, w przypadku przetwarzania strumieniowego nie możesz tego określić. Korki w mieście mogą nagle generować dużo zdarzeń z określonego obszaru, które trzeba będzie przetworzyć.
  • Okna : zamiast przetwarzania zdarzeń pojedynczo często zdarza się, że chcesz grupować zdarzenia na osi czasu w mniejsze „okna” jako jednostki obliczeniowe. Do wyboru są różne strategie stosowania okien, takie jak „okna stałe (np. każdy dzień kalendarzowy)”, „okna przesuwne (ostatnie 5 minut)” czy „okna sesji (podczas tej podróży)”. Im dłuższe okno, tym dłuższy czas oczekiwania na wyniki. Wybierz model i konfigurację, które spełniają Twoje wymagania.
  • Wyzwalanie : w niektórych przypadkach nie masz innego wyjścia, jak tylko stosować stosunkowo dłuższe okna. Nie chcesz jednak czekać do końca tego okna, aby generować zdarzenia, ale zamiast tego emitować wyniki pośrednie w międzyczasie. Tę koncepcję można zastosować w przypadkach, gdy warto najpierw zwrócić szybkie wyniki, a potem je skorygować. Wyobraź sobie, że emitujesz stan pośredni na poziomie 25%, 50% i 75% realizacji dostawy.
  • Kolejność : zdarzenia niekoniecznie docierają do systemu w kolejności, w jakiej zostały wygenerowane. zwłaszcza w przypadkach, w których wymagana jest komunikacja przez sieci komórkowe, która zwiększa opóźnienia i składa się z skomplikowanych ścieżek. Musisz zdawać sobie sprawę z różnicy między „czasem zdarzenia” (kiedy zdarzenie rzeczywiście miało miejsce) a „czasem przetwarzania” (kiedy zdarzenie dotarło do systemu) i odpowiednio obsługiwać zdarzenia. Zwykle zdarzenia są przetwarzane na podstawie „czasu zdarzenia”.
  • Dostarczanie wiadomości – „Co najmniej raz” lub „Tylko raz”: różne platformy zdarzeń obsługują inne typy obsługi. W zależności od przypadku użycia musisz rozważyć strategie ponownego próbowania lub usuwania duplikatów.
  • Pełnowartość : podobnie jak w przypadku zmiany kolejności wiadomości, istnieje ryzyko ich utraty. Może to być spowodowane wyłączeniem aplikacji lub urządzenia z powodu wyczerpania baterii, niezamierzonego uszkodzenia telefonu, utraty połączenia w tunelu lub otrzymania wiadomości poza dozwolonym oknem. Jak niepełne dane wpłyną na Twoje wyniki?

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

Współtwórcy

Dokument ten jest utrzymywany przez Google. Pierwotnie napisali go autorzy wymienieni poniżej.

Główni autorzy: