أباتشي فلينك: النقطة الكاملة مقابل النقطة التزايدية

أباتشي فلينك هو محرك معالجة تيارات البيانات في الوقت الحقيقي. معظم تطبيقات معالجة التيارات هي ‘تحتوي على حالة.’ وهذا يعني أن الحالة تُخزن وتُستخدم للمعالجة اللاحقة. في أباتشي فلينك، يتم إدارة الحالة من خلال خلفية حالة مُكونة. يدعم فلينك اثنين من خلفيات الحالة في الإنتاج. الأول هو HashMapStateBackend، والآخر هو EmbeddedRocksDBStateBackend.

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

في هذا المقال، سنقوم بمقارنة HashMapStateBackend مع التحقق الكامل وEmbeddedRocksDBStateBackend مع التحقق التدريجي. يفترض هذا المقال أن الجمهور يمتلك إما معرفة عملية أو نظرية بـ أباتشي فلينك.

نظرة عامة على خلفية حالة فلينك

لفهم خلفية حالة فلينك، من المهم معرفة الفرق بين حالة الطيران و لقطات الحالة.

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

على الجانب الآخر، يتم تخزين لقطات الحالة (نقطة فحص أو نقطة حفظ) في موقع بعيد متين. تُستخدم هذه اللقطات لإعادة بناء حالة وظيفة Flink في حالة فشل الوظيفة.

يمكن أن يتم فقدان الحالة التي تم فيها العمل إذا فشلت الوظيفة. هذا لا يؤثر على استرداد الوظيفة إذا تم تمكين النقطة الفرعية في الوظيفة. عندما يتم تكوين النقطة الفرعية، يتم استرداد الحالة من التخزين المتين في وقت الاسترداد.

أي خلفية حالة يجب اختيارها للإنتاج يعتمد على متطلبات التطبيق للإنتاجية والكفاءة الزمنية والتوسعية.

هناك خلفيتان لحالة يدعمهما Apache Flink في الإنتاج.

1. HashMapStateBackend

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

2. EmbeddedRocksDBStateBackend

يخزن ذاكرة التخزين الخلفية هذه البيانات التي تم نقلها في ذاكرة قاعدة بيانات RocksDB. بشكل افتراضي، تخزن RocksDB البيانات في القرص المحلي لمدير المهام. يتم تسلسل البيانات وتخزينها في ذاكرة خارج الحدود ويتم تفريغها إلى قرص محلي مرتبط بمدير المهام. تعتمد تنسيق التسلسل على مسلسل النوع الذي تم تكوينه في التطبيق. 

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

نظرة عامة على حالة اللقطة

اللقطة تمثل الحالة العامة لوظيفة Flink. تتكون من مؤشر لكل مصدر بيانات وحالة جميع المشغلات التي تحتوي على حالة Flink بعد معالجة حتى تلك المؤشرات من المصادر. عملية عمليات الفحص في Apache Flink هي آلية لتحقيق التحمل من الأخطاء من خلال حفظ الحالة بانتظام في تخزين عن بُعد دائم. 

في حالة فشل الوظيفة، يستعيد Flink الحالة المخزنة من التخزين عن بُعد الدائم ويبدأ في معالجة بيانات البث من حيث توقف. يستخدم Flink عملية لقط الحواجز غير المتزامنة. إنها نسخة من خوارزمية Chandy-Lamport. 

يدعم Flink نوعين من عمليات الفحص.

1. عمليات فحص كاملة

النقطة الكاملة هي حيث يتم التقاط وتخزين الحالة الكاملة لوظيفة Flink في تخزين عن بُعد متين. في حالة فشل الوظيفة، تستعيد الوظيفة من الحالة المخزنة مسبقًا. متطلبات مساحة التخزين والوقت اللازم لعملية الفحص النقطي تعتمد بالكامل على حالة التطبيق. النقطة الكاملة تعمل مع كل من HashMapStateBackend و RocksDBStateBackend。

2. الفحص النقطي التدريجي

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

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

التحليل

تفاصيل الخط الأنابيب: تشغيل خط الأنابيب Apache Beam على محرك Flink بنافذة ثابتة تبلغ 10 دقائق وتم تكوين الفحص النقطي لتشغيله كل 3 دقائق. نوع التسلسل المكون هو AVRO.

• نوع العنقودة: “m5dn.4xlarge”
• تخزين النقطة النهائي: S3
• عدد المفاتيح الفريدة: 2K

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

الملخص

فيما يلي ملخص التجربة.