रॉब्लॉक्सचे दररोज २ ट्रिलियन विश्लेषण घटनांपर्यंत पोहोचण्याचा मार्ग

दररोज सरासरी 97.8 दशलक्ष वापरकर्ते* Roblox वर संवाद साधण्यासाठी, निर्मिती करण्यासाठी आणि एकत्र खेळण्यासाठी भेट देतात. या सर्व परस्परसंवादांमुळे दररोज 2 पेटाबाइट्स विश्लेषण घटना डेटा तयार होतो. नवीन स्केलेबल इनजेशन प्रणालीमुळे, आम्ही अलीकडेच एक महत्त्वपूर्ण टप्पा गाठला आहे: आमची प्रणाली आता दररोज 2 ट्रिलियनपेक्षा जास्त घटना प्रक्रिया करत आहे. ही प्रणाली Roblox प्लॅटफॉर्मला चालना देणाऱ्या वैयक्तिकरण, सुरक्षा आणि आर्थिक कार्यक्षमतेच्या अल्गोरिदमना सक्षम करते.

यापूर्वी, क्लाउड क्यू सेवा Roblox-निर्मित विश्लेषणात्मक डेटा events_hourly नावाच्या एकाच लॉजिकल टेबलमध्ये इनजेस्ट करत असे. ते तारखेनुसार, तासानुसार आणि वेब, मोबाइल किंवा friendService यांसारख्या मनमानीपणे परिभाषित टॅगनुसार विभाजित केले गेले होते. आमचे डेटा शास्त्रज्ञ आणि अभियंते विशिष्ट इव्हेंट्स समर्पित टेबल्समध्ये काढण्यासाठी नियोजित बॅच जॉब्सवर अवलंबून होते. नवीन विश्लेषणात्मक इव्हेंट्स तयार करण्यासाठी आणि पाठवण्यासाठी कोणत्याही पूर्व-निर्धारित स्कीमाची आवश्यकता नव्हती. अभियंत्यांनी त्यांच्या स्वतःच्या टेबल स्कीमावर नंतरच्या 'extract, transform, and load' (ETL) पाइपलाइन टप्प्यात नियंत्रण ठेवले.

ही व्यवस्था लवचिक होती आणि अभियंत्यांना जलद गतीने काम करण्यास सक्षम करत होती, परंतु त्यात काही आव्हाने होती. 

• घटनांची संख्या वाढल्यामुळे, फक्त तारीख, तास आणि टॅग्सनुसार विभाजित केलेल्या 2 ट्रिलियन ओळींसह संवाद साधणे अधिकाधिक अकार्यक्षम झाले.
• events_hourly टेबलसाठी सहा तासांचा दिवसअखेर विलंब आणि events_daily साठी २४ तासांचा विलंब यामुळे डेटा पाइपलाइन्स अडथळ्यात आल्या. 
• डेटसेट-स्तरीय परवानग्या, स्तर, संग्रहण कालावधी आणि अलर्ट व्यवस्थापित करणे अधिक गुंतागुंतीचे झाले. 
• घटना दस्तऐवजीकरण, इतिहास आणि मालकीची माहिती उपलब्ध नव्हती, ज्यामुळे डेटाचा वापर आणि त्याचा मागोवा घेणे अवघड झाले. 
• क्लाउड क्यू सेवा वापरून तयार केलेल्या इनजेक्शन इन्फ्रास्ट्रक्चरवर 23 Gbps क्लाउड इनजेक्शन खर्च झाला.

डेटा विश्लेषण पूर्वी एकाच लॉजिकल टेबलमधून अनेक बॅच पाइपलाइन्सद्वारे डेटा काढण्यावर अवलंबून होते. मोठ्या, कार्यक्षम क्वेरी चालवण्यासाठी हे आवश्यक होते—पण त्यामुळे प्रक्रिया मंदावत असे. इनजेशन बॅकएंड सेवा वापरून या इव्हेंट्सना समर्पित टेबल्सकडे मार्गनिर्देशित केल्याने बॅच एक्सट्रॅक्शन पाइपलाइन्सची गरज नाहीशी होते, कारण विश्लेषणात्मक इव्हेंट्ससाठी आधीच स्कीमा ठरवली जाते आणि गंतव्य टेबल निश्चित केले जाते. 

आम्ही Roblox येथे विश्लेषण इव्हेंटसाठी स्कीमा भाषा म्हणून Protobuf (proto) निवडले. ही एक नैसर्गिक निवड होती, कारण proto आणि gRPC हे आमच्या पसंतीचे बिल्डिंग सर्व्हिस फ्रेमवर्क आहेत. याव्यतिरिक्त, proto कस्टम पर्याय परिभाषित करण्यासाठी उत्कृष्ट समर्थन देते, ज्याचा आम्ही मालकी, संग्रहण, उत्पादकता सॉफ्टवेअर चॅनेल आणि इव्हेंट स्कीमा यांसारखी अतिरिक्त मेटाडेटा गोळा करण्यासाठी वापर करतो. 

