استخدام توازي الاستعلام في Azure Stream Analytics

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

كشرط أساسي، قد ترغب في أن تكون على دراية بمفهوم وحدة البث الموضحة في فهم وحدات الدفق وضبطها.

ما هي أجزاء وظيفة Stream Analytics؟

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

الأقسام في الإدخالات والمخرجات

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

الإدخالات

يمكن لجميع مدخلات دفق Azure Stream Analytics الاستفادة من التقسيم: مراكز الأحداث، مركز IoT، تخزين Blob، Data Lake Storage Gen2.

إشعار

بالنسبة لمستوى التوافق 1.2 وما فوق، اضبط مفتاح القسم كخاصية إدخال، دون الحاجة إلى كلمة PARTITION BY في الاستعلام. بالنسبة لمستوى التوافق 1.1 وما بعده، حدد مفتاح التقسيم باستخدام الكلمة المفتاحية PARTITION BY في الاستعلام.

المخرجات

عند العمل مع Stream Analytics، استفد من تقسيم المخرجات التالية:

  • Azure Data Lake Storage Gen2
  • دالات Azure
  • جداول Azure
  • تخزين الكتلة (تعيين مفتاح القسم بشكل صريح)
  • Azure Cosmos DB (set the partition key بشكل صريح)
  • Event Hubs (تعيين مفتاح القسم بشكل صريح)
  • IoT Hub (قم بتعيين مفتاح القسم بشكل صريح)
  • ناقل الخدمة
  • SQL وAzure Synapse Analytics مع التقسيم الاختياري: راجع المزيد من المعلومات في صفحة الإخراج إلى قاعدة بيانات Azure SQL.

لا يدعم Power BI التقسيم. ومع ذلك، لا يزال بإمكانك تقسيم المدخل كما هو موضح في هذا القسم.

لمزيد من المعلومات حول التقسيم، راجع المقالات التالية:

الاستعلام

لكي تكون الوظيفة متوازية، يجب محاذاة مفاتيح الأقسام بين جميع المدخلات، وجميع خطوات منطق الاستعلام، وجميع المخرجات. يتم تحديد تقسيم منطق الاستعلام بواسطة المفاتيح المستخدمة للصلات والتجميعات (GROUP BY). يمكن تجاهل المطلب الأخير إذا لم يكن منطق الاستعلام مفتاحا (الإسقاط، عوامل التصفية، الصلات المرجعية...).

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

تكون الوظيفة متوازية فقط عندما تستخدم جميع المدخلات والمخرجات وخطوات الاستعلام نفس المفتاح.

وظائف موازية بشكل مثالي

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

  • إذا كان منطق الاستعلام لديك يعتمد على نفس المفتاح الذي تتم معالجته بواسطة نفس مثيل الاستعلام، يجب التأكد من أن الأحداث تنتقل إلى نفس قسم الإدخال الخاص بك. بالنسبة ل Event Hubs أو IoT Hub، فهذا يعني أن بيانات الحدث يجب أن تحتوي على مجموعة قيمة PartitionKey . بدلاً من ذلك، يمكنك استخدام المرسلين المقسمين. لتخزين الكائن الثنائي كبير الحجم، مما يعني أن الأحداث يتم إرسالها إلى نفس مجلد القسم. مثال على ذلك هو مثيل استعلام يجمع البيانات لكل userID حيث يتم تقسيم مركز أحداث الإدخال باستخدام userID كمفتاح تقسيم. ومع ذلك، إذا كان منطق الاستعلام الخاص بك لا يتطلب معالجة نفس المفتاح بواسطة نفس مثيل الاستعلام، يمكنك تجاهل هذا المطلب. مثال على هذا المنطق هو استعلام بسيط لتصفية تحديد المشروع.

  • بعد ذلك، اجعل استعلامك مقسما. بالنسبة للوظائف التي لديها مستوى توافق 1.2 أو أعلى (موصى به)، حدد عمودا مخصصا كمفتاح القسم في إعدادات الإدخال وتصبح المهمة متوازية تلقائيا. بالنسبة للوظائف التي تحتوي على مستوى توافق 1.0 أو 1.1، استخدم PARTITION BY PartitionId في جميع خطوات استفسارك. يمكنك أن يكون لديك عدة خطوات، لكن يجب أن تكون كلها مقسمة بنفس المفتاح.

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

  • يجب أن يساوي عدد أقسام الإدخال عدد أقسام الإخراج. يمكن أن يدعم إخراج تخزين الكائنات الثنائية كبيرة الحجم الأقسام ويرث نظام التقسيم للاستعلام المصدر. عندما تحدد مفتاح تقسيم لتخزين Blob، يتم تقسيم البيانات لكل قسم إدخال، وبالتالي تظل النتيجة متوازية بالكامل. فيما يلي أمثلة على قيم التقسيم التي تسمح بمهمة متوازية تماماً:

    • ثمانية أقسام لإدخال مركز الحدث وثمانية أقسام لإخراج مركز الحدث
    • ثمانية أقسام لإدخال مركز الحدث وإخراج تخزين الكائنات الثنائية كبيرة الحجم
    • ثمانية أقسام لإدخال مركز الحدث وإخراج تخزين الكائنات الثنائية كبيرة الحجم مقسمة حسب حقل مخصص مع علاقة أساسية عشوائية
    • ثمانية أقسام لإدخال تخزين الكائنات الثنائية كبيرة الحجم وإخراج تخزين الكائنات الثنائية كبيرة الحجم
    • ثمانية أقسام لإدخال تخزين الكائنات الثنائية كبيرة الحجم وثمانية أقسام لإخراج مركز الحدث

