مسيرة Roblox نحو 2 تريليون حدث تحليلي يوميًا

كل يوم، يزور Roblox ما معدله 97.8 مليون مستخدم* للتواصل والإبداع واللعب معًا. وتولد هذه التفاعلات مجتمعة 2 بيتابايت من بيانات الأحداث التحليلية. وبفضل نظام استيعاب جديد قابل للتوسع، حققنا مؤخرًا إنجازًا هامًا: حيث يعالج نظامنا الآن أكثر من 2 تريليون حدث يوميًا. ويتيح هذا النظام خوارزميات التخصيص والأمان والاقتصاد التي تدعم منصة Roblox.

في السابق، كانت خدمة قائمة انتظار سحابية تستقبل البيانات التحليلية التي تولدها Roblox في جدول منطقي واحد، يُسمى events_hourly. وكان يتم تقسيمه حسب التاريخ والساعة وعلامات محددة بشكل تعسفي مثل web أو mobile أو friendService. اعتمد علماء البيانات والمهندسون لدينا على مهام دفعية مجدولة لاستخراج أحداث محددة إلى جداول مخصصة. لم يتطلب إنشاء أحداث تحليلية جديدة وإرسالها أي مخطط مسبق. كان المهندسون يتحكمون في مخطط الجدول الخاص بهم في مرحلة لاحقة من مسار الاستخراج والتحويل والتحميل (ETL).

كان هذا الإعداد مرنًا ومكّن المهندسين من التحرك بسرعة، لكنه طرح تحديات. 

• مع تزايد حجم الأحداث، أصبح التفاعل مع 2 تريليون صف مقسمة فقط حسب التاريخ والساعة والعلامات غير فعال بشكل متزايد.
• أدى التأخير لمدة ست ساعات في نهاية اليوم لجدول events_hourly والتأخير لمدة 24 ساعة لجدول events_daily إلى حدوث فترات تم فيها حظر مسارات البيانات. 
• أصبحت إدارة الأذونات على مستوى مجموعة البيانات والمستويات والاحتفاظ والإنذارات أكثر تعقيدًا. 
• كانت توثيق الأحداث وسجلها وملكيتها مفقودة، مما أدى إلى ضعف قابلية استخدام البيانات وإمكانية تتبعها. 
• تكبدت البنية التحتية للاستيعاب، التي تم إنشاؤها باستخدام خدمة قائمة انتظار السحابة، تكلفة استيعاب سحابي بلغت 23 جيجابت في الثانية.

كانت تحليلات البيانات تعتمد في السابق على استخراج البيانات من جدول منطقي واحد عبر العديد من خطوط الأنابيب الدفعية. كان هذا ضروريًا لتشغيل استعلامات كبيرة وعالية الأداء — ولكنه أدى أيضًا إلى إبطاء المعالجة. يؤدي استخدام خدمة الخلفية للاستيعاب لتوجيه هذه الأحداث إلى جداول مخصصة إلى التخلص من خطوط الأنابيب الدفعية للاستخراج من خلال تزويد الأحداث التحليلية بمخطط وتحديد جدول الوجهة مسبقًا. 

اخترنا Protobuf (proto) كلغة مخطط لأحداث التحليلات في Roblox. كان هذا اختيارًا طبيعيًا، نظرًا لأن proto و gRPC هما أطر عمل خدمات البناء المفضلة لدينا. بالإضافة إلى ذلك، يوفر proto دعمًا رائعًا لتحديد الخيارات المخصصة التي نستفيد منها لجمع بيانات تعريفية إضافية، مثل الملكية والاحتفاظ وقنوات برامج الإنتاجية ومخطط الأحداث. 

بعد اختيار لغة المخطط، قمنا بفحص ما يحدث عند تحديث المخطط وأي التحديثات يجب السماح بها. لدعم أكبر عدد ممكن من المستخدمين النهائيين الذين يستخدمون المخطط المنشور، اعتمد فريق البيانات الوضع الانتقالي الرجعي الموصوف في سجل المخططات. مع هذا النهج، يُسمح بإضافة الحقول وحذفها بشكل مؤقت. وهذا يتيح إجراء تغييرات على المخطط دون الحاجة إلى التنسيق مع المستخدمين النهائيين. 

في المثال أعلاه، يمكننا إضافة حقل وحذفه عن طريق تحديث ملف proto.

تقدم المخططات العديد من المزايا، لكن اشتراطها مسبقًا يسبب بعض الصعوبات. يحتاج علماء البيانات والمهندسون إلى التحرك بسرعة والتكرار دون عوائق. لدعم ذلك، أدخلنا مستودعًا مركزيًا للمخططات وقمنا ببناء مجموعة من الأدوات لجعل إنشاء المخططات آليًا ومبسطًا قدر الإمكان. 

