El camino de Roblox hacia los 2 billones de eventos analíticos al día

Cada día, una media de 97,8 millones de usuarios* visitan Roblox para comunicarse, crear y jugar juntos. En conjunto, estas interacciones generan 2 petabytes de datos de eventos analíticos. Gracias a un nuevo sistema de ingestión escalable, recientemente hemos alcanzado un hito importante: nuestro sistema procesa ahora más de 2 billones de eventos al día. Este sistema permite los algoritmos de personalización, seguridad y economía que impulsan la plataforma Roblox.

Anteriormente, un servicio de colas en la nube ingería los datos analíticos generados por Roblox en una única tabla lógica, denominada events_hourly. Estaba particionada por fecha, hora y etiquetas definidas arbitrariamente, como web, mobile o friendService. Nuestros científicos de datos e ingenieros se basaban en trabajos por lotes programados para extraer eventos específicos a tablas dedicadas. La creación y el envío de nuevos eventos analíticos no requerían un esquema previo. Los ingenieros controlaban su propio esquema de tabla en la fase posterior del proceso de extracción, transformación y carga (ETL).

Esta configuración era flexible y permitía a los ingenieros actuar con rapidez, pero planteaba algunos retos. 

• A medida que aumentaba el volumen de eventos, interactuar con 2 billones de filas divididas únicamente por fecha, hora y etiquetas se volvió cada vez más ineficiente.
• Un retraso de seis horas al final del día para la tabla events_hourly y de 24 horas para events_daily creaba periodos en los que los flujos de datos quedaban bloqueados. 
• La gestión de los permisos, los niveles, la retención y las alertas a nivel de conjunto de datos se volvió más compleja. 
• Faltaban la documentación, el historial y la propiedad de los eventos, lo que daba lugar a una escasa usabilidad y trazabilidad de los datos. 
• La infraestructura de ingesta, construida con el servicio de colas en la nube, generaba un coste de ingesta en la nube de 23 Gbps.

Anteriormente, el análisis de datos se basaba en la extracción de datos de una única tabla lógica a través de numerosas canalizaciones por lotes. Esto era necesario para ejecutar consultas grandes y de alto rendimiento, pero también ralentizaba el procesamiento. El uso del servicio de backend de ingestión para enrutar estos eventos a tablas dedicadas elimina las canalizaciones de extracción por lotes, al asignar un esquema a los eventos analíticos y definir una tabla de destino de antemano. 

En Roblox elegimos Protobuf (proto) como lenguaje de esquema para los eventos analíticos. Fue una elección natural, ya que proto y gRPC son nuestros marcos de servicios de desarrollo preferidos. Además, proto ofrece un gran soporte para definir opciones personalizadas que aprovechamos para recopilar metadatos adicionales, como la propiedad, la retención, los canales de software de productividad y el esquema de eventos. 

Tras elegir nuestro lenguaje de esquema, examinamos qué ocurre cuando se actualiza un esquema y qué actualizaciones deben permitirse. Para dar soporte al mayor número posible de consumidores posteriores que utilizan el esquema publicado, el equipo de datos adoptó el modo transitivo hacia atrás descrito en el Registro de esquemas. Con este enfoque, se permite añadir y eliminar temporalmente un campo. Esto permite realizar cambios en el esquema sin necesidad de coordinarse con los consumidores posteriores. 

En el ejemplo anterior, podemos añadir y eliminar un campo actualizando el archivo proto.

Los esquemas ofrecen muchas ventajas, pero exigirlos desde el principio añade fricción. Los científicos de datos y los ingenieros necesitan actuar con rapidez y realizar iteraciones sin obstáculos. Para facilitar esto, hemos introducido un repositorio centralizado de esquemas y hemos creado un conjunto de herramientas para que la creación de esquemas sea lo más automatizada y optimizada posible. 

