أفضل ممارسة لاستخدام واجهة برمجة تطبيقات أحادية المتغير لـ Anomaly Detector
هام
اعتبارا من 20 سبتمبر 2023، لن تتمكن من إنشاء موارد Anomaly Detector جديدة. يتم إيقاف خدمة Anomaly Detector في 1 أكتوبر 2026.
واجهة برمجة تطبيقات Anomaly Detector هي خدمة الكشف عن الحالات الشاذة عديمة الحالة. يمكن أن تتأثر دقة نتائجها وأدائها بما يلي:
- كيفية إعداد بيانات السلسلة الزمنية.
- معلمات واجهة برمجة تطبيقات Anomaly Detector التي تم استخدامها.
- عدد نقاط البيانات في طلب واجهة برمجة التطبيقات الخاصة بك.
استخدم هذه المقالة للتعرف على أفضل ممارسة لاستخدام واجهة برمجة التطبيقات للحصول على أفضل النتائج لبياناتك.
متى تستخدم الدفعة (بأكملها) أو أحدث (آخر) كشف عن الحالات الخارجة عن المألوف للنقطة
تتيح لك نقطة نهاية الكشف الدفعي لواجهة برمجة تطبيقات Anomaly Detector اكتشاف الحالات الشاذة من خلال بيانات سلسلة الأوقات بأكملها. في وضع الكشف هذا، يتم إنشاء نموذج إحصائي واحد وتطبيقه على كل نقطة في مجموعة البيانات. إذا كانت السلسلة الزمنية الخاصة بك لها الخصائص أدناه، نوصي باستخدام الكشف عن الدفعات لمعاينة بياناتك في استدعاء واجهة برمجة تطبيقات واحد.
- سلسلة زمنية موسمية مع حالات شاذة عرضية.
- سلسلة زمنية ثابتة للاتجاه، مع ارتفاعات/انخفاضات عرضية.
لا نوصي باستخدام الكشف عن الحالات الشاذة الدفعية لمراقبة البيانات في الوقت الفعلي، أو استخدامه على بيانات السلاسل الزمنية التي لا تحتوي على الخصائص المذكورة أعلاه.
يقوم الكشف عن الدفعات بإنشاء نموذج واحد فقط وتطبيقه، ويتم الكشف عن كل نقطة في سياق السلسلة بأكملها. إذا كانت اتجاهات بيانات السلسلة الزمنية صعوداً وهبوطاً دون موسمية، فقد يفوت النموذج بعض نقاط التغيير (الانخفاضات والارتفاعات في البيانات). وبالمثل، قد لا يتم حساب بعض نقاط التغيير الأقل أهمية من تلك التي طرأت لاحقاً في مجموعة البيانات على أنها ذات أهمية كافية لإدراجها في النموذج.
الكشف عن الدفعات أبطأ من الكشف عن حالة الشذوذ لأحدث نقطة عند القيام بمراقبة البيانات في الوقت الحقيقي، بسبب عدد النقاط التي يتم تحليلها.
لمراقبة البيانات في الوقت الحقيقي، نوصي بالكشف عن الحالات الشاذة لأحدث نقطة بيانات فقط. من خلال تطبيق أحدث اكتشاف للنقطة باستمرار، يمكن إجراء مراقبة البيانات المتدفقة بشكل أكثر كفاءة ودقة.
يصف المثال أدناه تأثير أوضاع الكشف هذه على الأداء. تظهر الصورة الأولى نتيجة الكشف المستمر عن أحدث نقطة حالة شاذة على طول 28 نقطة بيانات تمت مشاهدتها مسبقاً. النقاط الحمراء هي حالات شاذة.
فيما يلي نفس مجموعة البيانات باستخدام الكشف عن الحالات الشاذة الدفعية. تجاهل النموذج الذي تم إنشاؤه للعملية العديد من الحالات الشاذة، التي تم وضع علامة عليها بواسطة المستطيلات.
تحضير البيانات
تقبل واجهة برمجة تطبيقات Anomaly Detector بيانات السلسلة الزمنية المنسقة في عنصر طلب JSON. يمكن أن تكون السلسلة الزمنية أي بيانات رقمية مسجلة بمرور الوقت بترتيب تسلسلي. يمكنك إرسال نوافذ بيانات السلسلة الزمنية إلى نقطة نهاية واجهة برمجة التطبيقات لـ Anomaly Detector لتحسين أداء واجهة برمجة التطبيقات. الحد الأدنى لعدد نقاط البيانات التي يمكنك إرسالها هو 12، والحد الأقصى هو 8640 نقطة. يتم تعريف النقاوة على أنها المعدل الذي يتم أخذ عينات من بياناتك فيه.
يجب أن تحتوي نقاط البيانات المرسلة إلى واجهة برمجة تطبيقات Anomaly Detector على طابع زمني صالح بالتوقيت العالمي المتفق عليه (UTC)، وقيمة رقمية.
{
"granularity": "daily",
"series": [
{
"timestamp": "2018-03-01T00:00:00Z",
"value": 32858923
},
{
"timestamp": "2018-03-02T00:00:00Z",
"value": 29615278
},
]
}
إذا تم أخذ عينات من بياناتك في فاصل زمني غير قياسي، يمكنك تحديدها عن طريق إضافة السمة customInterval في طلبك. على سبيل المثال، إذا تم أخذ عينات من السلسلة كل 5 دقائق، يمكنك إضافة ما يلي إلى طلب JSON الخاص بك:
{
"granularity" : "minutely",
"customInterval" : 5
}
نقاط البيانات المفقودة
نقاط البيانات المفقودة شائعة في مجموعات بيانات السلاسل الزمنية الموزعة بالتساوي، خاصةً تلك التي لها دقة دقيقة (فاصل زمني صغير لأخذ العينات. على سبيل المثال، البيانات التي يتم أخذ عينات منها كل بضع دقائق). يجب ألا يكون لفقد أقل من 10% من عدد النقاط المتوقع في بياناتك تأثير سلبي على نتائج الكشف الخاصة بك. ضع في اعتبارك سد الثغرات في بياناتك استناداً إلى خصائصها، مثل استبدال نقاط البيانات من فترة سابقة أو استنتاج خطي أو متوسط متحرك.
تجميع البيانات الموزعة
تعمل واجهة برمجة تطبيقات Anomaly Detector بشكل أفضل على سلسلة زمنية موزعة بالتساوي. إذا تم توزيع بياناتك عشوائياً، يجب تجميعها حسب وحدة زمنية، مثل كل دقيقة أو ساعة أو يومياً.
الكشف عن الحالات الشاذة على البيانات ذات الأنماط الموسمية
إذا كنت تعرف أن بيانات السلسلة الزمنية الخاصة بك لها نمط موسمي (نمط يحدث على فترات منتظمة)، يمكنك تحسين الدقة ووقت استجابة واجهة برمجة التطبيقات.
يمكن أن يؤدي تحديد period عند إنشاء طلب JSON إلى تقليل زمن انتقال الكشف عن الحالات الشاذة بنسبة تصل إلى 50%. يعد period عدداً صحيحاً يحدد تقريباً عدد نقاط البيانات التي تستغرقها السلسلة الزمنية لتكرار نمط. على سبيل المثال، السلسلة الزمنية التي تحتوي على نقطة بيانات واحدة في اليوم سيكون لها period كـ 7، وسلسلة زمنية بنقطة واحدة في الساعة (بنفس النمط الأسبوعي) سيكون لها period من 7*24. إذا لم تكن متأكداً من أنماط بياناتك، فلن تحتاج إلى تحديد هذه المعلمة.
للحصول على أفضل النتائج، قم بتوفير أربع نقاط بيانات لـ period، بالإضافة إلى نقطة بيانات إضافية. على سبيل المثال، يجب أن توفر البيانات بالساعة ذات النمط الأسبوعي كما هو موضح أعلاه 673 نقطة بيانات في نص الطلب (7 * 24 * 4 + 1).
بيانات أخذ العينات للمراقبة في الوقت الحقيقي
إذا تم أخذ عينات من البيانات المتدفقة على فاصل زمني قصير (على سبيل المثال ثوانٍ أو دقائق)، فقد يتجاوز إرسال العدد الموصى به من نقاط البيانات الحد الأقصى المسموح به لواجهة برمجة تطبيقات Anomaly Detector (8640 نقطة بيانات). إذا أظهرت بياناتك نمطاً موسمياً مستقراً، ففكر في إرسال عينة من بيانات السلسلة الزمنية الخاصة بك في فاصل زمني أكبر، مثل الساعات. يمكن أن يؤدي أخذ عينات بياناتك بهذه الطريقة أيضا إلى تحسين وقت استجابة واجهة برمجة التطبيقات بشكل ملحوظ.