ஒரு நாளைக்கு 2 டிரில்லியன் பகுப்பாய்வு நிகழ்வுகளுக்கான ராப்ளாக்ஸின் பாதை

ஒவ்வொரு நாளும், சராசரியாக 97.8 மில்லியன் பயனர்கள்* தொடர்புகொள்ளவும், உருவாக்கவும், ஒன்றாக விளையாடவும் ராப்லாக்ஸுக்கு வருகிறார்கள். இந்த தொடர்புகள் அனைத்தும் சேர்ந்து 2 பெட்டாபைட்ஸ் அளவிலான பகுப்பாய்வு நிகழ்வுத் தரவை உருவாக்குகின்றன. ஒரு புதிய அளவிடக்கூடிய உள்ளீட்டு அமைப்பிற்கு நன்றி, நாங்கள் சமீபத்தில் ஒரு முக்கிய மைல்கல்லை எட்டியுள்ளோம்: எங்கள் அமைப்பு இப்போது ஒரு நாளைக்கு 2 டிரில்லியனுக்கும் அதிகமான நிகழ்வுகளைச் செயலாக்குகிறது. இந்த அமைப்பு ராப்லாக்ஸ் தளத்தை இயக்கும் தனிப்பயனாக்கம், பாதுகாப்பு மற்றும் பொருளாதார வழிமுறைகளை செயல்படுத்துகிறது.

முன்பு, ஒரு கிளவுட் வரிசை சேவை, ராப்ளக்ஸ் உருவாக்கிய பகுப்பாய்வுத் தரவை events_hourly எனப்படும் ஒரே தர்க்கரீதியான அட்டவணையில் உள்ளிழுத்தது. அது தேதி, மணிநேரம், மற்றும் வலை, மொபைல், அல்லது friendService போன்ற தன்னிச்சையாக வரையறுக்கப்பட்ட குறிச்சொற்களின்படி பிரிக்கப்பட்டது. எங்கள் தரவு விஞ்ஞானிகளும் பொறியாளர்களும், குறிப்பிட்ட நிகழ்வுகளை பிரத்யேக அட்டவணைகளுக்குப் பிரித்தெடுப்பதற்காகத் திட்டமிடப்பட்ட தொகுதிப் பணிகளைச் சார்ந்திருந்தனர். புதிய பகுப்பாய்வு நிகழ்வுகளை உருவாக்கி அனுப்புவதற்கு முன்-வரையறுக்கப்பட்ட திட்டம் எதுவும் தேவையாக இல்லை. பொறியாளர்கள், பிரித்தெடுத்தல், மாற்றுதல் மற்றும் ஏற்றுதல் (ETL) குழாய்நிலைப் பகுதியில், தங்களின் சொந்த அட்டவணைத் திட்டத்தை அடுத்த கட்டத்தில் கட்டுப்படுத்தினர்.

இந்த அமைப்பு நெகிழ்வானதாகவும், பொறியாளர்கள் விரைவாகச் செயல்பட உதவியதாகவும் இருந்தது, ஆனால் இது சவால்களையும் முன்வைத்தது. 

• நிகழ்வுகளின் அளவு அதிகரித்ததால், தேதி, மணி நேரம் மற்றும் குறிச்சொற்களால் மட்டுமே பிரிக்கப்பட்ட 2 டிரில்லியன் வரிசைகளுடன் தொடர்புகொள்வது மிகவும் திறனற்றதாக மாறியது.
• events_hourly அட்டவணைக்கு ஆறு மணி நேர இறுதி-நாள் தாமதமும், events_daily-க்கு 24 மணி நேர தாமதமும், தரவுக் குழாய்கள் தடுக்கப்பட்ட காலகட்டங்களை உருவாக்கியது. 
• தரவுத்தொகுப்பு-நிலை அனுமதிகள், அடுக்கு, தக்கவைத்தல் மற்றும் எச்சரிக்கை ஆகியவற்றை நிர்வகிப்பது மிகவும் சிக்கலானது. 
• நிகழ்வு ஆவணங்கள், வரலாறு மற்றும் உரிமை ஆகியவை இல்லை, இதன் விளைவாக தரவுப் பயன்பாடு மற்றும் கண்டறியும் திறன் மோசமடைந்தது. 
• கிளவுட் வரிசை சேவையைக் கொண்டு உருவாக்கப்பட்ட தரவு உள்வாங்கும் உள்கட்டமைப்பு, 23 ஜிபிபிஎஸ் கிளவுட் உள்வாங்கும் செலவை ஏற்படுத்தியது.

