Le parcours de Roblox vers les 2 000 milliards d'événements analytiques par jour

Chaque jour, 97,8 millions d'utilisateurs* en moyenne se rendent sur Roblox pour communiquer, créer et jouer ensemble. Ensemble, ces interactions génèrent 2 pétaoctets de données d'événements analytiques. Grâce à un nouveau système d'ingestion évolutif, nous avons récemment franchi une étape majeure : notre système traite désormais plus de 2 000 milliards d'événements par jour. Ce système permet le fonctionnement des algorithmes de personnalisation, de sécurité et d'économie qui alimentent la plateforme Roblox.

Auparavant, un service de file d'attente cloud ingérait les données analytiques générées par Roblox dans une table logique unique, appelée events_hourly. Celle-ci était partitionnée par date, heure et balises définies arbitrairement telles que web, mobile ou friendService. Nos data scientists et ingénieurs s'appuyaient sur des tâches batch planifiées pour extraire des événements spécifiques vers des tables dédiées. La création et l'envoi de nouveaux événements analytiques ne nécessitaient aucun schéma prédéfini. Les ingénieurs contrôlaient leur propre schéma de table en aval, au stade du pipeline d'extraction, de transformation et de chargement (ETL).

Cette configuration était flexible et permettait aux ingénieurs d'agir rapidement, mais elle posait des défis. 

• À mesure que le volume d'événements augmentait, l'interaction avec 2 000 milliards de lignes partitionnées uniquement par date, heure et balises devenait de plus en plus inefficace.
• Un délai de six heures en fin de journée pour la table events_hourly et un délai de 24 heures pour events_daily créaient des périodes pendant lesquelles les pipelines de données étaient bloqués. 
• La gestion des autorisations au niveau des ensembles de données, des niveaux de stockage, de la conservation et des alertes est devenue plus complexe. 
• La documentation, l'historique et la propriété des événements faisaient défaut, ce qui nuisait à la facilité d'utilisation et à la traçabilité des données. 
• L'infrastructure d'ingestion, construite avec le service de file d'attente cloud, a engendré un coût d'ingestion cloud de 23 Gbps.

L'analyse des données reposait auparavant sur l'extraction de données à partir d'une seule table logique via de nombreux pipelines par lots. Cela était nécessaire pour exécuter des requêtes volumineuses et performantes, mais cela ralentissait également le traitement. L'utilisation du service backend d'ingestion pour acheminer ces événements vers des tables dédiées élimine les pipelines d'extraction par lots en attribuant un schéma aux événements analytiques et en définissant une table de destination à l'avance. 

Nous avons choisi Protobuf (proto) comme langage de schéma pour les événements analytiques chez Roblox. Ce choix s'est imposé naturellement, car proto et gRPC sont nos frameworks de services de développement préférés. De plus, proto offre une excellente prise en charge pour la définition d'options personnalisées que nous exploitons pour collecter des métadonnées supplémentaires, telles que la propriété, la conservation, les canaux de logiciels de productivité et le schéma d'événements. 

Après avoir choisi notre langage de schéma, nous avons examiné ce qui se passe lorsqu'un schéma est mis à jour et quelles mises à jour devaient être autorisées. Afin de prendre en charge le plus grand nombre possible d'utilisateurs en aval utilisant le schéma publié, l'équipe chargée des données a adopté le mode transitif vers l'arrière décrit dans le registre de schémas. Avec cette approche, l'ajout et la suppression temporaire d'un champ sont autorisés. Cela permet de modifier le schéma sans avoir à coordonner ces changements avec les utilisateurs en aval. 

Dans l'exemple ci-dessus, nous pouvons ajouter et supprimer un champ en mettant à jour le fichier proto.

Les schémas offrent de nombreux avantages, mais leur imposition dès le départ crée des frictions. Les data scientists et les ingénieurs doivent pouvoir agir rapidement et itérer sans obstacle. Pour y parvenir, nous avons mis en place un référentiel centralisé de schémas et développé une suite d'outils visant à automatiser et rationaliser au maximum la création de schémas. 

