Droga Roblox do 2 bilionów zdarzeń analitycznych dziennie

Każdego dnia średnio 97,8 miliona użytkowników* odwiedza Roblox, aby komunikować się, tworzyć i wspólnie grać. Łącznie interakcje te generują 2 petabajty danych analitycznych dotyczących zdarzeń. Dzięki nowemu, skalowalnemu systemowi pozyskiwania danych osiągnęliśmy niedawno ważny kamień milowy: nasz system przetwarza obecnie ponad 2 biliony zdarzeń dziennie. System ten umożliwia działanie algorytmów personalizacji, bezpieczeństwa i ekonomii, które napędzają platformę Roblox.

Wcześniej usługa kolejki w chmurze pobierała dane analityczne generowane przez Roblox do jednej tabeli logicznej o nazwie events_hourly. Była ona podzielona według daty, godziny i dowolnie zdefiniowanych tagów, takich jak web, mobile lub friendService. Nasi analitycy danych i inżynierowie polegali na zaplanowanych zadaniach wsadowych, aby wyodrębnić określone zdarzenia do dedykowanych tabel. Tworzenie i wysyłanie nowych zdarzeń analitycznych nie wymagało wcześniejszego schematu. Inżynierowie kontrolowali własny schemat tabeli na dalszym etapie procesu ETL (extract, transform, load).

Ta konfiguracja była elastyczna i pozwalała inżynierom na szybkie działanie, ale wiązała się z pewnymi wyzwaniami. 

• Wraz ze wzrostem liczby zdarzeń praca z 2 bilionami wierszy podzielonych jedynie według daty, godziny i tagów stawała się coraz mniej wydajna.
• Sześciogodzinne opóźnienie na koniec dnia dla tabeli events_hourly i 24-godzinne opóźnienie dla events_daily powodowały okresy, w których potoki danych były blokowane. 
• Zarządzanie uprawnieniami na poziomie zbiorów danych, warstwami, przechowywaniem i alertami stało się bardziej złożone. 
• Brakowało dokumentacji zdarzeń, historii i informacji o właścicielach, co skutkowało słabą użytecznością i identyfikowalnością danych. 
• Infrastruktura pozyskiwania danych, zbudowana przy użyciu usługi kolejki w chmurze, generowała koszty pozyskiwania danych z chmury na poziomie 23 Gb/s.

Analiza danych opierała się wcześniej na pobieraniu danych z jednej tabeli logicznej za pomocą wielu potoków przetwarzania wsadowego. Było to konieczne do uruchamiania dużych, wydajnych zapytań, ale spowalniało też przetwarzanie. Wykorzystanie usługi zaplecza pozyskiwania danych do kierowania tych zdarzeń do dedykowanych tabel eliminuje potoki pobierania wsadowego, nadając zdarzeniom analitycznym schemat i definiując z góry tabelę docelową. 

Jako język schematu dla zdarzeń analitycznych w Roblox wybraliśmy Protobuf (proto). Był to naturalny wybór, ponieważ proto i gRPC to nasze preferowane frameworki usług programistycznych. Ponadto proto oferuje doskonałe wsparcie dla definiowania opcji niestandardowych, które wykorzystujemy do gromadzenia dodatkowych metadanych, takich jak własność, retencja, kanały oprogramowania zwiększającego produktywność oraz schemat zdarzeń. 

Po wybraniu języka schematu sprawdziliśmy, co się dzieje, gdy schemat jest aktualizowany i jakie aktualizacje powinny być dozwolone. Aby zapewnić obsługę jak największej liczby odbiorców korzystających z opublikowanego schematu, zespół ds. danych przyjął tryb wstecznej przechodniości opisany w rejestrze schematów. Dzięki temu podejściu dozwolone jest dodawanie i miękkie usuwanie pól. Umożliwia to wprowadzanie zmian w schemacie bez konieczności koordynacji z odbiorcami. 

W powyższym przykładzie możemy dodawać i usuwać pola poprzez aktualizację pliku proto.

Schematy oferują wiele korzyści, ale wymaganie ich z góry powoduje utrudnienia. Analitycy danych i inżynierowie muszą działać szybko i iterować bez przeszkód. Aby to wspierać, wprowadziliśmy scentralizowane repozytorium schematów i stworzyliśmy zestaw narzędzi, aby tworzenie schematów było jak najbardziej zautomatyzowane i usprawnione. 

