Share via

أنماط حل Azure Stream Analytics

  • مقالة

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

أنشئ وظيفة Stream Analytics لتعزيز تجربة لوحة المعلومات في الوقت الفعلي

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

Diagram that shows events from Event Hubs and IoT Hubs flowing through Stream Analytics and to the Power BI dashboard.

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

يوفر نمط الحل هذا أقل زمن انتقال من مصدر الحدث إلى لوحة معلومات Power BI في المستعرض. Azure Stream Analytics هي خدمة Azure الوحيدة التي تحتوي على هذه الإمكانية المضمنة.

استخدام SQL للوحة المعلومات

توفر لوحة معلومات Power BI زمن انتقال منخفض، ولكن لا يمكنك استخدامها لإنتاج تقارير Power BI كاملة. نمط التقارير المتداول هو إخراج بياناتك إلى SQL Database أولاً. ثم استخدم موصل Power BI SQL لاستعلام SQL عن أحدث البيانات.

Diagram that shows SQL Database as an intermediate store between Stream Analytics and Power BI dashboard.

عند استخدام قاعدة بيانات SQL، فإنه يمنحك المزيد من المرونة ولكن على حساب زمن انتقال أعلى قليلا. هذا الحل مثالي للوظائف التي تتطلب زمن انتقال أكبر من ثانية واحدة. عند استخدام هذا الأسلوب، يمكنك تكبير قدرات Power BI لمزيد من تقسيم البيانات والنرد لها للتقارير، وخيارات مرئيات أكثر بكثير. يمكنك أيضًا اكتساب المرونة في استخدام حلول لوحة المعلومات الأخرى، مثل Tableau.

SQL ليس مخزن بيانات عالي الإنتاجية. يبلغ الحد الأقصى لمعدل النقل لـ SQL Database من Azure Stream Analytics حالياً حوالي 24 ميغابايت/ثانية. إذا كانت مصادر الأحداث في الحل الخاص بك تنتج بيانات بمعدل أعلى، فأنت بحاجة إلى استخدام منطق المعالجة في Stream Analytics لتقليل معدل الإخراج إلى SQL. يمكنك استخدام تقنيات مثل التصفية والتجاميع ذات النوافذ ومطابقة النمط مع الصلات الزمنية والوظائف التحليلية. يمكنك تحسين معدل الإخراج إلى SQL باستخدام التقنيات الموضحة في إخراج Azure Stream Analytics إلى قاعدة بيانات Azure SQL.

دمج رؤى في الوقت الفعلي في تطبيقك من خلال رسائل الأحداث

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

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

Diagram that shows Event Hubs and IoT Hubs as data sources and Event Hubs, Service Bus, or Functions as destinations for an Azure Stream Analytics job.

من ناحية أخرى، تقدم خدمة Azure Event Hubs نقطة التكامل الأكثر مرونة. يمكن للعديد من الخدمات الأخرى، مثل Azure Data Explorer وTime Series Insights، أن تستهلك الأحداث من Event Hubs. يمكن توصيل الخدمات مباشرة بحوض Event Hubs من Azure Stream Analytics لإكمال الحل. ويُعد Event Hubs أيضًا أعلى وسطاء المراسلة المتاحين على Azure من حيث معدل النقل من أجل سيناريوهات التكامل تلك.

التطبيقات والمواقع الديناميكية

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

Diagram that shows a Web app using SignalR service as a destination.

تضمين رؤى في الوقت الفعلي في تطبيقك من خلال مخازن البيانات

تستخدم معظم خدمات الويب وتطبيقات الويب اليوم نمط الطلب/الاستجابة لخدمة طبقة العرض التقديمي. يعد نمط الطلب/الاستجابة بسيطا للبناء ويمكن قياسه بسهولة مع وقت استجابة منخفض باستخدام مخازن أمامية عديمة الحالة وقابلة للتطوير مثل Azure Cosmos DB.

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

Diagram that shows a real-time application as a destination for a Stream Analytics job.

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

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

Diagram that shows Event Hubs as an intermediary and a real-time application as a destination for a Stream Analytics job.

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

