Wydarzenia w czasie rzeczywistym w Fleet Engine

Sygnały w czasie zbliżonym do rzeczywistego pochodzące z floty działającej w terenie 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
  • Zmniejsz koszty, identyfikując i eliminując nieefektywności
  • Zwiększ bezpieczeństwo, monitorując zachowania kierowców i identyfikują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

Ten dokument pokazuje, jak deweloperzy mogą przekształcać sygnały z „usług mobilności” Google Maps Platform („rozwiązanie Last Mile Fleet Solution (LMFS) lub „rozwiązanie On-demand Rides and Deliveries (ODRD)) w niestandardowe zdarzenia, 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:

  • 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 obsługi przejazdów i dostaw na żądanie w zależności od swoich potrzeb.
  • Architekci znający Google Cloud. Osobom, które dopiero zaczynają korzystać z Google Cloud, zalecamy zapoznanie się z 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 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 określonych danych powiązanych z zadaniami lub przejazdami. Możesz używać tych zdarzeń do wysyłania powiadomień, np. tych 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 przybycia pracownika
  • 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 Fleet Events.

Omówienie zdarzeń dotyczących 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 Solution, 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ń logu, 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 mogą nie zawsze 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 struktury przetwarzania zapewniają trwałość danych pośrednich. 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ść.
  • Miejsce docelowe (zdarzenia niestandardowe): wykryta zmiana stanu powinna być udostępniana każdej aplikacji lub usłudze, która może z niej korzystać. Dlatego naturalnym wyborem jest opublikowanie tego zdarzenia niestandardowego w systemie dostarczania zdarzeń w celu 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 w przypadku opcji „Przetwarzanie” dostępnych jest wiele możliwości. 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ą płatności.

Źródło zdarzeń

„Rozwiązanie ostatniej mili Fleet” i „Rozwiązanie przejazdów i dostaw na żądanie” zapisują ładunki żądań do interfejsu API i odpowiedzi 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 programowania Java ze względu na dostępność bibliotek klienta dla 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

Funkcje 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 masz też możliwość dostosowania ich 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 jak najmniejszych uprawnień oraz sprawdzonych metod bezpieczeństwa Google Cloud, takich jak przyjęcie tożsamości konta usługi. Zapoznaj się z tymi artykułami, aby lepiej zrozumieć, co Google Cloud oferuje w zakresie większej kontroli nad bezpieczeństwem:

Następne czynności

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 zebranych 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 „low”. Minuty? Sekundy? Mniej niż sekunda? A jakie opóźnienie?
  • Czy Twój zespół zainwestował już w zestaw technologii 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ś 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 strumieniowego lub opartego na zdarzeniach, warto zapoznać się z kilkoma kluczowymi pojęciami, 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 dobrą orientację co do 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 możesz wybierać. Im dłuższe okno, tym większe opóźnienia w generowaniu 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żesz zastosować tę koncepcję w przypadkach, gdy ważniejsze jest szybkie zwracanie wyników, a dopiero potem ich poprawianie. 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. Zazwyczaj zdarzenia przetwarza się na podstawie parametru „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ą łączności 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. Oryginalny tekst został napisany przez te osoby:

Główni autorzy: