فهم التعامل مع الوقت في Azure Stream Analytics

إدارة الوقت في Azure Stream Analytics هي مجموعة الآليات التي تحدد كيفية تحديد وقت الأحداث المتدفقة وترتيبها ومعالجتها بناء على توقيت حدوثها ووقت وصولها. تشرح هذه المقالة كيفية اتخاذ قرارات تصميمية لحل مشاكل التعامل العملية مع الوقت في وظائف Azure Stream Analytics. ترتبط قرارات تصميم التعامل مع الوقت ارتباطًا وثيقًا بعوامل ترتيب الأحداث.

مفاهيم وقت الخلفية

لتأطير المناقشة بشكل أفضل، لنحدد مجموعة من مفاهيم الخلفية:

• وقت الحدث: الوقت الذي يحدث فيه الحدث الأصلي. على سبيل المثال، عندما تقترب سيارة متحركة على الطريق السريع من كشك تحصيل رسوم الطريق.

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

• علامة مائية: علامة زمن حدث تشير إلى النقطة التي استقبل فيها معالج البث أحداثا. تتيح العلامات المائية للنظام الإشارة إلى تقدم واضح في استيعاب الأحداث. وفقًا لطبيعة التدفقات، لا تتوقف بيانات الحدث الوارد أبدًا، لذا تشير العلامات المائية إلى التقدم إلى نقطة معينة في الدفق.

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

للحصول على موارد إضافية حول هذا الموضوع، راجع منشورات مدونة تايلر أكيداو Streaming 101 وStreaming 102.

اختر أفضل وقت للبدء

يوفر لك Azure Stream Analytics خيارين لاختيار وقت الحدث: وقت الوصول ووقت التقديم.

وقت الوصول

يتم تعيين وقت الوصول في مصدر الإدخال عندما يصل الحدث إلى المصدر. يمكنك الوصول إلى وقت الوصول باستخدام الخاصية EventEnqueuedUtcTime لإدخال مراكز الأحداث والخاصية IoTHub.EnqueuedTime لإدخال مركز IoT، والخاصية BlobProperties.LastModified لإدخال البيانات الثنائية الكبيرة.

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

وقت التطبيق (يسمى أيضًا «وقت الحدث»)

يتم تعيين وقت التطبيق عند إنشاء الحدث، وهو جزء من حمولة الحدث. لمعالجة الأحداث حسب وقت التطبيق، استخدم عبارة Timestamp by في استعلام SELECT. إذا كانت عبارة Timestamp by غير موجودة، فستتم معالجة الأحداث حسب وقت الوصول.

من المهم استخدام طابع زمني في الحمولة عندما يتم تضمين منطق زمني لحساب التأخيرات في النظام المصدر أو في الشبكة. الوقت المعيّن لحدث متاح في SYSTEM.TIMESTAMP.

كيف يتقدم الوقت في Azure Stream Analytics

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

• عندما يكون هناك حدث وارد، فإن علامة الماء هي أكبر زمن حدث شهدته Azure Stream Analytics حتى الآن باستثناء حجم نافذة التسامح خارج الترتيب.

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

  يمكن تقدير وقت الوصول فقط لأن وقت الوصول الحقيقي يتم توليده على وسيط الأحداث المدخل (مثل Event Hubs أو IoTHub)، وليس على جهاز Azure Stream Analytics الافتراضي الذي يعالج الأحداث.

يخدم التصميم غرضين إضافيين بخلاف إنشاء علامات مائية:

1. يولد النظام النتائج في الوقت المناسب مع الأحداث الواردة أو بدونها.

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

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

   قد تعاني أنظمة معالجة البيانات المتدفقة دون نافذة التسامح مع الوصول المتأخر من المخرجات المتأخرة عندما تكون المدخلات متفرقة ويتم استخدام أقسام متعددة.

2. يجب أن يكون سلوك النظام قابلًا للتكرار. التكرار هو خاصية مهمة لنظام معالجة البيانات المتدفقة.

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

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

وصول الأحداث المتأخرة

حسب تعريف نافذة التسامح مع الوصول المتأخر، يقارن Azure Stream Analytics في كل حدث وارد بين وقت الحدثووقت الوصول. إذا كان وقت الحدث خارج نافذة التسامح، يمكنك إعداد النظام لإلغاء الحدث أو تعديل وقت الحدث ليكون ضمن تلك الحدود.

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

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

