مشاركة عبر

تغيير حجم مهمة Azure Stream Analytics لزيادة معدل النقل

  • مقالة

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

كمتطلب أساسي، اقرأ المقالات التالية:

الحالة 1 - استعلامك قابل للتوازي تماماً بطبيعته عبر أقسام الإدخال

إذا كان الاستعلام الخاص بك قابلاً للتوازي تماماً بطبيعته عبر أقسام الإدخال، يمكنك اتباع الخطوات التالية:

  • تأليف استعلامك ليكون متوازياً بشكل مربك باستخدام الكلمة الأساسية PARTITION BY. لمزيد من المعلومات، راجع استخدام توازي الاستعلام في Azure Stream Analytics.
  • اعتمادا على أنواع الإخراج المستخدمة في الاستعلام الخاص بك، يمكن أن تكون بعض المخرجات إما غير قابلة للتوازي، أو تحتاج إلى مزيد من التكوين لتكون متوازية بشكل محرج. على سبيل المثال، إخراج Power BI غير قابل للتوازي. دائماً ما يتم دمج المخرجات قبل إرسالها إلى متلقي الإخراج. يتم موازاة الكائنات الثنائية كبيرة الحجم والجداول وAzure Data Lake Storage ونقل الخدمة وAzure Function تلقائيا. تحتوي مخرجات SQL وAzure Synapse Analytics على خيار للتوازي. يحتاج مركز الأحداث إلى تعيين تكوين PartitionKey لمطابقة حقل PARTITION BY (عادة PartitionId). بالنسبة لمراكز الأحداث، انتبه أيضا لمطابقة عدد الأقسام لجميع المدخلات وجميع المخرجات لتجنب التقاطع بين الأقسام.
  • قم بتشغيل الاستعلام باستخدام وحدة دفق واحدة (SU) V2 (وهي السعة الكاملة لعقدة حوسبة واحدة) لقياس الحد الأقصى لمعدل النقل القابل للتحقيق، وإذا كنت تستخدم GROUP BY، فقم بقياس عدد المجموعات (العلاقة الأساسية) التي يمكن للوظيفة التعامل معها. فيما يلي الأعراض العامة للمهمة التي تصل إلى حدود موارد النظام.
    • قياس استخدام وحدة الدفق (SU) ٪ أكثر من 80٪. يشير إلى أن استخدام الذاكرة مرتفع. يتم وصف العوامل المساهمة في زيادة هذا المقياس فهم وحدات دفق Stream Analytics وضبطها.
    • يتخلف الطابع الزمني للإخراج بالنسبة لوقت ساعة الحائط. اعتمادا على منطق الاستعلام الخاص بك، يمكن أن يحتوي الطابع الزمني للإخراج على إزاحة منطق من وقت ساعة الحائط. ومع ذلك، ينبغي أن تتقدم بنفس المعدل تقريباً. إذا كان الطابع الزمني للإخراج يتراجع أكثر فأكثر، فهذا مؤشر على أن النظام يعمل بشكل زائد. يمكن أن ينتج هذا عن تقييد متلقي إخراج المصب، أو الاستخدام العالي لوحدة المعالجة المركزية. لا نقدم مقياس استخدام وحدة المعالجة المركزية في الوقت الحالي، لذلك قد يكون من الصعب التمييز بين الاثنين.
      • إذا كانت المشكلة بسبب تقييد المتلقي، فأنت بحاجة إلى زيادة عدد أقسام الإخراج (وكذلك أقسام الإدخال للحفاظ على المهمة قابلة للتوازي تماما)، أو زيادة مقدار موارد المتلقي (على سبيل المثال عدد وحدات الطلب ل Cosmos DB).
    • في الرسم التخطيطي للوظيفة، هناك مقياس حدث تراكم لكل قسم لكل إدخال. إذا استمر مقياس حدث التراكم في الزيادة، فهو أيضاً مؤشر على أن مورد النظام مقيد (إما بسبب تقييد متلقي الإخراج، أو وحدة المعالجة المركزية العالية).
  • بمجرد تحديد حدود ما يمكن أن تصل إليه وظيفة SU V2 واحدة، يمكنك استقراء سعة المعالجة للوظيفة خطيا أثناء إضافة المزيد من وحدات SUs، على افتراض أنه ليس لديك أي انحراف في البيانات يجعل قسم معين "ساخنا".