تناقش الأقسام التالية بعض أمثلة السيناريوهات المتوازية بشكل مثالي.

استعلام نموذجي

  • الإدخال: مركز أحداث مع ثمانية أقسام
  • الإخراج: يجب تعيين مركز أحداث يحتوي على ثمانية أقسام ("عمود مفتاح القسم" لاستخدام PartitionId)

الاستعلام:

    --Using compatibility level 1.2 or above
    SELECT TollBoothId
    FROM Input1
    WHERE TollBoothId > 100
    
    --Using compatibility level 1.0 or 1.1
    SELECT TollBoothId
    FROM Input1 PARTITION BY PartitionId
    WHERE TollBoothId > 100

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

الاستعلام باستخدام مفتاح تجميع

  • الإدخال: مركز الأحداث مع ثمانية أقسام
  • الإخراج: تخزين الكائنات الثنائية كبيرة الحجم

الاستعلام:

    --Using compatibility level 1.2 or above
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId
    
    --Using compatibility level 1.0 or 1.1
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

يحتوي هذا الاستعلام على مفتاح تجميع. لذلك، يجب إرسال الأحداث المجمعة معاً إلى نفس قسم مراكز الأحداث. بما أنك في هذا المثال تقوم بتجميع حسب TollBoothID، يجب أن تتأكد من استخدامه TollBoothID كمفتاح تقسيم عند إرسال الأحداث إلى Event Hubs. ثم في Azure Stream Analytics، يمكنك استخدام PARTITION BY PartitionId للتوارث من نظام التقسيم هذا وتمكين التوازي الكامل. بما أن المخرج هو تخزين blob، فلا داعي للقلق بشأن تكوين قيمة مفتاح القسم، كما هو مطلوب #4.

مثال على السيناريوهات التي ليست متوازية بشكل محرج*

في القسم السابق، غطت المقالة بعض السيناريوهات المتوازية بشكل محرج. في هذا القسم، ستتعرف على السيناريوهات التي لا تلبي جميع المتطلبات لتكون متوازية بشكل محرج.

عدد الأقسام غير المتطابقة

  • الإدخال: مركز أحداث مع ثمانية أقسام
  • الإخراج: مركز أحداث به 32 قسما

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

الاستعلام باستخدام الإخراج غير المقسم

  • الإدخال: مركز أحداث مع ثمانية أقسام
  • الإخراج: Power BI

لا يدعم إخراج Power BI التقسيم حالياً. لذلك، هذا السيناريو ليس موازياً بشكل مثالي.

استعلام متعدد الخطوات بقيم PARTITION BY مختلفة

  • الإدخال: مركز الأحداث مع ثمانية أقسام
  • الإخراج: مركز الأحداث مع ثمانية أقسام
  • مستوى التوافق: 1.0 أو 1.1

الاستعلام:

    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 Partition By TollBoothId
    GROUP BY TumblingWindow(minute, 3), TollBoothId

كما ترى، تستخدم الخطوة الثانية TollBoothId كمفتاح التقسيم. هذه الخطوة ليست هي نفسها الخطوة الأولى، ولذلك تتطلب خلطا في المرحلة.

