Roblox, Theta Sketches'i kullanarak içerik oluşturucu analizlerini nasıl genişletti?

Analitik, günümüzün gerçek zamanlı çok oyunculu oyunları için vazgeçilmezdir. Roblox'ta, yaratıcılarımızın başarılı olmalarına yardımcı olacak ölçüm araçları geliştirmeye odaklanıyoruz. Ücretsiz ve kullanıma hazır analitik araçlarımız, yaratıcılara deneyimlerinin büyümesi, kullanıcı kazanımı ve elde tutma konusunda anlık içgörüler sunarak başarılarını en üst düzeye çıkarmalarına yardımcı olur. 

Milyonlarca Roblox yaratıcısının güvendiği güncel analitik sistemleri oluşturmak önemli bir zorluktur. Bu zorluğun üstesinden gelmek için, analitik sorgu motorumuzu optimize ettik; böylece 120 çekirdekli bir işleme kümesi, 86 TB veriye erişen yaklaşık 300.000 günlük ziyaretçiden gelen 6 milyondan fazla sorguyu günde işleyebiliyor. Çözümümüzün merkezinde, ölçeklenebilirliği ve yaklaşım algoritmalarıyla entegrasyonu nedeniyle seçtiğimiz bir çevrimiçi analitik işleme (OLAP) veritabanı yer alıyor. Veri toplama teknikleri ile HyperLogLog ve Theta Sketch algoritmalarını bir arada kullanarak, milyonlarca Roblox deneyimi için analitik sağlıyoruz1. 

Ne kadar çok veri sorgulanırsa, sonuçların üretilmesi o kadar uzun sürer. Gerekli veriyi azaltıp analiz sürecini hızlandırabildiğimizde, içerik oluşturucular eylemlerinden neredeyse gerçek zamanlı içgörüler elde edebilirler. Kullandığımız tekniklerden bazıları şunlardır:

1. Sütunlu depolama: OLAP, Druid, yalnızca gerekli sütunları okur.
2. Bölümleme ve sıralama filtreleri: OLAP, yalnızca gerekli veri bloklarına doğrudan indekslenen ilgili dosyaları okur.
3. Toplama: OLAP, ortak gruplamaları kullanarak olayları kısmen toplar.

Özellikle toplama işlemleri, OLAP'lerin Spark veya Presto gibi en büyük SQL sorgu motorları (on saniyelik gecikmelerle) ile genellikle tamamen toplatılmış veriler sunan nokta sorgusu veya sınırlı SQL arasında çalışmasını sağlar. Toplama işlemleri sayesinde sorgular, boyut gruplamalarına göre anahtarlanır ve bu da toplam satır kardinalitesinde büyük azalmalar sağlar. Milyarlarca hatta trilyonlarca ham olaya bakıldığında, bunları saniyenin altında gecikme süresiyle toplanabilen milyonlarca gruplamaya toplamak çok daha verimli olabilir. Örneğin: 

Rollup'lar yukarıda bahsedilen indirgeme avantajlarını sunsa da, farklı sayımlar, yüzdelik dilimler ve sıklık sorguları gibi ham verilerin tam tablo sıralamasını gerektiren sorgular dahil olmak üzere bazı metrikler bunlara direnç gösterir.

Neyse ki, tam veri kümesinin bir örneğini barındıran karmaşık veri yapılarına dayalı olarak istatistiksel olarak sınırlı bir yaklaşık sonuç döndüren tekniklerle bu sınırlamaları aşabiliriz. Bu veri yapıları, toplama tekniklerinde kullanılmak üzere tasarlanmıştır ve iki sayıyı birbirine eklemeye benzer şekilde, birleştirme işlemi yoluyla iki farklı sayıyı birleştirir.

Roblox'ta, içerik oluşturuculara en önemli içgörülerini bulabilecekleri merkezi bir kontrol paneli sunuyoruz. Bunlar arasında şunlar yer alır: 