Por ejemplo, hemos creado un linter proto personalizado para validar que cada esquema tenga los metadatos necesarios y se ajuste a las convenciones de Roblox. También creamos un complemento proto para traducir un esquema de eventos al lenguaje de definición de datos de Hive, de modo que la tabla de Hive correspondiente se mantenga sincronizada siempre que se cree o actualice un esquema. Todas estas herramientas están integradas en un canal de CI/CD y se ejecutan automáticamente cuando se crea una solicitud de incorporación de cambios. Esto permite a los ingenieros detectar problemas en los esquemas de forma temprana y verificar los eventos en tablas de Hive de prueba antes de que se fusionen sus esquemas. Como resultado, implementar un esquema en producción es tan sencillo como fusionarlo. 

Una vez optimizada la experiencia de los desarrolladores, examinamos en qué punto del proceso de ingestión debía esquematizarse un evento y convertirse a proto. Pedir a los productores de eventos que adoptaran y enviaran bytes proto serializados supondría un cambio significativo que afectaría a varios equipos. Para abordar los puntos débiles y aportar valor de forma incremental, desvinculamos la tarea de esquematización de los productores de eventos actualizando el servicio backend de ingestión para convertir los eventos entrantes a proto. Ahora, los eventos convertidos se recopilan en archivos Parquet, se cargan en un almacenamiento distribuido y se registran como tablas Hive individuales.

A continuación, nos centramos en los costes de servir eventos de análisis. Anteriormente, el backend de ingestión se había construido sobre la infraestructura en la nube. Los eventos analíticos se enviaban a un servicio de colas, que los almacenaba en búfer y luego los guardaba en un almacenamiento duradero en la nube para su procesamiento y análisis posteriores. Aunque un servicio de colas en la nube simplificaba nuestro servicio y permitía un escalado transparente, resulta difícil de usar para otros trabajos de streaming y es más caro. Para solucionar esto, exploramos la posibilidad de trasladar el servicio de ingestión a los centros de datos de Roblox. 

Nuestro equipo interno de almacenamiento había creado un servicio de colas como servicio (QaaS), basado en una plataforma de streaming de eventos distribuida de código abierto. QaaS es un excelente sustituto para la ingesta de eventos analíticos, ya que los eventos se procesan en orden de «primero en entrar, primero en salir» y se eliminan tras un breve periodo de retención. En Roblox, creamos un tema específico para cada evento esquematizado y utilizamos el recuento de particiones para escalar en caso de grandes flujos de eventos. El equipo de datos también creó un servicio específico para consumir datos de QaaS, generar archivos Parquet y subirlos a un almacenamiento duradero en la nube.

Con QaaS en funcionamiento y un servicio dedicado a la creación y el almacenamiento de archivos Parquet, el equipo de datos realizó escrituras en la sombra durante seis meses para validar tanto la corrección de los datos como la escalabilidad. Finalmente, tras exhaustivas comprobaciones de la integridad y la exhaustividad de los datos, migramos con éxito la ingesta de eventos analíticos desde nuestro antiguo servicio de colas en la nube. Este fue un hito importante. Eliminamos el coste de los recursos en la nube de la ruta de ingestión y redujimos significativamente la latencia entre la activación de un evento y su llegada a nuestro lago de datos. Anteriormente teníamos un acuerdo de nivel de servicio de tres horas, que a menudo no cumplíamos; hoy en día, alcanzamos de forma constante una media de 15 minutos. 

Esto permite a los ingenieros escribir canalizaciones de procesamiento de eventos en tiempo real basadas en eventos esquematizados, utilizando QaaS para potenciar funciones de seguridad y recomendaciones en tiempo real. También hemos lanzado la captura de datos modificados con el mismo marco de esquematización y la ingesta de QaaS, lo que elimina en gran medida los volcados completos de bases de datos. Desde el análisis en tiempo real y la transmisión de eventos hasta el desarrollo de nuevos casos de uso, nuestro trabajo continúa a medida que innovamos y construimos sistemas de datos a gran escala más inteligentes, rápidos y rentables. 

Nos gustaría agradecer a Paul Mou sus valiosas contribuciones a este trabajo.

^{* A fecha del trimestre finalizado el 31 de marzo de 2025.}