রবলোক্সের দিনে ২ ট্রিলিয়ন অ্যানালিটিক্স ইভেন্টে পৌঁছানোর পথ

প্রতিদিন গড়ে ৯৭.৮ মিলিয়ন ব্যবহারকারী* যোগাযোগ, সৃষ্টি এবং একসঙ্গে খেলার জন্য Roblox-এ ভিজিট করে। এই মিথস্ক্রিয়াগুলো মিলিয়ে ২ পেটাбайт বিশ্লেষণাত্মক ইভেন্ট ডেটা তৈরি করে। একটি নতুন স্কেলযোগ্য ইনজেশন সিস্টেমের কারণে, সম্প্রতি আমরা একটি বড় মাইলফলক স্পর্শ করেছি: আমাদের সিস্টেম এখন প্রতিদিন ২ ট্রিলিয়নেরও বেশি ইভেন্ট প্রক্রিয়া করছে। এই সিস্টেমটি Roblox প্ল্যাটফর্মকে চালিত ব্যক্তিগতকরণ, নিরাপত্তা এবং অর্থনীতি অ্যালগরিদমগুলোকে সক্ষম করে।

এর আগে, একটি ক্লাউড কুই সার্ভিস Roblox-উৎপন্ন অ্যানালিটিক্স ডেটা events_hourly নামে একটি একক যৌক্তিক টেবিলে গ্রহণ করত। এটি তারিখ, ঘণ্টা এবং web, mobile বা friendService-এর মতো মনগড়া ট্যাগ অনুযায়ী ভাগ করা হত। আমাদের ডেটা বিজ্ঞানী ও প্রকৌশলীরা নির্দিষ্ট ইভেন্টগুলো পৃথক টেবিলে আহরণ করার জন্য নির্ধারিত ব্যাচ জবগুলোর উপর নির্ভর করতেন। নতুন অ্যানালিটিক ইভেন্ট তৈরি ও পাঠানোর জন্য কোনো পূর্বনির্ধারিত স্কিমা প্রয়োজন হত না। প্রকৌশলীরা এক্সট্র্যাক্ট, ট্রান্সফর্ম, এবং লোড (ETL) পাইপলাইন ধাপে তাদের নিজস্ব টেবিল স্কিমা নিয়ন্ত্রণ করতেন।

এই সেটআপটি নমনীয় ছিল এবং ইঞ্জিনিয়ারদের দ্রুত কাজ করার সুযোগ দিত, তবে এতে কিছু চ্যালেঞ্জও ছিল। 

• ইভেন্টের পরিমাণ বাড়ার সাথে সাথে শুধুমাত্র তারিখ, ঘণ্টা এবং ট্যাগ অনুযায়ী ভাগ করা ২ ট্রিলিয়ন সারি নিয়ে কাজ করা ক্রমশ অকার্যকর হয়ে উঠল।
• events_hourly টেবিলের জন্য ছয় ঘণ্টার দিনের শেষে বিলম্ব এবং events_daily-এর জন্য ২৪ ঘণ্টার বিলম্ব এমন সময় তৈরি করেছিল যখন ডেটা পাইপলাইনগুলো আটকে গিয়েছিল। 
• ডেটাসেট-স্তরের অনুমতি, স্তর, সংরক্ষণকাল এবং সতর্কতা পরিচালনা আরও জটিল হয়ে উঠল। 
• ইভেন্টের ডকুমেন্টেশন, ইতিহাস এবং মালিকানা অনুপস্থিত ছিল, যার ফলে ডেটার ব্যবহারযোগ্যতা এবং ট্রেসেবিলিটি দুর্বল হয়েছিল। 
• ক্লাউড কুই সার্ভিস দিয়ে নির্মিত ইনজেশন অবকাঠামোতে ২৩ জিবিপিএস ক্লাউড ইনজেশন খরচ হয়েছে।

ডেটা অ্যানালিটিক্স পূর্বে একাধিক ব্যাচ পাইপলাইনের মাধ্যমে একটি একক যৌক্তিক টেবিল থেকে ডেটা আহরণে নির্ভর করত। বড়, কর্মক্ষম কুয়েরি চালানোর জন্য এটি প্রয়োজনীয় ছিল—কিন্তু এতে প্রক্রিয়াকরণ ধীর হয়ে যেত। ইঞ্জেষ্টিয়ন ব্যাকএন্ড সার্ভিস ব্যবহার করে এই ইভেন্টগুলোকে নির্দিষ্ট টেবিলে রাউট করা ব্যাচ এক্সট্র্যাকশন পাইপলাইনগুলো বাদ দেয়, কারণ এতে অ্যানালিটিক ইভেন্টগুলোকে আগে থেকেই একটি স্কিমা এবং গন্তব্য টেবিল নির্ধারণ করা হয়। 

আমরা Roblox-এ অ্যানালিটিক্স ইভেন্টের জন্য স্কিমা ভাষা হিসেবে Protobuf (proto) বেছে নিয়েছি। এটি একটি স্বাভাবিক পছন্দ ছিল, কারণ proto এবং gRPC আমাদের পছন্দের বিল্ডিং সার্ভিস ফ্রেমওয়ার্ক। এছাড়াও, proto কাস্টম অপশন সংজ্ঞায়িত করার জন্য চমৎকার সমর্থন প্রদান করে, যা আমরা মালিকানা, সংরক্ষণকাল, প্রোডাক্টিভিটি সফটওয়্যার চ্যানেল এবং ইভেন্ট স্কিমা-এর মতো অতিরিক্ত মেটাডেটা সংগ্রহ করতে ব্যবহার করি। 

আমাদের স্কিমা ভাষা নির্বাচন করার পর, আমরা পরীক্ষা করেছিলাম যে স্কিমা আপডেট হলে কী ঘটে এবং কোন আপডেটগুলো অনুমোদিত হওয়া উচিত। প্রকাশিত স্কিমা ব্যবহারকারী সর্বাধিক সংখ্যক ডাউনস্ট্রিম ভোক্তাকে সমর্থন করার জন্য, ডেটা টিম স্কিমা রেজিস্ট্রিতে বর্ণিত ব্যাকওয়ার্ড ট্রানসিটিভ মোড গ্রহণ করেছিল। এই পদ্ধতিতে একটি ফিল্ড যোগ করা এবং নরমভাবে মুছে ফেলা অনুমোদিত। এর ফলে ডাউনস্ট্রিম ভোক্তাদের সাথে সমন্বয় না করেই স্কিমা পরিবর্তন করা সম্ভব হয়। 

উপরের উদাহরণে, আমরা proto ফাইল আপডেট করে একটি ফিল্ড যোগ এবং মুছে ফেলতে পারি।

স্কিমা অনেক সুবিধা প্রদান করে, তবে এগুলো আগে থেকেই বাধ্যতামূলক করলে তা বাধা সৃষ্টি করে। ডেটা বিজ্ঞানী ও প্রকৌশলীদের দ্রুত কাজ করতে এবং বাধা ছাড়াই পুনরাবৃত্তি করতে হয়। এই বিষয়টি সমর্থন করতে, আমরা একটি কেন্দ্রীভূত স্কিমা রিপোজিটরি চালু করেছি এবং স্কিমা রচনাকে যতটা সম্ভব স্বয়ংক্রিয় ও সরল করতে বিভিন্ন সরঞ্জামের একটি স্যুট তৈরি করেছি। 

