Il percorso di Roblox verso i 2 trilioni di eventi analitici al giorno

Ogni giorno, una media di 97,8 milioni di utenti* visita Roblox per comunicare, creare e giocare insieme. Nel loro insieme, queste interazioni generano 2 petabyte di dati relativi agli eventi analitici. Grazie a un nuovo sistema di acquisizione scalabile, abbiamo recentemente raggiunto un traguardo importante: il nostro sistema ora elabora più di 2 trilioni di eventi al giorno. Questo sistema rende possibili gli algoritmi di personalizzazione, sicurezza ed economia che alimentano la piattaforma Roblox.

In precedenza, un servizio di coda cloud acquisiva i dati analitici generati da Roblox in un'unica tabella logica, denominata events_hourly. Era suddivisa per data, ora e tag definiti arbitrariamente come web, mobile o friendService. I nostri data scientist e ingegneri si affidavano a processi batch pianificati per estrarre eventi specifici in tabelle dedicate. La creazione e l'invio di nuovi eventi analitici non richiedevano uno schema iniziale. Gli ingegneri controllavano il proprio schema di tabella a valle nella fase della pipeline di estrazione, trasformazione e caricamento (ETL).

Questa configurazione era flessibile e consentiva agli ingegneri di agire rapidamente, ma presentava delle sfide. 

• Con l'aumentare del volume degli eventi, l'interazione con 2 trilioni di righe suddivise solo per data, ora e tag è diventata sempre più inefficiente.
• Un ritardo di sei ore a fine giornata per la tabella events_hourly e di 24 ore per events_daily creava periodi in cui le pipeline di dati venivano bloccate. 
• La gestione delle autorizzazioni a livello di set di dati, del livello, della conservazione e degli avvisi è diventata più complessa. 
• Mancavano la documentazione, la cronologia e la proprietà degli eventi, con conseguente scarsa usabilità e tracciabilità dei dati. 
• L'infrastruttura di acquisizione, realizzata con il servizio di coda cloud, comportava un costo di acquisizione cloud di 23 Gbps.

L'analisi dei dati in precedenza si basava sull'estrazione dei dati da una singola tabella logica tramite numerose pipeline batch. Ciò era necessario per eseguire query di grandi dimensioni e ad alte prestazioni, ma rallentava anche l'elaborazione. L'utilizzo del servizio di backend di acquisizione per instradare questi eventi verso tabelle dedicate elimina le pipeline di estrazione batch, assegnando uno schema agli eventi analitici e definendo in anticipo una tabella di destinazione. 

Abbiamo scelto Protobuf (proto) come linguaggio di schema per gli eventi analitici in Roblox. Si è trattato di una scelta naturale, poiché proto e gRPC sono i nostri framework di servizi di sviluppo preferiti. Inoltre, proto offre un ottimo supporto per la definizione di opzioni personalizzate che sfruttiamo per raccogliere metadati aggiuntivi, quali proprietà, conservazione, canali del software di produttività e schema degli eventi. 

Dopo aver scelto il nostro linguaggio di schema, abbiamo esaminato cosa succede quando uno schema viene aggiornato e quali aggiornamenti dovrebbero essere consentiti. Per supportare il maggior numero possibile di consumatori a valle che utilizzano lo schema pubblicato, il team dei dati ha adottato la modalità transitiva a ritroso descritta in Schema Registry. Con questo approccio, è consentito aggiungere e cancellare in modo non definitivo un campo. Ciò consente di apportare modifiche allo schema senza richiedere il coordinamento con i consumatori a valle. 

Nell'esempio sopra riportato, è possibile aggiungere ed eliminare un campo aggiornando il file proto.

Gli schemi offrono molti vantaggi, ma richiederli in anticipo crea attrito. I data scientist e gli ingegneri devono muoversi rapidamente e iterare senza ostacoli. Per supportare questo, abbiamo introdotto un repository centralizzato di schemi e creato una suite di strumenti per rendere la creazione degli schemi il più automatizzata e snella possibile. 