التعامل مع اختلاف الوقت مع التدفقات الفرعية

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

بدلا من استخدام علامة مائية عالمية لجميع الأحداث في قسم الإدخال، لدى Azure Stream Analytics آلية أخرى تسمى substreams. يمكنك استخدام التدفقات الفرعية في عملك عن طريق كتابة استعلام وظيفة يستخدم جملة TIMESTAMP BY وكلمة OVER المفتاحية (OVER). لتعيين التدفق الفرعي، قم بتوفير اسم عمود أساسي بعد الكلمة الأساسية OVER، مثل deviceid حتى يطبق هذا النظام نُهج الوقت حسب هذا العمود. يحصل كل تيار فرعي على علامته المائية المستقلة. هذه الآلية مفيدة للسماح بتوليد المخرجات في الوقت المناسب، عند التعامل مع انحرافات الساعة الكبيرة أو تأخيرات الشبكة بين مرسلي الأحداث.

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

أحداث الوصول المبكر

نافذة الوصول المبكر هي تحمل ثابت مدته 5 دقائق يحدد مدى سرعة وصول الحدث مقارنة بوقت الحدث قبل أن تتخلى عنه Azure Stream Analytics. تخدم هذه النافذة غرضا مختلفا عن نافذة تحمل الوصول المتأخر.

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

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

هذا المفهوم يضمن أن المعالجة قابلة للتكرار بغض النظر عن مكان بدء الإخراج. بدون مثل هذه الآلية، لن يكون من الممكن ضمان إمكانية التكرار، كما تدعي العديد من أنظمة الدفق الأخرى أنها تفعل ذلك.

الآثار الجانبية لترتيب الأحداث هو تفاوتات الوقت

وظائف Azure Stream Analytics تحتوي على عدة خيارات لترتيب الأحداث . يمكن تكوين اثنين في مدخل Azure: إعداد أحداث خارج الترتيب (التسامح خارج الترتيب)، والأحداث التي تصل متأخرًا (تفاوت الوصول المتأخر). تم إصلاح التسامح مع الوصول المبكر ولا يمكن تعديله. تستخدم Azure Stream Analytics هذه السياسات الزمنية لتقديم ضمانات قوية. إلا أنه يمكن أن يكون لهذه الإعدادات في بعض الأحيان آثار غير متوقعة:

1. إرسال أحداث مبكرة جدًا بطريق الخطأ.

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

2. إرسال الأحداث القديمة إلى Event Hubs لتتم معالجتها من قِبل Azure Stream Analytics.

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

3. يبدو أن النواتج قد تأخرت.

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

4. المدخلات متفرقة.

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

5. النظام. تختلف قيمة الطابع الزمني عن الوقت في حقل وقت الحدث.

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

المقاييس التي يجب مراعاتها

يمكنك ملاحظة العديد من تأثيرات التسامح مع وقت ترتيب الحدث من خلال مقاييس مهمة Stream Analytics. المقاييس التالية ذات صلة:

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

تفاصيل تأخير العلامة المائية

يحسب Azure Stream Analytics مقياس تأخير العلامة المائية كوقت ساعة الجدار لعقدة المعالجة مطروحا منه أكبر علامة مائية رآها حتى الآن. لمزيد من المعلومات، راجع تأخير العلامة المائية.

يمكن أن يكون هناك عدة أسباب لكون هذه القيمة المتريّة أكبر من 0 في ظل التشغيل العادي:

1. تأخير المعالجة المتأصل لخط أنابيب التدفق. عادة ما يكون هذا التأخير اسميًا.

2. أدخلت نافذة التسامح خارج الطلب تأخيرًا، لأنه يتم تقليل العلامة المائية حسب حجم نافذة التسامح.

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

4. انحراف الساعة لعقدة المعالجة التي تولد المقياس.

هناك عدة قيود أخرى على الموارد يمكن أن تسبب بطء خط أنابيب البث. يمكن أن يرتفع مقياس تأخير العلامة المائية للأسباب التالية:

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

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

3. مصارف الإخراج (مثل Azure SQL Database، Blob Storage، أو Power BI) ليست مجهزة بسعة كافية، لذا يتم تقييدها. تختلف الحلول الممكنة بشكل كبير بناء على خدمة الإخراج المستخدمة.

