أباتشي فلينك يريد التوقف عن نسخ البيانات عند كل مُشغّل. وهذا هو الجزء السهل

في كل مرة تنتقل فيها البيانات بين مُشغّلين متسلسلين في بيئة تشغيل التدفقات في أباتشي فلينك، تنسخها بيئة التشغيل. وقد أُدرج هذا السلوك عمداً، لتفادي المشكلات المرتبطة بالكائنات القابلة للتغيير عندما تخزّن خلفيات الحالة الكائنات على الكومة (heap). ويضمن النسخ أن ما يمرّره المُشغّل إلى ما بعده لن يتغيّر ما دام طرف آخر لا يزال يشير إليه.

النسخة التي يجريها فلينك عند كل مُشغّل

يهدف FLIP-21، وهو اقتراح تغيير قيد النقاش حالياً، إلى إزالة معظم هذه التكلفة دون التخلي عن الضمان. وتسرد وثيقته أربع مشكلات في النهج الحالي. فالنسخ مكلف بالنسبة إلى أنواع معقدة مثل Avro وThrift وJSON. والعمليات المعنونة (keyed) التي تعمل بعد عملية خلط (shuffle) لم تكن بحاجة إلى النسخ أصلاً، لأنها تأتي أولاً في السلسلة. ولا تنسخ واجهة DataSet API عند كل خطوة، ما يعني أن نصفي فلينك يتبعان قواعد مختلفة للبيانات نفسها. أما الخيار الذي يتحكم في السلوك بأكمله، enableObjectReuse()، فاسمه مضلل، لأنه لا يعيد استخدام الكائنات فعلياً.

وتصف الوثيقة هذه التكاليف بعبارات نوعية ولا تُرفق أي رقم قياسي (benchmark) بأي منها، لذا لا يحدد الاقتراح مقدار ما تخسره خط معالجة نموذجية بسبب هذه النسخ. واثنتان من الشكاوى الأربع تتعلقان بالمطورين لا بمعدل الإنتاجية، ولهما أهمية لسبب أكثر هدوءاً. فوجود واجهتَي برمجة (API) في مشروع واحد تتعاملان مع هوية الكائنات بشكل مختلف يجعل من الصعب استنتاج ما تعنيه الإشارة المرجعية عند نقطة معينة في المهمة. وأسوأ من ذلك علامة (flag) يَعِد اسمها بإعادة الاستخدام لكنها تقدّم شيئاً آخر، لأنها تزرع نموذجاً ذهنياً خاطئاً حول المدة التي تظل فيها الإشارة المرجعية صالحة.

ثلاثة أنماط، والمفتاح الذي يتحكم فيها

وبدلاً من إيقاف النسخ في كل مكان، يعرّف FLIP-21 ثلاثة أنماط ويتيح للمستخدمين اختيار موضعهم على الخط الفاصل بين السلامة والأداء.

النمط	ما يفعله	ما يكلّفه
DEFAULT	ينشئ كائنات جديدة فقط أثناء فك التسلسل (deserialization)، ثم يمرّرها دون نسخ	مقترح ليكون المعيار الجديد لواجهتَي DataStream وDataSet
COPY_PER_OPERATOR	ينسخ البيانات بين كل مُشغّل	سلوك فلينك الحالي؛ آمن لكنه أبطأ
FULL_REUSE	يعيد استخدام الكائنات حيثما استطاع	الخيار الأسرع؛ ويتطلب أقصى قدر من الحرص في كود المستخدم

النمط DEFAULT هو النمط الذي يتوقع الاقتراح أن يصبح المعيار الجديد لواجهتَي DataStream وDataSet معاً. فهو يحصر النسخة الوحيدة التي لا مفر منها في نقطة واحدة، وهي فك التسلسل، ويتيح للكائنات أن تنتقل بعدها دون مساس. ويحيط النمطان الآخران به. فـ COPY_PER_OPERATOR هو ما يفعله فلينك اليوم. ويدفع FULL_REUSE إعادة الاستخدام إلى أقصى مدى ممكن، فيشتري السرعة مقابل نقل عبء التعامل مع الإشارات المرجعية المشتركة إلى الدوال التي تستقبل الكائنات. والمخاطرة غير متكافئة: فـ COPY_PER_OPERATOR بطيء لكنه متسامح، بينما يفشل FULL_REUSE بطرق تعتمد على مدى حرص كتابة الكود المحيط.

وهناك مفتاح إعداد مرتبط به، هو pipeline.object-reuse، وقيمته الافتراضية false. وتعيينه إلى true يتيح لفلينك إعادة استخدام الكائنات داخلياً في فك التسلسل وفي تمرير البيانات إلى دوال المستخدم. وتقرأ ملاحظات الاقتراح نفسه على هذا المفتاح كنسخة مختصرة من المقايضة: فهو يقلل تكلفة إنشاء الكائنات وجمع المهملات (garbage collection)، لكن على الدوال أن تتعامل مع الكائنات المعاد استخدامها بشكل صحيح، ولا ضمان أن تظل الإشارات المرجعية صالحة بعد عودة استدعاء الدالة، ويحتاج الإعداد إلى اختبار شامل قبل أن يقترب من بيئة الإنتاج.

الترحيل: قطيعة نظيفة أم توافق مع الإصدارات السابقة

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

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

وبالنسبة إلى الفرق التي تشغّل فلينك اليوم، فإن التغيير الفوري يقارب الصفر. وإلى أن يصل افتراضي جديد، يظل قاعدة النسخ عند كل مُشغّل قائماً ويبقى pipeline.object-reuse معطلاً. ويمكن لافتراضي يخص السلامة أن يستمر في تكبيد التكاليف مدة طويلة بعد تغيّر الظروف التي برّرته. وهو لا يتغيّر إلا عندما يقيس أحدهم الفاتورة ويطالب بالتغيير.