Roblox'un Günde 2 Trilyon Analitik Olayına Giden Yolu

Her gün ortalama 97,8 milyon kullanıcı* iletişim kurmak, içerik oluşturmak ve birlikte oynamak için Roblox'u ziyaret ediyor. Bu etkileşimler toplamda 2 petabaytlık analitik olay verisi oluşturuyor. Yeni ve ölçeklenebilir bir veri alım sistemi sayesinde kısa süre önce önemli bir dönüm noktasına ulaştık: Sistemimiz artık günde 2 trilyondan fazla olayı işliyor. Bu sistem, Roblox platformunu destekleyen kişiselleştirme, güvenlik ve ekonomi algoritmalarını mümkün kılıyor.

Daha önce, bir bulut kuyruk hizmeti, Roblox tarafından üretilen analitik verileri events_hourly adlı tek bir mantıksal tabloya alıyordu. Bu tablo tarih, saat ve web, mobil veya friendService gibi keyfi olarak tanımlanmış etiketlere göre bölümlere ayrılmıştı. Veri bilimcilerimiz ve mühendislerimiz, belirli olayları özel tablolara aktarmak için planlanmış toplu işlere güveniyordu. Yeni analitik olayların oluşturulması ve gönderilmesi için önceden bir şema gerekmiyordu. Mühendisler, ETL (extract, transform, load) boru hattı aşamasında kendi tablo şemalarını kontrol ediyordu.

Bu yapı esnekti ve mühendislerin hızlı hareket etmesini sağlıyordu, ancak bazı zorluklar da ortaya çıkardı. 

• Olayların hacmi arttıkça, yalnızca tarih, saat ve etiketlere göre bölümlere ayrılmış 2 trilyon satırla etkileşim kurmak giderek verimsiz hale geldi.
• events_hourly tablosu için gün sonu altı saatlik gecikme ve events_daily tablosu için 24 saatlik gecikme, veri boru hatlarının tıkandığı dönemler yaratıyordu. 
• Veri kümesi düzeyinde izinleri, katmanları, saklama sürelerini ve uyarıları yönetmek daha karmaşık hale geldi. 
• Olay belgeleri, geçmişi ve sahipliği eksikti, bu da verilerin kullanılabilirliği ve izlenebilirliğinin zayıf olmasına neden oldu. 
• Bulut kuyruk hizmeti ile oluşturulan veri alımı altyapısı, 23 Gbps'lik bir bulut veri alımı maliyetine neden oldu.

Veri analitiği, daha önce birçok toplu iş boru hattı aracılığıyla tek bir mantıksal tablodan veri çıkarılmasına dayanıyordu. Bu, büyük ve yüksek performanslı sorguları çalıştırmak için gerekliydi, ancak aynı zamanda işlemeyi de yavaşlatıyordu. Bu olayları özel tablolara yönlendirmek için veri alımı arka uç hizmetini kullanmak, analitik olaylara bir şema vererek ve hedef tabloyu önceden tanımlayarak toplu iş çıkarma boru hatlarını ortadan kaldırır. 

Roblox'ta analiz olayları için şema dili olarak Protobuf'u (proto) seçtik. Proto ve gRPC, tercih ettiğimiz hizmet çerçeveleri olduğu için bu doğal bir tercihti. Ayrıca proto, sahiplik, saklama, üretkenlik yazılımı kanalları ve olay şeması gibi ek meta verileri toplamak için kullandığımız özel seçenekleri tanımlamaya yönelik mükemmel destek sunar. 

Şema dilimizi seçtikten sonra, bir şema güncellendiğinde ne olacağını ve hangi güncellemelerin izin verilmesi gerektiğini inceledik. Yayınlanan şemayı kullanan en fazla sayıda alt tüketiciyi desteklemek için, veri ekibi Schema Registry'de açıklanan geriye dönük geçişli modu benimsedi. Bu yaklaşımla, bir alanın eklenmesi ve geçici olarak silinmesi izin verilir. Bu, alt tüketicilerle koordinasyon gerektirmeden şema değişikliklerine olanak tanır. 

Yukarıdaki örnekte, proto dosyasını güncelleyerek bir alan ekleyebilir ve silebiliriz.

Şemalar birçok fayda sağlar, ancak bunların önceden talep edilmesi işleri zorlaştırır. Veri bilimcileri ve mühendisleri hızlı hareket etmeli ve engelsiz bir şekilde yineleme yapmalıdır. Bunu desteklemek için, merkezi bir şema deposu getirdik ve şema oluşturmayı olabildiğince otomatik ve verimli hale getirmek için bir dizi araç geliştirdik. 