استخدام البيانات المرجعية لتخصيص التطبيق

تم تصميم ميزة البيانات المرجعية في Azure Stream Analytics خصوصاً لتخصيص المستخدم النهائي مثل حد التنبيه وقواعد المعالجة والموقع الجغرافي. يمكن لطبقة التطبيق قبول تغييرات المعلمات وتخزينها في SQL Database. تستعلم وظيفة Stream Analytics بشكل دوري عن التغييرات من قاعدة البيانات وتجعل معلمات التخصيص قابلة للوصول من خلال ضم بيانات مرجعية. لمزيد من المعلومات حول كيفية استخدام البيانات المرجعية لتخصيص التطبيق، راجع بيانات مرجع SQL وربط البيانات المرجعية.

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

Diagram that shows a Stream Analytics job and the destination application using reference data.

إضافة التعلم الآلي من Microsoft Azure إلى إحصاءاتك في الوقت الحقيقي

يعد نموذج اكتشاف العيوب المدمج في Stream Analytics طريقة ملائمة لتقديم التعلم الآلي من Microsoft Azure لتطبيقك في الوقت الحقيقي. للحصول على مجموعة واسعة من احتياجات التعلم الآلي من Microsoft Azure، راجع Azure Stream Analytics يتكامل مع خدمة تسجيل التعلم الآلي من Microsoft Azure.

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

Diagram that shows an Azure Stream Analytics job using an ML scoring model.

تخزين البيانات في الوقت الحقيقي

نمط متداول آخر هو تخزين البيانات في الوقت الحقيقي، ويسمى أيضاً مستودع البيانات المتدفقة. بالإضافة إلى الأحداث التي تصل إلى مراكز الأحداث وIoT Hub من تطبيقك، يمكن استخدام Azure Stream Analytics الذي يعمل على IoT Edge لتلبية احتياجات حذف البيانات وتقليل البيانات وتخزين البيانات وإعادة التوجيه. يمكن لـ Stream Analytics التي تعمل على IoT Edge التعامل بأمان مع قيود النطاق الترددي ومشكلات الاتصال في النظام. يمكن أن يدعم Stream Analytics معدلات نقل تصل إلى 200 ميجابايت/ ثانية أثناء الكتابة إلى Azure Synapse Analytics.

Diagram that shows real-time data warehouse a destination for a Stream Analytics job.

أرشفة البيانات في الوقت الحقيقي للتحليلات

لا تزال معظم أنشطة علم البيانات والتحليلات تحدث في وضع عدم الاتصال. يمكنك أرشفة البيانات في Azure Stream Analytics من خلال إخراج Azure Data Lake Store Gen2 وتنسيقات إخراج Parquet. تزيل هذه الإمكانية الاحتكاك لموجز البيانات مباشرة في Azure Data Lake Analytics وAzure Databricks وAzure HDInsight. يتم استخدام Azure Stream Analytics كمحرك قريب من الوقت الحقيقي Extract-Transform-Load (ETL) في هذا الحل. يمكنك استكشاف البيانات المؤرشفة في Data Lake باستخدام العديد من محركات الحوسبة.

Diagram that shows archiving of real-time data from a Stream Analytics job.

استخدام البيانات المرجعية للإثراء

غالباً ما يكون إثراء البيانات شرطاً لمحركات ETL. يدعم Azure Stream Analytics إثراء البيانات باستخدام البيانات المرجعية من SQL Database وموقع تخزين Azure Blob. يمكن إجراء إثراء البيانات لهبوط البيانات في كل من Azure Data Lake وAzure Synapse Analytics..

Diagram that shows the usage of reference data to enrich streaming data and then use it offline analytics.

تفعيل النتائج المعرفية من البيانات المؤرشفة

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

Diagram that shows both cold path and hot path in a Stream Analytics solution.

كيفية مراقبة وظائف ASA

