تكوين نُهج طلب الأحداث لـ Azure Stream Analytics

تشرح هذه المقالة كيفية إعداد واستخدام سياسات الأحداث المتعلقة بالوصول المتأخر والخارج عن الترتيب في Azure Stream Analytics. يتم تطبيق هذه السياسات فقط عند استخدام عبارة TIMESTAMP BY في الاستعلام الخاص بك، ويتم تطبيقها فقط لمصادر الإدخال السحابية.

وقت الحدث ووقت الوصول

يمكن لمهمة Stream Analytics معالجة الأحداث استنادًا إلى وقت الحدث أو وقت الوصول. زمن الحدث/التطبيق هو الطابع الزمني الموجود في حمولة الحدث (عند إنشاء الحدث). وقت الوصول هو الطابع الزمني عند استلام الحدث في مصدر الإدخال (مراكز الأحداث/مركز إنترنت الأشياء/تخزين Blob).

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

ما هو نهج الوصول المتأخر؟

أحيانا تصل الأحداث متأخرة لأسباب مختلفة. على سبيل المثال، الحدث الذي يصل متأخرًا 40 ثانية سيكون وقت الحدث = 00:10:00 ووقت الوصول = 00:10:40. إذا قمت بضبط سياسة الوصول المتأخر على 15 ثانية، فإن أي حدث يصل بعد 15 ثانية سيتم إبعاده (دون معالجته بواسطة Stream Analytics) أو يتم تعديل وقت الحدث الخاص به. في المثال أعلاه، نظرًا لوصول الحدث متأخرًا 40 ثانية (أكثر من تعيين النهج)، سيتم تعديل وقت الحدث الخاص به إلى الحد الأقصى لنهج الوصول المتأخر 00:10:25 (وقت الوصول - قيمة نهج الوصول المتأخر). نهج الوصول المتأخر الافتراضية هي 5 ثوانٍ.

ما هو نهج الخروج من النظام؟

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

تعديل أو إسقاط الأحداث المتأخرة وغير المرتبة

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

المثال التالي يوضح هذه السياسات أثناء التنفيذ.

  • سياسة الوصول المتأخر: 15 ثانية
  • نهج الخروج من النظام: 5 ثوان
رقم الحدث. وقت الحدث وقت الوصول System.Timestamp الشرح
1 00:10:00 00:10:40 00:10:25 وصل الحدث متأخرًا وخارج مستوى التسامح. لذلك يتم تعديل وقت الحدث إلى الحد الأقصى لتفاوت الوصول المتأخر.
2 00:10:30 00:10:41 00:10:30 وصل الحدث متأخرًا ولكن ضمن مستوى التسامح. لذلك لا يتم تعديل وقت الحدث.
3 00:10:42 00:10:42 00:10:42 وصل الحدث في الوقت المحدد. لا حاجة للتعديل.
4 00:10:38 00:10:43 00:10:38 وصل الحدث خارج الترتيب ولكن في غضون 5 ثوانٍ. لذلك، لا يتم تعديل وقت الحدث. لأغراض التحليلات، سيعتبر هذا الحدث رقم الحدث السابق 3 (مع النظر في إجمالي 5 أحداث. الترتيب الفعلي هو: 1، 2، 5، 4، 3).
5 00:10:35 00:10:45 00:10:37 وصل الحدث خارج الترتيب والتسامح الخارجي لمدة 5 ثوانٍ. لذلك، يتم ضبط وقت الحدث إلى الحد الأقصى من التسامح خارج الترتيب.

هل يمكن أن تؤدي السياسات المتعلقة بالتأخر وعدم الترتيب إلى تأخير إنتاج الوظائف؟

نعم. بشكل افتراضي، يتم تعيين نهج "خارج الطلب" على صفر (00 دقيقة و00 ثانية). إذا قمت بتغيير القيمة الافتراضية، فإن الإخراج الأول لوظيفتك يتأخر بهذه القيمة (أو أكبر).

إذا لم يستقبل أحد أقسام المدخلات أحداثًا، يجب أن تتوقع تأجيل إخراجك بسبب قيمة نهج الوصول المتأخر. لمعرفة السبب، راجع رسائل InputPartitionNotProgressing.

أرى رسائل LateInputEvents في سجل أنشطتي

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

إليك مثال على هذه الرسالة:

{"message Time":"2019-02-04 17:11:52Z","error":null,
"message":"First Occurred: 02/04/2019 17:11:48 | Resource Name: ASAjob | Message: Source 'ASAjob' had 24 data errors of kind 'LateInputEvent' between processing times '2019-02-04T17:10:49.7250696Z' and '2019-02-04T17:11:48.7563961Z'. Input event with application timestamp '2019-02-04T17:05:51.6050000' and arrival time '2019-02-04T17:10:44.3090000' was sent later than configured tolerance.","type":"DiagnosticMessage","correlation ID":"aaaa0000-bb11-2222-33cc-444444dddddd"}

أرى قسم الإدخال لا يتقدم في سجل النشاط الخاص بي

من المحتمل أن يحتوي مصدر الإدخال (مركز الحدث/مركز IoT) على أقسام متعددة. ينتج Azure Stream Analytics مخرجات الطابع الزمني T1 فقط بعد أن تكون جميع الأقسام المدمجة على الأقل في الوقت t1. على سبيل المثال، افترض أن الاستعلام يقرأ من قسم محور الحدث الذي يحتوي على قسمين. أحد الأقسام، P1، به أحداث حتى الوقت t1. القسم الآخر، P2، به أحداث حتى الوقت t1 + x. ثم يتم إنتاج المخرجات حتى الوقت t1. ولكن إذا كان هناك جملة صريحة من قسم PartitionId، فإن كلا القسمين يتقدمان بشكل مستقل.

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

{"message Time":"2/3/2019 8:54:16 PM UTC","message":"Input Partition [2] does not have additional data for more than [5] minute(s). Partition will not progress until either events arrive or late arrival threshold is met.","type":"InputPartitionNotProgressing","correlation ID":"0000000000-0000-0000-0000-00000000000000"}

تخبرك هذه الرسالة أن قسما واحدا على الأقل في مدخلك فارغ وسيؤخر مخرجاتك بعتبة الوصول المتأخر. لتجاوز ذلك، ينصح أن:

  • تأكد من أن جميع أقسام مركز الحدث/مركز IoT تتلقى مدخلات.
  • استخدم جملة Partition by PartitionID في الاستعلام الخاص بك.

لماذا أرى تأخيرًا لمدة 5 ثوانٍ حتى عندما يتم تعيين نهج الوصول المتأخر على 0؟

يحدث هذا عندما يكون هناك قسم إدخال لم يتلق أي إدخال مطلقًا. يمكنك التحقق من مقاييس الإدخال عن طريق القسم للتحقق من صحة هذا السلوك.

عندما لا يحتوي قسم على بيانات تزيد عن الحد المتأخر المحدد للوصول، تقوم تحليلات التدفق بتقديم الطابع الزمني للتطبيق كما هو موضح في قسم اعتبارات ترتيب الأحداث. هذا يتطلب الوقت المقدر للوصول. إذا لم يكن القسم يحتوي على أي بيانات، تقدر Stream Analytics وقت الوصول بأنه الوقت المحلي - 5 ثوان. نتيجة لذلك، يمكن أن تظهر الأقسام التي لم يكن بها أي بيانات تأخيرًا للعلامة المائية لمدة 5 ثوانٍ.

الخطوات التالية