आमची स्कीमा भाषा निवडल्यानंतर, स्कीमा अद्ययावत केल्यावर काय होते आणि कोणत्या अद्यतनांना परवानगी द्यावी हे आम्ही तपासले. प्रकाशित स्कीमा वापरणाऱ्या अधिकाधिक डाउनस्ट्रीम ग्राहकांना समर्थन देण्यासाठी, डेटा टीमने स्कीमा रजिस्ट्रीमध्ये वर्णन केलेल्या बॅकवर्ड ट्रान्झिटिव्ह मोडचा अवलंब केला. या पद्धतीमुळे फील्ड जोडणे आणि सौम्यपणे हटवणे परवानगी आहे. यामुळे डाउनस्ट्रीम ग्राहकांशी समन्वय न करता स्कीमात बदल करता येतात. 

वरील उदाहरणात, आम्ही प्रोटो फाइल अपडेट करून फील्ड जोडू आणि हटवू शकतो.

स्कीमा अनेक फायदे देतात, परंतु त्यांना आगाऊ अनिवार्य केल्याने अडथळा निर्माण होतो. डेटा सायंटिस्ट आणि अभियंत्यांना अडचणींशिवाय जलद गतीने काम करून पुनरावृत्ती करण्याची गरज असते. यासाठी, आम्ही एक केंद्रीकृत स्कीमा रिपॉझिटरी सुरू केली आणि स्कीमा तयार करण्याची प्रक्रिया शक्य तितकी स्वयंचलित व सुलभ करण्यासाठी विविध साधनांची एक मालिका विकसित केली. 

उदाहरणार्थ, प्रत्येक स्कीमामध्ये आवश्यक मेटाडेटा आहे का आणि ती Roblox कन्व्हेन्शन्सचे पालन करते का हे पडताळण्यासाठी आम्ही एक सानुकूलित प्रोटो लिंटर तयार केला. आम्ही एक प्रोटो प्लग-इन देखील तयार केला आहे जो इव्हेंट स्कीमाला Hive डेटा डेफिनिशन लँग्वेजमध्ये अनुवादित करतो, जेणेकरून स्कीमा जिथेही तयार किंवा अद्ययावत केली जाते तिथे संबंधित Hive टेबल समक्रमित राहते. ही सर्व साधने CI/CD पाइपलाइनमध्ये समाकलित आहेत आणि पुల్ रिक्वेस्ट तयार होताच स्वयंचलितपणे चालतात. यामुळे अभियंत्यांना स्कीमाच्या समस्या लवकर ओळखता येतात आणि त्यांच्या स्कीमा मर्ज होण्यापूर्वी टेस्ट Hive टेबलमध्ये इव्हेंट्स पडताळता येतात. परिणामी, स्कीमा प्रोडक्शनमध्ये तैनात करणे मर्ज करण्याइतकेच सोपे आहे. 

सुव्यवस्थित डेव्हलपर अनुभव तयार झाल्यानंतर, आम्ही इनजेस्टन पाइपलाइनमध्ये कुठे एखाद्या घटनेचे स्कीमा तयार करायचे आणि ते प्रोटोमध्ये रूपांतरित करायचे याचा अभ्यास केला. इव्हेंट उत्पादकांना सिरीअलाइज्ड प्रोटो बाइट्स स्वीकारून पाठवण्यास सांगणे हा अनेक संघांमध्ये पसरलेला एक मोठा बदल असता. समस्या सोडवण्यासाठी आणि टप्प्याटप्प्याने मूल्य देण्यासाठी, आम्ही इनजेस्टन बॅकएंड सेवा अद्ययावत करून येणाऱ्या घटनांना प्रोटोमध्ये रूपांतरित करण्यासाठी स्कीमा तयार करण्याचे काम इव्हेंट उत्पादकांपासून स्वतंत्र केले. आता रूपांतरित इव्हेंट्स पार्क्वे फाइल्समध्ये गोळा केले जातात, वितरित संग्रहणमध्ये अपलोड केले जातात आणि स्वतंत्र Hive टेबल्स म्हणून नोंदवले जातात.

