रॉब्लॉक्स ने क्रिएटर एनालिटिक्स को स्केल करने के लिए थेटा स्केचेज़ का उपयोग कैसे किया

आज के रीयल-टाइम मल्टीप्लेयर गेम्स के लिए एनालिटिक्स आवश्यक हैं। Roblox में, हम अपने क्रिएटर्स को फलने-फूलने में मदद करने के लिए मापन उपकरण विकसित करने पर ध्यान केंद्रित कर रहे हैं। हमारे मुफ़्त, आउट-ऑफ-द-बॉक्स एनालिटिक्स क्रिएटर्स को उनके अनुभवों की वृद्धि, उपयोगकर्ता अधिग्रहण और प्रतिधारण में तत्काल अंतर्दृष्टि प्रदान करते हैं, जिससे उन्हें अपनी सफलता को अधिकतम करने में मदद मिलती है। 

ऐसे अद्यतित एनालिटिक्स सिस्टम का निर्माण करना जिस पर लाखों रोब्लॉक्स निर्माता निर्भर करते हैं, एक महत्वपूर्ण चुनौती है। इसे हल करने के लिए, हमने अपने एनालिटिक्स क्वेरी इंजन को अनुकूलित किया है ताकि 120 कोर प्रोसेसिंग क्लस्टर, 86 टीबी डेटा तक पहुँचने वाले लगभग 300,000 दैनिक आगंतुकों से प्रतिदिन 6 मिलियन से अधिक क्वेरीज़ को पूरा कर सके। हमारे समाधान के केंद्र में एक ऑनलाइन एनालिटिकल प्रोसेसिंग (OLAP) डेटाबेस है जिसे हमने इसकी स्केलेबिलिटी और अनुमानित एल्गोरिदम के साथ एकीकरण के लिए चुना है। डेटा रोलअप तकनीकों के साथ-साथ हाइपरलॉगलॉग और थेटा स्केच एल्गोरिदम के मिश्रण का उपयोग करके, हम लाखों रॉब्लॉक्स अनुभवों¹ के लिए एनालिटिक्स प्रदान करते हैं। 

जितना अधिक डेटा क्वेरी किया जाता है, परिणाम उत्पन्न करने में उतना ही अधिक समय लगता है। जब हम आवश्यक डेटा को कम करके विश्लेषण प्रक्रिया को तेज कर पाते हैं, तो निर्माता अपनी क्रियाओं से लगभग वास्तविक समय में अंतर्दृष्टि प्राप्त कर सकते हैं। कुछ तकनीकों में शामिल हैं:

1. स्तंभ-आधारित भंडारण: OLAP, Druid, केवल आवश्यक स्तंभों को ही पढ़ता है।
2. विभाजन और क्रमबद्ध फ़िल्टर: OLAP केवल प्रासंगिक फ़ाइलों को पढ़ता है जो सीधे आवश्यक डेटा ब्लॉकों को इंडेक्स करती हैं।
3. रोलअप: OLAP सामान्य समूहों का उपयोग करके घटनाओं का आंशिक रूप से समूहीकरण करता है।

विशेष रूप से रोलअप्स, OLAP को सबसे बड़े SQL क्वेरी इंजनों, जैसे Spark या Presto (जिनकी लेटेंसी दसियों सेकंड की होती है), और पॉइंट क्वेरी या सीमित SQL, जो आमतौर पर पूरी तरह से एग्रीगेटेड डेटा प्रदान करते हैं, के बीच संचालित करने में सक्षम बनाते हैं। रोलअप्स के साथ, क्वेरीज़ आयामों के समूहों द्वारा कीड (keyed) हो जाती हैं, जिसके परिणामस्वरूप कुल पंक्ति कार्डिनैलिटी में बड़ी कमी आती है। जब अरबों या खरबों कच्ची घटनाओं को देखा जाता है, तो उन्हें लाखों समूहों में समूहित करना कहीं अधिक कुशल हो सकता है, जिन्हें सबसेकंड विलंब के साथ समेकित किया जा सकता है। उदाहरण के लिए: 

