Perjalanan Roblox Menuju 2 Triliun Acara Analitik Per Hari

Setiap hari, rata-rata 97,8 juta pengguna* mengunjungi Roblox untuk berkomunikasi, berkreasi, dan bermain bersama. Secara keseluruhan, interaksi ini menghasilkan 2 petabyte data peristiwa analitik. Berkat sistem penyerapan baru yang dapat diskalakan, kami baru-baru ini mencapai tonggak penting: Sistem kami kini memproses lebih dari 2 triliun peristiwa per hari. Sistem ini memungkinkan algoritme personalisasi, keamanan, dan ekonomi yang mendukung platform Roblox.

Sebelumnya, layanan antrian cloud mengimpor data analitik yang dihasilkan Roblox ke dalam satu tabel logis, yang disebut events_hourly. Tabel ini dipartisi berdasarkan tanggal, jam, dan tag yang didefinisikan secara arbitrer seperti web, mobile, atau friendService. Para ilmuwan data dan insinyur kami mengandalkan pekerjaan batch yang dijadwalkan untuk mengekstrak peristiwa tertentu ke dalam tabel khusus. Membuat dan mengirim peristiwa analitik baru tidak memerlukan skema di awal. Insinyur mengontrol skema tabel mereka sendiri di hilir pada tahap pipa ekstraksi, transformasi, dan pemuatan (ETL).

Pengaturan ini fleksibel dan memungkinkan para insinyur untuk bergerak cepat, tetapi juga menghadirkan tantangan. 

• Seiring bertambahnya volume peristiwa, berinteraksi dengan 2 triliun baris yang hanya dipartisi berdasarkan tanggal, jam, dan tag menjadi semakin tidak efisien.
• Penundaan enam jam di akhir hari untuk tabel events_hourly dan penundaan 24 jam untuk events_daily menyebabkan periode di mana pipa data terhambat. 
• Pengelolaan izin tingkat dataset, tingkatan, retensi, dan peringatan menjadi lebih rumit. 
• Dokumentasi, riwayat, dan kepemilikan peristiwa tidak tersedia, sehingga mengakibatkan rendahnya kegunaan dan keterlacakan data. 
• Infrastruktur ingestion, yang dibangun dengan layanan antrian cloud, menimbulkan biaya ingestion cloud sebesar 23 Gbps.

Analisis data sebelumnya bergantung pada ekstraksi data dari satu tabel logis melalui banyak pipa batch. Hal ini diperlukan untuk menjalankan kueri besar dan berkinerja tinggi—tetapi juga memperlambat pemrosesan. Menggunakan layanan backend ingestion untuk mengarahkan peristiwa ini ke tabel khusus menghilangkan pipa ekstraksi batch dengan memberikan skema pada peristiwa analitik dan menentukan tabel tujuan sebelumnya. 

Kami memilih Protobuf (proto) sebagai bahasa skema untuk peristiwa analitik di Roblox. Ini adalah pilihan yang wajar, karena proto dan gRPC adalah kerangka kerja layanan pembangunan yang kami sukai. Selain itu, proto menawarkan dukungan yang sangat baik untuk menentukan opsi khusus yang kami manfaatkan untuk mengumpulkan metadata tambahan, seperti kepemilikan, retensi, saluran perangkat lunak produktivitas, dan skema peristiwa. 

Setelah memilih bahasa skema kami, kami meneliti apa yang terjadi saat skema diperbarui dan pembaruan mana yang boleh dilakukan. Untuk mendukung sebanyak mungkin pengguna hilir yang menggunakan skema yang dipublikasikan, tim data mengadopsi mode transitif mundur yang dijelaskan di Schema Registry. Dengan pendekatan ini, penambahan dan penghapusan lembut suatu bidang diperbolehkan. Hal ini memungkinkan perubahan skema tanpa memerlukan koordinasi dengan pengguna hilir. 

Dalam contoh di atas, kita dapat menambahkan dan menghapus bidang dengan memperbarui berkas proto.

Skema menawarkan banyak manfaat, tetapi mewajibkan penggunaannya sejak awal dapat menimbulkan hambatan. Ilmuwan data dan insinyur perlu bergerak cepat dan melakukan iterasi tanpa hambatan. Untuk mendukung hal ini, kami memperkenalkan repositori skema terpusat dan membangun serangkaian alat untuk membuat penulisan skema seotomatis dan seefisien mungkin. 

