مشاركة عبر

استخدام توازي الاستعلام في 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 (تحتاج إلى تعيين مفتاح القسم بشكل صريح)
  • مراكز الأحداث (تحتاج إلى تعيين مفتاح التقسيم بشكل صريح)
  • مركز IoT (تحتاج إلى تعيين مفتاح التقسيم بشكل صريح)
  • ناقل الخدمة
  • 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 الاستفادة من التقسيم. إذا كنت تستخدم نوع إخراج لا يدعم التقسيم، فإن وظيفتك لن تكون متوازية بشكل مثالي. بالنسبة إلى إخراج مراكز الأحداث، تأكد من تعيين عمود مفتاح التقسيم⁧ إلى نفس مفتاح التقسيم⁧ المستخدم في الاستعلام. لمزيد من المعلومات، راجع قسم الإخراج.

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

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

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

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

  • الإدخال: مركز أحداث مع ثمانية أقسام
  • الإخراج: يجب تعيين مركز أحداث يحتوي على ثمانية أقسام ("عمود مفتاح القسم" لاستخدام 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 يتم استخدامه كمفتاح القسم عند إرسال الأحداث إلى مراكز الأحداث. ثم في Azure Stream Analytics، يمكنك استخدام PARTITION BY PartitionId للتوارث من نظام التقسيم هذا وتمكين التوازي الكامل. نظراً لأن الإخراج هو تخزين الكائنات الثنائية كبيرة الحجم، فلا داعي للقلق بشأن تكوين قيمة مفتاح التقسيم، وفقاً للمتطلب رقم 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 غير مطلوبة.

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

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

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

يمكن أن يكون للاستعلام خطوة واحدة أو عدة خطوات. كل خطوة هي استعلام فرعي محدد بواسطة الكلمة الأساسية 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) لوظيفة Stream Analytics. بالإضافة إلى ذلك، يمكنك إضافة SU V2 واحد لكل قسم في خطوة مقسمة. يمكنك مشاهدة بعض الأمثلة في الجدول التالي.

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

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

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

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

لاستخدام المزيد من وحدات SUs للاستعلام، يجب تقسيم كل من دفق بيانات الإدخال والاستعلام. نظرا لتعيين قسم دفق البيانات إلى 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 بشكل منفصل بواسطة Stream Analytics. ونتيجة لذلك، سيتم إنشاء سجلات متعددة لعدد السيارات لنفس مقر التحصيل في نفس نافذة الإسقاط. إذا تعذر تغيير مفتاح قسم الإدخال، يمكن إصلاح هذه المشكلة عن طريق إضافة خطوة غير تقسيمية لتجميع القيم عبر الأقسام، كما في المثال التالي:

    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 V2s.

إشعار

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

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

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

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

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

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

يتوسع حل مراكز الأحداث خطياً من حيث وحدات الدفق (SU) ومعدل النقل، مما يجعله الطريقة الأكثر كفاءة وأداء لتحليل البيانات ودفقها من Stream Analytics. يمكن توسيع نطاق الوظائف حتى 66 وحدة SU V2s، والتي تترجم تقريبا إلى معالجة تصل إلى 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 من Stream Analytics لاستخدام التكامل الأصلي ضمن مستوى التوافق 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.

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