• Etkileşim: günlük aktif kullanıcılar (DAU), aylık aktif kullanıcılar (MAU), kullanıcı tutma oranı ve dönüşüm hunileri 
• Para kazanma: gelir, kullanıcı başına ortalama gelir, satışlar ve ekonomi
• Kullanıcı kazanımı verileri 
• Küçük resim kişiselleştirme ve deney sonuçları
• Ana Sayfa Önerileri analitiği
• Ve daha fazlası yakında. 

Üretim gölge testlerinin son turunda önemli bir sorunla karşılaştık: Tek bir büyük sorgudan günlük toplama modellerine geçtikten sonra MAU sorgu performansımızın güçlendirilmesi gerekiyordu. Bunlar, içerik oluşturucu analitik görselleştirmelerimiz için çok önemlidir. 

Sorgu yapısının, OLAP çözümümüzün temel performansını büyük ölçüde etkilediğini gördük. Birden fazla yürütme aşaması içeren standart sorgular (iç içe geçmiş "GROUP BY" deyimleri gibi²), genellikle işin büyük bir kısmını hafif broker düğümlerine yükler. 

Bu, sorgunun bir kısmının önemli küçük hizmet düğümlerinde yürütülmesiyle sonuçlanan klasik bir büyük veri sorunudur. Yaklaşık veri yapılarımızın basit sayımlar veya toplamlar gibi işlev görmesini bekliyorduk, ancak aslında çok farklı davrandıklarını keşfettik. 

Aşağıdaki şekil bu sorunu göstermektedir. Şekil, geçmiş düğümlerimizin nasıl kısmi toplama yaptığını, her gün için bir Theta Sketch'i topladığını ve ardından verilerini broker'a geri aktardığını göstermektedir. Broker daha sonra her büyük günlük taslağı, her gün için tek bir aylık değere birleştirmeye çalıştı. 30 günlük MAU için bu, bir broker üzerinde maksimum boyuttaki 1.800 Theta Sketch'i birleştirmek anlamına geliyordu; bu da broker CPU'sunu tek başına kullanan, daha yavaş ve hataya açık bir sorgu ile sonuçlanıyordu. 

Çözümümüz, yaklaşım sorgularına dayanan veri kaynakları için veri yerelliğini en üst düzeye çıkarmak amacıyla daha az sayıda büyük geçmiş işleyicisi ile OLAP'ı çalıştırmaktı. Uygulamada bu, 100 MB'den fazla veri işleme gerektirebilecek bir birleştirme işlemini geçmiş düğümlerimize geri itti.

Bunu SQL'de gerçekleştirmek için, sorguların gerekli bilgileri geçmiş düğümlerine yayması için satır içi birleştirme kullandık ve satır içi sonuç tarihlerinin bir listesini içeren bir sorgu hazırladık. Her sonuç tarihi, geçmiş düğüm segmentlerinden ilgili verileri toplayabilir. Veriler daha sonra broker'a geri gönderilir ve burada sonuçlar, aşağıda görüldüğü gibi sonuç tarihi ile metrik verilerinin tek bir haritasında hızlı bir şekilde birleştirilir.

Bu optimizasyon, büyük ölçekli sorguların performansı üzerinde önemli bir etki yarattı. Aşağıdaki grafikte gösterildiği gibi, büyük bir deneyimin ülkelere göre aylık aktif kullanıcı (MAU) dağılımı için ortalama sorgu performansı 5 kat arttı (17,53 saniyeden 3,23 saniyeye). Ayrıca, broker üzerindeki CPU süresinde 50 kat azalma gördük (16,83 saniyeden 0,34 saniyeye). 

Sonuçlar değişiklik gösterse de bu durum, karmaşık işlemlerin (milyonlarca taslağın birleştirilmesi gibi) özenle ele alınmasının önemini vurgulamaktadır. Bu işlemlerin basit toplama işlemlerine eşdeğer olduğunu varsaymak, özellikle son aşama istemci toplama işlemlerinin yaygın olduğu sistemlerde önemli performans sorunlarına yol açabilir.