উদাহরণস্বরূপ, আমরা একটি কাস্টম প্রোটো লিন্টার তৈরি করেছি যা যাচাই করে যে প্রতিটি স্কিমা প্রয়োজনীয় মেটাডেটা ধারণ করে এবং Roblox-এর নিয়মাবলী মেনে চলে। আমরা একটি প্রোটো প্লাগ-ইনও তৈরি করেছি যা ইভেন্ট স্কিমাকে Hive ডেটা ডেফিনিশন ল্যাঙ্গুয়েজে অনুবাদ করে, যাতে স্কিমা তৈরি বা আপডেট হওয়ার সাথে সাথে সংশ্লিষ্ট Hive টেবিল সিঙ্ক্রোনাইজড থাকে। এই সব টুল CI/CD পাইপলাইনে ইন্টিগ্রেট করা হয়েছে এবং পুল রিকোয়েস্ট তৈরি হলে স্বয়ংক্রিয়ভাবে চলে। এর ফলে ইঞ্জিনিয়াররা স্কিমা সংক্রান্ত সমস্যাগুলো আগেভাগেই ধরতে পারে এবং তাদের স্কিমা মर्ज করার আগে টেস্ট Hive টেবিলে ইভেন্টগুলো যাচাই করতে পারে। ফলস্বরূপ, প্রোডাকশনে একটি স্কিমা ডিপ্লয় করা মর্জের মতোই সহজ। 

একটি সরলীকৃত ডেভেলপার অভিজ্ঞতা নিশ্চিত করার পর, আমরা ইনজেশন পাইপলাইনের কোন ধাপে একটি ইভেন্টকে স্কিমাটাইজ এবং প্রোটোতে রূপান্তর করা উচিত তা পরীক্ষা করেছি। ইভেন্ট প্রযোজকদের সিরিয়ালাইজড প্রোটো বাইট গ্রহণ ও প্রেরণ করতে বলা একটি উল্লেখযোগ্য পরিবর্তন হতো যা একাধিক দলের মধ্যে বিস্তৃত। সমস্যাগুলো সমাধান করতে এবং ধাপে ধাপে মূল্য প্রদান করতে, আমরা ইভেন্ট প্রযোজকদের থেকে স্কিমাটাইজেশন প্রচেষ্টা আলাদা করেছি, ইনজেশন ব্যাকএন্ড সার্ভিস আপডেট করে ইনকামিং ইভেন্টগুলোকে প্রোটোতে রূপান্তর করার মাধ্যমে। এখন রূপান্তরিত ইভেন্টগুলো পারকেট ফাইলে সংগৃহীত হয়, বিতরণকৃত স্টোরেজে আপলোড করা হয় এবং পৃথক Hive টেবিল হিসেবে নিবন্ধিত করা হয়।

পরবর্তী, আমরা অ্যানালিটিক্স ইভেন্ট সার্ভ করার খরচগুলিতে মনোনিবেশ করেছি। পূর্বে, ইনজেশন ব্যাকএন্ডটি ক্লাউড অবকাঠামোর উপর নির্মিত ছিল। এ্যানালিটিক্স ইভেন্টগুলো একটি কুই (queue) সার্ভিসে পাঠানো হতো, যা সেগুলোকে বাফার করে পরবর্তী প্রক্রিয়াকরণ ও বিশ্লেষণের জন্য টেকসই ক্লাউড স্টোরেজে সংরক্ষণ করত। যদিও ক্লাউড কুই সার্ভিস আমাদের সেবাকে সহজ করেছে এবং স্বচ্ছ স্কেলিংয়ের সুযোগ দিয়েছে, এটি অন্যান্য স্ট্রিমিং জব দ্বারা ব্যবহার করা কঠিন এবং আরও ব্যয়বহুল। এই সমস্যা সমাধানের জন্য, আমরা ইনজেশন সার্ভিসটি Roblox-এর ডেটা সেন্টারে আনার কথা ভাবলাম। 

