Roblox’ Weg zu 2 Billionen Analyseereignissen pro Tag

Jeden Tag besuchen durchschnittlich 97,8 Millionen Nutzer* Roblox, um miteinander zu kommunizieren, Inhalte zu erstellen und gemeinsam zu spielen. Zusammen generieren diese Interaktionen 2 Petabyte an Analyseereignisdaten. Dank eines neuen skalierbaren Erfassungssystems haben wir kürzlich einen wichtigen Meilenstein erreicht: Unser System verarbeitet nun mehr als 2 Billionen Ereignisse pro Tag. Dieses System ermöglicht die Personalisierungs-, Sicherheits- und Wirtschaftsalgorithmen, die die Roblox-Plattform antreiben.

Zuvor speiste ein Cloud-Queue-Dienst die von Roblox generierten Analysedaten in eine einzige logische Tabelle namens „events_hourly“ ein. Diese war nach Datum, Uhrzeit und willkürlich definierten Tags wie „web“, „mobile“ oder „friendService“ partitioniert. Unsere Datenwissenschaftler und Ingenieure stützten sich auf geplante Batch-Jobs, um bestimmte Ereignisse in dedizierte Tabellen zu extrahieren. Das Erstellen und Senden neuer Analyseereignisse erforderte kein vorab definiertes Schema. Die Ingenieure kontrollierten ihr eigenes Tabellenschema nachgelagert in der ETL-Pipeline-Phase (Extract, Transform, Load).

Diese Konfiguration war flexibel und ermöglichte es den Ingenieuren, schnell zu handeln, stellte sie jedoch vor Herausforderungen. 

• Da das Ereignisvolumen wuchs, wurde die Arbeit mit 2 Billionen Zeilen, die nur nach Datum, Uhrzeit und Tags partitioniert waren, zunehmend ineffizient.
• Eine Verzögerung von sechs Stunden am Tagesende für die Tabelle „events_hourly“ und eine Verzögerung von 24 Stunden für „events_daily“ führten zu Zeiträumen, in denen die Datenpipelines blockiert waren. 
• Die Verwaltung von Berechtigungen, Ebenen, Aufbewahrungsfristen und Warnmeldungen auf Datensatzebene wurde komplexer. 
• Es fehlten Ereignisdokumentation, -historie und -verantwortlichkeit, was zu einer schlechten Verwertbarkeit und Rückverfolgbarkeit der Daten führte. 
• Die mit dem Cloud-Queue-Service aufgebaute Erfassungsinfrastruktur verursachte Cloud-Erfassungskosten in Höhe von 23 Gbit/s.

Die Datenanalyse stützte sich bisher auf die Extraktion von Daten aus einer einzigen logischen Tabelle über zahlreiche Batch-Pipelines. Dies war notwendig, um umfangreiche, leistungsstarke Abfragen auszuführen – verlangsamte jedoch auch die Verarbeitung. Durch die Nutzung des Ingest-Backend-Dienstes zur Weiterleitung dieser Ereignisse an dedizierte Tabellen entfallen die Batch-Extraktionspipelines, da den Analyseereignissen ein Schema zugewiesen und die Zieltabelle im Voraus definiert wird. 

Wir haben uns bei Roblox für Protobuf (proto) als Schemasprache für Analyseereignisse entschieden. Dies war eine naheliegende Wahl, da proto und gRPC unsere bevorzugten Frameworks für die Entwicklung von Diensten sind. Darüber hinaus bietet proto hervorragende Unterstützung für die Definition benutzerdefinierter Optionen, die wir nutzen, um zusätzliche Metadaten zu erfassen, wie z. B. Eigentumsverhältnisse, Aufbewahrungsfristen, Produktivitätssoftware-Kanäle und Ereignisschemata. 

Nachdem wir unsere Schemasprache ausgewählt hatten, untersuchten wir, was bei einer Schemaaktualisierung geschieht und welche Aktualisierungen zulässig sein sollten. Um die größtmögliche Anzahl von nachgelagerten Verbrauchern zu unterstützen, die das veröffentlichte Schema nutzen, entschied sich das Datenteam für den in der Schema Registry beschriebenen rückwärts-transitiven Modus. Bei diesem Ansatz ist das Hinzufügen und das weiche Löschen eines Feldes zulässig. Dies ermöglicht Schemaänderungen, ohne dass eine Abstimmung mit nachgelagerten Verbrauchern erforderlich ist. 

Im obigen Beispiel können wir ein Feld hinzufügen und löschen, indem wir die Proto-Datei aktualisieren.

Schemas bieten viele Vorteile, aber ihre Vorab-Anforderung verursacht Reibungsverluste. Datenwissenschaftler und Ingenieure müssen schnell vorankommen und ohne Hindernisse iterieren können. Um dies zu unterstützen, haben wir ein zentrales Schema-Repository eingeführt und eine Reihe von Tools entwickelt, um die Erstellung von Schemas so automatisiert und optimiert wie möglich zu gestalten. 