Na przykład stworzyliśmy niestandardowy linter proto, aby sprawdzić, czy każdy schemat zawiera wymagane metadane i jest zgodny z konwencjami Roblox. Stworzyliśmy również wtyczkę proto do tłumaczenia schematu zdarzeń na język definicji danych Hive, dzięki czemu odpowiednia tabela Hive pozostaje zsynchronizowana niezależnie od tego, gdzie schemat jest tworzony lub aktualizowany. Wszystkie te narzędzia są zintegrowane z potokiem CI/CD i uruchamiają się automatycznie po utworzeniu pull requestu. Pozwala to inżynierom na wczesne wykrywanie problemów ze schematami i weryfikację zdarzeń w testowych tabelach Hive przed scaleniem schematów. W rezultacie wdrożenie schematu do środowiska produkcyjnego jest tak proste, jak scalanie. 

Dzięki usprawnionemu środowisku programistycznemu zbadaliśmy, w którym miejscu potoku pozyskiwania dane zdarzenia powinny być schematyzowane i konwertowane do proto. Poproszenie producentów zdarzeń o przyjęcie i wysyłanie zserializowanych bajtów proto byłoby znaczącą zmianą obejmującą wiele zespołów. Aby rozwiązać problemy i dostarczać wartość stopniowo, oddzieliliśmy proces schematyzacji od producentów zdarzeń, aktualizując usługę zaplecza pozyskiwania danych w celu konwersji przychodzących zdarzeń do proto. Obecnie przekonwertowane zdarzenia są gromadzone w plikach Parquet, przesyłane do pamięci rozproszonej i rejestrowane jako indywidualne tabele Hive.

Następnie skupiliśmy się na kosztach obsługi zdarzeń analitycznych. Wcześniej backend pozyskiwania danych był zbudowany w oparciu o infrastrukturę chmury. Zdarzenia analityczne były wysyłane do usługi kolejkowej, która buforowała je, a następnie przechowywała w trwałej pamięci chmurowej w celu dalszego przetwarzania i analizy. Chociaż usługa kolejkowa w chmurze uprościła naszą usługę i umożliwiła przejrzyste skalowanie, jest ona trudna w użyciu przez inne zadania strumieniowe i bardziej kosztowna. Aby rozwiązać ten problem, rozważaliśmy przeniesienie usługi pozyskiwania danych do centrów danych Roblox. 

Nasz wewnętrzny zespół ds. pamięci masowej zbudował usługę typu „queue-as-a-service” (QaaS) w oparciu o otwartą platformę strumieniowania zdarzeń. QaaS to świetny zamiennik dla pobierania zdarzeń analitycznych, ponieważ zdarzenia są śledzone w kolejności „pierwsze weszło, pierwsze wyszło” i usuwane po krótkim okresie przechowywania. W Roblox tworzymy dedykowany temat dla każdego zdarzenia schematycznego i wykorzystujemy liczbę partycji do skalowania dużych strumieni zdarzeń. Zespół ds. danych stworzył również dedykowaną usługę do pobierania danych z QaaS, tworzenia plików Parquet i przesyłania ich do trwałej pamięci masowej w chmurze.

Dzięki wdrożeniu QaaS i dedykowanej usłudze do tworzenia i przechowywania plików Parquet zespół ds. danych przez sześć miesięcy przeprowadzał operacje shadow write w celu sprawdzenia zarówno poprawności danych, jak i skalowalności. W końcu, po przeprowadzeniu szczegółowych kontroli kompletności i integralności danych, z powodzeniem przenieśliśmy pobieranie zdarzeń analitycznych z naszej starej usługi kolejkowania w chmurze. Był to ważny kamień milowy. Wyeliminowaliśmy koszty zasobów chmury z ścieżki pozyskiwania danych i znacznie zmniejszyliśmy opóźnienie między wywołaniem zdarzenia a jego pojawieniem się w naszym jeziorze danych. Wcześniej mieliśmy umowę o gwarantowanym poziomie usług wynoszącym trzy godziny, której często nie dotrzymywaliśmy — obecnie konsekwentnie osiągamy średni czas wynoszący 15 minut. 

Pozwala to inżynierom na tworzenie potoków przetwarzania zdarzeń w czasie rzeczywistym w oparciu o schematyzowane zdarzenia, wykorzystując dane z QaaS do zasilania funkcji bezpieczeństwa i rekomendacji w czasie rzeczywistym. Wprowadziliśmy również funkcję wykrywania zmian danych przy użyciu tej samej struktury schematyzacji i pozyskiwania danych z QaaS, co w znacznym stopniu wyeliminowało konieczność wykonywania pełnych zrzutów bazy danych. Od analizy w czasie rzeczywistym i strumieniowania zdarzeń po odkrywanie nowych zastosowań – nasza praca trwa, a my wprowadzamy innowacje i budujemy inteligentniejsze, szybsze i bardziej opłacalne systemy danych na dużą skalę. 

Chcielibyśmy podziękować Paulowi Mou za jego cenny wkład w tę pracę.

^{* Stan na koniec kwartału zakończonego 31 marca 2025 r.}