تكرار حدث الإخراج

يستخدم Azure Stream Analytics تقدم العلامة المائية باعتباره المشغل الوحيد لإنتاج أحداث الإخراج. نظرا لأن العلامة المائية مشتقة من بيانات الإدخال، فهي قابلة للتكرار أثناء استعادة الفشل وأيضا في إعادة المعالجة التي يبدأها المستخدم. عند استخدام التجميعات التي تستخدم النوافذ، فتنتج الخدمة فقط مخرجات في نهاية النوافذ. في بعض الحالات، قد ترغب في رؤية تجمعات جزئية مولدة من النوافذ. التجميعات الجزئية غير مدعومة حاليا في Azure Stream Analytics.

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

مثال مصور للعلامات المائية

توضح الصور التالية كيفية تقدم العلامات المائية في ظروف مختلفة.

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

وقت الحدث	وقت الوصول	DeviceId
12:07	12:07	device1
12:08	12:08	device2
12:17	12:11	device1
12:08	12:13	device3
12:19	12:16	device1
12:12	12:17	device3
12:17	12:18	device2
12:20	12:19	device2
12:16	12:21	device3
12:23	12:22	device2
12:22	12:24	device2
12:21	12:27	device3

في هذا الرسم التوضيحي، يتم استخدام التفاوتات التالية:

• نافذة الوصول المبكر هي 5 دقائق
• تبلغ نافذة الوصول المتأخر 5 دقائق
• تبلغ نافذة إعادة الترتيب دقيقتين

1. رسم توضيحي للعلامة المائية التي تتقدم خلال هذه الأحداث:

   

   عمليات بارزة موضحة في الرسم السابق:

   1. الحدث الأول (device1)، والحدث الثاني (device2) لهما أوقات متطابقة وتتم معالجتهما بدون تعديلات. تقدم العلامة المائية في كل حدث.

   2. عند معالجة الحدث الثالث (device1)، يسبق وقت الوصول (12:11) وقت الحدث (12:17). وصل الحدث مبكرًا بـ 6 دقائق، لذلك تم إلغاء الحدث نظرًا للتسامح مع الوصول المبكر لمدة 5 دقائق.

      لا تتقدم العلامة المائية في هذه الحالة لحدث مبكر.

   3. الحدث الرابع (الجهاز 3) والحدث الخامس (الجهاز 1) تمت محاذاة أوقاتهما وتتم معالجتهما بدون تعديل. تقدم العلامة المائية في كل حدث.

   4. عند معالجة الحدث السادس (الجهاز3)، يكون وقت الوصول (12:17) ووقت الحدث (12:12) أقل من مستوى العلامة المائية. يتم تعديل زمن الحدث ليكون مستوى العلامة المائية (12:17).

   5. عند معالجة الحدث الثاني عشر (device3)، يكون وقت الوصول (12:27) قبل وقت الحدث بـ 6 دقائق (12:21). يتم تطبيق نهج الوصول المتأخر. يتم ضبط وقت الحدث (12:22)، وهو أعلى من العلامة المائية (12:21) لذلك لا يتم تطبيق أي تعديل إضافي.

2. الرسم التوضيحي الثاني لتقدم العلامة المائية دون نهج الوصول المبكر:

   

   في هذا المثال، لا يتم تطبيق نهج الوصول المبكر. الأحداث الخارجة التي تصل مبكرًا ترفع العلامة المائية بشكل كبير. لاحظ عدم إسقاط الحدث الثالث (deviceId1 في الوقت 12:11) في هذا السيناريو، ويتم رفع العلامة المائية إلى 12:15. يتم تعديل وقت الحدث الرابع للأمام بمقدار 7 دقائق (12:08 إلى 12:15) كنتيجة لذلك.

3. في الرسم التوضيحي الأخير، يتم استخدام التدفقات الفرعية (فوق معرف الجهاز). يتم تعقب علامات مائية متعددة، واحدة لكل بث. هناك عدد أقل من الأحداث مع تعديل أوقاتها نتيجةً لذلك.

   

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

• اعتبارات ترتيب أحداث Azure Stream Analytics
• مقاييس مهمة Azure Stream Analytics