Conceitos

Neste artigo, vamos abordar conceitos comuns com os quais trabalhamos na API Timeseries Insights e tentar fornecer uma explicação intuitiva do que representam.

Evento

Um evento é um ponto de dados e a entrada não processada com a qual a API Timeseries Insights funciona. Em termos conceptuais, representa uma ação realizada por algum agente (por exemplo, uma transação por um cliente ou a publicação de um artigo de notícias) ou uma observação (por exemplo, as leituras de um sensor de temperatura ou a utilização da CPU numa máquina).

Um evento contém:

  • Um conjunto de valores em diferentes dimensões, que representam propriedades que descrevem o evento, como etiquetas ou medições numéricas.
  • Uma data/hora que representa a hora em que o evento ocorreu. Esta data/hora é usada quando os eventos são agregados para formar uma série cronológica.
  • Um ID de grupo.

Dimensão

Uma dimensão representa um tipo de propriedade para os eventos num conjunto de dados e o domínio de valores que pode assumir. Uma dimensão pode ser:

  • Categórico. Uma propriedade de evento nesta dimensão pode conter um dos valores limitados/finitos, normalmente strings. Exemplos: o país ou o nome do publicador num conjunto de dados com artigos de notícias, o nome da máquina num conjunto de dados com dados de monitorização da produção.
  • Numérico. Uma medição ou uma propriedade numérica geral para um evento. Exemplos: número de visualizações de páginas para artigos de notícias, utilização da CPU ou número de erros para dados de monitorização da produção.

Conjunto de dados

Um conjunto de dados é uma coleção de eventos com um nome único num projeto. As consultas são realizadas no mesmo conjunto de dados.

Grupo

Os eventos podem ser agrupados especificando o mesmo ID do grupo (consulte Event.groupId). O grupo é semelhante a uma "sessão" de atividades na Internet.

Normalmente, é atribuído a cada registo de Event um ID de grupo exclusivo. Os exemplos de utilização do ID do grupo também incluem, entre outros:

  • Um identificador de evento para o mesmo evento (com datas/horas iguais ou semelhantes) de vários registos de Event, especialmente quando diferentes propriedades do mesmo evento provêm de diferentes origens e não são unidas antes de entrar no sistema. Por exemplo, vários sensores que monitorizam o mesmo dispositivo podem produzir cada um um registo de evento separado.
  • Um identificador de sessão para uma coleção de eventos relacionados (normalmente, com indicações de tempo num curto período). Um exemplo são as atividades de uma sessão de navegação na Web. Outro exemplo são as entradas de registo de uma viagem de táxi.
  • Um identificador da conta de utilizador, para que todos os registos de Eventos com o mesmo ID do grupo pertençam ao mesmo utilizador.

O objetivo do grupo é calcular correlações entre (dimensões de) eventos do mesmo grupo. Por exemplo, se o seu conjunto de dados contiver dados de monitorização (como CPU, RAM, etc.), um grupo pode conter todos os dados de monitorização de um processo. Isso permitir-nos-ia, eventualmente, detetar que um aumento na CPU está correlacionado com outro evento, como uma atualização da versão binária num momento anterior.

Se não tiver a certeza ou não tiver interesse em calcular estes tipos de correlações, cada evento deve ter um ID do grupo globalmente exclusivo. A omissão de groupId tem um efeito semelhante e é gerado um groupId interno com base nos conteúdos e na data/hora.

Dividir

Uma fatia é o subconjunto de todos os eventos de um conjunto de dados que têm determinados valores em algumas dimensões. Para uma dimensão categórica, o valor indicado é um único valor fixo; para uma dimensão numérica, o valor indicado é um intervalo.

Por exemplo, vamos considerar que temos um conjunto de dados com as vendas de um retalhista internacional e que cada evento é uma venda que tem estas dimensões categóricas: o país onde ocorreu a venda, o nome do produto e o nome da empresa que fabricou o produto. Exemplos de divisões neste caso: todas as vendas de um determinado produto, todas as vendas de um determinado país para todos os produtos fabricados por uma determinada empresa.

Intervalos temporais