हालाँकि रोलअप उपरोक्त उल्लिखित संकुचन लाभ प्रदान करते हैं, कुछ मेट्रिक्स उनके प्रति प्रतिरोधी होते हैं, जिनमें उन क्वेरीज़ शामिल हैं जिन्हें कच्चे डेटा की पूरी टेबल सॉर्ट की आवश्यकता होती है, जैसे कि डिस्टिंक्ट काउंट, पर्सेंटाइल, और आवृत्ति क्वेरीज़।

सौभाग्य से, हम उन तकनीकों के साथ इन सीमाओं से पार पा सकते हैं जो जटिल डेटा संरचनाओं के आधार पर एक सांख्यिकीय रूप से सीमित अनुमानित परिणाम लौटाती हैं, जो पूरे डेटासेट के एक नमूने को संग्रहीत करती हैं। इन डेटा संरचनाओं को रोलअप तकनीकों में उपयोग के लिए डिज़ाइन किया गया है और ये दो अलग-अलग गणनाओं को एक यूनियन ऑपरेशन के माध्यम से जोड़ती हैं, जो दो संख्याओं को जोड़ने के समान है।

Roblox में, हम क्रिएटर्स को एक केंद्रीकृत डैशबोर्ड प्रदान करते हैं जहाँ वे अपनी सबसे महत्वपूर्ण अंतर्दृष्टि पा सकते हैं। इनमें शामिल हैं: 

• एंगेजमेंट: दैनिक सक्रिय उपयोगकर्ता (DAU), मासिक सक्रिय उपयोगकर्ता (MAU), रिटेंशन, और फ़नल 
• मनीकरण: राजस्व, प्रति उपयोगकर्ता औसत राजस्व, बिक्री, और अर्थव्यवस्था
• अधिग्रहण डेटा 
• थंबनेल वैयक्तिकरण और प्रयोग परिणाम
• होम सिफारिशें विश्लेषिकी
• और भी बहुत कुछ आने वाला है। 

उत्पादन शैडो परीक्षण के अंतिम दौर में, हमने एक महत्वपूर्ण चुनौती पाई: एकल बड़ी क्वेरीज़ से प्रतिदिन के एग्रीगेशन पैटर्न में स्विच करने के बाद हमारी MAU क्वेरी प्रदर्शन को मजबूत करने की आवश्यकता थी। ये हमारे क्रिएटर एनालिटिक्स विज़ुअलाइज़ेशन के लिए महत्वपूर्ण हैं। 

हमने पाया कि क्वेरी की संरचना ने हमारे OLAP समाधान के अंतर्निहित प्रदर्शन को बहुत प्रभावित किया। कई निष्पादन चरणों वाली मानक क्वेरीज़ (जैसे नेस्टेड "GROUP BY" स्टेटमेंट्स²) अक्सर काम के बड़े हिस्सों को हल्के ब्रोकर नोड्स पर धकेल देती हैं। 

यह एक क्लासिक बिग डेटा समस्या है जहाँ क्वेरी का कुछ हिस्सा महत्वपूर्ण छोटे सर्विंग नोड्स पर निष्पादित हो जाता है। हमने उम्मीद की थी कि हमारे अनुमानित डेटा संरचनाएँ सरल गणनाओं या योगों की तरह काम करेंगी, लेकिन हमने पाया कि वे वास्तव में बहुत अलग व्यवहार कर रही थीं। 

नीचे दिया गया चित्र इस समस्या को दर्शाता है। यह दिखाता है कि हमारे पुराने नोड कैसे आंशिक समेकन करते थे, प्रत्येक दिन के लिए एक थेटा स्केच को रोल-अप करते थे और फिर अपने डेटा को वापस ब्रोकर पर भेजते थे। फिर ब्रोकर प्रत्येक बड़े दैनिक स्केच को प्रति दिन एक एकल मासिक मान में विलय करने का प्रयास करता था। 30 दिनों के MAU के लिए, इसका मतलब था कि एक ब्रोकर पर 1,800 अधिकतम-आकार के थेटा स्केच को मर्ज करना, जिसके परिणामस्वरूप एक धीमी, विफलता-प्रवण क्वेरी बनी जो ब्रोकर CPU पर एकाधिकार कर रही थी। 