पुढे, आम्ही विश्लेषण घटनांची सेवा करण्याच्या खर्चावर लक्ष केंद्रित केले. पूर्वी, इनजेस्टन बॅकएंड क्लाउड पायाभूत सुविधांवर तयार केले गेले होते. विश्लेषणात्मक घटना क्यू सेवेकडे पाठवल्या जात होत्या, जी त्यांना बफर करून नंतर पुढील प्रक्रिया व विश्लेषणासाठी टिकाऊ क्लाउड स्टोरेजमध्ये संग्रहित करत असे. जरी क्लाउड क्यू सेवेने आमची सेवा सुलभ केली आणि पारदर्शक स्केलिंगची परवानगी दिली, तरी ती इतर स्ट्रीमिंग जॉब्सना वापरण्यासाठी अवघड आणि जास्त महाग आहे. यावर उपाय म्हणून, आम्ही इनजेक्शन सेवा Roblox च्या डेटा सेंटरमध्ये आणण्याचा विचार केला.  

आमच्या अंतर्गत स्टोरेज टीमने ओपन-सोर्स वितरित इव्हेंट स्ट्रीमिंग प्लॅटफॉर्मवर आधारित क्यू-एज-ए-सर्व्हिस (QaaS) तयार केले होते. QaaS हे विश्लेषणात्मक इव्हेंट इनजेक्शनसाठी उत्कृष्ट पर्याय आहे कारण इव्हेंट्स प्रथम-प्रवेश, प्रथम-निर्गमन क्रमाने टेल केले जातात आणि अल्प कालावधीसाठी ठेवल्यानंतर हटवले जातात. Roblox मध्ये, आम्ही प्रत्येक संरचित इव्हेंटसाठी एक समर्पित टॉपिक तयार करतो आणि मोठ्या इव्हेंट स्ट्रिमसाठी स्केल करण्यासाठी पार्टिशन काउंटचा वापर करतो. डेटा टीमने QaaS मधून डेटा घेण्यासाठी, पार्केट फाइल्स तयार करण्यासाठी आणि फाइल्स टिकाऊ क्लाउड स्टोरेजमध्ये अपलोड करण्यासाठी एक समर्पित सेवा देखील तयार केली.

QaaS अस्तित्वात आल्यानंतर आणि पार्केट फाइल्स तयार करण्यासाठी व संग्रहित करण्यासाठी एक समर्पित सेवा तयार केल्यानंतर, डेटा टीमने सहा महिन्यांसाठी शॅडो रायट्स (shadow writes) केले, ज्याद्वारे डेटाची अचूकता आणि स्केलेबिलिटी दोन्ही पडताळून पाहण्यात आली. शेवटी, डेटाच्या पूर्णतेची आणि अखंडतेची सखोल तपासणी केल्यानंतर, आम्ही आमच्या जुन्या क्लाउड क्यू सेवेवरून विश्लेषणात्मक इव्हेंट इनजेक्शन यशस्वीरित्या स्थलांतरित केले. हा एक मोठा टप्पा होता. आम्ही इनजेक्शन मार्गातून क्लाउड संसाधनांचा खर्च काढून टाकला आणि एखादी घटना घडण्यापासून ते आमच्या डेटा लेकमध्ये पोहोचण्यापर्यंतचा विलंब लक्षणीयरीत्या कमी केला. पूर्वी आमचा तीन तासांचा सेवा-स्तरीय करार होता, जो आम्ही अनेकदा पूर्ण करू शकत नव्हतो—आज, आम्ही सातत्याने सरासरी 15 मिनिटांचा वेळ गाठत आहोत. 

यामुळे अभियंत्यांना QaaS मधून डेटा घेऊन संरचित घटनांवर आधारित रिअल-टाइम इव्हेंट प्रोसेसिंग पाइपलाइन्स लिहता येतात, ज्यामुळे सुरक्षा आणि रिअल-टाइम शिफारस वैशिष्ट्ये सक्षम होतात. आम्ही त्याच संरचनात्मक फ्रेमवर्क आणि QaaS इनजेक्शनसह चेंज डेटा कॅप्चरही सुरू केले आहे, ज्यामुळे पूर्ण डेटाबेस डंपची गरज मोठ्या प्रमाणात कमी झाली आहे. रिअल-टाइम विश्लेषण आणि इव्हेंट स्ट्रीमिंगपासून नवीन उपयोगाच्या प्रकरणांना अनलॉक करण्यापर्यंत, आमचे कार्य सुरूच आहे कारण आम्ही मोठ्या प्रमाणावर अधिक हुशार, जलद आणि कमी खर्चात डेटा प्रणाली विकसित करत आहोत. 

या कामात केलेल्या मौल्यवान योगदानाबद्दल आम्ही पॉल मौ यांचे आभार मानतो.

^{* 31 मार्च 2025 रोजी संपलेल्या तीन महिन्यांपर्यंत.}