As séries cronológicas com que trabalhamos são de tempo discreto, compostas por pontos a intervalos de tempo iguais. A duração dos intervalos de tempo entre pontos de séries cronológicas consecutivos denomina-se granularidade da série cronológica.

Um intervalo temporal é calculado da seguinte forma:

  • Para uma determinada fatia, recolha todos os eventos no intervalo de tempo [detectionTime - TimeseriesParams.forecastHistory, detectionTime + granularity].
  • Agrupe estes eventos com base na respetiva data/hora e detalhe. Um evento E é atribuído a um ponto que começa no tempo T se E.eventTime estiver no intervalo de tempo [T, T + granularity].
  • Agregue, para cada ponto na série cronológica, os eventos com base na dimensão numérica especificada como métrica (TimeseriesParams.metric), que representa o valor desses pontos. A agregação pode ser feita através da contagem (se não for especificado nenhum metric, normalmente, se todas as dimensões do evento forem categóricas), da soma ou da média (se for especificado metric).

Ponto de intervalo temporal

Cada ponto da série cronológica tem um time e um value associados.

Na verdade, time é um intervalo de duração granularity com time como hora de início.

Se métrica (TimeseriesParams.metric) for especificada, tem de ser uma dimensão numérica. O value do ponto é agregado a partir dos valores da dimensão na dimensão metric de todos os eventos no intervalo de tempo, usando TimeseriesParams.metricAggregationMethod.

Se não for especificada nenhuma métrica, o value do ponto é o número de eventos no intervalo de tempo.

Previsão

O processo de prever valores futuros para uma determinada série cronológica. A previsão usa a parte inicial da série cronológica como dados de preparação para criar um modelo.

Horizon

Prevemos os valores de uma série cronológica a partir da hora de deteção até ao horizonte temporal (indicado no campo ForecastParams.horizonTime).

Intuitivamente, este campo indica-nos o período futuro para o qual devemos fazer a previsão. Embora estejamos principalmente interessados no valor do ponto de deteção ao classificar uma fatia como uma anomalia, permitimos que sejam previstas pontos adicionais, uma vez que podem fornecer informações úteis ao utilizador.

Hora e ponto de deteção

O tempo de deteção (especificado por QueryDataSetRequest.detectionTime) é o ponto no tempo que estamos a analisar para detetar potenciais anomalias.

O ponto de deteção é o ponto da série cronológica no momento da deteção.

Desvio esperado

Consoante a estabilidade e a previsibilidade de uma série cronológica, podemos ter mais ou menos confiança na nossa previsão. O nível de confiança reflete-se no campo EvaluatedSlice.expectedDeviation, que especifica o que é um desvio absoluto aceitável do valor que previmos para a hora de deteção.

Anomalia

Uma divisão pode ser considerada uma anomalia se o desvio entre os respetivos valores previstos e reais durante o tempo de deteção for superior ao que esperamos que seja.

Denominamos a distância entre o desvio real e o desvio esperado de pontuação de anomalia:

anomalyScore = (detectionPointActual - detectionPointForecast) / expectedDeviation

Em geral, as pontuações inferiores a 1,0 refletem variações comuns tendo em conta o histórico da fatia, enquanto as pontuações superiores a 1,0 devem exigir atenção, com pontuações mais elevadas a representar anomalias mais graves.

Limite de ruído

A pontuação de anomalia, conforme definido anteriormente, mostra o quão estatisticamente significativo é um desvio do normal. No entanto, em muitos casos, este desvio pode não ser importante porque a alteração no valor absoluto pode não ser de interesse.

Por exemplo, se uma série cronológica tiver todos os seus valores distribuídos uniformemente no intervalo (9,9, 10,1), o valor expectedDeviation será ~0,1. Se o detectionPointForecast for 10.0 e o detectionPointActual for 10.3, o anomalyScore é 3.0.

Se as alterações com um valor absoluto superior forem mais importantes para si, o limite de ruído oferece uma forma de penalizar as divisões com alterações inferiores a esse limite, reduzindo a ponderação da pontuação de anomalia:

anomalyScore = (detectionPointActual - detectionPointForecast) / (expectedDeviation + noiseThreshold)

O que se segue?