فهم وضبط وحدات دفق Stream Analytics

يتعين فهم وحدة الدفق وعقدة الدفق

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

يدعم Azure Stream Analytics هيكلين لوحدة البث: SU V1 (ليتم إهماله) وSU V2 (مستحسن) .

نموذج SU V1 هو العرض الأصلي ل Azure Stream Analytics حيث تمثل كل 6 وحدات بث مباشرة واحدة للعمل. قد تعمل الوظائف أيضا مع وحدات SU 1 و3، وهي تتوافق مع عقد البث الجزئي. يحدث التوسع بزيادات من 6 فوق 6 وظائف SU، إلى 12، 18، 24، وما بعدها بإضافة المزيد من عقد البث التي توفر موارد حوسبة موزعة.

نموذج SU V2 (الموصى به) هو هيكل مبسط مع تسعير مناسب لنفس موارد الحوسبة. في نموذج SU V2، يتوافق 1 SU V2 مع عقدة دفق واحدة لمهمتك. 2 وحدة SU V2 تمثل عقدتين للبث، 3 إلى 3، وهكذا. تتوفر الوظائف ذات الإصدارين 1/3 و2/3 SU أيضا مع عقدة دفق واحدة ولكن جزءا من موارد الحوسبة. توفر وظائف 1/3 و2/3 SU V2 خيارا فعالا من حيث التكلفة لأحمال العمل التي تتطلب نطاقا أصغر.

يوضح الجدول التالي القدرة الحوسبة الأساسية لوحدات البث V1 وV2:

لقطة شاشة لجدول تعيين SU V1 و SU V2.

للحصول على معلومات حول تسعير SU، تفضل بزيارة صفحة تسعير Azure Stream Analytics.

فهم تحويلات وحدة البث ومكان تطبيقها

يقوم النظام تلقائيا بتحويل وحدات البث من طبقة واجهة برمجة التطبيقات REST إلى واجهة المستخدم (بوابة Azure وكود Visual Studio). ترى هذا التحويل أيضا في سجل النشاط ، حيث تظهر قيم وحدات البث بشكل مختلف عن القيم الموجودة في واجهة المستخدم. يتم هذا السلوك بسبب التصميم. حقول REST API محدودة بالقيم الصحيحة، لكن وظائف تحليلات التدفق تدعم العقد الجزئية (وحدات البث 1/3 و2/3). واجهة Azure Stream Analytics تعرض قيم العقد ك 1/3، 2/3، 1، 2، 3، وهكذا، بينما تعرض الواجهة الخلفية (سجلات النشاط، طبقة REST API) نفس القيم مضروبة في 10 مثل 3، 7، 10، 20، و30 على التوالي.

قياسي الإصدار 2 القياسي (UI) الإصدار 2 القياسي (الخلفية مثل السجلات وواجهة برمجة تطبيقات Rest وما إلى ذلك)
1 1/3 3
3 2/3 7
6 1 10
12 2 20
18 3 30
... ... ...

هذا التحويل ينقل نفس الدقة ويلغي الفاصلة العشرية في طبقة API لوحدات حفظ مخزون V2 (SKUs). هذا التحويل تلقائي وليس له أي تأثير على أداء وظيفتك.

فهم الاستهلاك واستخدام الذاكرة

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

يصف مقياس استخدام SU٪ الذي يتراوح بين 0٪ و100٪، استهلاك الذاكرة فيما يتعلق بحمل العمل الخاص بك. فيما يتعلق بمهمة الدفق بأقل قدر من البصمة، عادة ما يتراوح هذا المقياس بين 10٪ و20٪. إذا كان استخدام SU٪ مرتفعا (أعلى من 80٪)، أو إذا تم تراكم أحداث الإدخال (حتى مع استخدام SU٪ منخفض لأنه لا يظهر استخدام وحدة المعالجة المركزية)، فمن المحتمل أن يتطلب حمل العمل الخاص بك المزيد من موارد الحوسبة، ما يتطلب منك زيادة عدد وحدات الدفق. من الأفضل الاحتفاظ بمقياس SU أقل من 80٪ من أجل حساب الارتفاعات العرضية. للرد على أحمال العمل المتزايدة وزيادة وحدات الدفق، ضع في اعتبارك أنه يجب تعيين تنبيه بنسبة 80٪ على مقياس استخدام SU. يمكنك أيضًا استخدام مقاييس تأخير العلامة المائية والأحداث المتراكمة من أجل معرفة ما إذا كان هناك تأثير.