استعلام متعدد الخطوات بقيم PARTITION BY مختلفة

  • الإدخال: مركز الأحداث مع ثمانية أقسام ("عمود مفتاح التقسيم" غير معين، الافتراضي إلى "PartitionId")
  • الإخراج: مركز الأحداث مع ثمانية أقسام (يجب تعيين "عمود مفتاح التقسيم" لاستخدام "TollBoothId")
  • مستوى التوافق - 1.2 أو أعلى

الاستعلام:

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

    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1
    GROUP BY TumblingWindow(minute, 3), TollBoothId

يتيح مستوى التوافق 1.2 أو أعلى تنفيذ الاستعلام المتوازي بشكل افتراضي. على سبيل المثال، يتم تقسيم الاستعلام من القسم السابق طالما أن عمود "TollBoothId" مضبوط كمفتاح تقسيم مدخل. عبارة PARTITION BY PartitionId ليست مطلوبة.

حساب الحد الأقصى لوحدات الدفق لأي وظيفة

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

الخطوات في استعلام

يمكن أن يكون للاستعلام خطوة واحدة أو عدة خطوات. كل خطوة هي استعلام فرعي محدد بواسطة الكلمة الأساسية WITH. يتم أيضاً حساب الاستعلام خارج الكلمة الأساسية WITH (استعلام واحد فقط) كخطوة، مثل عبارة SELECT في الاستعلام التالي:

الاستعلام:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        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

يحتوي هذا الاستعلام على خطوتين.

إشعار

تمت مناقشة هذا الاستعلام بمزيد من التفصيل لاحقاً في المقالة.

تقسيم خطوة

يتطلب تقسيم خطوة الشروط التالية:

  • يجب تقسيم مصدر الإدخال.
  • يجب قراءة عبارة SELECT للاستعلام من مصدر إدخال مقسم.
  • يجب أن يحتوي الاستعلام داخل الخطوة على الكلمة الأساسية PARTITION BY.

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

حساب الحد الأقصى لوحدات الدفق لوظيفة

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

الاستعلام الحد الأقصى لوحدات SUs للوظيفة
  • يحتوي الاستعلام على خطوة واحدة.
  • الخطوة غير مقسمة.
 1 SU V2
  • يتم تقسيم دفق بيانات الإدخال على 16.
  • يحتوي الاستعلام على خطوة واحدة.
  • تم تقسيم الخطوة.
 16 SU V2 (1 * 16 قسما)
  • يحتوي الاستعلام على خطوتين.
  • لم يتم تقسيم أي من الخطوات.
 1 SU V2
  • يتم تقسيم دفق بيانات الإدخال على 3.
  • يحتوي الاستعلام على خطوتين. يتم تقسيم خطوة الإدخال والخطوة الثانية ليست كذلك.
  • تقرأ عبارة SELECT من الإدخال المقسم.
 4 وحدات SU V2 (3 للخطوات المقسمة + 1 للخطوات غير المقسمة)

أمثلة على التحجيم

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

    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

لاستخدام المزيد من وحدات البيانات في الاستعلام، قم بتقسيم كل من تدفق بيانات الإدخال والاستعلام. نظرا لتعيين قسم دفق البيانات إلى 3، يمكن توسيع نطاق الاستعلام المعدل التالي حتى 3 SU V2s:

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

عند تقسيم استعلام، تتم معالجة أحداث الإدخال وتجميعها في مجموعات تقسيم منفصلة. يقوم الاستعلام بتوليد أحداث الإخراج لكل مجموعة. يمكن أن يؤدي التقسيم إلى بعض النتائج غير المتوقعة عندما لا يكون حقل GROUP BY هو مفتاح التقسيم في دفق بيانات الإدخال. على سبيل المثال، الحقل TollBoothId في الاستعلام السابق ليس هو مفتاح تقسيم Input1. والنتيجة أن البيانات من TollBooth #1 يمكن نشرها عبر عدة أقسام.

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

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        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

يمكنك توسيع هذا الاستعلام إلى 4 وحدات SU V2.

إشعار

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

تحقيق معدل نقل أعلى على نطاق واسع

وظيفة متوازية بشكل مثالي ضرورية ولكنها ليست كافية للحفاظ على معدل نقل أعلى على نطاق واسع. يحتوي كل نظام تخزين، ومخرجات Stream Analytics المقابلة له، على اختلافات حول كيفية تحقيق أفضل معدل نقل ممكن للكتابة. كما هو الحال مع أي سيناريو على نطاق واسع، تتطلب بعض التحديات التكوينات المناسبة لحلها. يناقش هذا القسم التكوينات لبعض المخرجات الشائعة ويوفر عينات للحفاظ على معدلات الاستيعاب من 1 K و5 K و10 K في الثانية.