على سبيل المثال، قمنا بإنشاء أداة فحص بروتو مخصصة للتحقق من أن كل مخطط يحتوي على البيانات الوصفية المطلوبة ويتوافق مع قواعد Roblox. كما قمنا بإنشاء مكون إضافي لـ proto لترجمة مخطط الأحداث إلى لغة تعريف البيانات Hive بحيث يظل جدول Hive المقابل متزامنًا أينما تم إنشاء المخطط أو تحديثه. يتم دمج جميع هذه الأدوات في خط أنابيب CI/CD وتُشغَّل تلقائيًا عند إنشاء طلب سحب. وهذا يتيح للمهندسين اكتشاف مشكلات المخططات في وقت مبكر والتحقق من الأحداث في جداول Hive التجريبية قبل دمج مخططاتهم. ونتيجة لذلك، أصبح نشر المخطط في بيئة الإنتاج أمرًا بسيطًا مثل الدمج. 

مع وجود تجربة مطور مبسطة، قمنا بفحص المكان الذي يجب فيه تخطيط الحدث وتحويله إلى proto في خط أنابيب الاستيعاب. سيكون طلب منتجي الأحداث اعتماد وإرسال بايتات proto المتسلسلة تغييرًا كبيرًا يمتد عبر فرق متعددة. لمعالجة نقاط الضعف وتقديم قيمة بشكل تدريجي، قمنا بفصل جهود التخطيط عن منتجي الأحداث عن طريق تحديث خدمة الخلفية للاستيعاب لتحويل الأحداث الواردة إلى proto. الآن، يتم تجميع الأحداث المحولة في ملفات Parquet، وتحميلها إلى التخزين الموزع، وتسجيلها كجداول Hive فردية.

بعد ذلك، ركزنا على تكاليف تقديم أحداث التحليلات. في السابق، تم بناء الخلفية الخاصة بالاستيعاب على البنية التحتية السحابية. كانت أحداث التحليلات تُرسَل إلى خدمة قائمة انتظار، والتي كانت تقوم بتخزينها مؤقتًا ثم تخزينها في سحابة تخزين دائمة من أجل المعالجة والتحليل في المراحل اللاحقة. على الرغم من أن خدمة قائمة الانتظار السحابية بسطت خدمتنا وسمحت بتوسيع نطاقها بشكل شفاف، إلا أنها صعبة الاستخدام من قبل مهام البث الأخرى وأكثر تكلفة. لمعالجة هذه المشكلة، بحثنا في إمكانية نقل خدمة الاستيعاب إلى مراكز بيانات Roblox. 

قام فريق التخزين الداخلي لدينا ببناء خدمة قائمة الانتظار كخدمة (QaaS)، استنادًا إلى منصة تدفق أحداث موزعة مفتوحة المصدر. تعد QaaS بديلاً رائعًا لاستيعاب الأحداث التحليلية لأن الأحداث يتم تتبعها بترتيب "الوارد أولاً، يخرج أولاً" ويتم حذفها بعد فترة احتفاظ قصيرة. في Roblox، نقوم بإنشاء موضوع مخصص لكل حدث مخطط ونستخدم عدد الأقسام لتوسيع نطاق تدفقات الأحداث الكبيرة. كما أنشأ فريق البيانات خدمة مخصصة للاستفادة من QaaS وإنشاء ملفات Parquet وتحميل الملفات إلى تخزين سحابي دائم.

مع وجود QaaS وخدمة مخصصة لإنشاء ملفات Parquet وتخزينها، أجرى فريق البيانات عمليات كتابة الظل لمدة ستة أشهر للتحقق من صحة البيانات وقابليتها للتوسع. وأخيرًا، بعد إجراء فحوصات شاملة لاكتمال البيانات وسلامتها، نجحنا في ترحيل استيعاب الأحداث التحليلية من خدمة قائمة الانتظار السحابية القديمة لدينا. كان هذا إنجازًا هامًا. لقد أزلنا تكلفة موارد السحابة من مسار الاستيعاب وقللنا بشكل كبير من زمن الاستجابة بين إطلاق الحدث ووصوله إلى بحيرة البيانات لدينا. كان لدينا سابقًا اتفاقية مستوى خدمة مدتها ثلاث ساعات، والتي غالبًا ما كنا نفشل في الوفاء بها — أما اليوم، فنحن نحقق باستمرار متوسطًا يبلغ 15 دقيقة. 

يتيح ذلك للمهندسين كتابة مسارات معالجة الأحداث في الوقت الفعلي مقابل الأحداث المخططة من خلال الاستفادة من QaaS لتعزيز ميزات السلامة والتوصيات في الوقت الفعلي. كما أطلقنا ميزة التقاط البيانات المتغيرة باستخدام نفس إطار العمل المخطط واستيعاب QaaS، مما أدى إلى التخلص بشكل كبير من عمليات تفريغ قواعد البيانات بالكامل. من التحليلات في الوقت الفعلي وتدفق الأحداث إلى فتح آفاق جديدة لحالات الاستخدام، يستمر عملنا مع ابتكارنا وبناء أنظمة بيانات أكثر ذكاءً وسرعة وكفاءة من حيث التكلفة على نطاق واسع. 

نود أن نشكر بول مو على مساهماته القيمة في هذا العمل.

^{* اعتبارًا من الربع المنتهي في 31 مارس 2025.}