Detecção de anomalias no Azure Stream Analytics

Disponível na nuvem e no Azure IoT Edge, o Azure Stream Analytics oferece funcionalidades internas de detecção de anomalias baseadas em machine learning que podem ser usadas para monitorar as duas anomalias mais comuns: temporárias e persistentes. Com as funções AnomalyDetection_SpikeAndDip e AnomalyDetection_ChangePoint , você pode executar a detecção de anomalias diretamente em seu trabalho do Stream Analytics.

Os modelos de machine learning pressupõem uma série temporal uniformemente amostrada. Se a série temporal não for uniforme, você poderá inserir uma etapa de agregação com uma janela deslizante antes de executar a detecção de anomalias.

As operações de machine learning não dão suporte a tendências de sazonalidade ou correlações de várias variações no momento.

Detecção de anomalias usando machine learning no Azure Stream Analytics

O vídeo a seguir demonstra como detectar uma anomalia em tempo real usando funções de machine learning no Azure Stream Analytics.

Comportamento do modelo

Em geral, 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. O modelo considera apenas o histórico de eventos na janela deslizante para verificar se o evento atual é anormal. À medida que a janela deslizante se move, os valores antigos são removidos do treinamento do modelo.

As funções operam estabelecendo um determinado valor normal com base no que foi observado até o momento. Exceções são identificadas comparando-se 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 para que, quando ocorrer uma anomalia, ele possa reconhecê-lo.

O tempo de resposta do modelo aumenta com o tamanho do histórico porque ele precisa comparar com um número maior de eventos passados. Recomendamos que você inclua apenas o número necessário de eventos para melhorar o desempenho.

As lacunas na série temporal podem ser resultado do modelo não receber eventos em determinados pontos no tempo. Essa situação é tratada pelo Stream Analytics usando a lógica de imputação. O tamanho do histórico e a duração para a mesma janela deslizante são usados para calcular a taxa média na qual os eventos são esperados.

Um gerador de anomalias disponível aqui pode ser usado para alimentar um Hub IoT com dados com padrões de anomalias diferentes. Um trabalho do Azure Stream Analytics pode ser configurado com essas funções de detecção de anomalias para ler deste Hub IoT e detectar anomalias.

Pico e queda

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 que o primeiro, a pontuação computada para o pico menor provavelmente não será significativa o suficiente em comparação com a pontuação do primeiro pico dentro do nível de confiança especificado. Você pode tentar diminuir o nível de confiança do modelo para detectar essas anomalias. No entanto, se você começar a receber muitos alertas, poderá usar um intervalo de confiança maior.

A consulta de exemplo a seguir pressupõe 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 instrução SELECT final extrai e apresenta a pontuação e o status 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 alterações de nível e tendências. No Stream Analytics, essas anomalias são detectadas usando o operador de AnomalyDetection_ChangePoint baseado em Machine Learning.

As alterações persistentes duram muito mais do que picos e quedas e podem indicar eventos catastróficos. As alterações persistentes geralmente não são visíveis a olho nu, mas podem ser detectadas com o operador AnomalyDetection_ChangePoint .

A imagem a seguir é um exemplo de alteração de nível:

A imagem a seguir é um exemplo de uma alteração de tendência:

A consulta de exemplo a seguir pressupõe 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 gera o score e o status da 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 do evento e se o particionamento no nível da função é usado. Esta seção discute essas configurações e fornece exemplos de como manter taxas de ingestão de 1 mil, 5 mil e 10 mil eventos por segundo.

• Tamanho do histórico – esses modelos são executados linearmente com o tamanho do histórico. Quanto maior o tamanho do histórico, mais tempo os modelos levam para pontuar um novo evento. Isso ocorre porque os modelos comparam o novo evento com cada um dos eventos anteriores no buffer de histórico.
• Duração da janela – a duração da janela deve refletir quanto tempo leva para receber quantos eventos forem especificados pelo tamanho do histórico. Sem tantos eventos na janela, o Azure Stream Analytics imputaria valores ausentes. Portanto, o consumo de CPU é uma função do tamanho do histórico.
• Carga de evento – Quanto maior a carga do evento, mais trabalho é executado pelos modelos, o que afeta o consumo de CPU. O trabalho pode ser escalado para fora, tornando-o embaraçosamente paralelo, supondo que faça sentido para a lógica de negócios usar mais partições de entrada.
• Particionamento em nível de função - O particionamento em nível de função é feito usando PARTITION BY dentro da chamada de função de detecção de anomalias. Esse tipo de particionamento adiciona uma sobrecarga, pois o estado precisa ser mantido para vários modelos ao mesmo tempo. O particionamento em nível de função é usado em cenários como particionamento em nível de dispositivo.

Relacionamento

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 detecçã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:

A tabela a seguir inclui as observações de taxa de transferência para um único nó (seis SU) para o caso particionado:

O código de exemplo para executar as configurações não particionadas acima está localizado no repositório streaming em escala de 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 que envia dados JSON (para até 1 K dispositivos). O tamanho do histórico, a duração da janela e a carga total do evento são variados em duas partições de entrada.

Identificando gargalos

Para identificar gargalos em seu pipeline, use o painel Métricas em seu trabalho do Azure Stream Analytics. Examine Eventos de Entrada/Saída para taxa de transferência e "Atraso de Marca-d'água" ou Eventos Acumulados para ver se o trabalho está acompanhando a taxa de entrada. Para as métricas dos Hubs de Eventos, procure Solicitações Limitadas e ajuste as Unidades de Limite adequadamente. Para métricas do Azure Cosmos DB, examine Máximo de RU/s consumidas por intervalo de chaves de partição em Taxa de Transferência para verificar se os intervalos de chave de partição foram consumidos uniformemente. Para o BD SQL do Azure, monitore a E/S de Log e CPU.

Vídeo de demonstração

Próximas etapas

• Introdução ao Stream Analytics do Azure
• Introdução ao uso do Stream Analytics do Azure
• Dimensionar trabalhos do Stream Analytics do Azure
• Referência de Linguagem de Consulta do Stream Analytics do Azure
• Referência da REST API de Gerenciamento do Azure Stream Analytics