முன்னர், தரவுப் பகுப்பாய்வுகள் பல தொகுப்புப் பைப்லைன்கள் (batch pipelines) வழியாக ஒரு ஒற்றை தர்க்கரீதியான அட்டவணையிலிருந்து தரவைப் பிரித்தெடுப்பதைச் சார்ந்திருந்தன. பெரிய, செயல்திறன் மிக்க வினவல்களை (queries) இயக்க இது அவசியமாக இருந்தது—ஆனால் இது செயலாக்கத்தையும் மெதுவாக்கியது. இந்த நிகழ்வுகளை பிரத்யேக அட்டவணைகளுக்கு வழிநடத்த உள்வாங்கும் பேக்கெண்ட் சேவையைப் (ingestion backend service) பயன்படுத்துவது, பகுப்பாய்வு நிகழ்வுகளுக்கு ஒரு ஸ்கீமாவைக் (schema) கொடுப்பதன் மூலமும், முன்கூட்டியே ஒரு சேருமிட அட்டவணையை (destination table) வரையறுப்பதன் மூலமும் தொகுப்புப் பிரித்தெடுப்புப் பைப்லைன்களை நீக்குகிறது. 

ராப்ளக்ஸில் பகுப்பாய்வு நிகழ்வுகளுக்கான திட்டமொழியாக ப்ரோட்டோபஃப் (ப்ரோட்டோ)வை நாங்கள் தேர்ந்தெடுத்தோம். இது ஒரு இயல்பான தேர்வாக இருந்தது, ஏனெனில் ப்ரோட்டோ மற்றும் gRPC ஆகியவை எங்கள் விருப்பமான கட்டமைப்பு சேவை கட்டமைப்புகளாகும். கூடுதலாக, உரிமை, தக்கவைப்பு, உற்பத்தித்திறன் மென்பொருள் சேனல்கள் மற்றும் நிகழ்வுத் திட்டம் போன்ற கூடுதல் மெட்டாடேட்டாவைச் சேகரிக்க நாங்கள் பயன்படுத்தும் தனிப்பயன் விருப்பங்களை வரையறுப்பதற்கு ப்ரோட்டோ சிறந்த ஆதரவை வழங்குகிறது. 

நமது ஸ்கீமா மொழியைத் தேர்ந்தெடுத்த பிறகு, ஒரு ஸ்கீமா புதுப்பிக்கப்படும்போது என்ன நடக்கிறது மற்றும் எந்தப் புதுப்பிப்புகள் அனுமதிக்கப்பட வேண்டும் என்பதை நாங்கள் ஆராய்ந்தோம். வெளியிடப்பட்ட ஸ்கீமாவைப் பயன்படுத்தும் அதிக எண்ணிக்கையிலான கீழ்நிலை நுகர்வோருக்கு ஆதரவளிக்க, தரவுக் குழு ஸ்கீமா பதிவேட்டில் விவரிக்கப்பட்டுள்ள பின்னோக்கிய பரிவರ್तमान முறையை ஏற்றுக்கொண்டது. இந்த அணுகுமுறையின் மூலம், ஒரு புலத்தைச் சேர்ப்பதும் மென்மையாக நீக்குவதும் அனுமதிக்கப்படுகிறது. இது கீழ்நிலை நுகர்வோருடன் ஒருங்கிணைப்பு தேவைப்படாமலேயே ஸ்கீமா மாற்றங்களைச் செய்ய உதவுகிறது. 

மேலே உள்ள எடுத்துக்காட்டில், ப்ரோட்டோ கோப்பைப் புதுப்பிப்பதன் மூலம் ஒரு புலத்தைச் சேர்க்கவும் நீக்கவும் முடியும்.

ஸ்கீமாக்கள் பல நன்மைகளை வழங்குகின்றன, ஆனால் அவற்றை முன்கூட்டியே கட்டாயமாக்குவது தடையை ஏற்படுத்துகிறது. தரவு விஞ்ஞானிகள் மற்றும் பொறியாளர்கள் தடைகள் இல்லாமல் விரைவாக நகர்ந்து மீண்டும் மீண்டும் உருவாக்க வேண்டும். இதை ஆதரிப்பதற்காக, நாங்கள் ஒரு மையப்படுத்தப்பட்ட ஸ்கீமா களஞ்சியத்தை அறிமுகப்படுத்தினோம் மற்றும் ஸ்கீமாக்களை உருவாக்குவதை முடிந்தவரை தானியங்குபடுத்தவும் நெறிப்படுத்தவும் ஒரு கருவிகளின் தொகுப்பை உருவாக்கினோம். 