हमारा समाधान यह था कि अनुमानित क्वेरीज़ पर निर्भर डेटा स्रोतों के लिए डेटा लोकल्टी को अधिकतम करने हेतु कम बड़े ऐतिहासिक वर्कर्स के साथ OLAP चलाया जाए। व्यवहार में, इसने एक मर्ज ऑपरेशन को हमारे ऐतिहासिक नोड्स पर वापस धकेल दिया, जिसके लिए 100 MB से अधिक डेटा प्रोसेसिंग की आवश्यकता हो सकती थी।

SQL में ऐसा हासिल करने के लिए, हमने इनलाइन जॉइन का इस्तेमाल किया ताकि क्वेरीज़ ऐतिहासिक नोड्स तक ज़रूरी जानकारी पहुँचा सकें और इनलाइन रिज़ल्ट डेट्स की एक सूची के साथ एक क्वेरी तैयार की। फिर प्रत्येक रिज़ल्ट डेट ऐतिहासिक नोड सेगमेंट्स से संबंधित डेटा इकट्ठा कर सकता है। फिर डेटा को ब्रोकर को वापस भेजा जाता है, जहाँ परिणामों को तेज़ी से रिज़ल्ट डेट से मेट्रिक डेटा के एकल मैप में मिला दिया जाता है, जैसा कि नीचे देखा गया है।

इस अनुकूलन का बड़े पैमाने के क्वेरीज़ के लिए प्रदर्शन पर नाटकीय प्रभाव पड़ा। एक प्रमुख अनुभव के लिए देश के अनुसार MAU ब्रेकडाउन में, औसत क्वेरी प्रदर्शन 5 गुना (17.53 सेकंड से घटकर 3.23 सेकंड) तक सुधार हुआ, जैसा कि नीचे दिए गए चार्ट में दिखाया गया है। हमने ब्रोकर पर CPU समय में भी 50 गुना की कमी देखी (16.83 सेकंड से घटकर 0.34 सेकंड)। 

हालांकि परिणाम भिन्न हो सकते हैं, यह जटिल संचालन (जैसे लाखों स्केच को मर्ज करना) को सावधानी से करने के महत्व को उजागर करता है। यह मान लेना कि ये संचालन सरल एकत्रीकरण के बराबर हैं, महत्वपूर्ण प्रदर्शन समस्याओं को जन्म दे सकता है, खासकर उन सिस्टमों पर जहाँ अंतिम-चरण क्लाइंट एकत्रीकरण आम हैं।

हमने एक थेटा क्यूब, या एक सामान्यीकृत दृष्टिकोण का भी अन्वेषण किया, जो अनुमानित सेट अंतर्संयोजन के माध्यम से बुनियादी रोलअप तालिकाओं और पूरी तरह से कच्ची तालिकाओं के बीच की खाई को पाटने का काम करता है। यह दृष्टिकोण एक मौलिक सीमा को संबोधित करता है: रोलअप तालिकाएं अपना लाभ तब खो देती हैं जब क्वेरीज़ को उच्च-कार्डिनैलिटी आयामों की कई परतों को छूने की आवश्यकता होती है। ऐसा इसलिए है क्योंकि प्रत्येक आयाम रोलअप कार्डिनैलिटी को ∏_dim (आयामों का गुणनफल) के रूप में स्केल करने का कारण बनता है।

हमने एक ऐसी प्रणाली डिज़ाइन की जो सामान्य आयाम समूहों द्वारा एक कार्डिनैलिटी कैप के साथ समूहीकरण करेगी, जिससे समूह में मौजूद किसी भी चीज़ पर रोलअप प्रदर्शन क्वेरीज़ की अनुमति मिलती है। फिर, समूहों के पार आयामों के संयोजनों को देखने पर, हम सेटों के पार एक अनुमानित जॉइन⁴ का प्रयास करेंगे और त्रुटि अनुमानों के साथ मेट्रिक परिणाम लौटाएंगे। उच्च अनुमानित त्रुटि वाली एक क्वेरी को एक कच्चे टेबल में भेज दिया जाएगा, जहाँ कई फ़िल्टर बड़े पुशडाउन अनुकूलन की अनुमति देंगे।

