Deteksi anomali di Azure Stream Analytics
Tersedia di Cloud dan Azure IoT Edge, Azure Stream Analytics menawarkan kemampuan deteksi anomali berbasis pembelajaran mesin bawaan yang dapat digunakan untuk memantau dua anomali yang paling umum terjadi: sementara dan persisten. Dengan AnomalyDetection_SpikeAndDip dan AnomalyDetection_ChangePoint, Anda dapat melakukan deteksi anomali langsung di pekerjaan Azure Stream Analytics Anda.
Model pembelajaran mesin mengasumsikan deret waktu yang disampel secara seragam. Jika rangkaian waktu tidak seragam, Anda dapat menyisipkan langkah agregasi dengan jendela tumbling sebelum memanggil deteksi anomali.
Operasi pembelajaran mesin tidak mendukung tren musiman atau korelasi multi-variasi saat ini.
Deteksi anomali menggunakan pembelajaran mesin di Azure Stream Analytics
Video berikut menunjukkan cara mendeteksi anomali secara real time menggunakan fungsi pembelajaran mesin di Azure Stream Analytics.
Perilaku model
Secara umum, akurasi model akan meningkat seiring banyak data di jendela geser. Data dalam jendela geser yang ditentukan diperlakukan sebagai bagian dari rentang nilai normal untuk jangka waktu tersebut. Model hanya mempertimbangkan riwayat kejadian di atas jendela geser untuk memeriksa apakah kejadian saat ini anomali. Saat jendela geser bergerak, nilai-nilai lama dikeluarkan dari pelatihan model.
Fungsi beroperasi dengan menetapkan normal tertentu berdasarkan apa yang telah mereka lihat sejauh ini. Titik luar diidentifikasi dengan perbandingan terhadap normal yang ditetapkan, dalam tingkat keyakinan. Ukuran jendela harus didasarkan pada kejadian minimum yang diperlukan untuk melatih model untuk perilaku normal sehingga ketika anomali terjadi, anomali bisa dikenali.
Waktu respons model meningkat dengan ukuran riwayat karena perlu dibandingkan dengan jumlah kejadian sebelumnya yang lebih tinggi. Kami menyarankan agar Anda hanya menyertakan jumlah peristiwa yang diperlukan untuk performa yang lebih baik.
Kesenjangan dalam deret waktu dapat menjadi hasil dari model yang tidak menerima kejadian pada titik-titik waktu tertentu. Situasi ini ditangani oleh Azure Stream Analytics menggunakan logika imputasi. Ukuran riwayat, serta durasi waktu, untuk jendela geser yang sama digunakan untuk menghitung tingkat rata-rata di mana kejadian diperkirakan akan tiba.
Generator anomali yang tersedia di sini dapat digunakan untuk memberi umpan Hub Iot dengan data dengan pola anomali yang berbeda. Pekerjaan Azure Stream Analytics dapat disiapkan dengan fungsi deteksi anomali ini untuk dibaca dari Iot Hub ini dan mendeteksi anomali.
Lonjakan dan turunan
Anomali sementara dalam aliran acara deret waktu dikenal sebagai lonjakan dan turunan. Lonjakan dan turunan dapat dipantau menggunakan operator berbasis Pembelajaran Mesin, AnomalyDetection_SpikeAndDip.
Di jendela geser yang sama, jika lonjakan kedua lebih kecil dari yang pertama, skor komputasi untuk lonjakan yang lebih kecil mungkin tidak cukup signifikan dibandingkan dengan skor untuk lonjakan pertama dalam tingkat keyakinan yang ditentukan. Anda dapat mencoba mengurangi tingkat keyakinan model untuk mendeteksi anomali tersebut. Namun, jika Anda mulai mendapatkan terlalu banyak pemberitahuan, Anda dapat menggunakan interval keyakinan yang lebih tinggi.
Contoh kueri berikut mengasumsikan tingkat input seragam satu kejadian per detik dalam jendela geser 2 menit dengan riwayat 120 kejadian. Pernyataan SELECT akhir mengekstrak dan menghasilkan skor dan status anomali dengan tingkat keyakinan 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
Mengubah titik
Anomali persisten dalam aliran kejadian deret waktu adalah perubahan dalam distribusi nilai di aliran kejadian, seperti perubahan tingkat dan tren. Di Azure Stream Analytics, anomali tersebut terdeteksi menggunakan operator AnomalyDetection_ChangePoint berbasis Pembelajaran Mesin.
Perubahan persisten berlangsung lebih lama daripada lonjakan dan penurunan dan dapat menunjukkan peristiwa bencana. Perubahan persisten biasanya tidak terlihat oleh mata telanjang, tetapi dapat dideteksi dengan operator AnomalyDetection_ChangePoint .
Gambar berikut adalah contoh perubahan tingkat:
Gambar berikut adalah contoh perubahan tren:
Contoh kueri berikut mengasumsikan tingkat input seragam satu peristiwa per detik dalam jendela geser 20 menit dengan ukuran riwayat 1.200 peristiwa. Pernyataan SELECT akhir mengekstrak dan menghasilkan skor dan status anomali dengan tingkat keyakinan 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
Karakteristik performa
Performa model ini tergantung pada ukuran riwayat, durasi jendela, beban kejadian, dan apakah pemartisian tingkat fungsi sedang digunakan. Bagian ini membahas konfigurasi ini dan menyediakan sampel tentang cara mempertahankan tingkat penyerapan 1 K, 5 K, dan 10K peristiwa per detik.
- Ukuran riwayat - Model-model ini berperforma linier dengan ukuran riwayat. Semakin panjang ukuran riwayat, semakin lama waktu yang dibutuhkan model untuk melakukan penskoran kejadian baru. Ini karena model membandingkan peristiwa baru dengan setiap peristiwa sebelumnya dalam buffer riwayat.
- Durasi jendela - Durasi Jendela harus mencerminkan berapa lama waktu yang diperlukan untuk menerima kejadian sebanyak yang ditentukan oleh ukuran riwayat. Tanpa banyak kejadian di jendela, Azure Stream Analytics akan mengimputasi nilai yang hilang. Oleh karena itu, konsumsi CPU adalah fungsi dari ukuran riwayat.
- Beban kejadian - Semakin besar beban kejadian, semakin banyak pekerjaan yang dilakukan oleh model, yang berdampak pada konsumsi CPU. Pekerjaan dapat diskalakan dengan menjadikannya paralel sempurna, dengan asumsi masuk akal bagi logika bisnis untuk menggunakan lebih banyak partisi input.
- Pemartisian tingkat fungsi - Pemartisian tingkat fungsi dilakukan dengan menggunakan
PARTITION BYdalam panggilan fungsi deteksi anomali. Jenis partisi ini menambahkan overhead, karena status perlu dipertahankan untuk beberapa model pada saat yang sama. Pemartisian tingkat fungsi digunakan dalam skenario seperti pemartisian tingkat perangkat.
Hubungan
Ukuran riwayat, durasi jendela, dan total beban kejadian terkait dengan cara berikut:
windowDuration (dalam ms) = 1000 * historySize / (total peristiwa input per detik / Jumlah Partisi Input)
Saat mempartisi fungsi dengan deviceId, tambahkan "PARTITION BY deviceId" ke panggilan fungsi deteksi anomali.
Pengamatan
Tabel berikut ini mencakup pengamatan throughput untuk satu simpul (enam SU) untuk kasus yang tidak dipartisi:
| Ukuran riwayat (kejadian) | Durasi jendela (md) | Total peristiwa input per detik |
|---|---|---|
| 60 | 55 | 2.200 |
| 600 | 728 | 1.650 |
| 6.000 | 10.910 | 1.100 |
Tabel berikut mencakup pengamatan throughput untuk satu simpul (enam SU) untuk kasus yang dipartisi:
| Ukuran riwayat (kejadian) | Durasi jendela (md) | Total peristiwa input per detik | Hitungan perangkat |
|---|---|---|---|
| 60 | 1.091 | 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 |
Kode sampel untuk menjalankan konfigurasi nonpartisi di atas terletak di repositori Streaming Dalam Skala Besar sampel Azure. Kode ini membuat pekerjaan analisis aliran tanpa pemartisian tingkat fungsi, yang menggunakan Azure Event Hubs sebagai input dan output. Beban input dihasilkan menggunakan klien uji. Setiap peristiwa input adalah dokumen json 1 KB. Peristiwa mensimulasikan perangkat IoT yang mengirim data JSON (hingga perangkat 1 K). Ukuran riwayat, durasi jendela, dan total beban peristiwa bervariasi di atas dua partisi input.
Catatan
Untuk perkiraan yang lebih akurat, kustomisasi sampel agar sesuai dengan skenario Anda.
Mengidentifikasi penyempitan
Untuk mengidentifikasi hambatan di alur Anda, uGunakan panel Metrik di pekerjaan Azure Stream Analytics Anda. Tinjau Peristiwa Input/Output untuk throughput dan "Watermark Delay" atau Backlogged Events untuk melihat apakah pekerjaan mengikuti laju input. Untuk metrik Azure Event Hubs, cari Permintaan Pembatasan dan sesuaikan Unit Ambang. Untuk metrik Azure Cosmos DB, tinjau Ru/dtk yang dikonsumsi maks per rentang kunci partisi di bawah Throughput untuk memastikan rentang kunci partisi Anda dikonsumsi secara seragam. Untuk Azure SQL DB, pantau Log IO dan CPU.