Roblox' weg naar 2 biljoen analytische gebeurtenissen per dag

Elke dag bezoeken gemiddeld 97,8 miljoen gebruikers* Roblox om te communiceren, te creëren en samen te spelen. Samen genereren deze interacties 2 petabytes aan analytische gebeurtenisgegevens. Dankzij een nieuw schaalbaar opnamesysteem hebben we onlangs een belangrijke mijlpaal bereikt: ons systeem verwerkt nu meer dan 2 biljoen gebeurtenissen per dag. Dit systeem maakt de personalisatie-, veiligheids- en economische algoritmen mogelijk die het Roblox-platform aandrijven.

Voorheen nam een cloudwachtrijdienst door Roblox gegenereerde analytische gegevens op in één logische tabel, genaamd events_hourly. Deze was gepartitioneerd op datum, uur en willekeurig gedefinieerde tags zoals web, mobiel of friendService. Onze datawetenschappers en engineers vertrouwden op geplande batchtaken om specifieke gebeurtenissen naar speciale tabellen te extraheren. Voor het aanmaken en verzenden van nieuwe analytische gebeurtenissen was geen vooraf gedefinieerd schema nodig. Engineers beheerden hun eigen tabelschema stroomafwaarts in de ETL-pijplijnfase (extract, transform, load).

Deze opzet was flexibel en stelde ingenieurs in staat om snel te handelen, maar bracht ook uitdagingen met zich mee. 

• Naarmate het aantal gebeurtenissen toenam, werd het werken met 2 biljoen rijen die alleen op datum, uur en tags waren gepartitioneerd, steeds inefficiënter.
• Een vertraging van zes uur aan het einde van de dag voor de tabel events_hourly en een vertraging van 24 uur voor events_daily zorgden voor periodes waarin datapijplijnen werden geblokkeerd. 
• Het beheer van machtigingen, niveaus, bewaartermijnen en waarschuwingen op datasetniveau werd complexer. 
• Documentatie, geschiedenis en eigendom van gebeurtenissen ontbraken, wat resulteerde in slechte bruikbaarheid en traceerbaarheid van gegevens. 
• De opname-infrastructuur, gebouwd met de cloudwachtrijservice, bracht 23 Gbps aan cloudopnamekosten met zich mee.

Data-analyse was voorheen afhankelijk van het extraheren van gegevens uit één logische tabel via vele batchpijplijnen. Dit was nodig om grote, performante query's uit te voeren, maar het vertraagde ook de verwerking. Door de ingestie-backendservice te gebruiken om deze gebeurtenissen naar speciale tabellen te leiden, worden de batch-extractiepijplijnen overbodig gemaakt door analytische gebeurtenissen een schema te geven en vooraf een bestemmings-tabel te definiëren. 

We hebben Protobuf (proto) gekozen als de schemataal voor analyse-events bij Roblox. Dit was een logische keuze, aangezien proto en gRPC onze voorkeursframeworks voor het bouwen van services zijn. Bovendien biedt proto uitstekende ondersteuning voor het definiëren van aangepaste opties die we gebruiken om aanvullende metadata te verzamelen, zoals eigendom, retentie, productiviteitssoftwarekanalen en eventschema's. 

Nadat we onze schemataal hadden gekozen, hebben we onderzocht wat er gebeurt wanneer een schema wordt bijgewerkt en welke updates moeten worden toegestaan. Om het grootste aantal downstream-gebruikers te ondersteunen die het gepubliceerde schema gebruiken, heeft het datateam de achterwaarts transitieve modus aangenomen die wordt beschreven in Schema Registry. Met deze aanpak is het toevoegen en zacht verwijderen van een veld toegestaan. Dit maakt schemawijzigingen mogelijk zonder dat er afstemming met downstream-gebruikers nodig is. 

In het bovenstaande voorbeeld kunnen we een veld toevoegen en verwijderen door het proto-bestand bij te werken.

Schema's bieden veel voordelen, maar het vooraf verplicht stellen ervan zorgt voor wrijving. Datawetenschappers en engineers moeten snel kunnen handelen en zonder obstakels kunnen itereren. Om dit te ondersteunen, hebben we een gecentraliseerde schema-repository geïntroduceerd en een reeks tools gebouwd om het opstellen van schema's zo geautomatiseerd en gestroomlijnd mogelijk te maken. 

