الكشف عن الحالات الشاذة في Azure Stream Analytics
يتوفر Azure Stream Analytics في كل من السحابة وAzure IoT Edge، ويوفر قدرات المضمنة للكشف عن الحالات الشاذة المستندة إلى التعلم الآلي التي يمكن استخدامها لمراقبة الحالات الشاذة الأكثر شيوعًا: المؤقتة والمستمرة. باستخدام الدالتين AnomalyDetection_SpikeAndDipوAnomalyDetection_ChangePoint، يمكنك إجراء الكشف عن الشذوذ مباشرة في مهمة Stream Analytics.
تفترض نماذج التعلم الآلي وجود سلسلة زمنية تم أخذ عينات منها بشكل موحد. إذا لم تكن السلسلة الزمنية موحدة، يمكنك إدراج خطوة تجميع مع نافذة متقلبة قبل استدعاء الكشف عن الشذوذ.
لا تدعم عمليات التعلم الآلي اتجاهات الموسمية أو الارتباطات متعددة المتغيرات في هذا الوقت.
الكشف عن الحالات الشاذة باستخدام التعلم الآلي في Azure Stream Analytics
يوضح الفيديو التالي كيفية الكشف عن الحالات الشاذة في الوقت الفعلي باستخدام دوال التعلم الآلي في Azure Stream Analytics.
سلوك النموذج
بشكل عام، تتحسن دقة النموذج كلما زادت البيانات في النافذة المنزلقة. يتم التعامل مع البيانات الموجودة في النافذة المنزلقة المحددة كجزء من النطاق الطبيعي للقيم لهذا الإطار الزمني. لا يأخذ النموذج في الاعتبار إلا محفوظات الأحداث عبر النافذة المنزلقة للتحقق مما إذا كان الحدث الحالي شاذًا. أثناء انتقال النافذة المنزلقة، يتم استبعاد القيم القديمة من تدريب النموذج.
تعمل الوظائف من خلال إنشاء عادي معين استنادا إلى ما شاهدوه حتى الآن. يتم تحديد القيم الخارجية من خلال المقارنة مع الوضع الطبيعي المعمول به، ضمن مستوى الثقة. يجب أن يستند حجم النافذة إلى الحد الأدنى من الأحداث المطلوبة لتدريب النموذج على السلوك العادي حتى عند حدوث شذوذ، يمكن التعرف عليه.
يزيد وقت استجابة النموذج كامت ازداد حجم المحفوظات لأنه يحتاج إلى المقارنة مع عدد أكبر من الأحداث السابقة. نوصي بتضمين العدد الضروري فقط من الأحداث للحصول على أداء أفضل.
يمكن أن تكون الثغرات في السلسلة الزمنية نتيجة لعدم تلقي النموذج للأحداث في نقاط زمنية معينة. تتم معالجة هذا الموقف عن طريق Stream Analytics باستخدام منطق الإسناد. يتم استخدام حجم المحفوظات، بالإضافة إلى المدة الزمنية، لنفس النافذة المنزلقة لحساب المعدل المتوسط الذي يُتوقع وصول الأحداث إليه.
يمكن استخدام مُنشئ الشذوذ المتوفر هنا لتغذية مركز Iot بالبيانات ذات أنماط مختلفة من الحالات الشاذة. يمكن إعداد وظيفة Azure Stream Analytics باستخدام وظائف الكشف عن الحالات الشاذة هذه للقراءة من مركز Iot هذا واكتشاف الحالات الشاذة.
الارتفاع والانخفاض
تعرف الحالات الشاذة المؤقتة في دفق أحداث السلسلة الزمنية بالارتفاعات والانخفاضات. يمكن مراقبة الارتفاعات والانخفاضات باستخدام عامل التشغيل القائم على التعلم الآلي، AnomalyDetection_SpikeAndDip.
في نفس النافذة المنزلقة، إن كان الارتفاع الثاني أصغر من الأول، فمن المحتمل ألا تكون النتيجة المحسوبة للارتفاع الأصغر كبيرة بما يكفي مقارنة بدرجة الارتفاع الأول ضمن مستوى الثقة المحدد. يمكنك محاولة تقليل مستوى ثقة النموذج للكشف عن مثل تلك الحالات الشاذة. مع ذلك، إذا بدأت في تلقي تنبيهات كثيرة للغاية، يمكنك استخدام فاصل ثقة أعلى.
يفترض استعلام المثال التالي معدل إدخال موحد لحدث واحد في الثانية في نافذة منزلقة مدتها دقيقتان مع محفوظات بها 120 حدثًا. تستخرج عبارة SELECT النهائية وتخرج النتيجة وحالة الشذوذ بمستوى ثقة 95٪.
WITH AnomalyDetectionStep AS
(
SELECT
EVENTENQUEUEDUTCTIME AS time,
CAST(temperature AS float) AS temp,
AnomalyDetection_SpikeAndDip(CAST(temperature AS float), 95, 120, 'spikesanddips')
OVER(LIMIT DURATION(second, 120)) AS SpikeAndDipScores
FROM input
)
SELECT
time,
temp,
CAST(GetRecordPropertyValue(SpikeAndDipScores, 'Score') AS float) AS
SpikeAndDipScore,
CAST(GetRecordPropertyValue(SpikeAndDipScores, 'IsAnomaly') AS bigint) AS
IsSpikeAndDipAnomaly
INTO output
FROM AnomalyDetectionStep
نقطة التغيير
الحالات الشاذة المستمرة في دفق أحداث السلسلة الزمنية هي تغييرات في توزيع القيم في دفق الحدث، مثل تغييرات المستوى والاتجاهات. في Stream Analytics، يتم الكشف عن مثل هذه الحالات الشاذة باستخدام عامل التشغيل المستند إلى التعلم الآلي AnomalyDetection_ChangePoint.
تستمر التغييرات المستمرة لفترة أطول بكثير من الارتفاعات والانخفاضات ويمكن أن تشير إلى أحداث كارثية. لا تكون التغييرات المستمرة مرئية للعين المجردة عادة، ولكن يمكن اكتشافها باستخدام عامل التشغيل AnomalyDetection_ChangePoint .
الصورة التالية مثال على تغيير مستوى:
الصورة التالية مثال على تغيير الاتجاه:
يفترض الاستعلام المثال التالي معدل إدخال موحد لحدث واحد في الثانية في نافذة منزلقة مدتها 20 دقيقة بحجم محفوظات يبلغ 1200 حدث. تستخرج عبارة SELECT النهائية وتخرج النتيجة وحالة الشذوذ بمستوى ثقة 80٪.
WITH AnomalyDetectionStep AS
(
SELECT
EVENTENQUEUEDUTCTIME AS time,
CAST(temperature AS float) AS temp,
AnomalyDetection_ChangePoint(CAST(temperature AS float), 80, 1200)
OVER(LIMIT DURATION(minute, 20)) AS ChangePointScores
FROM input
)
SELECT
time,
temp,
CAST(GetRecordPropertyValue(ChangePointScores, 'Score') AS float) AS
ChangePointScore,
CAST(GetRecordPropertyValue(ChangePointScores, 'IsAnomaly') AS bigint) AS
IsChangePointAnomaly
INTO output
FROM AnomalyDetectionStep
الخصائص المتعلقة بالأداء
يعتمد أداء هذه النماذج على حجم المحفوظات ومدة النافذة وتحميل الحدث وما إذا كان يتم استخدام تقسيم مستوى الدالة أم لا. يناقش هذا القسم هذه التكوينات ويوفر عينات لكيفية الحفاظ على معدلات الاستيعاب من 1 K و5 K و10K في الثانية.
- حجم المحفوظات - تعمل هذه النماذج خطيًا مع حجم المحفوظات. كلما زاد حجم المحفوظات، زاد طول الوقت الذي تستغرقه النماذج لتسجيل حدث جديد. وذلك لأن النماذج تقارن الحدث الجديد مع كل حدث من الأحداث السابقة في المخزن المؤقت للمحفوظات.
- مدة النافذة - يجب أن تعكس مدة النافذة المدة التي تستغرقها لتلقي أكبر عدد من الأحداث كما هو محدد حسب حجم المحفوظات. بدون هذا العدد الكبير من الأحداث في النافذة، فإن Azure Stream Analytics سيحسب القيم المفقودة. ومن ثم، فإن استهلاك CPU هو دالة لحجم المحفوظات.
- تحميل الحدث - كلما كان تحميل الحدث أكبر، زاد العمل الذي تقوم به النماذج، ما يؤثر على استهلاك CPU. يمكن توسيع نطاق المهمة بجعلها متوازية بشكل مثالي، على افتراض أنه من المنطقي لمنطق تسلسل العمل استخدام المزيد من أقسام الإدخال.
- تقسيم مستوى الدالة - يتم تقسيم مستوى الدالة باستخدام
PARTITION BYداخل استدعاء دالة اكتشاف الحالات الشاذة. يضيف هذا النوع من التقسيم حملًا، إذ يجب الحفاظ على الحالة لنماذج متعددة في نفس الوقت. يتم استخدام تقسيم مستوى الدالة في سيناريوهات مثل تقسيم مستوى الجهاز.
العلاقة
يرتبط حجم المحفوظات ومدة النافذة وإجمالي تحميل الحدث بالطريقة التالية:
windowDuration (بالملي ثانية) = 1000 * historySize / (إجمالي أحداث الإدخال في الثانية / عدد أقسام الإدخال)
عند تقسيم الدالة حسب معرف الجهاز، أضف "PARTITION BY deviceId" إلى استدعاء دالة اكتشاف الحالات الشاذة.
الملاحظات
يتضمن الجدول التالي ملاحظات معدل النقل لعقدة واحدة (ستة SU) للحالة غير المضمنة:
| حجم المحفوظات (الأحداث) | مدة النافذة (مللي ثانية) | إجمالي أحداث الإدخال في الثانية |
|---|---|---|
| 60 | 55 | 2,200 |
| 600 | 728 | 1,650 |
| 6,000 | 10,910 | 1,100 |
يتضمن الجدول التالي ملاحظات معدل النقل لعقدة واحدة (ستة SU) للحالة المقسمة:
| حجم المحفوظات (الأحداث) | مدة النافذة (مللي ثانية) | إجمالي أحداث الإدخال في الثانية | عدد الأجهزة |
|---|---|---|---|
| 60 | 1091 | 1,100 | 10 |
| 600 | 10,910 | 1,100 | 10 |
| 6,000 | 218,182 | <550 | 10 |
| 60 | 21,819 | 550 | 100 |
| 600 | 218,182 | 550 | 100 |
| 6,000 | 2,181,819 | <550 | 100 |
يوجد نموذج التعليمات البرمجية لتشغيل التكوينات غير المتدرجة أعلاه في مستودع Streaming At Scale من Azure Samples. تنشئ التعليمات البرمجية مهمة تحليلات الدفق دون تقسيم مستوى الوظيفة، والذي يستخدم مراكز الأحداث كإخراج وإخراج. يتم إنشاء تحميل الإدخال باستخدام عملاء الاختبار. كل حدث إدخال هو مستند json 1 كيلوبايت. تحاكي الأحداث جهاز IoT يرسل بيانات JSON (لأجهزة تصل إلى 1 كيلوبايت). يختلف حجم المحفوظات ومدة النافذة وإجمالي تحميل الحدث على قسمين من أقسام الإدخال.
إشعار
للحصول على تقدير أكثر دقة، قم بتخصيص العينات لتناسب السيناريو الخاص بك.
تحديد الازدحامات
لتحديد الاختناقات في البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بك، راجع استخدام جزء المقاييس في وظيفة Azure Stream Analytics. راجع أحداث الإدخال/الإخراج لمعدل النقل و "تأخير العلامة المائية" أو الأحداث المتراكمة لمعرفة ما إذا كانت المهمة تواكب معدل الإدخال. بالنسبة لمقاييس مراكز الأحداث، ابحث عن الطلبات المقيدة واضبط وحدات الحد وفقاً لذلك. بالنسبة لمقاييس Azure Cosmos DB، راجع الحد الأقصى المستهلك ل RU/s لكل نطاق مفتاح قسم ضمن معدل النقل لضمان استهلاك نطاقات مفاتيح القسم بشكل موحد. بالنسبة إلى قاعدة بيانات Azure SQL، راقب إدخال/إخراج السجل و CPU.