So haben wir beispielsweise einen benutzerdefinierten Proto-Linter entwickelt, um zu überprüfen, ob jedes Schema über die erforderlichen Metadaten verfügt und den Roblox-Konventionen entspricht. Außerdem haben wir ein Proto-Plugin entwickelt, um ein Ereignisschema in die Hive-Datendefinitionssprache zu übersetzen, sodass die entsprechende Hive-Tabelle synchron bleibt, unabhängig davon, wo ein Schema erstellt oder aktualisiert wird. Alle diese Tools sind in eine CI/CD-Pipeline integriert und werden automatisch ausgeführt, wenn ein Pull-Request erstellt wird. Dies ermöglicht es Ingenieuren, Schemaprobleme frühzeitig zu erkennen und Ereignisse in Test-Hive-Tabellen zu überprüfen, bevor ihre Schemata zusammengeführt werden. Infolgedessen ist die Bereitstellung eines Schemas in der Produktion so einfach wie das Zusammenführen. 

Nachdem wir eine optimierte Entwicklererfahrung geschaffen hatten, untersuchten wir, an welcher Stelle in der Erfassungspipeline ein Ereignis schematisiert und in Proto konvertiert werden sollte. Die Aufforderung an die Ereignisproduzenten, serialisierte Proto-Bytes zu übernehmen und zu senden, wäre eine erhebliche Änderung gewesen, die mehrere Teams betroffen hätte. Um Schwachstellen zu beheben und schrittweise Mehrwert zu schaffen, haben wir den Schematisierungsaufwand von den Ereignisproduzenten entkoppelt, indem wir den Erfassungs-Backend-Dienst so aktualisierten, dass eingehende Ereignisse in Proto konvertiert werden. Nun werden die konvertierten Ereignisse in Parquet-Dateien gesammelt, in einen verteilten Speicher hochgeladen und als einzelne Hive-Tabellen registriert.

Als Nächstes haben wir uns auf die Kosten für die Bereitstellung von Analyseereignissen konzentriert. Zuvor basierte das Backend für die Datenerfassung auf der Cloud-Infrastruktur. Analytik-Ereignisse wurden an einen Queue-Dienst gesendet, der sie zwischenspeicherte und anschließend in einem dauerhaften Cloud-Speicher für die nachgelagerte Verarbeitung und Analyse ablegte. Ein Cloud-Queue-Dienst vereinfachte zwar unseren Service und ermöglichte eine transparente Skalierung, ist jedoch für andere Streaming-Jobs schwer nutzbar und zudem teurer. Um dieses Problem zu lösen, prüften wir die Möglichkeit, den Erfassungsdienst in die Rechenzentren von Roblox zu verlagern. 

Unser internes Speicherteam hatte „Queue-as-a-Service“ (QaaS) entwickelt, basierend auf einer Open-Source-Plattform für verteiltes Event-Streaming. QaaS ist ein hervorragender Ersatz für die Erfassung von Analyseereignissen, da Ereignisse in First-In-First-Out-Reihenfolge verarbeitet und nach einer kurzen Aufbewahrungsfrist gelöscht werden. Bei Roblox erstellen wir für jedes schematisierte Ereignis ein eigenes Topic und nutzen die Partitionsanzahl zur Skalierung bei großen Ereignisströmen. Das Datenteam entwickelte zudem einen dedizierten Dienst, um Daten aus QaaS zu beziehen, Parquet-Dateien zu erstellen und diese in einen dauerhaften Cloud-Speicher hochzuladen.

Mit QaaS und einem dedizierten Dienst zum Erstellen und Speichern von Parquet-Dateien führte das Datenteam sechs Monate lang Schatten-Schreibvorgänge durch, um sowohl die Datenkorrektheit als auch die Skalierbarkeit zu validieren. Schließlich, nach umfangreichen Prüfungen der Datenvollständigkeit und -integrität, migrierten wir die Erfassung analytischer Ereignisse erfolgreich von unserem alten Cloud-Queue-Dienst weg. Dies war ein wichtiger Meilenstein. Wir haben die Kosten für Cloud-Ressourcen aus dem Erfassungsprozess entfernt und die Latenz zwischen dem Auslösen eines Ereignisses und dessen Speicherung in unserem Data Lake deutlich reduziert. Früher hatten wir eine Service-Level-Vereinbarung von drei Stunden, die wir oft nicht einhalten konnten – heute erreichen wir durchweg einen Durchschnitt von 15 Minuten. 

Dies ermöglicht es Ingenieuren, Echtzeit-Verarbeitungs-Pipelines für schematisierte Ereignisse zu erstellen, indem sie Daten aus QaaS nutzen, um Sicherheits- und Echtzeit-Empfehlungsfunktionen zu unterstützen. Wir haben außerdem die Erfassung von Datenänderungen mit demselben Schematisierungs-Framework und der QaaS-Erfassung eingeführt, wodurch vollständige Datenbank-Dumps weitgehend entfallen. Von Echtzeitanalysen und Event-Streaming bis hin zur Erschließung neuer Anwendungsfälle – unsere Arbeit geht weiter, während wir innovativ sind und intelligentere, schnellere und kosteneffizientere Datensysteme in großem Maßstab aufbauen. 

Wir möchten Paul Mou für seine wertvollen Beiträge zu dieser Arbeit danken.

^{* Stand: 31. März 2025.}