يمكن تشغيل وظيفة Azure Stream Analytics على مدار الساعة طوال أيام الأسبوع لمعالجة الأحداث الواردة باستمرار في الوقت الفعلي. يعد ضمان وقت التشغيل أمرًا بالغ الأهمية لسلامة التطبيق العام. في حين أن Stream Analytics هي خدمة تحليلات البث الوحيدة في الصناعة التي تقدم ضمان توفر بنسبة 99.9٪، إلا أنك لا تزال تتحمل مستوى معين من وقت التعطل. على مر السنين، قدمت Stream Analytics مقاييس وسجلات وحالات وظيفية لتعكس صحة الوظائف. يتم عرض كل منهم من خلال خدمة Azure Monitor ويمكن تصديرها إلى OMS. لمزيد من المعلومات، راجع مهمة Monitor Stream Analytics باستخدام مدخل Microsoft Azure.

Diagram that shows monitoring of Stream Analytics jobs.

هناك شيئان أساسيان يجب مراقبتهما:

  • حالة فشل الوظيفة

    أولاً وقبل كل شيء، تحتاج إلى التأكد من أن الوظيفة تعمل. بدون الوظيفة في حالة التشغيل، لا يتم إنشاء مقاييس أو سجلات جديدة. يمكن أن تتغير الوظائف إلى حالة فاشلة لأسباب مختلفة، بما في ذلك وجود مستوى عال من استخدام SU (أي نفاد الموارد).

  • مقاييس تأخير العلامة المائية

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

عند الفشل، تعد سجلات النشاط وسجلات التشخيص أفضل الأماكن لبدء البحث عن الأخطاء.

بناء تطبيقات مرنة ومهمة

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

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

يمكنك أيضا اختيار بدء الإخراج من بعض الوقت في الماضي. تحتوي نُهج الاحتفاظ لكل من Event Hubs وIoT Hub على قدر معقول من البيانات للسماح بالمعالجة من الماضي. المقايضة هي السرعة التي يمكنك من خلالها اللحاق بالوقت الحالي والبدء في إنشاء تنبيهات جديدة في الوقت المناسب. تفقد البيانات قيمتها بسرعة بمرور الوقت، لذلك من المهم اللحاق بالوقت الحالي بسرعة. هناك طريقتان للمتابعة بسرعة:

  • توفير المزيد من الموارد (SU) عند اللحاق بالركب.
  • إعادة التشغيل من الوقت الحالي.

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

يمكن أن يؤدي توفير المزيد من الموارد إلى تسريع العملية، ولكن تأثير زيادة معدل المعالجة أمر معقد.

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

  • تأكد من وجود أقسام كافية في Event Hub أو IoT Hub بحيث يمكنك إضافة المزيد من وحدات الصبيب (TUs) لتوسيع نطاق إنتاجية الإدخال. تذكر أن كل حدث TU يصل إلى الحد الأقصى بمعدل إخراج يبلغ 2 ميجابايت/ثانية.

  • تأكد من توفير موارد كافية في أحواض الإخراج (أي قاعدة بيانات SQL وAzure Cosmos DB)، حتى لا تقيد الزيادة في الإخراج، والتي يمكن أن تتسبب في بعض الأحيان في تأمين النظام.

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

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

بنى Lambda أو عملية Backfill

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

ASA backfill

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

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

السيناريوهات إعادة التشغيل من الآن فقط إعادة التشغيل من آخر وقت توقف إعادة التشغيل من الآن + إعادة ملء الأحداث المؤرشفة
Dashboarding يخلق فجوة موافق لانقطاع قصير استخدام لفترة طويلة من الانقطاع
تنبيه مقبول موافق لانقطاع قصير أمور غير ضرورية
تطبيق مصادر الأحداث مقبول موافق لانقطاع قصير استخدام لفترة طويلة من الانقطاع
تخزين البيانات فقدان البيانات مقبول أمور غير ضرورية
التحليلات في حال عدم الاتصال فقدان البيانات مقبول أمور غير ضرورية

جمع كل ذلك معاً

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

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

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

لقد رأيت الآن أنماط حلول مختلفة باستخدام Azure Stream Analytics. بعد ذلك، يمكنك التعمق وإنشاء أول وظيفة عبر Stream Analytics: