مفاهيم نقطة التحقق وإعادة التشغيل في مهام Azure Stream Analytics
توضح هذه المقالة مفاهيم نقطة التحقق وإعادة التشغيل الداخلية في Azure Stream Analytics، وتأثيرها على استرداد المهمة. في كل مرة يتم فيها تشغيل مهمة Stream Analytics، يتم الاحتفاظ بمعلومات الحالة داخلياً. يتم حفظ معلومات الحالة هذه في نقطة تحقق بشكل دوري. في بعض السيناريوهات، يتم استخدام معلومات نقطة التحقق لاسترداد المهمة في حال فشل المهمة أو ترقيتها. في ظروف أخرى، لا يمكن استخدام نقطة التحقق للاسترداد، وتكون إعادة التشغيل ضرورية.
منطق الاستعلام ذو الحالة في العناصر الزمنية
تتمثل إحدى إمكانات مهمة Azure Stream Analytics الفريدة في إجراء معالجة ذات حالة، مثل التجميعات ذات النوافذ والصلات الزمنية والدالات التحليلية الزمنية. يحتفظ كل عامل من عوامل التشغيل هذه بمعلومات الحالة عند تشغيل المهمة. الحد الأقصى لحجم الإطار الزمني لعناصر الاستعلام هذه هو سبعة أيام.
يظهر مفهوم النافذة الزمنية في العديد من عناصر استعلام Stream Analytics:
تجميعات ذات نوافذ (مجموعة من نوافذ Tumbling، وHopping، وSliding)
الصلات الزمنية (JOIN مع DATEDIFF)
الدالات التحليلية الزمنية (ISFIRST، وLAST، وLAG مع LIMIT DURATION)
استرداد مهمة من فشل العقدة، بما في ذلك ترقية نظام التشغيل
في كل مرة يتم فيها تشغيل مهمة Stream Analytics، يتم توسيع نطاقها داخلياً للقيام بالعمل عبر عقد عاملة متعددة. يتم فحص نقاط التحقق لحالة كل عقدة عامل كل بضع دقائق، ما يساعد النظام على الاسترداد إذا حدث فشل.
في بعض الأحيان، قد تفشل عقدة عامل معينة، أو تتم ترقية نظام تشغيل عقدة العامل هذه. للاسترداد تلقائياً، يكتسب Stream Analytics عقدة صحية جديدة، وتتم استعادة حالة عقدة العامل السابقة من أحدث نقطة تحقق متاحة. لاستئناف العمل، يلزم مقدار صغير من إعادة التشغيل لاستعادة الحالة من وقت أخذ نقطة التحقق. عادة ما تكون فجوة الاستعادة بضع دقائق فقط. عند تحديد وحدات دفق كافية للمهمة، يجب إكمال إعادة التشغيل بسرعة.
في استعلام متوازٍ تماماً، يكون الوقت المستغرق للحاق بعد فشل عقدة العامل متناسباً مع:
[معدل حدث الإدخال] x [طول الفجوة] / [عدد أقسام المعالجة]
إذا لاحظت تأخيراً كبيراً في المعالجة بسبب فشل العقدة وترقية نظام التشغيل، ففكر في جعل الاستعلام متوازياً تماماً، وقم بتغيير حجم المهمة لتخصيص المزيد من وحدات الدفق. لمزيد من المعلومات، راجع تغيير حجم مهمة Azure Stream Analytics لزيادة معدل النقل.
لا يعرض Stream Analytics الحالي تقريراً عند حدوث هذا النوع من عمليات الاسترداد.
استرداد المهمة من ترقية الخدمة
تقوم Microsoft أحياناً بترقية الثنائيات التي تقوم بتشغيل مهام Stream Analytics في خدمة Azure. في هذه الأوقات، تتم ترقية المهام قيد التشغيل للمستخدمين إلى إصدار أحدث وإعادة تشغيل المهمة تلقائياً.
يستخدم Azure Stream Analytics نقاط التحقق حيثما أمكن لاستعادة البيانات من آخر حالة ذات نقاط تحقق. في السيناريوهات التي لا يمكن فيها استخدام نقاط التحقق الداخلية، تتم استعادة حالة استعلام الدفق بالكامل باستخدام تقنية إعادة التشغيل. للسماح لمهام Stream Analytics بإعادة تشغيل نفس الإدخال السابق بالضبط، من المهم تعيين نهج الاستبقاء للبيانات المصدر إلى أحجام الإطار الزمني على الأقل في الاستعلام الخاص بك. قد يؤدي الفشل في القيام بذلك إلى نتائج غير صحيحة أو جزئية أثناء ترقية الخدمة، حيث قد لا يتم الاحتفاظ ببيانات المصدر بعد فترة كافية لتضمين حجم الإطار الزمني الكامل.
بشكل عام، يتناسب مقدار إعادة التشغيل المطلوب مع حجم الإطار الزمني مضروباً في متوسط معدل الحدث. على سبيل المثال، بالنسبة لمهمة بمعدل إدخال يبلغ 1000 حدث في الثانية، يعتبر الإطار الزمني الأكبر من ساعة واحدة له حجم إعادة تشغيل كبير. قد يلزم إعادة معالجة ما يصل إلى ساعة واحدة من البيانات لتهيئة الحالة حتى تتمكن من الحصول على نتائج كاملة وصحيحة، ما قد يتسبب في تأخير الإخراج (عدم وجود إخراج) لفترة ممتدة. لن يكون للاستعلامات التي لا تحتوي على إطارات زمنية أو عوامل تشغيل زمنية أخرى، مثل JOIN أو LAG، أي إعادة تشغيل.
تقدير وقت متابعة إعادة التشغيل
لتقدير طول التأخير بسبب ترقية الخدمة، يمكنك اتباع هذه التقنية:
تحميل مراكز أحداث الإدخال ببيانات كافية لتغطية أكبر حجم للإطار الزمني في الاستعلام الخاص بك، بمعدل الحدث المتوقع. يجب أن يكون الطابع الزمني للأحداث قريباً من وقت ساعة الحائط طوال تلك الفترة الزمنية، كما لو كان موجز إدخال مباشر. على سبيل المثال، إذا كان لديك إطار زمني مدته 3 أيام في الاستعلام، فارسل الأحداث إلى مراكز الأحداث لمدة ثلاثة أيام، وتابع إرسال الأحداث.
ابدأ المهمة باستخدام الآن كوقت البدء.
قياس الوقت بين وقت البدء ووقت إنشاء الإخراج الأول. يعتبر الوقت تقريبياً لمقدار التأخير الذي قد تتعرض له المهمة أثناء ترقية الخدمة.
إذا كان التأخير طويلاً جداً، فحاول تقسيم المهمة وزيادة عدد وحدات الدفق (SUs)، بحيث يتم توزيع الحمل إلى المزيد من العقد. بدلاً من ذلك، ضع في اعتبارك تقليل أحجام الإطار الزمني في الاستعلام الخاص بك، وإجراء المزيد من التجميع أو المعالجة الأخرى ذات الحالة على الإخراج الذي تنتجه مهمة Stream Analytics في متلقي انتقال البيانات من الخادم (على سبيل المثال، باستخدام Azure SQL Database).
للحد من القلق العام بشأن استقرار الخدمة أثناء ترقية الوظائف الحرجة للمهمة، ضع في اعتبارك تشغيل وظائف مكررة في مناطق Azure المقترنة. لمزيد من المعلومات، راجع ضمان وثوقية مهمة Stream Analytics أثناء تحديثات الخدمة.
استرداد المهمة من توقف وبدء تشغيل يبدأه المستخدم
لتحرير بناء جملة الاستعلام في مهمة دفق، أو لضبط المدخلات والمخرجات، يجب إيقاف المهمة لإجراء التغييرات وترقية تصميم المهمة. في مثل هذه السيناريوهات، عندما يوقف المستخدم مهمة الدفق، ويبدأها مرة أخرى، يكون سيناريو الاسترداد مشابهاً لترقية الخدمة.
لا يمكن استخدام بيانات نقطة التحقق لإعادة تشغيل مهمة بدأها المستخدم. لتقدير تأخير الإخراج أثناء إعادة التشغيل هذه، استخدم نفس الإجراء كما هو موضح في القسم السابق، وطبق تخفيفاً مشابهاً إذا كان التأخير طويلاً جداً.
الخطوات التالية
لمزيد من المعلومات حول الوثوقية وقابلية التوسع، راجع هذه المقالات: