فهم التعامل مع الوقت في Azure Stream Analytics
ستتعرف، في هذه المقالة، على كيفية تحديد خيارات التصميم لحل مشكلات التعامل مع الوقت العملي في مهام Azure Stream Analytics. ترتبط قرارات تصميم التعامل مع الوقت ارتباطًا وثيقًا بعوامل ترتيب الأحداث.
مفاهيم وقت الخلفية
لتأطير المناقشة بشكل أفضل، لنحدد مجموعة من مفاهيم الخلفية:
وقت الحدث: وقت وقوع الحدث الأصلي. على سبيل المثال، عندما تقترب سيارة متحركة على الطريق السريع من كشك تحصيل رسوم الطريق.
وقت المعالجة: الوقت الذي يصل فيه الحدث إلى نظام المعالجة ويتم ملاحظته. على سبيل المثال، عندما يرى مستشعر كشك تحصيل رسوم الطريق السيارة ونظام الكمبيوتر يستغرق بضع لحظات لمعالجة البيانات.
العلامة المائية: علامة وقت الحدث التي تشير إلى النقطة التي تم إدخال الأحداث فيها إلى معالج البث. تتيح العلامات المائية للنظام الإشارة إلى تقدم واضح في استيعاب الأحداث. وفقًا لطبيعة التدفقات، لا تتوقف بيانات الحدث الوارد أبدًا، لذا تشير العلامات المائية إلى التقدم إلى نقطة معينة في الدفق.
مفهوم العلامة المائية مهم. تتيح العلامات المائية لـ Stream Analytics تحديد متى يمكن للنظام أن ينتج نتائج كاملة وصحيحة وقابلة للتكرار لا تحتاج إلى التراجع. يمكن تنفيذ المعالجة بطريقة يمكن التنبؤ بها وقابلة للتكرار. على سبيل المثال، إذا كان من الضروري إجراء إعادة فرز لبعض حالات معالجة الأخطاء، فإن العلامات المائية هي نقاط بداية ونهاية آمنة.
للحصول على موارد إضافية حول هذا الموضوع، راجع منشورات مدونة تايلر أكيداو Streaming 101 وStreaming 102.
اختر أفضل وقت للبدء
يوفر Stream Analytics للمستخدمين خيارين لاختيار وقت الحدث: وقت الوصول ووقت التطبيق.
وقت الوصول
يتم تعيين وقت الوصول في مصدر الإدخال عندما يصل الحدث إلى المصدر. يمكنك الوصول إلى وقت الوصول باستخدام الخاصية EventEnqueuedUtcTime لإدخال مراكز الأحداث والخاصية IoTHub.EnqueuedTime لإدخال مركز IoT، والخاصية BlobProperties.LastModified لإدخال البيانات الثنائية الكبيرة.
يتم استخدام وقت الوصول بشكل افتراضي واستخدامه بشكل أفضل لسيناريوهات أرشفة البيانات إذ لا يكون المنطق الزمني ضروريًا.
وقت التطبيق (يسمى أيضًا «وقت الحدث»)
يتم تعيين وقت التطبيق عند إنشاء الحدث، وهو جزء من حمولة الحدث. لمعالجة الأحداث حسب وقت التطبيق، استخدم عبارة Timestamp by في استعلام SELECT. إذا كانت عبارة Timestamp by غير موجودة، فستتم معالجة الأحداث حسب وقت الوصول.
من المهم استخدام طابع زمني في الحمولة عندما يتم تضمين منطق زمني لحساب التأخيرات في النظام المصدر أو في الشبكة. الوقت المعيّن لحدث متاح في SYSTEM.TIMESTAMP.
كيف يتقدم الوقت في Azure Stream Analytics
يعتمد تقدم الوقت، عند استخدام وقت التطبيق، على الأحداث الواردة. يصعب على نظام معالجة الدفق معرفة ما إذا كانت هناك أحداث أو أحداث يتم تأخيرها. لهذا السبب، يُنشئ Azure Stream Analytics علامات مائية إرشادية بالطرق التالية لكل قسم إدخال:
إن العلامة المائية، عندما يكون هناك أي حدث وارد، هي أكبر وقت حدث شهده Stream Analytics حتى الآن مطروحًا منه حجم نافذة التسامح مع الخروج عن الترتيب.
تكون العلامة المائية، عندما لا يكون هناك حدث وارد، هي وقت الوصول المقدر الحالي مطروحًا منه نافذة التسامح مع الوصول المتأخر. وقت الوصول المقدر هو الوقت الذي انقضى من آخر مرة تمت فيها مشاهدة حدث إدخال بالإضافة إلى وقت وصول حدث الإدخال هذا.
لا يمكن تقدير وقت الوصول إلا لأن وقت الوصول الفعلي يتم إنشاؤه على وسيط حدث الإدخال، مثل مراكز الأحداث وليس على جهاز Azure Stream Analytics الظاهري الذي يعالج الأحداث.
يخدم التصميم غرضين إضافيين بخلاف إنشاء علامات مائية:
يولد النظام النتائج في الوقت المناسب مع الأحداث الواردة أو بدونها.
يمكنك التحكم في الوقت المناسب الذي تريد أن تظهر خلاله نتائج الإخراج. في مدخل Azure، في صفحة ترتيب الأحداث لوظيفة Stream Analytics، يمكنك تكوين إعداد أحداث خارج الطلب. يوصى، عند تكوين هذا الإعداد، بمقايضة التوقيت بالتسامح مع الأحداث خارج الترتيب في دفق الحدث.
تعد نافذة التسامح مع الوصول المتأخر ضرورية للحفاظ على إنشاء علامات مائية حتى في حالة عدم وجود أحداث واردة. قد تكون هناك وفي بعض الأحيان فترة لا تأتي فيها أحداث واردة، كما هو الحال عندما يكون تدفق إدخال الحدث متفرقًا. تتفاقم هذه المشكلة عن طريق استخدام أقسام متعددة في وسيط حدث الإدخال.
قد تعاني أنظمة معالجة البيانات المتدفقة بدون نافذة تحمل الوصول المتأخر من تأخر المخرجات عندما تكون المدخلات متفرقة ويتم استخدام أقسام متعددة.
يجب أن يكون سلوك النظام قابلًا للتكرار. التكرار هو خاصية مهمة لنظام معالجة البيانات المتدفقة.
العلامة المائية مشتقة من وقت الوصول ووقت التطبيق. كلاهما استمر في وسيط الحدث، وبالتالي قابل للتكرار. إذا تم تقدير وقت الوصول في حالة عدم وجود أحداث، فيباشر Azure Stream Analytics تسجيل وقت الوصول المقدر للتكرار أثناء إعادة التشغيل لاسترداد الفشل.
لاحظ أنه عند اختيار استخدام وقت الوصول كوقت الحدث، فلا داعي لتكوين التسامح مع الخروج عن الترتيب والتسامح مع الوصول المتأخر. نظرًا لأنه من المضمون زيادة وقت الوصول في وسيط حدث الإدخال، فيتجاهل Azure Stream Analytics عمليات التكوين ببساطة.
وصول الأحداث المتأخرة
حسب تعريف نافذة التسامح مع الوصول المتأخر، يقارن Azure Stream Analytics في كل حدث وارد بين وقت الحدثووقت الوصول. إذا كان وقت الحدث خارج نافذة التسامح، فيمكنك تكوين النظام لإسقاط الحدث أو تعديل وقت الحدث ليكون ضمن التسامح.
من المحتمل وبمجرد إنشاء علامات مائية، أن تتلقى الخدمة أحداثًا بوقت حدث أقل من العلامة المائية. يمكنك تكوين الخدمة إما لإسقاط هذه الأحداث أو تعديل وقت الحدث إلى قيمة العلامة المائية.
يتم كجزء من التعديل، تعيين System.Timestamp الخاص بالحدث إلى القيمة الجديدة، لكن لا يتم تغيير حقل وقت الحدث نفسه. هذا التعديل هو الموقف الوحيد الذي يمكن أن يكون System.Timestamp لحدث مختلفًا عن القيمة الموجودة في حقل وقت الحدث، وقد يتسبب في إنشاء نتائج غير متوقعة.
التعامل مع اختلاف الوقت مع التدفقات الفرعية
تعمل آلية إنشاء العلامة المائية الإرشادية الموضحة بشكل جيد في معظم الحالات التي تتم فيها مزامنة الوقت في الغالب بين مرسلي الأحداث المختلفين. ومع ذلك، في الحياة الواقعية، لا سيما في العديد من سيناريوهات إنترنت الأشياء، لا يمتلك النظام سوى القليل من التحكم في الساعة على مرسلي الأحداث. يمكن أن يكون مرسلو الأحداث جميع أنواع الأجهزة في الميدان، ربما على إصدارات مختلفة من الأجهزة والبرامج.
بدلاً من استخدام علامة مائية عمومية لجميع الأحداث في قسم الإدخال، يحتوي Stream Analytics على آلية أخرى تسمى التدفقات الفرعية. يمكنك الاستفادة من التدفقات الفرعية في المهمة بكتابة استعلام عن مهمة يستخدم عبارة TIMESTAMP BY والكلمة الأساسية OVER. لتعيين التدفق الفرعي، قم بتوفير اسم عمود أساسي بعد الكلمة الأساسية OVER، مثل deviceid حتى يطبق هذا النظام نُهج الوقت حسب هذا العمود. يحصل كل تيار فرعي على علامته المائية المستقلة. هذه الآلية مفيدة للسماح بتوليد المخرجات في الوقت المناسب، عند التعامل مع انحرافات الساعة الكبيرة أو تأخيرات الشبكة بين مرسلي الأحداث.
تعد التدفقات الفرعية حلاً فريدًا يتم توفيره من قِبل Azure Stream Analytics، ولا يتم تقديمه من قِبل أنظمة معالجة بيانات التدفق الأخرى.
يطبق Stream Analytics، عند استخدام التدفقات الفرعية، نافذة التسامح مع الوصول المتأخر على الأحداث الواردة. يحدد التسامح مع الوصول المتأخر الحد الأقصى للمقدار الذي يمكن من خلاله أن تكون به التدفقات الفرعية المختلفة منفصلة عن بعضها بعضًا. على سبيل المثال إذا كان الجهاز 1 في الطابع الزمني 1، وكان الجهاز 2 في الطابع الزمني 2، فإن التسامح مع الوصول المتأخر هو الطابع الزمني 2 مطروحًا منه الطابع الزمني 1. الإعداد الافتراضي هو (5 ثوانٍ)، ومن المحتمل أن يكون صغيرًا جدًا بالنسبة للأجهزة ذات الطوابع الزمنية المختلفة. نوصي بأن تبدأ بـ 5 دقائق، وإجراء تعديلات بناءً على نمط انحراف ساعة الجهاز.
أحداث الوصول المبكر
ربما لاحظت مفهومًا آخر يسمى نافذة الوصول المبكر، والتي تبدو عكس نافذة التسامح مع الوصول المتأخر. يتم تثبيت هذه النافذة على 5 دقائق، وتخدم غرضًا مختلفًا عن غرض نافذة التسامح مع الوصول المتأخر.
يمكنك فقط، نظرًا لأن Azure Stream Analytics يضمن نتائج كاملة، تحديد وقت بدء المهمة باعتباره وقت الإخراج الأول للمهمة، وليس وقت الإدخال. وقت بدء المهمة مطلوب حتى تتم معالجة النافذة الكاملة، وليس فقط من منتصف النافذة.
يعمل Stream Analytics على اشتقاق وقت البدء من مواصفات الاستعلام. إلا أنه ونظرًا لأن وسيط حدث الإدخال تتم فهرسته فقط حسب وقت الوصول، يتعين على النظام ترجمة وقت بدء الحدث إلى وقت الوصول. يمكن للنظام بدء معالجة الأحداث من تلك النقطة في وسيط حدث الإدخال. باستخدام حد نافذة الوصول المبكر، تكون الترجمة مباشرة: وقت بدء الحدث مطروحًا منه نافذة الوصول المبكر التي تبلغ 5 دقائق. يعني هذا الحساب أيضًا أن النظام يسقط جميع الأحداث التي يُنظر إليها على أنها تتضمن وقت حدث يسبق وقت الوصول بـ 5 دقائق. يتم زيادة مقياس أحداث الإدخال المبكر عند إسقاط الأحداث.
يستخدم هذا المفهوم للتأكد من أن المعالجة قابلة للتكرار بغض النظر عن المكان الذي تبدأ منه الإخراج. بدون مثل هذه الآلية، لن يكون من الممكن ضمان التكرار، كما تدعي العديد من أنظمة التدفق الأخرى.
الآثار الجانبية لترتيب الأحداث هو تفاوتات الوقت
وظائف Stream Analytics لها العديد من خيارات ترتيب الأحداث. يمكن تكوين اثنين في مدخل Azure: إعداد أحداث خارج الترتيب (التسامح خارج الترتيب)، والأحداث التي تصل متأخرًا (تفاوت الوصول المتأخر). تم إصلاح تفاوت الوصول المبكر ولا يمكن تعديله. يتم استخدام سياسات الوقت هذه من قِبل Stream Analytics لتوفير ضمانات قوية. إلا أنه يمكن أن يكون لهذه الإعدادات في بعض الأحيان آثار غير متوقعة:
إرسال أحداث مبكرة جدًا بطريق الخطأ.
لا ينبغي إخراج الأحداث المبكرة بشكل طبيعي. من المحتمل أن يتم إرسال الأحداث المبكرة إلى الإخراج إذا كانت ساعة المرسل تعمل بسرعة كبيرة. يتم إسقاط جميع الأحداث التي وصلت مبكرًا، لذلك لن ترى أيًا منها من الإخراج.
إرسال الأحداث القديمة إلى Event Hubs لتتم معالجتها من قِبل Azure Stream Analytics.
في حين أن الأحداث القديمة قد تبدو غير ضارة في البداية، بسبب تطبيق التسامح مع الوصول المتأخر، قد يتم إسقاط الأحداث القديمة. إذا كانت الأحداث قديمة جدًا، يتم تغيير قيمة الطابع الزمني System.Timestamp أثناء عرض الحدث. نظرًا لهذا السلوك، يعد Azure Stream Analytics حاليًا أكثر ملاءمة لسيناريوهات معالجة الأحداث في الوقت الفعلي تقريبًا، بدلاً من سيناريوهات معالجة الأحداث التاريخية. يمكنك تعيين الأحداث التي تصل متأخرًا إلى أكبر قيمة ممكنة (20 يومًا) للتغلب على هذا السلوك في بعض الحالات.
يبدو أن النواتج قد تأخرت.
يتم إنشاء العلامة المائية الأولى في الوقت المحسوب: الحد الأقصى لوقت الحدث الذي لاحظه النظام حتى الآن، مطروحًا منه حجم نافذة التسامح خارج الترتيب. بشكل افتراضي، يتم تكوين التسامح خارج الترتيب إلى الصفر (00 دقيقة و00 ثانية). عندما تقوم بتعيينها على قيمة زمنية أعلى غير صفرية، فإن الإخراج الأول لمهمة البث يتأخر بهذه القيمة الزمنية (أو أكبر) بسبب وقت العلامة المائية الأول الذي تم حسابه.
المدخلات متفرقة.
في حالة عدم وجود إدخال في قسم معين، يتم حساب وقت العلامة المائية على أنه وقت الوصول مطروحًا منه نافذة التسامح مع الوصول المتأخر. نتيجةً لذلك، إذا كانت أحداث الإدخال نادرة ومتفرقة، فيمكن أن يتأخر الإخراج بمقدار هذا الوقت. الأحداث الافتراضية التي تصل متأخرًا هي 5 ثوانٍ. يجب أن تتوقع رؤية بعض التأخير عند إرسال أحداث الإدخال واحدًا تلو الآخر، على سبيل المثال. يمكن أن تزداد حالات التأخير سوءًا عند تعيين قيمة كبيرة للأحداث التي تصل متأخرًا.
النظام. تختلف قيمة الطابع الزمني عن الوقت في حقل وقت الحدث.
وكما هو موضح سابقًا، يضبط النظام وقت الحدث من خلال نافذة التسامح خارج الترتيب أو نوافذ تفاوت الوصول المتأخر. يتم تعديل قيمة System.Timestamp للحدث، ولكن ليس حقل وقت الحدث. يمكن استخدام هذا لتحديد الأحداث التي تم تعديل الطوابع الزمنية لها. إذا أجرى النظام تغييرًا على الطابع الزمني بسبب أحد الاختلافات، فتكون عادةً هي نفسها.
المقاييس التي يجب مراعاتها
يمكنك ملاحظة العديد من تأثيرات التسامح مع وقت ترتيب الحدث من خلال مقاييس مهمة Stream Analytics. المقاييس التالية ذات صلة:
| متري | الوصف |
|---|---|
| الأحداث خارج الترتيب | يشير إلى عدد الأحداث المستلمة خارج الترتيب، والتي إما تم إسقاطها أو منح طابع زمني معدل. يتأثر هذا المقياس بشكل مباشر بتكوين إعداد أحداث خارج الترتيب في صفحة ترتيب الأحداث في الوظيفة في مدخل Azure. |
| أحداث الإدخال المتأخرة | تشير إلى عدد الأحداث التي وصلت متأخرة من المصدر. يتضمن هذا المقياس الأحداث التي تم تجاهلها أو تم تعديل طابعها الزمني. يتأثر هذا المقياس بشكل مباشر بتكوين الأحداث التي تصل متأخرًا في صفحة ترتيب الأحداث في الوظيفة في مدخل Azure. |
| أحداث المدخلات المبكرة | يشير إلى عدد الأحداث التي تصل مبكرًا من المصدر والتي تم إسقاطها، أو تم تعديل طابعها الزمني إذا تجاوزت 5 دقائق مبكرًا. |
| تأخير العلامة المائية | يشير إلى تأخير مهمة معالجة البيانات المتدفقة. راجع المزيد من المعلومات في القسم التالي. |
تفاصيل تأخير العلامة المائية
يتم حساب مقياس تأخير العلامة المائية كوقت ساعة حائط عقدة المعالجة مطروحًا منه أكبر علامة مائية رأتها حتى الآن. لمزيد من المعلومات، راجع منشور مدونة تأخير العلامة المائية.
يمكن أن يكون هناك عدة أسباب لكون هذه القيمة المتريّة أكبر من 0 في ظل التشغيل العادي:
تأخير المعالجة المتأصل لخط أنابيب التدفق. عادة ما يكون هذا التأخير اسميًا.
أدخلت نافذة التسامح خارج الطلب تأخيرًا، لأنه يتم تقليل العلامة المائية حسب حجم نافذة التسامح.
أدخلت نافذة الوصول المتأخر تأخيرًا، لأنه يتم تقليل العلامة المائية حسب حجم نافذة التسامح.
انحراف الساعة لعقدة المعالجة التي تولد المقياس.
هناك العديد من قيود الموارد الأخرى التي يمكن أن تتسبب في إبطاء مسار التدفق. يمكن أن يرتفع مقياس تأخير العلامة المائية للأسباب التالية:
لا توجد موارد معالجة كافية في Stream Analytics للتعامل مع حجم أحداث الإدخال. لتوسيع نطاق الموارد، راجع فهم وحدات البث وتعديلها.
لا توجد سعة نقل كافية داخل وسطاء حدث الإدخال، لذلك يتم تقييدهم. للحصول على الحلول الممكنة، راجع توسيع نطاق وحدات معدل النقل في مراكز أحداث Azure تلقائيًا.
لا يتم تزويد أحواض الإخراج بسعة كافية، لذلك يتم اختناقها. تختلف الحلول الممكنة على نطاق واسع بناءً على نكهة خدمة الإخراج المستخدمة.
تكرار حدث الإخراج
يستخدم 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 دقائق
- تبلغ نافذة إعادة الترتيب دقيقتين
رسم توضيحي للعلامة المائية التي تتقدم خلال هذه الأحداث:
عمليات بارزة موضحة في الرسم السابق:
الحدث الأول (device1)، والحدث الثاني (device2) لهما أوقات متطابقة وتتم معالجتهما بدون تعديلات. تقدم العلامة المائية في كل حدث.
عند معالجة الحدث الثالث (device1)، يسبق وقت الوصول (12:11) وقت الحدث (12:17). وصل الحدث مبكرًا بـ 6 دقائق، لذلك تم إلغاء الحدث نظرًا للتسامح مع الوصول المبكر لمدة 5 دقائق.
لا تتقدم العلامة المائية في هذه الحالة لحدث مبكر.
الحدث الرابع (الجهاز 3) والحدث الخامس (الجهاز 1) تمت محاذاة أوقاتهما وتتم معالجتهما بدون تعديل. تقدم العلامة المائية في كل حدث.
عند معالجة الحدث السادس (device3)، يكون وقت الوصول (12:17) ووقت الحدث (12:12) أقل من مستوى العلامة المائية. يتم ضبط وقت الحدث على مستوى العلامة المائية (12:17).
عند معالجة الحدث الثاني عشر (device3)، يكون وقت الوصول (12:27) قبل وقت الحدث بـ 6 دقائق (12:21). يتم تطبيق نهج الوصول المتأخر. يتم ضبط وقت الحدث (12:22)، وهو أعلى من العلامة المائية (12:21) لذلك لا يتم تطبيق أي تعديل إضافي.
الرسم التوضيحي الثاني لتقدم العلامة المائية دون نهج الوصول المبكر:
في هذا المثال، لا يتم تطبيق نهج الوصول المبكر. الأحداث الخارجة التي تصل مبكرًا ترفع العلامة المائية بشكل كبير. لاحظ أن الحدث الثالث (deviceId1 في الوقت 12:11) لم يتم إسقاطه في هذا السيناريو، ويتم رفع العلامة المائية إلى 12:15. يتم تعديل وقت الحدث الرابع للأمام بمقدار 7 دقائق (12:08 إلى 12:15) كنتيجة لذلك.
في الرسم التوضيحي الأخير، يتم استخدام التدفقات الفرعية (فوق معرف الجهاز). يتم تعقب علامات مائية متعددة، واحدة لكل بث. هناك عدد أقل من الأحداث مع تعديل أوقاتها نتيجةً لذلك.