Örneğin, her şemanın gerekli meta verilere sahip olduğunu ve Roblox kurallarına uygun olduğunu doğrulamak için özel bir proto linter geliştirdik. Ayrıca, bir olay şemasını Hive veri tanımlama diline çevirmek için bir proto eklentisi geliştirdik; böylece, şema nerede oluşturulur veya güncellenirse güncellenilsin, ilgili Hive tablosu senkronize kalır. Tüm bu araçlar bir CI/CD boru hattına entegre edilmiştir ve bir çekme isteği oluşturulduğunda otomatik olarak çalışır. Bu, mühendislerin şema sorunlarını erken tespit etmelerine ve şemaları birleştirilmeden önce test Hive tablolarındaki olayları doğrulamalarına olanak tanır. Sonuç olarak, bir şemayı üretime dağıtmak, birleştirme kadar basittir. 

Kolaylaştırılmış bir geliştirici deneyimi sağlandıktan sonra, alım boru hattının hangi noktasında bir olayın şemaya dönüştürülmesi ve proto'ya dönüştürülmesi gerektiğini inceledik. Olay üreticilerinden serileştirilmiş proto baytlarını benimsemelerini ve göndermelerini istemek, birden fazla ekibi kapsayan önemli bir değişiklik olurdu. Sorunlu noktaları gidermek ve kademeli olarak değer sunmak için, gelen olayları proto'ya dönüştürmek üzere alım arka uç hizmetini güncelleyerek şemaya dönüştürme çalışmasını olay üreticilerinden ayırdık. Artık dönüştürülen olaylar parquet dosyalarına toplanıyor, dağıtılmış depolamaya yükleniyor ve ayrı Hive tabloları olarak kaydediliyor.

Ardından, analitik olaylarını sunmanın maliyetlerine odaklandık. Daha önce, veri alımı arka ucu bulut altyapısı üzerine kurulmuştu. Analitik olaylar bir kuyruk hizmetine gönderiliyordu; bu hizmet, olayları tamponlayıp daha sonra aşağı akış işleme ve analiz için dayanıklı bulut depolama alanında saklıyordu. Bulut kuyruk hizmeti, hizmetimizi basitleştirip şeffaf ölçeklendirme imkanı sağlasa da, diğer akış işleri tarafından kullanılması zordu ve daha pahalıydı. Bu sorunu çözmek için, veri alımı hizmetini Roblox'un veri merkezlerine taşımayı düşündük. 

Şirket içi depolama ekibimiz, açık kaynaklı bir dağıtılmış olay akışı platformuna dayalı bir kuyruk hizmeti (QaaS) oluşturmuştu. QaaS, olaylar ilk giren ilk çıkar (FIFO) sırasına göre takip edildiği ve kısa bir saklama süresinden sonra silindiği için analitik olay alımının yerine geçmek için harika bir seçenektir. Roblox'ta, şematize edilmiş her olay için özel bir konu oluşturuyoruz ve büyük olay akışları için ölçeklendirme amacıyla bölüm sayısını kullanıyoruz. Veri ekibi ayrıca QaaS'tan veri almak, parquet dosyaları oluşturmak ve dosyaları dayanıklı bulut depolama alanına yüklemek için özel bir hizmet geliştirdi.

QaaS'ın devreye alınması ve parquet dosyalarını oluşturmak ve depolamak için özel bir hizmetin kurulmasıyla, veri ekibi hem verilerin doğruluğunu hem de ölçeklenebilirliği doğrulamak için altı ay boyunca gölge yazma işlemleri gerçekleştirdi. Son olarak, kapsamlı veri eksiksizliği ve bütünlüğü kontrollerinin ardından, analitik olay alımını eski bulut kuyruk hizmetimizden başarıyla taşıdık. Bu, önemli bir dönüm noktasıydı. Alım yolundan bulut kaynak maliyetini ortadan kaldırdık ve bir olayın tetiklenmesi ile veri gölümüze ulaşması arasındaki gecikmeyi önemli ölçüde azalttık. Daha önce üç saatlik bir hizmet seviyesi anlaşmamız vardı ve bunu sıklıkla yerine getiremiyorduk; bugün ise tutarlı bir şekilde ortalama 15 dakikayı tutturuyoruz. 

Bu, mühendislerin QaaS'tan verileri kullanarak şematize edilmiş olaylara karşı gerçek zamanlı olay işleme boru hatları yazmalarını ve böylece güvenlik ve gerçek zamanlı öneri özelliklerini güçlendirmelerini sağlar. Ayrıca, aynı şematizasyon çerçevesi ve QaaS alımıyla veri değişikliği yakalama özelliğini de başlattık ve böylece tam veritabanı dökümlerini büyük ölçüde ortadan kaldırdık. Gerçek zamanlı analitik ve olay akışından yeni kullanım senaryolarının ortaya çıkarılmasına kadar, daha akıllı, daha hızlı ve daha uygun maliyetli veri sistemlerini büyük ölçekte geliştirip yenilikler sunmaya devam ediyoruz. 

Bu çalışmaya değerli katkıları için Paul Mou'ya teşekkür ederiz.

^{* 31 Mart 2025 tarihinde sona eren üç aylık dönem itibarıyla.}