يجب تكوين وحدات دفق Stream Analytics (SUs)

  1. سجل الدخول إلى مدخل Microsoft Azure.

  2. في قائمة الموارد، ابحث عن مهمة Stream Analytics التي تريد تحجيمها ثم افتحها.

  3. في صفحة المهمة، وضمن العنوان تكوين، حدد "Scale". العدد الافتراضي لوحدات SU هو 1 عند إنشاء وظيفة.

لقطة شاشة من القائمة في بوابة Azure Stream Analytics.

  1. اختر خيار SU في القائمة المنسدلة لتعيين وحدات الوظيفة المطلوبة. أنت محدود بنطاق معين من SU.

  2. يمكنك تغيير عدد وحدات SUs المعينة إلى وظيفتك أثناء تشغيلها. قد تكون مقيدا بالاختيار من بين مجموعة من قيم SU أثناء تشغيل الوظيفة إذا كانت وظيفتك تستخدم مخرجا غير مقسما أو تحتوي على استعلام متعدد الخطوات بقيم PARTITION BY مختلفة.

عملية مراقبة أداء الوظيفة

باستخدام بوابة Azure، يمكنك تتبع مقاييس الأداء المتعلقة بالوظيفة. لمزيد من المعلومات حول تعريف المقاييس، راجع مقاييس وظائف Azure Stream Analytics. لمزيد من المعلومات حول مراقبة المقاييس في البوابة، راجع وظيفة تحليل التدفق المراقبة مع بوابة Azure.

لقطة شاشة لأداء وظيفة المراقبة.

قم بحساب معدل النقل المتوقع لحمل العمل. إذا كان معدل النقل أقل من المتوقع، فقم بضبط قسم الإدخال، واضبط الاستعلام، وأضف وحدات SUs إلى وظيفتك.

كم يبلغ عدد وحدات SUs المطلوبة لوظيفة؟

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

بشكل عام، ابدأ ب 1 SU V2 للاستفسارات التي لا تستخدم PARTITION BY. ثم ابحث عن أفضل رقم بالتجربة والخطأ. عدل عدد وحدات الوحدة بعد تمرير كميات البيانات الممثلة وفحص مقياس استخدام% الاتحاد. الحد الأقصى لعدد وحدات البث التي يمكن أن تستخدمها وظيفة تحليلات التدفق يعتمد على عدد الخطوات في الاستعلام المعرف للمهمة وعدد الأقسام في كل خطوة. يمكنك معرفة المزيد حول الحدود هنا .

لمزيد من المعلومات حول اختيار العدد المناسب من وحدات SU، راجع وظائف تحليل التدفق في Azure لزيادة معدل الإنتاجية.

إشعار

عدد وحدات SU التي تحتاجها الوظيفة يعتمد على تكوين القسم للمدخلات وعلى الاستعلام الذي تحدده للوظيفة. يُمكنك تحديد ما يصل إلى الحصة النسبية في وحدات SUs لوظيفة. للحصول على معلومات حول حصة اشتراك Azure Stream Analytics، تفضل بزيارة حدود Stream Analytics. لزيادة وحدات SUs لاشتراكاتك بما يتجاوز هذه الحصة النسبية، قم بالاتصال بدعم Microsoft. القيم الصالحة لوحدات SUs لكل مهمة هي 1/3 و2/3 و1 و2 و3 وما إلى ذلك.

العوامل التي تزيد من استخدام SU٪

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

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