Ad esempio, abbiamo creato un linter proto personalizzato per verificare che ogni schema abbia i metadati richiesti e sia conforme alle convenzioni di Roblox. Abbiamo anche creato un plug-in proto per tradurre uno schema di evento nel linguaggio di definizione dei dati Hive, in modo che la tabella Hive corrispondente rimanga sincronizzata ovunque venga creato o aggiornato uno schema. Tutti questi strumenti sono integrati in una pipeline CI/CD e vengono eseguiti automaticamente quando viene creata una richiesta pull. Ciò consente agli ingegneri di individuare tempestivamente i problemi relativi agli schemi e di verificare gli eventi nelle tabelle Hive di prova prima che i loro schemi vengano uniti. Di conseguenza, distribuire uno schema in produzione è semplice come unire. 

Con un'esperienza di sviluppo ottimizzata, abbiamo esaminato in quale punto della pipeline di acquisizione un evento dovesse essere schematizzato e convertito in proto. Chiedere ai produttori di eventi di adottare e inviare byte proto serializzati sarebbe stato un cambiamento significativo che avrebbe coinvolto più team. Per affrontare i punti critici e fornire valore in modo incrementale, abbiamo separato il lavoro di schematizzazione dai produttori di eventi aggiornando il servizio di backend di acquisizione per convertire gli eventi in arrivo in proto. Ora, gli eventi convertiti vengono raccolti in file Parquet, caricati su uno storage distribuito e registrati come singole tabelle Hive.

Successivamente, ci siamo concentrati sui costi di gestione degli eventi di analisi. In precedenza, il backend di acquisizione era basato sull'infrastruttura cloud. Gli eventi analitici venivano inviati a un servizio di coda, che li bufferizzava e poi li memorizzava in uno storage cloud durevole per l'elaborazione e l'analisi a valle. Sebbene un servizio di coda cloud semplificasse il nostro servizio e consentisse uno scaling trasparente, era difficile da utilizzare per altri lavori di streaming e più costoso. Per risolvere questo problema, abbiamo valutato la possibilità di portare il servizio di acquisizione nei data center di Roblox. 

Il nostro team di archiviazione interno aveva realizzato un servizio di coda (QaaS), basato su una piattaforma open-source di streaming di eventi distribuita. QaaS è un ottimo sostituto per l'acquisizione di eventi analitici perché gli eventi vengono gestiti in ordine first-in, first-out e cancellati dopo un breve periodo di conservazione. In Roblox, creiamo un argomento dedicato per ogni evento schematizzato e utilizziamo il conteggio delle partizioni per scalare i flussi di eventi di grandi dimensioni. Il team dei dati ha inoltre realizzato un servizio dedicato per l'utilizzo di QaaS, la creazione di file Parquet e il caricamento dei file su un archivio cloud durevole.

Con QaaS in funzione e un servizio dedicato per la creazione e l'archiviazione dei file Parquet, il team dei dati ha eseguito shadow write per sei mesi per convalidare sia la correttezza dei dati che la scalabilità. Infine, dopo approfonditi controlli di completezza e integrità dei dati, abbiamo migrato con successo l'acquisizione degli eventi analitici dal nostro vecchio servizio di coda cloud. Questa è stata una pietra miliare importante. Abbiamo eliminato il costo delle risorse cloud dal percorso di acquisizione e ridotto significativamente la latenza tra l'attivazione di un evento e il suo arrivo nel nostro data lake. In precedenza avevamo un accordo sul livello di servizio di tre ore, che spesso non riuscivamo a rispettare; oggi raggiungiamo costantemente una media di 15 minuti. 

Ciò consente agli ingegneri di scrivere pipeline di elaborazione degli eventi in tempo reale basate su eventi schematizzati, attingendo da QaaS per potenziare le funzionalità di sicurezza e di raccomandazione in tempo reale. Abbiamo inoltre lanciato la cattura dei dati modificati con lo stesso framework di schematizzazione e l'acquisizione QaaS, eliminando in gran parte i dump completi del database. Dall'analisi in tempo reale e dallo streaming di eventi allo sblocco di nuovi casi d'uso, il nostro lavoro continua mentre innoviamo e costruiamo sistemi di dati su larga scala più intelligenti, veloci ed economici. 

Vorremmo ringraziare Paul Mou per i suoi preziosi contributi a questo lavoro.

^{* Al 31 marzo 2025.}