Misalnya, kami membangun linter proto khusus untuk memvalidasi bahwa setiap skema memiliki metadata yang diperlukan dan sesuai dengan konvensi Roblox. Kami juga membangun plugin Proto untuk menerjemahkan skema acara ke dalam bahasa definisi data Hive, sehingga tabel Hive yang sesuai tetap sinkron di mana pun skema dibuat atau diperbarui. Semua alat ini terintegrasi ke dalam pipeline CI/CD dan berjalan secara otomatis saat permintaan pull dibuat. Hal ini memungkinkan insinyur untuk mendeteksi masalah skema sejak dini dan memverifikasi acara di tabel Hive uji sebelum skema digabungkan. Akibatnya, mengimplementasikan skema ke produksi sesederhana menggabungkannya. 

Dengan pengalaman pengembang yang telah disederhanakan, kami meneliti di mana dalam pipa ingestion sebuah peristiwa harus diskematisasikan dan dikonversi ke proto. Meminta produsen peristiwa untuk mengadopsi dan mengirim byte proto yang diserialisasi akan menjadi perubahan signifikan yang melibatkan banyak tim. Untuk mengatasi masalah dan memberikan nilai secara bertahap, kami memisahkan upaya skematisasi dari produsen peristiwa dengan memperbarui layanan backend ingestion untuk mengonversi peristiwa yang masuk ke proto. Sekarang, peristiwa yang telah dikonversi dikumpulkan ke dalam file parquet, diunggah ke penyimpanan terdistribusi, dan didaftarkan sebagai tabel Hive individual.

Selanjutnya, kami berfokus pada biaya penyampaian peristiwa analitik. Sebelumnya, backend pengambilan data dibangun di atas infrastruktur cloud. Peristiwa analitik dikirim ke layanan antrian, yang menyimpannya sementara dan kemudian menyimpannya di penyimpanan cloud yang tahan lama untuk pemrosesan dan analisis hilir. Meskipun layanan antrian cloud menyederhanakan layanan kami dan memungkinkan penskalaan yang transparan, layanan ini sulit digunakan oleh pekerjaan streaming lain dan lebih mahal. Untuk mengatasi hal ini, kami menjajaki kemungkinan untuk membawa layanan ingestion ke pusat data Roblox. 

Tim penyimpanan internal kami telah membangun queue-as-a-service (QaaS), berdasarkan platform streaming acara terdistribusi open-source. QaaS merupakan pengganti yang ideal untuk pengambilan acara analitik karena acara diproses secara first-in, first-out dan dihapus setelah periode retensi singkat. Di Roblox, kami membuat topik khusus untuk setiap peristiwa yang telah diskematisasikan dan menggunakan jumlah partisi untuk menskalakan aliran peristiwa besar. Tim data juga membangun layanan khusus untuk mengonsumsi data dari QaaS, membuat file Parquet, dan mengunggah file tersebut ke penyimpanan awan yang tahan lama.

Dengan QaaS yang sudah terpasang dan layanan khusus untuk membuat serta menyimpan file Parquet, tim data melakukan penulisan bayangan selama enam bulan untuk memvalidasi keakuratan data dan skalabilitas. Akhirnya, setelah pemeriksaan kelengkapan dan integritas data yang ekstensif, kami berhasil memigrasikan pengambilan data analitik dari layanan antrian cloud lama kami. Ini merupakan tonggak penting. Kami menghilangkan biaya sumber daya cloud dari jalur pengambilan data dan secara signifikan mengurangi latensi antara pemicu peristiwa dan penyimpanan di data lake kami. Sebelumnya, kami memiliki perjanjian tingkat layanan (SLA) tiga jam, yang seringkali tidak terpenuhi—sekarang, kami secara konsisten mencapai rata-rata 15 menit. 

Hal ini memungkinkan para insinyur untuk menulis pipa pemrosesan peristiwa waktu nyata terhadap peristiwa yang diskematisasikan dengan mengonsumsi dari QaaS untuk mendukung fitur keamanan dan rekomendasi waktu nyata. Kami juga meluncurkan penangkapan data perubahan dengan kerangka kerja skematisasi yang sama dan penyerapan QaaS, yang secara besar-besaran menghilangkan dump basis data penuh. Dari analitik waktu nyata dan streaming peristiwa hingga membuka kasus penggunaan baru, pekerjaan kami terus berlanjut seiring kami berinovasi dan membangun sistem data yang lebih cerdas, lebih cepat, dan lebih hemat biaya dalam skala besar. 

Kami ingin mengucapkan terima kasih kepada Paul Mou atas kontribusinya yang berharga dalam pekerjaan ini.

^{* Per tiga bulan yang berakhir pada 31 Maret 2025.}