क्योंकि हम इस त्रुटि दर की गणना जल्दी कर सकते हैं, यह एक मजबूत संकेत के रूप में भी काम करता है कि कच्ची तालिका को पढ़ना संभवतः कुशल होगा। उन मामलों में जहाँ यूनियन के सापेक्ष ओवरलैपिंग डेटा छोटा होता है (उदाहरण के लिए, जर्मनी में जापानी वक्ता), कच्ची तालिका की बड़ी संख्या में पंक्तियाँ फ़िल्टर कर दी जाएँगी। इससे कुशल पुशडाउन अनुकूलन होते हैं। एक ऐसी प्रणाली जो डाइमेंशन ग्रुप्स, एप्रोक्सिमेट जॉइन्स, और त्रुटि-आधारित रॉ टेबल रीड्स का उपयोग करती है, वह एप्रोक्सिमेशन-फ्रेंडली क्वेरीज़ पर रोलअप प्रदर्शन को वास्तव में अधिकतम करेगी।

Roblox के लिए, यह समाधान हमारे अगले स्तर के पैमाने पर अधिक लागू होगा—संभावित रूप से डायनामिक फनल या कस्टम इवेंट विश्लेषण के लिए—जबकि हमारी वर्तमान सरल रोलअप प्रतिकृति आज की जरूरतों को पूरा करती है।

हमारे ब्रोकर को अनुकूलित करने के बाद, हमने अपने OLAP समाधान में जोड़े गए डेटासेट के ऑनबोर्डिंग और क्वेरी करने के लिए उपकरण बनाने की ओर रुख किया। हमने अपने डेटास्केच फ़ंक्शंस के लिए एक ओपन-सोर्स स्पार्क और ट्रिनो UDAF लाइब्रेरी बनाई, जिससे स्पार्क हमारे OLAP⁶ के समान बाइनरी डेटास्केच फ़ॉर्मेट का उपयोग कर सके। इसने हमारे अधिकांश कंप्यूट वर्कलोड को स्पार्क में बनाए रखा और Roblox में अनुमान को मानकीकृत करने में मदद की, जिससे कुछ डेटासेट के लिए कंप्यूट लागत में संभावित रूप से 80% तक की कमी आई।

हमने अपने बैच जॉब शेड्यूलर के एक आंतरिक एक्सटेंशन के साथ ऑनबोर्डिंग को सरल बनाया और एक डेटाफ्रेम-शैली की एपीआई (API) परिभाषित की जो डेवलपर्स को निश्चित माप और आयाम तय करने में मार्गदर्शन करती है, जिससे ओपन क्वेरीज़ का प्रभाव कम हो जाता है। हमने अपने OLAP में इस डेटा को कैसे लोड और क्वेरी करें, इसके लिए कुछ नमूना वर्कफ़्लो को ओपन-सोर्स भी किया है।

हमारे अनुकूलित एनालिटिक्स डेटासेट अब हमारे क्रिएटर्स को गहरी अंतर्दृष्टि प्रदान कर रहे हैं। हमारे अनुकूलनों ने औसत प्रदर्शन को 4 गुना और सबसे खराब स्थिति में प्रदर्शन को 50 गुना तक बेहतर बनाया है। सेल्फ-सर्व प्लेटफ़ॉर्म हमारी क्रिएटर एनालिटिक्स टीम को डेवलपर्स के लिए नए डेटासेट पर लगातार काम करते रहने में सक्षम बनाता है। हम सभी आकारों के डेवलपर्स को इन टूल का उपयोग करके Roblox पर अविश्वसनीय अनुभव बनाते हुए देखने के लिए उत्साहित हैं।