Azure Stream Analytics'te anomali algılama
Hem bulutta hem de Azure IoT Edge'de kullanılabilen Azure Stream Analytics, geçici ve kalıcı olmak üzere en yaygın iki anomaliyi izlemek için kullanılabilecek yerleşik makine öğrenmesi tabanlı anomali algılama özellikleri sunar. AnomalyDetection_SpikeAndDip ve AnomalyDetection_ChangePoint işlevleriyle anomali algılamayı doğrudan Stream Analytics işinizde gerçekleştirebilirsiniz.
Makine öğrenmesi modelleri, tekdüzen örneklenmiş bir zaman serisi olduğunu varsayar. Zaman serisi tekdüzen değilse, anomali algılamayı çağırmadan önce yuvarlanan pencere içeren bir toplama adımı ekleyebilirsiniz.
Makine öğrenmesi işlemleri şu anda mevsimsellik eğilimlerini veya çok değişkenli bağıntıları desteklemez.
Azure Stream Analytics’te makine öğrenmesi kullanarak anomali algılama
Aşağıdaki videoda, Azure Stream Analytics'te makine öğrenmesi işlevlerini kullanarak anomaliyi gerçek zamanlı olarak algılama işlemi gösterilmektedir.
Model davranışı
Genellikle, kayan pencerede daha fazla veri ile modelin doğruluğu artar. Belirtilen kayan penceredeki veriler, bu zaman çerçevesi için normal değer aralığının bir parçası olarak değerlendirilir. Model, geçerli olayın anormal olup olmadığını denetlemek için yalnızca kayan pencere üzerinde olay geçmişini dikkate alır. Kayan pencere ilerledikçe eski değerler modelin eğitiminden çıkarılır.
İşlevler, şimdiye kadar gördüklerine göre belirli bir normal oluşturarak çalışır. Aykırı değerler, güven düzeyi içinde yerleşik normale göre karşılaştırılarak tanımlanır. Pencere boyutu, modeli normal davranış için eğitmek için gereken en düşük olayları temel almalıdır, böylece bir anomali oluştuğunda bunu tanıyabilir.
Modelin yanıt süresi geçmiş boyutuyla artar çünkü daha fazla sayıda geçmiş olayla karşılaştırması gerekir. Daha iyi performans için yalnızca gerekli olay sayısını eklemenizi öneririz.
Zaman serisindeki boşluklar, modelin belirli zaman noktalarında olayları almamasından kaynaklanıyor olabilir. Bu durum, Stream Analytics tarafından imputation mantığı kullanılarak işlenir. Aynı kayan pencere için geçmiş boyutu ve bir süre, olayların gelmesi beklenen ortalama oranı hesaplamak için kullanılır.
Burada bulunan bir anomali oluşturucu, bir Iot Hub'ı farklı anomali desenlerine sahip verilerle beslemek için kullanılabilir. Azure Stream Analytics işi, bu Iot Hub'dan okumak ve anomalileri algılamak için bu anomali algılama işlevleriyle ayarlanabilir.
Ani artış ve dip
Zaman serisi olay akışındaki geçici anomaliler ani artışlar ve düşüşler olarak bilinir. Ani artışlar ve düşüşler Machine Learning tabanlı işleç AnomalyDetection_SpikeAndDip kullanılarak izlenebilir.
Aynı kayan pencerede ikinci bir ani artış ilkinden küçükse, küçük ani artış için hesaplanan puan, belirtilen güvenilirlik düzeyindeki ilk ani artışa göre büyük olasılıkla yeterince önemli değildir. Bu tür anomalileri algılamak için modelin güvenilirlik düzeyini azaltmayı deneyebilirsiniz. Ancak çok fazla uyarı almaya başlarsanız daha yüksek bir güvenilirlik aralığı kullanabilirsiniz.
Aşağıdaki örnek sorgu, 120 olay geçmişine sahip 2 dakikalık kayan pencerede saniyede bir olayın tekdüzen giriş hızını varsayar. Son SELECT deyimi puanı ve anomali durumunu %95 güvenilirlik düzeyiyle ayıklar ve çıkarır.
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
Değişiklik noktası
Zaman serisi olay akışındaki kalıcı anomaliler, düzey değişiklikleri ve eğilimler gibi olay akışındaki değerlerin dağılımındaki değişikliklerdir. Stream Analytics'te bu tür anomaliler Machine Learning tabanlı AnomalyDetection_ChangePoint işleci kullanılarak algılanıyor.
Kalıcı değişiklikler ani artışlardan ve düşüşlerden çok daha uzun sürer ve yıkıcı olaylara işaret edebilir. Kalıcı değişiklikler genellikle çıplak gözle görülemez, ancak AnomalyDetection_ChangePoint işleciyle algılanabilir.
Aşağıdaki görüntü, bir düzey değişikliği örneğidir:
Aşağıdaki görüntüde eğilim değişikliği örneği verilmiştir:
Aşağıdaki örnek sorgu, geçmiş boyutu 1.200 olay olan 20 dakikalık kayan pencerede saniyede bir olay için tekdüzen giriş hızı olduğunu varsayar. Son SELECT deyimi puanı ve anomali durumunu %80 güvenilirlik düzeyiyle ayıklar ve çıkarır.
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
Performans özellikleri
Bu modellerin performansı geçmiş boyutuna, pencere süresine, olay yüküne ve işlev düzeyi bölümlemenin kullanılıp kullanılmadığına bağlıdır. Bu bölümde bu yapılandırmalar ele alınmaktadır ve saniyede 1 K, 5 K ve 10.000 olay alım oranlarının nasıl sürdürülmesi için örnekler sağlanmaktadır.
- Geçmiş boyutu - Bu modeller geçmiş boyutuyla doğrusal olarak performans gösterir. Geçmiş boyutu ne kadar uzun olursa modeller yeni bir etkinliği puanlar. Bunun nedeni modellerin yeni olayı geçmiş arabelleğindeki geçmiş olayların her biriyle karşılaştırmasıdır.
- Pencere süresi - Pencere süresi , geçmiş boyutuna göre belirtilen sayıda olayı almanın ne kadar sürdüğünü yansıtmalıdır. Pencerede bu kadar çok olay olmadan Azure Stream Analytics eksik değerleri gösterir. Bu nedenle, CPU tüketimi geçmiş boyutunun bir işlevidir.
- Olay yükü - Olay yükü ne kadar büyükse, modeller tarafından gerçekleştirilen ve CPU tüketimini etkileyen o kadar fazla iş olur. İş mantığının daha fazla giriş bölümü kullanması mantıklı olduğu varsayılarak, işin ölçeği utanç verici derecede paralel hale getirilerek genişletilebilir.
- İşlev düzeyi bölümleme - İşlev düzeyi bölümleme , anomali algılama işlev çağrısı içinde kullanılarak
PARTITION BYyapılır. Bu bölümleme türü, aynı anda birden çok model için durumun korunması gerektiğinden ek yük ekler. İşlev düzeyi bölümleme, cihaz düzeyinde bölümleme gibi senaryolarda kullanılır.
İlişki
Geçmiş boyutu, pencere süresi ve toplam olay yükü aşağıdaki şekilde ilişkilidir:
windowDuration (ms cinsinden) = 1000 * geçmişSize / (saniyede toplam giriş olayları / Giriş Bölümü Sayısı)
İşlevi deviceId'ye göre bölümlerken anomali algılama işlev çağrısına "PARTITION BY deviceId" ekleyin.
Gözlemler
Aşağıdaki tablo, bölümlenmemiş durum için tek bir düğüme (altı SU) yönelik aktarım hızı gözlemlerini içerir:
| Geçmiş boyutu (olaylar) | Pencere süresi (ms) | Saniye başına toplam giriş olayı |
|---|---|---|
| 60 | 55 | 2.200 |
| 600 | 728 | 1,650 |
| 6.000 | 10,910 | 1.100 |
Aşağıdaki tablo, bölümlenmiş durum için tek bir düğüm (altı SU) için aktarım hızı gözlemlerini içerir:
| Geçmiş boyutu (olaylar) | Pencere süresi (ms) | Saniye başına toplam giriş olayı | Cihaz sayımı |
|---|---|---|---|
| 60 | 1,091 | 1.100 | 10 |
| 600 | 10,910 | 1.100 | 10 |
| 6.000 | 218,182 | <550 | 10 |
| 60 | 21,819 | 550 | Kategori 100 |
| 600 | 218,182 | 550 | Kategori 100 |
| 6.000 | 2,181,819 | <550 | Kategori 100 |
Yukarıdaki bölümlenmemiş yapılandırmaları çalıştırmak için örnek kod, Azure Örnekleri'nin Uygun Ölçekte Akış deposunda bulunur. Kod, giriş ve çıkış olarak Event Hubs kullanan işlev düzeyinde bölümleme içermeyen bir akış analizi işi oluşturur. Giriş yükü, test istemcileri kullanılarak oluşturulur. Her giriş olayı 1 KB'lık bir json belgesidir. Olaylar, JSON verileri gönderen bir IoT cihazının benzetimini (en fazla 1 K cihaz için) sağlar. Geçmiş boyutu, pencere süresi ve toplam olay yükü iki giriş bölümü üzerinde değişir.
Dekont
Daha doğru bir tahmin için örnekleri senaryonuza uyacak şekilde özelleştirin.
Performans sorunlarını tanımlama
İşlem hattınızdaki performans sorunlarını belirlemek için Azure Stream Analytics işinizde Ölçümler bölmesini kullanın. İşin giriş hızına uygun olup olmadığını görmek için aktarım hızı ve "Filigran Gecikmesi" veya GeriLogged Olayları için Giriş/Çıkış Olayları'nı gözden geçirin. Event Hubs ölçümleri için Kısıtlanmış İstekler'i arayın ve Eşik Birimlerini buna göre ayarlayın. Azure Cosmos DB ölçümleri için, bölüm anahtarı aralıklarınızın düzgün bir şekilde tüketildiğinden emin olmak için Aktarım Hızı altındaki Bölüm anahtarı aralığı başına en fazla tüketilen RU/sn bölümünü gözden geçirin. Azure SQL DB için Günlük GÇ ve CPU'sunu izleyin.