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

مقالة
01/02/2024

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

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

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

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

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

طاقة الحوسبة الأساسية لوحدات تدفق V1 وV2 هي كما يلي:

SU V1 and SU V2 mapping.

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

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

هناك تحويل تلقائي لوحدات البث الذي يحدث من طبقة REST API إلى واجهة المستخدم (مدخل Microsoft Azure وVisual Studio Code). ستلاحظ هذا التحويل في سجل النشاط أيضا حيث تظهر قيم SU مختلفة عن القيم الموجودة في واجهة المستخدم. هذا حسب التصميم والسبب في ذلك هو أن حقول REST API تقتصر على قيم عدد صحيح ووظائف ASA تدعم العقد الكسرية (وحدات دفق 1/3 و2/3). تعرض واجهة مستخدم ASA قيم العقدة 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
...	...	...

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

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

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

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

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

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

screen shot of menu on ASA portal.

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

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

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

Screenshot of monitor job performance.

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

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

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

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

لمزيد من المعلومات حول اختيار العدد الصحيح من وحدات SUs، راجع هذه الصفحة: تغيير حجم وظائف Azure Stream Analytics لزيادة معدل النقل.

إشعار

يعتمد اختيار عدد وحدات SUs المطلوبة فيما يتعلق بوظيفة معينة على تكوين القسم للمدخلات وعلى الاستعلام المحدد للوظيفة. يُمكنك تحديد ما يصل إلى الحصة النسبية في وحدات 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٪ فجأة إلى 0 لفترة قصيرة قبل العودة إلى المستويات المتوقعة. يحدث هذا نتيجة لأخطاء عابرة أو ترقيات بدأها النظام. قد لا تؤدي زيادة عدد وحدات الدفق لوظيفة ما إلى تقليل استخدام SU٪ إذا لم يكن الاستعلام متوازياً تماماَ.

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

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

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

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

التجميع المغطى بالرياح: GROUP BY من النوافذ المتدحرجة والقفز والانزلاق
صلات مؤقتة: الانضمام مع وظيفة DATEDIFF
الوظائف التحليلية الزمنية: ISFIRST وLAST وLAG بمدة محدودة

تؤثر العوامل التالية على الذاكرة المستخدمة (جزء من وحدات البث المترية) بواسطة وظائف 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 القيم الواردة إلى كل عقدة ومن ثمّ تقليل العلاقة الأساسية للمجموعة وفقًا لعامل التشغيل.

يجب تقسيم أقسام مراكز الأحداث بواسطة مفتاح التجميع من أجل تجنب الحاجة إلى خطوة تقليل. لمزيد من المعلومات، راجع 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 مع عدد الأقسام في مركز الأحداث الخاص بك.

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

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

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

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

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

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

Share via