We hebben bijvoorbeeld een aangepaste proto-linter gebouwd om te valideren dat elk schema de vereiste metadata bevat en voldoet aan de Roblox-conventies. We hebben ook een proto-plug-in gebouwd om een gebeurtenisschema te vertalen naar de Hive-gegevenstaalt, zodat de bijbehorende Hive-tabel gesynchroniseerd blijft, ongeacht waar een schema wordt aangemaakt of bijgewerkt. Al deze tools zijn geïntegreerd in een CI/CD-pijplijn en worden automatisch uitgevoerd wanneer er een pull-verzoek wordt aangemaakt. Hierdoor kunnen ingenieurs schema-problemen vroegtijdig opsporen en gebeurtenissen in test-Hive-tabellen verifiëren voordat hun schema's worden samengevoegd. Het resultaat is dat het implementeren van een schema in de productie net zo eenvoudig is als het samenvoegen ervan. 

Nu we een gestroomlijnde ontwikkelaarservaring hadden, onderzochten we waar in de opnamepijplijn een gebeurtenis moest worden geschematiseerd en geconverteerd naar proto. Het zou een aanzienlijke verandering zijn die meerdere teams zou omvatten om producenten van gebeurtenissen te vragen om geserialiseerde proto-bytes te gebruiken en te verzenden. Om knelpunten aan te pakken en stapsgewijs waarde te leveren, hebben we het schematiseren losgekoppeld van de producenten van gebeurtenissen door de backend-service voor opname bij te werken om binnenkomende gebeurtenissen naar proto te converteren. Nu worden geconverteerde gebeurtenissen verzameld in parquet-bestanden, geüpload naar gedistribueerde opslag en geregistreerd als afzonderlijke Hive-tabellen.

Vervolgens hebben we ons gericht op de kosten van het aanbieden van analytische gebeurtenissen. Voorheen was de backend voor gegevensopname gebouwd op de cloudinfrastructuur. Analytische gebeurtenissen werden naar een wachtrijdienst gestuurd, die ze bufferde en vervolgens opsloeg in duurzame cloudopslag voor verdere verwerking en analyse. Hoewel een cloudwachtrijdienst onze service vereenvoudigde en transparante schaalbaarheid mogelijk maakte, is deze moeilijk te gebruiken voor andere streamingtaken en duurder. Om dit aan te pakken, hebben we onderzocht of we de opnamedienst naar de datacenters van Roblox konden verplaatsen. 

Ons interne opslagteam had Queue-as-a-Service (QaaS) gebouwd, gebaseerd op een open-source gedistribueerd platform voor het streamen van gebeurtenissen. QaaS is een uitstekende vervanging voor de opname van analytische gebeurtenissen, omdat gebeurtenissen in first-in, first-out-volgorde worden bijgehouden en na een korte bewaartermijn worden verwijderd. Bij Roblox maken we een speciaal onderwerp aan voor elke geschematiseerde gebeurtenis en gebruiken we het aantal partities om op te schalen voor grote gebeurtenisstromen. Het datateam heeft ook een speciale service gebouwd om gegevens uit QaaS te halen, Parquet-bestanden te maken en de bestanden te uploaden naar duurzame cloudopslag.

Met QaaS en een speciale service voor het bouwen en opslaan van Parquet-bestanden heeft het datateam zes maanden lang schaduwschrijvingen uitgevoerd om zowel de juistheid van de data als de schaalbaarheid te valideren. Uiteindelijk, na uitgebreide controles op de volledigheid en integriteit van de data, hebben we de opname van analytische gebeurtenissen met succes gemigreerd van onze oude cloudwachtrijservice. Dit was een belangrijke mijlpaal. We hebben de kosten voor cloudresources uit het opnameproces gehaald en de vertraging tussen het activeren van een gebeurtenis en het opslaan ervan in ons datameer aanzienlijk verminderd. Voorheen hadden we een serviceovereenkomst van drie uur, die we vaak niet haalden. Tegenwoordig halen we consequent een gemiddelde van 15 minuten. 

Hierdoor kunnen ingenieurs realtime pijplijnen voor gebeurtenisverwerking schrijven op basis van geschematiseerde gebeurtenissen door gebruik te maken van QaaS om veiligheids- en realtime aanbevelingsfuncties aan te sturen. We hebben ook change data capture gelanceerd met hetzelfde schematiseringsraamwerk en QaaS-opname, waardoor volledige databasedumps grotendeels overbodig zijn geworden. Van realtime analyses en gebeurtenisstreaming tot het ontsluiten van nieuwe use cases: ons werk gaat door terwijl we innoveren en slimmere, snellere en kostenefficiëntere datasystemen op schaal bouwen. 

We willen Paul Mou bedanken voor zijn waardevolle bijdragen aan dit werk.

^{* Per de drie maanden eindigend op 31 maart 2025.}