Ayrıca, temel toplama tabloları ile tamamen ham tablolar arasındaki boşluğu yaklaşık küme kesişimleri yoluyla doldurmak için bir teta küpü veya genelleştirilmiş bir yaklaşım da araştırdık. Bu yaklaşım, temel bir sınırlamayı ele almaktadır: Sorguların yüksek kardinaliteli boyutların birçok katmanına dokunması gerektiğinde, toplama tabloları avantajlarını yitirir. Bunun nedeni, her boyutun toplama kardinalitesinin ∏_dim (boyutların çarpımı) olarak ölçeklenmesine neden olmasıdır.

Kardinalite sınırı olan ortak boyut gruplarına göre toplama yapan ve grup içindeki her şey üzerinde toplama performansı sorguları yapılmasına olanak tanıyan bir sistem tasarladık. Ardından, gruplar arası boyut kombinasyonlarını ararken, kümeler arasında yaklaşık bir join⁴ denemesi yapar ve metrik sonuçları hata tahminleriyle birlikte döndürürdük. Tahmini hatası yüksek olan bir sorgu, ham tabloya iletilirdi; burada birçok filtre, büyük pushdown optimizasyonlarına olanak tanırdı.

Bu hata oranını hızlı bir şekilde hesaplayabildiğimiz için, ham tablonun okunmasının muhtemelen yüksek performanslı olacağına dair güçlü bir işaret de olur. Birleşime göre çakışan verilerin az olduğu durumlarda (örneğin, Almanya'daki Japonca konuşanlar), ham tablonun satırlarının büyük bir kısmı filtrelenir. Bu da verimli itme optimizasyonlarına yol açar. Boyut grupları, yaklaşık birleşimler ve hataya dayalı ham tablo okumaları kullanan bir sistem, yaklaşım dostu sorgularda toplama performansını gerçekten en üst düzeye çıkaracaktır.

Roblox için bu çözüm, bir sonraki ölçek seviyemizde (muhtemelen dinamik huni veya özel olay analizi için) daha uygulanabilir olacaktır; ancak mevcut basit toplama replikamız bugünkü ihtiyaçları karşılamaktadır.

Brokerimizi optimize ettikten sonra, OLAP çözümümüze eklenen veri kümelerini entegre etmek ve sorgulamak için araçlar geliştirmeye yöneldik. Datasketch işlevlerimiz için açık kaynaklı bir Spark ve Trino UDAF kütüphanesi oluşturduk, böylece Spark'ın OLAP⁶ ile aynı ikili datasketch formatını kullanmasını sağladık. Bu sayede hesaplama iş yükümüzün çoğunu Spark'ta tutabildik ve Roblox genelinde yaklaşımları standartlaştırarak belirli veri kümeleri için hesaplama maliyetlerini %80'e varan oranda azaltabildik.

Toplu iş zamanlayıcımıza eklediğimiz dahili bir uzantı ile entegrasyonu basitleştirdik ve geliştiricilerin kesin ölçütler ve boyutlar üzerinde karar vermelerine yardımcı olan, açık sorguların etkisini azaltan bir veri çerçevesi tarzı API tanımladık. Ayrıca, bu verileri OLAP'ımıza nasıl yüklediğimize ve sorguladığımıza dair bazı örnek iş akışlarını açık kaynak olarak paylaştık.

Optimize edilmiş analitik veri kümelerimiz artık içerik oluşturucularımıza derinlemesine içgörüler sağlıyor. Optimizasyonlarımız, ortalama performansı 4 kat, en kötü durum performansını ise 50 kat artırdı. Self servis platform, Creator Analytics ekibimizin geliştiriciler için yeni veri kümeleri üzerinde çalışmaya devam etmesini sağlıyor. Her büyüklükteki geliştiricinin bu araçları kullanarak Roblox'ta inanılmaz deneyimler yaratmasını görmekten büyük heyecan duyuyoruz.