உதாரணமாக, ஒவ்வொரு ஸ்கீமாவிலும் தேவையான மெட்டாடேட்டா உள்ளதா என்பதையும், அது Roblox மரபுகளுக்கு இணக்கமாக உள்ளதா என்பதையும் சரிபார்க்க, நாங்கள் ஒரு பிரத்யேக ப்ரோட்டோ லிண்டரை உருவாக்கினோம். ஒரு நிகழ்வு ஸ்கீமாவை ஹைவ் தரவு வரையறை மொழிக்கு மொழிபெயர்க்க ஒரு புரோட்டோ பிளக்-இன்னையும் நாங்கள் உருவாக்கினோம், இதன் மூலம் ஒரு ஸ்கீமா உருவாக்கப்படும்போதோ அல்லது புதுப்பிக்கப்படும்போதோ அதற்கேற்ற ஹைவ் அட்டவணை ஒத்திசைவாக இருக்கும். இந்தக் கருவிகள் அனைத்தும் ஒரு CI/CD பைப்லைனில் ஒருங்கிணைக்கப்பட்டு, ஒரு புல் கோரிக்கை உருவாக்கப்படும்போது தானாகவே இயங்குகின்றன. இது பொறியாளர்கள் ஸ்கீமா சிக்கல்களை முன்கூட்டியே கண்டறியவும், அவர்களின் ஸ்கீமாக்கள் இணைக்கப்படுவதற்கு முன்பு சோதனை ஹைவ் அட்டவணைகளில் நிகழ்வுகளைச் சரிபார்க்கவும் அனுமதிக்கிறது. இதன் விளைவாக, ஒரு ஸ்கீமாவை உற்பத்திக்கு அனுப்புவது, அதை இணைப்பது போலவே எளிமையானது. 

வளர்க்கப்பட்ட டெவலப்பர் அனுபவம் நடைமுறையில் இருந்ததால், உள்ளீட்டுப் பாதையில் (ingestion pipeline) ஒரு நிகழ்வு எங்கு திட்டமிடப்பட்டு (schematized) புரோட்டோவாக (proto) மாற்றப்பட வேண்டும் என்பதை நாங்கள் ஆராய்ந்தோம். நிகழ்வு உற்பத்தியாளர்களை வரிசைப்படுத்தப்பட்ட புரோட்டோ பைட்களை (serialized proto bytes) ஏற்றுக்கொண்டு அனுப்பச் சொல்வது பல குழுக்களை உள்ளடக்கிய ஒரு குறிப்பிடத்தக்க மாற்றமாக இருக்கும். சிக்கல்களைத் தீர்க்கவும், படிப்படியாக மதிப்பை வழங்கவும், நாங்கள் உள்ளீட்டுப் பின்னணி சேவையை (ingestion backend service) புதுப்பித்து, வரும் நிகழ்வுகளை புரோட்டோவாக மாற்றும் மூலம், திட்டமிடும் முயற்சியை நிகழ்வு உற்பத்தியாளர்களிடமிருந்து பிரித்தெடுத்தோம். இப்போது, மாற்றப்பட்ட நிகழ்வுகள் பார்கெட் கோப்புகளில் சேகரிக்கப்பட்டு, விநியோகிக்கப்பட்ட சேமிப்பில் பதிவேற்றப்பட்டு, தனித்தனி ஹைவ் அட்டவணைகளாகப் பதிவு செய்யப்படுகின்றன.

அடுத்து, பகுப்பாய்வு நிகழ்வுகளை வழங்குவதற்கான செலவுகளில் நாங்கள் கவனம் செலுத்தினோம். முன்னதாக, உள்ளீட்டு பேக்கெண்ட் கிளவுட் உள்கட்டமைப்பில் கட்டப்பட்டது. பகுப்பாய்வு நிகழ்வுகள் ஒரு வரிசை சேவைக்கு அனுப்பப்பட்டன, அது அவற்றை தற்காலிகமாகச் சேமித்து, பின்னர் அடுத்தகட்ட செயலாக்கம் மற்றும் பகுப்பாய்விற்காக நீடித்த கிளவுட் சேமிப்பில் சேமித்தது. ஒரு கிளவுட் வரிசை சேவை எங்கள் சேவையை எளிதாக்கியதோடு, வெளிப்படையான அளவிடுதலுக்கும் அனுமதித்தாலும், மற்ற ஸ்ட்ரீமிங் வேலைகளால் அதைப் பயன்படுத்துவது கடினமாகவும், அதிக செலவுள்ளதாகவும் இருந்தது. இதைச் சரிசெய்ய, உள்வாங்கும் சேவையை ராப்லாக்ஸின் தரவு மையங்களுக்குள் கொண்டு வருவதை நாங்கள் ஆராய்ந்தோம். 

எங்கள் உள் சேமிப்புக் குழு, ஒரு திறந்த மூல விநியோகிக்கப்பட்ட நிகழ்வு ஸ்ட்ரீமிங் தளத்தை அடிப்படையாகக் கொண்டு, வரிசை-ஒரு-சேவையாக (QaaS) ஒன்றை உருவாக்கியிருந்தது. பகுப்பாய்வு நிகழ்வுகளை உள்ளிழுப்பதற்கு QaaS ஒரு சிறந்த மாற்றாகும், ஏனெனில் நிகழ்வுகள் முதலில் வருபவர், முதலில் செல்பவர் வரிசையில் கண்காணிக்கப்படுகின்றன மற்றும் ஒரு குறுகிய காலம் தக்கவைக்கப்பட்ட பிறகு நீக்கப்படுகின்றன. ராப்லாக்ஸில், ஒவ்வொரு திட்டமிடப்பட்ட நிகழ்விற்கும் ஒரு பிரத்யேக டாபிக்கை உருவாக்கி, பெரிய நிகழ்வு ஓட்டங்களுக்காக அளவிடுதலுக்கு பிரிவினை எண்ணிக்கையைப் (partition count) பயன்படுத்துகிறோம். தரவுக் குழுவானது QaaS-இலிருந்து தரவைப் பெறவும், பார்கெட் கோப்புகளை உருவாக்கவும், கோப்புகளை நீடித்த கிளவுட் சேமிப்பில் பதிவேற்றவும் ஒரு பிரத்யேக சேவையை உருவாக்கியது.

QaaS நடைமுறையில் இருந்ததாலும், பார்க்யூட் கோப்புகளை உருவாக்கி சேமிப்பதற்கான ஒரு பிரத்யேக சேவை இருந்ததாலும், தரவுக் குழு ஆறு மாதங்களுக்கு தரவுத் துல்லியம் மற்றும் அளவிடுதல் ஆகிய இரண்டையும் சரிபார்க்க நிழல் எழுத்துக்களைச் செய்தது. இறுதியாக, விரிவான தரவு முழுமை மற்றும் ஒருமைப்பாட்டுச் சோதனைகளுக்குப் பிறகு, எங்கள் பழைய கிளவுட் வரிசை சேவையிலிருந்து பகுப்பாய்வு நிகழ்வுகளின் உள்ளீட்டை வெற்றிகரமாக இடமாற்றம் செய்தோம். இது ஒரு முக்கிய மைல்கல் ஆகும். தரவு உள்ளீட்டுப் பாதையிலிருந்து கிளவுட் வளச் செலவை நாங்கள் நீக்கினோம், மேலும் ஒரு நிகழ்வு நடப்பதற்கும் அது எங்கள் தரவு ஏரியில் (data lake) வந்து சேர்வதற்கும் இடையிலான தாமதத்தை கணிசமாகக் குறைத்தோம். முன்பு எங்களுக்கு மூன்று மணி நேர சேவை-நிலை ஒப்பந்தம் இருந்தது, அதை நாங்கள் அடிக்கடி தவறவிட்டோம்—இன்று, நாங்கள் தொடர்ந்து சராசரியாக 15 நிமிடங்களை எட்டுகிறோம். 

இது, QaaS-இலிருந்து பயன்படுத்தி, பாதுகாப்பு மற்றும் நிகழ்நேரப் பரிந்துரை அம்சங்களுக்கு ஆற்றல் அளிக்க, திட்டமிடப்பட்ட நிகழ்வுகளுக்கு எதிராக நிகழ்நேர நிகழ்வு செயலாக்கக் குழாய்களைப் பொறியாளர்கள் எழுத அனுமதிக்கிறது. அதே திட்டமிடல் கட்டமைப்பு மற்றும் QaaS உள்ளீட்டுடன் மாற்றத் தரவுப் பிடிப்பையும் நாங்கள் அறிமுகப்படுத்தினோம், இது முழுமையான தரவுத்தள டம்ப்களை பெருமளவில் நீக்குகிறது. நிகழ்நேரப் பகுப்பாய்வுகள் மற்றும் நிகழ்வு ஓட்டத்திலிருந்து புதிய பயன்பாட்டு நிகழ்வுகளைத் திறப்பது வரை, பெரிய அளவில் புத்திசாலித்தனமான, வேகமான, அதிக செலவு குறைந்த தரவு அமைப்புகளை நாங்கள் புதுமை செய்து உருவாக்கும்போது எங்கள் பணி தொடர்கிறது. 

இந்தப் பணிக்கு அவரது மதிப்புமிக்க பங்களிப்புகளுக்காக பால் மௌவுக்கு நாங்கள் நன்றி தெரிவிக்க விரும்புகிறோம்.

^{* மார்ச் 31, 2025-இல் முடிவடையும் மூன்று மாதங்கள் வரை.}