Azure 串流分析中的異常偵測
Azure 串流分析 (在雲端和 Azure IoT Edge 中都可取得) 提供內建的機器學習型異常偵測功能，可用來監視兩個最常出現的異常狀況：暫存和持續性。 利用 AnomalyDetection_SpikeAndDip 和 AnomalyDetection_ChangePoint 函式，您可以直接在串流分析作業中執行異常偵測。
機器學習模型假設有一個均勻取樣的時間序列。 如果時間序列不統一，您可以在呼叫異常偵測之前，透過輪轉視窗插入彙總步驟。
機器學習作業目前不支援季節性趨勢或多變量的相互關聯。
在 Azure 串流分析中使用機器學習偵測異常情況
下列影片示範如何在 Azure 串流分析中使用機器學習功能即時偵測異常。
模型行為
一般而言，在滑動視窗中使用更多資料可改善模型的精確度。 所指定滑動視窗中的資料會被視為屬於該時間範圍的正常值範圍。 此模型只會考慮整個滑動視窗的事件歷程記錄，以檢查目前的事件是否異常。 隨著滑動視窗移動，系統會從模型的訓練中收回舊值。
函數的運作方式是根據其到目前為止所看到的內容建立某種標準。 與所建立的標準進行比較 (在信賴等級內)，藉此識別極端值。 視窗大小應該以針對正常行為定型模型所需的事件數目下限為基礎，如此在發生異常狀況時，才能夠加以辨識。
模型的回應時間會隨著歷程記錄大小而增加，因為其需要與較高的過去事件數目進行比較。 我們建議您只包含所需的事件數目，以獲得較佳效能。
時間序列中的間距可能是未能在特定時間點及時收到事件的模型結果。 串流分析會使用插補邏輯來處理這種情況。 相同滑動視窗的歷程記錄大小，以及持續時間用來計算事件預計抵達的平均速率。
這裡提供的異常產生器可用來提供將具有不同異常模式的資料餵入 IoT 中樞。 串流分析作業可以使用這些異常偵測函數進行設定，以從這個 IoT 中樞讀取並偵測異常。
峰值和谷值
時間序列事件資料流中的暫存異常狀況也稱為峰值和谷值。 您可以使用 Machine Learning 型運算子AnomalyDetection_SpikeAndDip 來監視峰值和谷值。
在相同的滑動視窗中，如果第二個峰值小於第一個峰值，則較小峰值的計算分數可能不足以與指定的信賴等級內第一個峰值的分數比較。 您可以嘗試降低模型的信賴等級，以偵測這類異常。 不過，如果您開始取得太多警示，則可使用較高的信賴區間。
下列範例查詢假設在歷程記錄有 120 個事件的 2 分鐘滑動視窗中，每秒一個事件的均勻輸入速率。 最終的 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
變更點
時間序列事件資料流中的持續性異常狀況是事件資料流中值分佈的變更，如等級變更和趨勢。 在串流分析中，使用 Machine Learning 型 AnomalyDetection_ChangePoint 運算子偵測這類異常。
持續性變更會比峰值和谷值持續更久，並可能表示發生重大事件。 肉眼通常無法看見持續性變更，但可以使用 AnomalyDetection_ChangePoint 運算子進行偵測。
下圖是等級變更的範例：
下圖是趨勢變更的範例：
下列範例查詢假設在歷程記錄大小為 1200 個事件的 20 分鐘滑動視窗中，每秒一個事件的均勻輸入速率。 最終的 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
效能特性
這些模型的效能取決於歷程記錄大小、時間範圍持續時間、事件載入，以及是否使用函數層級資料分割。 本節討論這些設定，並提供範例來說明如何維持每秒 1K、5K 和 10K 個事件的擷取速率。
- 歷程記錄大小 - 這些模型會使用「歷程記錄大小」以線性方式執行。 歷程記錄大小越長，模型評分新事件所花費的時間就越長。 這是因為模型會比較新事件與歷程記錄緩衝區中的每個過去事件。
- 時間範圍持續時間 - [時間範圍持續時間] 應該反映接收歷程記錄大小所指定事件數目所需的時間。 如果視窗中沒有這麼多事件，則 Azure 串流分析會插補遺漏值。 因此，CPU 耗用量是歷程記錄大小的功能。
- 事件載入 - 「事件載入」愈大，模型所執行的工作就愈多，這會影響 CPU 耗用量。 工作可以藉由平行運作予以擴增，並假設商務邏輯可以使用更多輸入分割區。
- 函數層級資料分割 - 「函數層級資料分割」是在異常偵測函數呼叫內使用
PARTITION BY來完成。 這種類型的資料分割會增加額外負荷，因為需要同時維護多個模型的狀態。 函數層級資料分割用於裝置層級資料分割這類案例。
關聯
歷程記錄大小、時間範圍持續時間和事件載入總計都透過下列方式而相關：
windowDuration (毫秒) = 1000 * historySize/(每秒輸入事件總計 / 輸入分割區計數)
依 deviceId 對函數進行資料分割時，將 "PARTITION BY deviceId" 新增至異常偵測函數呼叫。
觀測
下表包括非資料分割案例中單一節點 (6 SU) 的輸送量觀察：
| 歷程記錄大小 (事件) | 時間範圍持續時間 (毫秒) | 每秒輸入事件總計 |
|---|---|---|
| 60 | 55 | 2,200 |
| 600 | 728 | 1,650 |
| 6,000 | 10,910 | 1,100 |
下表包括資料分割案例中單一節點 (6 SU) 的輸送量觀察：
| 歷程記錄大小 (事件) | 時間範圍持續時間 (毫秒) | 每秒輸入事件總計 | 裝置計數 |
|---|---|---|---|
| 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 |
執行上述非資料分割設定的範例程式碼位於 Azure 範例的大規模串流存放庫。 此程式碼會建立沒有函數層級資料分割的串流分析作業，而其會使用事件中樞作為輸入和輸出。 輸入負載是使用測試用戶端所產生。 每個輸入事件都是 1KB JSON 文件。 事件會模擬 IoT 裝置傳送 JSON 資料 (針對最多 1K 個裝置)。 歷程記錄大小、時間範圍持續時間和事件載入總計會隨著 2 個輸入分割區而不同。
注意
如需更精確的評估，請自訂範例以符合您的案例。
找出瓶頸
若要找出管線中的瓶頸，請使用您串流分析作業中的 [計量] 窗格。 檢閱 [輸入/輸出事件] 來了解輸送量，並檢閱「浮水印延遲」 \(英文\) 或 [待處理的事件] 來查看作業是否能與輸入速率保持一致。 針對事件中樞計量，請尋找 [節流的要求]，並據以調整閾值單位。 針對 Azure Cosmos DB 計量，檢閱 [輸送量] 底下的 [每個分割區索引鍵範圍每秒取用的 RU 上限]，以確保系統會一致地取用您的分割區索引鍵範圍。 針對 Azure SQL DB，請監視 [記錄 IO] 和 [CPU]。