Deteção de anomalias no Azure Stream Analytics
Disponível na nuvem e no Azure IoT Edge, o Azure Stream Analytics oferece recursos internos de deteção de anomalias baseados em aprendizado de máquina que podem ser usados para monitorar as duas anomalias mais comuns: temporárias e persistentes. Com as funções AnomalyDetection_SpikeAndDip e AnomalyDetection_ChangePoint, você pode executar a deteção de anomalias diretamente em seu trabalho do Stream Analytics.
Os modelos de aprendizado de máquina assumem uma série temporal uniformemente amostrada. Se a série temporal não for uniforme, você pode inserir uma etapa de agregação com uma janela de tombamento antes de chamar a deteção de anomalias.
As operações de aprendizado de máquina não suportam tendências de sazonalidade ou correlações multivariadas no momento.
Deteção de anomalias com machine learning no Azure Stream Analytics
O vídeo a seguir demonstra como detetar uma anomalia em tempo real usando funções de aprendizado de máquina no Azure Stream Analytics.
Comportamento do modelo
Geralmente, a precisão do modelo melhora com mais dados na janela deslizante. Os dados na janela deslizante especificada são tratados como parte de seu intervalo normal de valores para esse período de tempo. O modelo considera apenas o histórico de eventos na janela deslizante para verificar se o evento atual é anômalo. À medida que a janela deslizante se move, valores antigos são removidos do treinamento do modelo.
As funções operam estabelecendo uma certa normalidade com base no que viram até agora. Os valores atípicos são identificados comparando com o normal estabelecido, dentro do nível de confiança. O tamanho da janela deve ser baseado nos eventos mínimos necessários para treinar o modelo para o comportamento normal, de modo que, quando ocorrer uma anomalia, ele seja capaz de reconhecê-la.
O tempo de resposta do modelo aumenta com o tamanho do histórico porque ele precisa ser comparado com um número maior de eventos passados. Recomendamos que inclua apenas o número necessário de eventos para um melhor desempenho.
As lacunas nas séries temporais podem ser resultado de o modelo não receber eventos em determinados momentos. Esta situação é tratada pelo Stream Analytics usando a lógica de imputação. O tamanho do histórico, bem como a duração do tempo, para a mesma janela deslizante é usado para calcular a taxa média na qual os eventos devem chegar.
Um gerador de anomalias disponível aqui pode ser usado para alimentar um Hub Iot com dados com diferentes padrões de anomalia. Um trabalho do Azure Stream Analytics pode ser configurado com essas funções de deteção de anomalias para ler a partir deste Hub Iot e detetar anomalias.
Espigão e imersão
Anomalias temporárias em um fluxo de eventos de série temporal são conhecidas como picos e quedas. Picos e quedas podem ser monitorados usando o operador baseado em Machine Learning, AnomalyDetection_SpikeAndDip.
Na mesma janela deslizante, se um segundo pico for menor do que o primeiro, a pontuação calculada para o pico menor provavelmente não é significativa o suficiente em comparação com a pontuação para o primeiro pico dentro do nível de confiança especificado. Você pode tentar diminuir o nível de confiança do modelo para detetar tais anomalias. No entanto, se você começar a receber muitos alertas, você pode usar um intervalo de confiança mais alto.
A consulta de exemplo a seguir assume uma taxa de entrada uniforme de um evento por segundo em uma janela deslizante de 2 minutos com um histórico de 120 eventos. A declaração final SELECT extrai e produz a pontuação e o estado de anomalia com um nível de confiança de 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
Ponto de alteração
Anomalias persistentes em um fluxo de eventos de série temporal são alterações na distribuição de valores no fluxo de eventos, como mudanças de nível e tendências. No Stream Analytics, essas anomalias são detetadas usando o operador de AnomalyDetection_ChangePoint baseado em Machine Learning.
Mudanças persistentes duram muito mais do que picos e quedas e podem indicar eventos catastróficos. Alterações persistentes geralmente não são visíveis a olho nu, mas podem ser detetadas com o operador AnomalyDetection_ChangePoint .
A imagem a seguir é um exemplo de uma mudança de nível:
A imagem a seguir é um exemplo de uma mudança de tendência:
A consulta de exemplo a seguir assume uma taxa de entrada uniforme de um evento por segundo em uma janela deslizante de 20 minutos com um tamanho de histórico de 1.200 eventos. A instrução final SELECT extrai e produz a pontuação e o estado de anomalia com um nível de confiança de 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
Características de desempenho
O desempenho desses modelos depende do tamanho do histórico, da duração da janela, da carga de eventos e se o particionamento de nível de função é usado. Esta seção discute essas configurações e fornece exemplos de como manter as taxas de ingestão de eventos de 1 K, 5 K e 10K por segundo.
- Tamanho do histórico - Estes modelos têm um desempenho linear com o tamanho do histórico. Quanto maior o tamanho da história, mais tempo os modelos levam para marcar um novo evento. Isso porque os modelos comparam o novo evento com cada um dos eventos passados no buffer de histórico.
- Duração da janela - A duração da janela deve refletir quanto tempo leva para receber tantos eventos conforme especificado pelo tamanho do histórico. Sem tantos eventos na janela, o Azure Stream Analytics imputaria valores ausentes. Assim, o consumo de CPU é uma função do tamanho do histórico.
- Carga de eventos - Quanto maior a carga de eventos, mais trabalho é realizado pelos modelos, o que afeta o consumo de CPU. O trabalho pode ser dimensionado tornando-o embaraçosamente paralelo, assumindo que faz sentido para a lógica de negócios usar mais partições de entrada.
- Particionamento de nível de função O particionamento de nível de função é feito usando dentro da chamada de função de - deteção de anomalia.
PARTITION BYEsse tipo de particionamento adiciona uma sobrecarga, pois o estado precisa ser mantido para vários modelos ao mesmo tempo. O particionamento no nível da função é usado em cenários como o particionamento no nível do dispositivo.
Relação
O tamanho do histórico, a duração da janela e a carga total do evento estão relacionados da seguinte maneira:
windowDuration (em ms) = 1000 * historySize / (total de eventos de entrada por segundo / Contagem de partições de entrada)
Ao particionar a função por deviceId, adicione "PARTITION BY deviceId" à chamada da função de deteção de anomalias.
Observações
A tabela a seguir inclui as observações de taxa de transferência para um único nó (seis SU) para o caso não particionado:
| Tamanho do histórico (eventos) | Duração da janela (ms) | Total de eventos de entrada por segundo |
|---|---|---|
| 60 | 55 | 2200 |
| 600 | 728 | 1,650 |
| 6000 | 10,910 | 1100 |
A tabela a seguir inclui as observações de taxa de transferência para um único nó (seis SU) para o caso particionado:
| Tamanho do histórico (eventos) | Duração da janela (ms) | Total de eventos de entrada por segundo | Contagem de dispositivos |
|---|---|---|---|
| 60 | 1,091 | 1100 | 10 |
| 600 | 10,910 | 1100 | 10 |
| 6000 | 218,182 | <550 | 10 |
| 60 | 21,819 | 550 | 100 |
| 600 | 218,182 | 550 | 100 |
| 6000 | 2,181,819 | <550 | 100 |
O código de exemplo para executar as configurações não particionadas acima está localizado no repositório Streaming At Scale dos Exemplos do Azure. O código cria um trabalho de análise de fluxo sem particionamento de nível de função, que usa Hubs de Eventos como entrada e saída. A carga de entrada é gerada usando clientes de teste. Cada evento de entrada é um documento json de 1 KB. Os eventos simulam um dispositivo IoT enviando dados JSON (para dispositivos de até 1 K). O tamanho do histórico, a duração da janela e a carga total de eventos variam em duas partições de entrada.
Nota
Para obter uma estimativa mais precisa, personalize as amostras para se adequar ao seu cenário.
Identificação de estrangulamentos
Para identificar gargalos em seu pipeline, uUse o painel Métricas em seu trabalho do Azure Stream Analytics. Analise os Eventos de Entrada/Saída para verificar a taxa de transferência e "Atraso de marca d'água" ou Eventos em atraso para ver se o trabalho está acompanhando a taxa de entrada. Para métricas de Hubs de Eventos, procure Solicitações Limitadas e ajuste as Unidades de Limite de acordo. Para métricas do Azure Cosmos DB, revise RU/s máximo consumido por intervalo de chaves de partição em Taxa de transferência para garantir que seus intervalos de chaves de partição sejam consumidos uniformemente. Para o Banco de Dados SQL do Azure, monitore a E/S de Log e a CPU.