Par exemple, nous avons développé un linter Proto personnalisé pour vérifier que chaque schéma contient les métadonnées requises et respecte les conventions Roblox. Nous avons également développé un plugin Proto pour traduire un schéma d'événement en langage de définition de données Hive, afin que la table Hive correspondante reste synchronisée quel que soit l'endroit où un schéma est créé ou mis à jour. Tous ces outils sont intégrés dans un pipeline CI/CD et s'exécutent automatiquement lorsqu'une pull request est créée. Cela permet aux ingénieurs de détecter rapidement les problèmes de schéma et de vérifier les événements dans des tables Hive de test avant que leurs schémas ne soient fusionnés. Par conséquent, le déploiement d'un schéma en production est aussi simple qu'une fusion. 

Une fois l'expérience développeur rationalisée, nous avons examiné à quel stade du pipeline d'ingestion un événement devait être schématisé et converti en proto. Demander aux producteurs d'événements d'adopter et d'envoyer des octets proto sérialisés aurait constitué un changement significatif impliquant plusieurs équipes. Pour résoudre les points sensibles et apporter de la valeur de manière incrémentielle, nous avons dissocié l'effort de schématisation des producteurs d'événements en mettant à jour le service backend d'ingestion afin de convertir les événements entrants en proto. Désormais, les événements convertis sont regroupés dans des fichiers Parquet, téléchargés vers un stockage distribué et enregistrés en tant que tables Hive individuelles.

Nous nous sommes ensuite intéressés aux coûts liés à la diffusion des événements analytiques. Auparavant, le backend d’ingestion était construit sur l’infrastructure cloud. Les événements analytiques étaient envoyés vers un service de file d'attente, qui les mettait en mémoire tampon puis les stockait dans un espace de stockage cloud durable en vue d'un traitement et d'une analyse en aval. Si un service de file d'attente cloud simplifiait notre service et permettait une évolutivité transparente, il était difficile à utiliser pour d'autres tâches de streaming et plus coûteux. Pour remédier à cela, nous avons envisagé d'intégrer le service d'ingestion dans les centres de données de Roblox. 

Notre équipe de stockage interne avait développé un service de file d’attente (QaaS), basé sur une plateforme open source de streaming d’événements distribuée. Le QaaS est un excellent substitut pour l’ingestion d’événements analytiques, car les événements sont traités selon le principe « premier entré, premier sorti » et supprimés après une courte période de conservation. Chez Roblox, nous créons un sujet dédié pour chaque événement schématisé et utilisons le nombre de partitions pour faire évoluer le système en fonction des flux d’événements volumineux. L’équipe chargée des données a également mis en place un service dédié pour extraire les données de QaaS, créer des fichiers Parquet et les télécharger vers un stockage cloud durable.

Une fois QaaS en place et grâce à un service dédié à la création et au stockage des fichiers Parquet, l’équipe chargée des données a effectué des écritures fantômes pendant six mois afin de valider à la fois l’exactitude des données et l’évolutivité du système. Enfin, après des vérifications approfondies de l’exhaustivité et de l’intégrité des données, nous avons réussi à migrer l’ingestion des événements analytiques hors de notre ancien service de file d’attente cloud. Il s’agissait d’une étape majeure. Nous avons supprimé le coût des ressources cloud du parcours d'ingestion et considérablement réduit la latence entre le déclenchement d'un événement et son arrivée dans notre lac de données. Nous avions auparavant un accord de niveau de service de trois heures, que nous ne respections souvent pas ; aujourd'hui, nous atteignons systématiquement une moyenne de 15 minutes. 

Cela permet aux ingénieurs de créer des pipelines de traitement d'événements en temps réel à partir d'événements schématisés en s'appuyant sur QaaS pour alimenter des fonctionnalités de sécurité et de recommandation en temps réel. Nous avons également lancé la capture des données modifiées avec le même cadre de schématisation et l'ingestion QaaS, éliminant ainsi en grande partie les sauvegardes complètes de bases de données. De l'analyse en temps réel et du streaming d'événements à l'ouverture de nouveaux cas d'utilisation, notre travail se poursuit alors que nous innovons et construisons des systèmes de données à grande échelle plus intelligents, plus rapides et plus rentables. 

Nous tenons à remercier Paul Mou pour ses précieuses contributions à ce travail.

^{* Au 31 mars 2025.}