الدروس المستفادة: تشغيل Presto على نطاق Meta
Presto هو محرك استعلام SQL مجاني ومفتوح المصدر. لقد استخدمناه في Meta على مدار السنوات العشر الماضية، وتعلمنا الكثير أثناء ذلك. يتطلب تشغيل أي شيء على نطاق واسع، أي الأدوات والعمليات والخدمات، القدرة على حل المشكلات للتغلب على التحديات غير المتوقعة. فيما يلي أربعة أشياء تعلمناها أثناء توسيع استخدام Presto على نطاق Meta، وبعض النصائح إذا كنت مهتمًا بتشغيل الاستعلامات الخاصة على نطاق واسع!
توسيع Presto بشكل سريع لتلبية المطالب المتزايدة: ما التحديات التي واجهناها؟
نشر إصدارات Presto الجديدة
الشكل الأول: معالجة دفق العمل لإطلاق إصدارات جديدة من Presto (مخطط بواسطة فيليب س. بيل)
تدير Meta عددًا كبيرًا من مجموعات Presto التي تغطي مراكز البيانات عبر عدة مواقع في جميع أنحاء العالم. تم إنشاء إصدار جديد من Presto وجاهز للنشر مرة واحدة على الأقل تقريبًا، وأحيانًا مرتين كل شهر. كان من أوائل التحديات التي واجهناها بالتزامن مع نمو تأثير Presto في Meta بسرعة هو نشر محرك الاستعلام لدى عدد كبير من المجموعات مع ضمان التوّفر الثابت والموثوقية. لا يزال هذا صحيحًا بشكل خاص لحالات استخدام Presto التفاعلي، أي عندما يبدأ المستخدم استعلامًا وينتظر نتيجة بتحفز. يعتبر تعذر الاستعلام أقل أهمية بالنسبة لحالات الاستخدام "المجمّعة" الآلية حيث تضمن عمليات إعادة المحاولة التلقائية نجاح الاستعلام في النهاية.
كان حل هذا الأمر بسيطًا. تتواجد كل مجموعات Presto خلف موازن تحميل يُسمى البوابة وهو مسؤول (بالاقتران مع الأنظمة الأخرى في Meta) عن توجيه استعلامات Presto إلى المجموعة المناسبة. عندما تحتاج مجموعة Presto إلى التحديث، يتم تحديدها أولاً على أنها مستنزفة من البوابة، أي تتوقف البوابة عن توجيه أي استعلامات جديدة إليها. ثم تنتظر الأتمتة وقتًا محددًا بشكل مسبق حتى تنتهي الاستعلامات التي تعمل حاليًا على المجموعة. يتم حينها تحديث المجموعة، وبمجرد التواجد على الإنترنت، تصبح مرئية للبوابة والتي يمكنها توجيه الاستعلامات الجديدة إليها.
الجانب الآخر لنشر إصدارات Presto الجديدة هو التوّفر. نحتاج إلى التأكد من أنه لا يزال بإمكان المستخدمين استخدام Presto أثناء تحديث المجموعات. مرة أخرى، تضمن الأتمتة أن كل مركز بيانات في كل منطقة فعلية لديه دائمًا العدد الضروري من مجموعات Presto المتوفرة. يجب بالتأكيد تحقيق توازن بين إزالة عدد كبير للغاية من المجموعات في وقت واحد (مشكلة توّفر) وإزالة عدد قليل للغاية في وقت واحد (يستغرق النشر وقتًا طويلاً).
أتمتة انتظار وإيقاف مجموعات Presto
الشكل الثاني: دفق العمل التلقائي لإضافة الأجهزة إلى المجموعات (مخطط من فيليب س. بيل)
يتطور توزيع مستودع البيانات في Meta على مستوى مناطق مختلفة باستمرار. هذا يعني أنه يجب أن تنتظر مجموعات Presto الجديدة بينما يتم إيقاف المجموعات الموجودة بانتظام. سابقًا عندما كان هناك عدد قليل من مجموعات Presto، كانت هذه عملية يدوية. عندما بدأت Meta في التوسع، سرعان ما أصبح من الصعب تتبع كل التغييرات يدويًا. لحل هذه المشكلة، قمنا بتنفيذ الأتمتة للتعامل مع انتظار المجموعات وإيقافها.
أولاً، كان علينا توحيد تكوينات المجموعة، أي أنه كان علينا تطوير تكوينات أساسية لحالات استخدام Presto المختلفة في Meta. سيكون لكل مجموعة حينها عدد أدنى من المواصفات الإضافية أو المتجاوزة على التكوين الأساسي. بمجرد اكتمال ذلك، يمكن تشغيل أي مجموعة جديدة عن طريق إنشاء التكوينات تلقائيًا من القالب الأساسي. تطلب تحويل الكتلة أيضًا الدمج مع روابط الأتمتة حتى نتمكن من التكامل مع خدمات البنية التحتية المتنوعة على مستوى الشركة مثل Tupperware والخدمات الخاصة بمستودعات البيانات. بمجرد تواجد المجموعة على الإنترنت، يتم إرسال عدد قليل من استعلامات الاختبار إلى المجموعة وتتحقق الأتمتة من أن الاستعلامات قد تم تنفيذها بنجاح بواسطة المجموعة. يتم تسجيل المجموعة بعد ذلك من خلال البوابة وتبدأ في تقديم الاستعلامات.
يتبع إيقاف المجموعة إلى حد كبير العملية العكسية لذلك. يتم إلغاء تسجيل المجموعة من البوابة ونسمح بإنهاء أي استعلامات قيد التشغيل. يتم إيقاف تشغيل عمليات Presto وحذف تكوينات المجموعة.
تم دمج هذه الأتمتة في دفق انتظار الأجهزة وإيقاف مستودع البيانات. النتيجة النهائية هي أن العملية بأكملها، بدءًا من الأجهزة الجديدة التي تظهر في مركز البيانات، وصولاً إلى تواجد مجموعات Presto على الإنترنت وتقديم الاستعلامات، ثم يتم إيقاف تشغيلها عند إيقاف الأجهزة، تكون مؤتمتة بالكامل. أدى تنفيذ ذلك إلى توفير ساعات قيمة للأشخاص، وتقليل وقت السكون في الأجهزة، والحد من معدل الخطأ البشري.
تصحيح الأخطاء والإصلاحات التلقائية
الشكل الثالث: اكتشاف المضيف غير الصالح (مخطط من فيليب س. بيل)
نظرًا إلى نشر Presto على نطاق واسع في Meta، من الضروري أن يكون لدينا أدوات وعمليات أتمتة تجعل دفق التواصل (نقطة اتصال Presto) سهلة.
على مدار الأعوام، قمنا بتطوير عدة "أدوات تحليل" تساعد عمليات التواصل في تصحيح الأخطاء بفعالية وتقييم السبب الجذري وراء المشكلات التي تظهر. تطلق أنظمة التحقق تنبيهات عندما تحدث انتهاكات لاتفاقيات مستوى الخدمة التي تظهر للعميل. يتم حينها تشغيل أدوات التحليل. حيث تعمل على إصدار المعلومات من مجموعة واسعة من أنظمة التحقق (مخزن البيانات التشغيلية أو ODS)، والأحداث المنشورة على Scuba، وحتى السجلات على مستوى المضيف. ثم يربط المنطق المخصص في أداة التحليل كل هذه المعلومات معًا لاستنتاج السبب الجذري المحتمل. هذا مفيد للغاية للتواصل من خلال تقديم تحليل السبب الجذري لهم والسماح لهم بالانتقال مباشرةً إلى خيارات التخفيف المحتملة. في بعض الحالات، قمنا بأتمتة كلاً من عمليات التصحيح والمعالجة بالكامل بحيث لا يحتاج الأمر إلى التواصل. يتم توضيح بعض الأمثلة أدناه:
اكتشاف المضيف غير الصالح
عند تشغيل Presto على نطاق واسع على عدد كبير من الأجهزة، لاحظنا أن بعض المضيفات "غير الصالحة" يمكن أن تتسبب في زيادة حالات تعذر الاستعلام. بعد التحقيقات التي أجريناها، حددنا بعض الأسباب الجذرية التي أدت إلى أن تصبح المضيفات "غير صالحة"، بما في ذلك:
- مشكلات على مستوى الأجهزة لم يتم اكتشافها بعد بواسطة أنظمة التحقق على مستوى المجموعة بسبب نقص التغطية
- أخطاء JVM المحجوبة والتي قد تؤدي في بعض الأحيان إلى دفق مستمر من حالات فشل الاستعلام
لمواجهة هذه المشكلة، نتحقق الآن من حالات فشل الاستعلام في مجموعات Presto. على وجه التحديد، نسند كل فشل استعلام إلى المضيف الذي تسبب فيه، حيثما أمكن ذلك. نقوم أيضًا بإعداد التنبيهات التي يتم تشغيلها عندما يتم إسناد عدد كبير بشكل غير طبيعي من حالات فشل الاستعلام إلى مضيفات معينة. يأتي دور الأتمتة لسحب المضيف من مجموعة Presto وبذلك تظهر حالات الفشل.
تصحيح أخطاء قوائم الانتظار
تدعم كل مجموعة Presto استعلامات قائمة انتظار بمجرد وصولها إلى الحد الأقصى للتزامن لتشغيل الاستعلامات بناءً على حالة الاستخدام وتكوين الأجهزة وحجم الاستعلام. في Meta، توجد آلية توجيه متطورة بحيث يتم إرسال استعلام Presto إلى المجموعة "الصحيحة" التي يمكنها تنفيذ الاستعلام مع الاستفادة المثلى من الموارد. تشارك العديد من الأنظمة بخلاف Presto في اتخاذ قرار التوجيه وتأخذ عوامل متعددة في الاعتبار:
- الحالة الحالية لقوائم الانتظار في مجموعات Presto
- توزيع الأجهزة عبر مراكز بيانات مختلفة
- مكان بيانات الجداول التي يستخدمها الاستعلام
بالنظر إلى هذا التعقيد، قد يكون من الصعب للغاية على جهة التواصل معرفة السبب الجذري وراء أي مشكلات في قائمة الانتظار تظهر في مرحلة الإنتاج. هذا مثال آخر حيث تظهر فيه أدوات التحليل في المقدمة عن طريق سحب المعلومات من مصادر متعددة وتقديم الاستنتاجات.
فعالية موازن التحميل
الشكل الرابع: فعالية موازن التحميل (مخطط من فيليب س. بيل)
كما ذكرنا أعلاه، تتواجد مجموعات Presto خلف موازنات التحميل التي توجه كل استعلام Presto فردي في Meta. في البداية، عندما لم تبدأ مجموعة Presto في رفع مستوى الاستخدام الداخلي الذي نشهده اليوم، كانت طريقة عمل البوابة بسيطة للغاية. مع ذلك، بينما ازداد استخدام Presto عبر Meta، تعرضنا لمشكلات تتعلق بالتوسع في عدة مرات. تمثلت إحدى المرات في فشل البوابة نتيجة التحميل الزائد، مما قد يؤدي إلى عدم توفر Presto لكل المستخدمين. كان السبب الجذري لبعض مشكلات الثبات هو قيام إحدى الخدمات بالتحميل على البوابة عن غير قصد من خلال ملايين الاستعلامات في فترة قصيرة، مما أدى إلى تعطل عمليات البوابة وعدم القدرة على توجيه أي استعلامات.
لتجنب مثل هذا السيناريو، قررنا تحسين البوابة لتكون أقوى وتستوعب عدد الزيارات غير المقصود الذي يشابه DDoS. قمنا بتنفيذ ميزة التقييد، والتي تعمل على رفض الاستعلامات في ظروف التحميل الزائد. يمكن تنشيط التقييد استنادًا إلى عدد الاستعلامات في الثانية على مستوى أبعاد متعددة، مثل لكل مستخدم ولكل مصدر ولكل عنوان IP وأيضًا على مستوى عالمي لكل الاستعلامات. من التحسينات الأخرى التي قمنا بتنفيذها هي التوسيع التلقائي. بالاعتماد على خدمة Meta واسعة النطاق التي تدعم توسيع نطاق المهام وتقليصها، أصبح عدد مثيلات البوابة ديناميكيًا الآن. هذا يعني أنه في ظل التحميل الزائد، يمكن للبوابة الآن توسيع نطاقها لمعالجة معدلات استخدام الشبكة الزائدة وعدم تجاوز الحد الأقصى لوحدة المعالجة المركزية/الذاكرة، وبالتالي تجنب سيناريو التعطل الموضح أعلاه. هذا، جنبًا إلى جنب مع ميزة التقييد، يضمن أن تظل البوابة قوية ويمكن أن تصمد أمام كل أشكال استخدام الشبكة التي لا يمكن التنبؤ بها.
ما النصيحة التي نقدمها للفريق لتوسيع نطاق بنية Data Lakehouse باستخدام Presto؟
الشكل الخامس: توسيع بنية Presto (مخطط من فيليب س. بيل)
بعض الجوانب المهمة التي يجب مراعاتها عند توسيع نطاق Presto هي:
- إنشاء اتفاقيات مستوى الخدمة سهلة الفهم ومحددة بشكل مناسب وموجهة للعملاء. يصبح تحديد اتفاقيات مستوى الخدمة حول أدوات القياس المهمة مثل قوائم الانتظار ومعدل فشل الاستعلام بطريقة تتعقب أوجه المشكلات لدى العميل أمرًا بالغ الأهمية بالتزامن مع توسيع نطاق Presto. عندما يكون هناك عدد كبير من المستخدمين، فإن عدم وجود اتفاقيات مستوى الخدمة المناسبة يمكن أن يعيق بشكل كبير الجهود المبذولة للتخفيف من مشكلات الإنتاج بسبب الارتباك في تحديد تأثير الحادث.
- التحقق وتصحيح الأخطاء التلقائي. بينما يتم توسيع نطاق Presto وزيادة عدد المجموعات، يصبح التحقق وتصحيح الأخطاء التلقائي أمرًا بالغ الأهمية.
- يمكن أن يساعد التحقق الشامل في تحديد مشكلات الإنتاج قبل أن يتفاقم الأمر. سيضمن اكتشاف المشكلات مبكرًا الحد من التأثير على المستخدم قدر المستطاع.
- التحقيقات اليدوية فيما يتعلق بمشكلات الإنتاج التي تؤثر على العملاء ليست قابلة للتوسيع. من الضروري أن يتوفر لديك دفق تصحيح أخطاء تلقائي بحيث يمكن تحديد السبب الجذري بسرعة.
- موازنة التحميل السليمة. بالتزامن مع نمو مجموعات Presto، من المهم توفير حل سليم لموازنة التحميل الناتج عن استيعاب مجموعات Presto. على نطاق واسع، يمكن أن يكون لأوجه القصور البسيطة المرتبطة بموازنة التحميل تأثيرًا سلبيًا كبيرًا نتيجة الحجم الهائل لعبء العمل.
- إدارة التكوين. يمكن أن تصبح إدارة التكوين لعدد كبير من مجموعات Presto صعبة إذا لم يتم التخطيط لها بشكل جيد. حيثما أمكن، يجب جعل التكوينات قابلة لإعادة التحميل بشكل سريع بحيث لا يلزم إعادة تشغيل مثيلات Presto أو تحديثها بطريقة مزعجة مما يؤدي إلى فشل الاستعلام وعدم رضا العملاء.
تمت كتابة هذا المقال بالتعاون مع نيراد سومانشي، مهندس إنتاج في Meta ، وفيليب بيل، مؤيد المطوّرين في Meta.
للتعرف على المزيد حول Presto، تفضل بزيارة prestodb.io أو شاهد فيديو فيليب بيل quick explanation of Presto على يوتيوب أو تابع Presto على تويتر وفيسبوك ولينكدإن.
للتعرف على المزيد حول Meta Open Source، تفضل بزيارة الموقع مفتوح المصدر أو اشترك في قناتنا على يوتيوب، أو تابعنا على تويتر وفيسبوك ولينكدإن.