إشعار

اختر العدد الصحيح من وحدات الدفق: نظرا لأن Stream Analytics ينشئ عقدة معالجة لكل وحدة SU V2 مضافة، فمن الأفضل جعل عدد العقد مقسما لعدد أقسام الإدخال، بحيث يمكن توزيع الأقسام بالتساوي عبر العقد. على سبيل المثال، قمت بقياس وظيفة 1 SU V2 يمكن أن تحقق معدل معالجة 4 ميغابايت/ ثانية، وعدد أقسام الإدخال الخاص بك هو 4. يمكنك اختيار تشغيل وظيفتك باستخدام 2 SU V2s لتحقيق معدل معالجة 8 ميغابايت/ثانية تقريبا، أو 4 وحدات SU V2s لتحقيق 16 ميغابايت/ثانية. يمكنك بعد ذلك تحديد وقت زيادة عدد وحدات SU للمهمة، كدالة لمعدل الإدخال الخاص بك.

الحالة 2 - إذا لم يكن استعلامك متوازيا بشكل محرج.

إذا لم يكن الاستعلام متوازيا بشكل محرج، يمكنك اتباع هذه الخطوات.

  • ابدأ باستعلام بدون PARTITION BY أولا لتجنب تعقيد التقسيم، وقم بتشغيل الاستعلام الخاص بك مع 1 SU V2 لقياس الحد الأقصى للتحميل كما هو الحال في الحالة 1.
  • إذا كان بإمكانك تحقيق الحمل المتوقع على مدى معدل النقل، فستنتهي. بدلا من ذلك، يمكنك اختيار قياس نفس المهمة التي تعمل مع العقد الكسرية في 2/3 SU V2 و1/3 SU V2، لمعرفة الحد الأدنى لعدد وحدات الدفق التي تعمل للسيناريو الخاص بك.
  • إذا لم تتمكن من تحقيق معدل النقل المطلوب، فحاول تقسيم الاستعلام إلى خطوات متعددة إذا لم يكن لديه خطوات متعددة بالفعل، وخصص ما يصل إلى SU V2 واحد لكل خطوة في الاستعلام. على سبيل المثال، إذا كان لديك ثلاث خطوات، فخصص ثلاثة SU V2s في خيار "Scale".
  • لتشغيل مثل هذه المهمة، يضع Stream Analytics كل خطوة على العقدة الخاصة بها مع مورد SU V2 واحد مخصص.
  • إذا لم تحقق هدف التحميل بعد، يمكنك محاولة استخدام PARTITION BY بدءاً من الخطوات الأقرب إلى الإدخال. بالنسبة إلى عامل تشغيل GROUP BY غير القابل للتقسيم بشكل طبيعي، يمكنك استخدام النمط التجميعي المحلي/العمومي لتنفيذ GROUP BY مقسم متبوعا ب GROUP BY غير مقسمة. على سبيل المثال، إذا كنت تريد حساب عدد السيارات التي تمر عبر كل كشك رسوم كل 3 دقائق، وحجم البيانات يتجاوز ما يمكن معالجته بواسطة SU V2 واحد.

الاستعلام:

WITH Step1 AS (
SELECT COUNT(*) AS Count, TollBoothId, PartitionId
FROM Input1 Partition By PartitionId
GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
)
SELECT SUM(Count) AS Count, TollBoothId
FROM Step1
GROUP BY TumblingWindow(minute, 3), TollBoothId

في الاستعلام، تقوم بحساب السيارات لكل كشك رسوم لكل قسم، ثم تضيف العدد من جميع الأقسام معا.

بمجرد التقسيم، لكل قسم من الخطوة، قم بتخصيص SU V2 واحد بحيث يمكن وضع كل قسم على عقدة المعالجة الخاصة به.

إشعار

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

الحالة 3 - تقوم بتشغيل الكثير من الاستعلامات المستقلة في وظيفة.

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

في هذه الحالة، يمكنك اتباع هذه الخطوات.

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

إشعار

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

الحصول على المساعدة

لمزيد من المساعدة، جرب صفحة سؤال Microsoft Q&A الخاصة بنا ل Azure Stream Analytics.

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