مخزن البلوب في Apache Flink يحتفظ بالبلوبات غير المستخدمة 30 دقيقة قبل التنظيف

يحتوي مخزن BLOB في Apache Flink على الملفات الثنائية التي لا تستطيع العنقودية العاملة الاستغناء عنها: ملفات JAR التي يرفعها المستخدمون لتشغيل مهامهم، والرسائل كبيرة الحجم التي تنتقل بين المهام، وسجلات TaskManager التي تعرضها واجهة الويب عند الطلب. قبل الإصدار 1.4، كان لهذا المخزن ثلاثة أنماط من الفشل عالجها المجتمع لاحقًا في FLIP-19. فقد ينتهي الملف نفسه مخزَّنًا أكثر من مرة. وملفات لم تعد أي مهمة تحتاجها بقيت على القرص. ويمكن تعديل محتويات الملف دون أن يلاحظ شيء ذلك.

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

ثلاثة مكونات، ثلاث مهام

تقسم التصميم الجديد العمل على ثلاثة أطراف، ولكل جزء نطاق محدود.

المكوّن	مكان تشغيله	المهمة
BlobServer	مركزيًا، للعنقودية بأكملها	يخزّن البلوبات ويقدّمها من نسخة محلية إضافة إلى نسخة احتياطية
BlobCache	على كل TaskManager	يخدم القراءات المحلية، ويجلب الملفات الناقصة من BlobServer، ويمسح مخزنه الخاص
BlobClient	لكل طلب	يفتح اتصالًا بـ BlobServer، ويتتبع الطلب، ويؤكد التسليم

يحتفظ BlobServer بنسختين من كل شيء: مخزن محلي للقراءات السريعة ومخزن احتياطي للاستعادة. وتُخزَّن الملفات وفق اصطلاح مسار ثابت، <path>/<jobId>/<BlobKey>، بحيث يمكن قراءة المهمة وهوية البلوب من موقعه. ويذهب الرفع إلى المخزن المحلي أولًا ثم يتزامن مع النسخة الاحتياطية، وهو ما يُقصد به تحقيق المتانة دون إيقاع كتابة النسخة الاحتياطية في طريق المستدعي. وتتحقق القراءة من المحلي أولًا ولا تلجأ إلى النسخة الاحتياطية إلا عند غياب الملف.

يعمل BlobCache على كل TaskManager ويحاكي بنية المسار نفسها. ويمكنه قراءة مخزن النسخ الاحتياطي المركزي لكن لا يمكنه الكتابة فيه. وعندما يحتاج ملفًا غير موجود لديه، يطلب من BlobServer نقله. وكل ذاكرة تخزين مؤقت تقرر بنفسها متى تمسح الملفات التي لم تعد تحتاجها، ما يُبقي قرارات التنظيف لدى الجهاز الذي يملك القرص.

BlobClient هو جانب الطلب. يفتح اتصالًا مخصصًا بـ BlobServer لكل عملية رفع أو تنزيل، ويسجّل الطلب، ويبقى مع النقل حتى يتأكد تسليم الملف.

العدّ المرجعي والوقفة المتعمدة قبل الحذف

حذف البلوب في اللحظة التي ينتهي فيها آخر قارئ معروف له هو السبيل الذي تفقد به العنقودية ملفًا كانت مهمة أخرى على وشك جلبه. ويجيب FLIP-19 على ذلك بالعدّ المرجعي: يتتبع النظام عدد المهام التي تحتفظ حاليًا بملف ما، وينتظر الحذف وصول العدد إلى الصفر. وحتى عند الصفر، لا يختفي الملف. بل يبقى لفترة قابلة للضبط، وأي طلب جديد خلال تلك النافذة يُبقيه حيًا.

لهذه النافذة كلفة. فكل بلوب محتفظ به هو مساحة قرص لا تستطيع العنقودية استخدامها لأي شيء آخر، والعنقودية المزدحمة تحتفظ بالملفات بعد انتهاء عمرها المفيد عن قصد. وقد تحركت القيمة الافتراضية نحو استعادة تلك المساحة بشكل أسرع: أصبح الإعداد blob.retention.interval افتراضيًا 30 دقيقة، نزولًا من ساعة. ولا تقدّم المادة المصدرية أرقامًا عن مقدار التخزين الذي تحرره الفترة الأقصر، لذا اقرأ الرقم كإعداد لا كنتيجة.

تحصل الملفات المختلفة على معاملة مختلفة، ولهذا يجب أن تغطي فترة واحدة جميعها.

نوع البلوب	الغرض	العمر
ملفات JAR	كود برنامج المستخدم	مرتبطة بالمهمة؛ تُنظَّف بمجرد انتهاء المهمة
رسائل RPC	التواصل بين المهام	قصيرة؛ تُحذف بعد الاستخدام
ملفات السجل	مراقبة النظام وواجهة الويب	تُخزَّن عند الطلب، وتُنظَّف بعد الاستخدام

يُظهر طلب السجل هذا النمط مصغرًا. تطلب واجهة الويب سجلات TaskManager، فيرفعها TaskManager إلى BlobServer، ثم تنزّلها الواجهة من هناك وتعرضها. ولأن لا أحد يحتاج الملف بعد ذلك، يمكن تنظيفه بدل الاحتفاظ به.

تسلك الرسائل الكبيرة المسار نفسه. يكتب المرسل الحمولة إلى BlobServer، وينزّلها المستقبِل، وينخفض العدّ المرجعي بمجرد معالجة الرسالة. وعندما يؤكد كل مستقبِل، ينضم البلوب إلى قائمة انتظار التنظيف وينتظر دورته المجدولة.

مجاميع التحقق والمخزن ذو الطبقتين: أين تتوقف الضمانات

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

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

تلك الفجوة الأخيرة مهمة لأن استلام BlobServer للعمل موصوف بأنه تسليم من أربع خطوات، ولا تسرد المادة المصدرية هذه الخطوات. أما القصد من إعادة التصميم فأسهل تحديدًا: فقد هدف FLIP-19 إلى إصلاح مشكلات التزامن والتنظيف في البنية الأصلية وإلى إفساح المجال لعمل لاحق، بما في ذلك التعامل مع رسائل RPC الكبيرة. وأين تضع البنية التنفيذية خطها الفاصل بين ما هو مغطى وما ليس مغطى يعيش في الإعدادات والشيفرة، لا في نظرة عامة.