يمكن أن تؤدي الأخطاء المؤقتة أو الترقيات التي تبدأ النظام إلى انخفاض استخدام% SU فجأة إلى الصفر لفترة قصيرة قبل العودة إلى المستويات المتوقعة. قد لا تؤدي زيادة عدد وحدات الدفق لوظيفة ما إلى تقليل استخدام SU٪ إذا لم يكن الاستعلام متوازياً تماماَ.

عند مقارنة الاستخدام على مدى فترة زمنية، استخدم مقاييس معدل الأحداث. تظهر مقاييس InputEvents و OutputEvents عدد الأحداث التي تم قراءتها ومعالجتها. تشير مقاييس مثل أخطاء إلغاء التسلسل إلى عدد أحداث الخطأ. عندما يزداد عدد الأحداث لكل وحدة زمنية، تزداد SU٪ في معظم الحالات.

منطق الاستعلام ذو الحالة في العناصر الزمنية

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

يظهر مفهوم النافذة الزمنية في العديد من عناصر استعلام Stream Analytics:

  1. تجمعات النوافذ: GROUP BY من نوافذ متقلبة، قفز، ونوافذ منزلقة

  2. الوصلات الزمنية: JOIN مع DATEDIFF وظيفة

  3. الدوال التحليلية الزمنية: ISFIRST، LAST، و LAG مع LIMIT DURATION

تؤثر العوامل التالية على الذاكرة المستخدمة (جزء من وحدات البث المترية) بواسطة وظائف Stream Analytics:

التجميعات التي وضعت في نافذة

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

على سبيل المثال، فيما يتعلق بالاستعلام التالي، الرقم المقترن clusterid هو العلاقة الأساسية للاستعلام. 

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

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

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

بمجرد تقسيم الاستعلام، يتم توزيعه على عدة عقد. نتيجة لذلك، يقل عدد القيم clusterid الواردة إلى كل عقدة، مما يقلل من عدد القيم العددية للمؤثر GROUP BY . 

قم بتقسيم مراكز الأحداث باستخدام مفتاح التجميع لتجنب الحاجة إلى خطوة تقليل. لمزيد من المعلومات، راجع Event Hubs المتميزة. 

الصلات الزمنية

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

عدد الأحداث غير المتطابقة في الانضمام يؤثر على استخدام الذاكرة للاستعلام. الاستعلام التالي يبحث عن ظهور الإعلانات التي تولد النقرات:

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

في هذا المثال، من الممكن أن تعرض الكثير من الإعلانات وقليل من الناس ينقرون عليها. يجب أن تبقي جميع الأحداث في نافذة زمنية. الذاكرة المستهلكة مُتناسبة مع حجم النافذة ومعدل الحدث. 

لمعالجة هذا السلوك، أرسل الأحداث إلى مراكز الأحداث مقسمة بواسطة مفاتيح الربط (المعرف في هذه الحالة)، وقم بتوسيع الاستعلام عن طريق السماح للنظام بمعالجة كل قسم إدخال بشكل منفصل باستخدام PARTITION BY كما هو موضح:

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10 

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

الدوال التحليلية الزمنية

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

المعالجة مُشابهة للصلة الزمنية. يمكنك توسيع نطاق الاستعلام باستخدام PARTITION BY. 

المخزن المؤقت خارج الترتيب

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

لمعالجة تجاوز سعة المخزن المؤقت خارج الترتيب، يجب توسيع الاستعلام باستخدام PARTITION BY. بمجرد تقسيم الاستعلام، يتم توزيعه عبر عقد متعددة. ونتيجة لذلك، يتم تقليل عدد الأحداث الواردة إلى كل عقدة ومن ثمّ تقليل عدد الأحداث في كل مخزن مؤقت من أجل إعادة الطلب. 

عدد أقسام الإدخال

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

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

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

البيانات المرجعية

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

يجب استخدام دالات UDF

عند إضافة دالة UDF، يقوم Azure Stream Analytics بتحميل وقت تشغيل JavaScript في الذاكرة، ما يؤثر على SU٪.

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

  • Last updated on