আমাদের অভ্যন্তরীণ স্টোরেজ দল একটি ওপেন-সোর্স বিতরণকৃত ইভেন্ট স্ট্রিমিং প্ল্যাটফর্মের উপর ভিত্তি করে কুই-অ্যাজ-এ-সার্ভিস (QaaS) তৈরি করেছিল। QaaS বিশ্লেষণাত্মক ইভেন্ট ইনজেশন-এর জন্য একটি চমৎকার বিকল্প, কারণ ইভেন্টগুলো প্রথম-আগমন, প্রথম-প্রস্থান ক্রমে টেইল করা হয় এবং স্বল্প সময়ের ধরে সংরক্ষণের পর মুছে ফেলা হয়। Roblox-এ, আমরা প্রতিটি স্কিমাটাইজড ইভেন্টের জন্য একটি নিবেদিত টপিক তৈরি করি এবং বড় ইভেন্ট স্ট্রিমের জন্য স্কেল করতে পার্টিশন কাউন্ট ব্যবহার করি। ডেটা টিম QaaS থেকে গ্রহণ করতে, পারকেট ফাইল তৈরি করতে এবং ফাইলগুলো টেকসই ক্লাউড স্টোরেজে আপলোড করতে একটি নিবেদিত সার্ভিসও তৈরি করেছে।

QaaS স্থাপিত হওয়ার পর এবং পারকেট ফাইল তৈরি ও সংরক্ষণের জন্য একটি নিবেদিত সার্ভিস থাকার কারণে, ডেটা টিম ছয় মাস ধরে শ্যাডো রাইটস পরিচালনা করে ডেটার সঠিকতা এবং স্কেলেবিলিটি উভয়ই যাচাই করেছে। অবশেষে, ব্যাপক ডেটা পরিপূর্ণতা এবং অখণ্ডতা যাচাইয়ের পর, আমরা সফলভাবে আমাদের পুরনো ক্লাউড কুই সার্ভিস থেকে অ্যানালিটিক ইভেন্ট ইনজেশন মাইগ্রেট করেছি। এটি ছিল একটি বড় মাইলফলক। আমরা ইনজেশন পথে ক্লাউড রিসোর্সের খরচ বাদ দিয়েছি এবং একটি ইভেন্ট ফায়ার হওয়ার এবং আমাদের ডেটা লেকে ল্যান্ড হওয়ার মধ্যে ল্যাটেন্সি উল্লেখযোগ্যভাবে কমিয়েছি। পূর্বে আমাদের তিন ঘণ্টার সার্ভিস-লেভেল এগ্রিমেন্ট ছিল, যা আমরা প্রায়ই মিস করতাম—আজ আমরা ধারাবাহিকভাবে গড়ে ১৫ মিনিটে পৌঁছাচ্ছি। 

এটি প্রকৌশলীদের QaaS থেকে গ্রহণ করে স্কিমেটাইজড ইভেন্টের বিরুদ্ধে রিয়েল-টাইম ইভেন্ট প্রসেসিং পাইপলাইন লেখার সুযোগ দেয়, যা পাওয়ার সেফটি এবং রিয়েল-টাইম সুপারিশ ফিচারগুলোকে শক্তিশালী করে। আমরা একই স্কিমেটাইজেশন ফ্রেমওয়ার্ক এবং QaaS ইনজেশন ব্যবহার করে চেঞ্জ ডেটা ক্যাপচারও চালু করেছি, যা প্রায় সম্পূর্ণরূপে পূর্ণ ডাটাবেস ডাম্প নির্মূল করে। রিয়েল-টাইম অ্যানালিটিক্স এবং ইভেন্ট স্ট্রিমিং থেকে নতুন ব্যবহারিক ক্ষেত্রে উন্মোচন পর্যন্ত, আমাদের কাজ অব্যাহত রয়েছে, কারণ আমরা বড় পরিসরে আরও স্মার্ট, দ্রুত এবং আরও খরচ-দক্ষ ডেটা সিস্টেম তৈরি ও উদ্ভাবন করছি। 

আমরা পল মু-কে এই কাজের জন্য তার মূল্যবান অবদানের জন্য ধন্যবাদ জানাই।

^{* ৩১ মার্চ, ২০২৫ তারিখে শেষ হওয়া তিন মাসের হিসাবে।}