تستخدم الملاحظات التالية وظيفة Stream Analytics مع استعلام عديم الحالة (passthrough)، أو دالة أساسية معرفة من قبل مستخدم JavaScript (UDF) تكتب إلى مراكز الأحداث أو Azure SQL أو Azure Cosmos DB.

مراكز الأحداث

معدل الاستيعاب (الأحداث في الثانية) وحدات الدفق موارد الإخراج
1 كيلو 1/3 2 TU
5 كيلو 1 6 TU
10 آلاف 2 10 TU

يتوسع حل مراكز الأحداث خطياً من حيث وحدات الدفق (SU) ومعدل النقل، مما يجعله الطريقة الأكثر كفاءة وأداء لتحليل البيانات ودفقها من Stream Analytics. يمكنك توسيع الوظائف حتى 66 وحدة SU V2، مما يعني تقريبا معالجة ما يصل إلى 400 ميجابايت/ثانية، أو 38 تريليون حدث يوميا.

عنوان SQL لـ Azure

معدل الاستيعاب (الأحداث في الثانية) وحدات الدفق موارد الإخراج
1 كيلو 2/3 S3
5 كيلو 3 P4
10 آلاف 6 P6

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

Azure Cosmos DB

معدل الاستيعاب (الأحداث في الثانية) وحدات الدفق موارد الإخراج
1 كيلو 2/3 20 كيلو بايت من وحدات الطلب
5 كيلو 4 60 كيلو بايت روبل
10 آلاف 8 120 كيلووات من وحدات الطلب

تم تحديث مخرجات Azure Cosmos DB من تحليلات التدفق لاستخدام التكامل الأصلي تحت مستوى compatibility 1.2. يتيح مستوى التوافق 1.2 معدل نقل أعلى بكثير ويقلل من استهلاك وحدة الطلب مقارنة بالمستوى 1.1، وهو مستوى التوافق الافتراضي للوظائف الجديدة. يستخدم الحل حاويات Azure Cosmos DB المقسمة على /deviceId ويتم تكوين بقية الحل بشكل متطابق.

تستخدم جميع عينات Azure للدفق على نطاق واسع مراكز الأحداث كإدخال يتم تغذيته من خلال عملاء اختبار محاكاة التحميل. كل حدث إدخال هو مستند JSON 1 كيلوبايت، والذي يترجم معدلات الاستيعاب المكونة إلى معدلات النقل (1 ميغابايت/ثانية و5 ميغابايت/ثانية و10 ميغابايت/ثانية) بسهولة. تحاكي الأحداث جهاز IoT يرسل بيانات JSON التالية (في شكل مختصر) لما يصل إلى 1000 جهاز:

{
    "eventId": "b81d241f-5187-40b0-ab2a-940faf9757c0",
    "complexData": {
        "moreData0": 51.3068118685458,
        "moreData22": 45.34076957651598
    },
    "value": 49.02278128887753,
    "deviceId": "contoso://device-id-1554",
    "type": "CO2",
    "createdAt": "2019-05-16T17:16:40.000003Z"
}

إشعار

تخضع التكوينات للتغيير بسبب المكونات المختلفة المستخدمة في الحل. للحصول على تقدير أكثر دقة، قم بتخصيص العينات لتناسب السيناريو الخاص بك.

تحديد الاختناقات

استخدم جزء "المقاييس" في مهمة Stream Analytics لتحديد الازدحامات في البنية الأساسية الخاصة بك. راجع أحداث الإدخال/الإخراج لمعدل النقل و "تأخير العلامة المائية" أو الأحداث المتراكمة لمعرفة ما إذا كانت المهمة تواكب معدل الإدخال. بالنسبة لمقاييس مراكز الأحداث، ابحث عن الطلبات المقيدة واضبط وحدات الحد وفقاً لذلك. بالنسبة لمقاييس Azure Cosmos DB، راجع الحد الأقصى المستهلك ل RU/s لكل نطاق مفتاح قسم ضمن معدل النقل لضمان استهلاك نطاقات مفاتيح القسم بشكل موحد. بالنسبة إلى قاعدة بيانات Azure SQL، راقب إدخال/إخراج السجل و CPU.

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

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

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

  • Last updated on