Informações gerais

Introdução

A previsão e a detecção de anomalias em bilhões de série temporal é uma computação intensiva. A maioria dos sistemas atuais executa previsão e detecção de anomalias como jobs em lote (por exemplo, pipelines de risco, previsão de tráfego, planejamento de demanda e assim por diante). Isso limita muito o tipo de análise que pode ser feita on-line, como decidir se deve alertar com base em um aumento ou uma diminuição repentinas em um conjunto de dimensões de eventos.

Os principais objetivos da API Timeseries Insights são:

  • Escalone para bilhões de série temporal criadas dinamicamente com base em eventos brutos e as propriedades correspondentes com base em parâmetros de consulta.
  • Fornecer resultados de previsão e detecção de anomalias em tempo real. Ou seja, em alguns segundos, detecte tendências e sazonalidade em todas as série temporal e decida se alguma fração está aumentando ou diminuindo inesperadamente.

Funcionalidade da API

  • Gerenciar conjuntos de dados
    • Indexe e carregue um conjunto de dados que consiste em várias fontes de dados armazenadas no Cloud Storage. Permitir a anexação de novos eventos de modo streaming.
    • Descarrega um conjunto de dados que não é mais necessário.
    • Solicita o status de processamento de um conjunto de dados.
  • Consultar conjuntos de dados
    • Recupere a série temporal que corresponde aos valores de propriedade fornecidos. A série temporal é prevista até um determinado horizonte de tempo. A série temporal também é avaliada em busca de anomalias.
    • Detecta automaticamente combinações de valores de propriedade para anomalias.
  • Atualize os conjuntos de dados
    • Ingerir novos eventos que ocorreram recentemente e incorporá-los ao índice quase em tempo real (atraso de alguns segundos ou minutos).

Recuperação de desastres

A API Timeseries Insights não serve como backup para o Cloud Storage nem retorna atualizações brutas de streaming. Os clientes são responsáveis por armazenar e fazer backup dos dados separadamente.

Após uma interrupção regional, o serviço realiza a melhor recuperação possível. É possível que os metadados (informações sobre o conjunto de dados e o status operacional) e o streaming de dados do usuário atualizados dentro de 24 horas do início da interrupção não sejam recuperados.

Durante a recuperação, as consultas e as atualizações de streaming dos conjuntos de dados podem não estar disponíveis.

Dados de entrada

É comum que dados numéricos e categóricos sejam coletados ao longo do tempo. Por exemplo, a figura a seguir mostra o uso da CPU, o uso da memória e o status de um único job em execução em um data center para cada minuto durante um período. O uso da CPU e da memória são valores numéricos, e o status é um valor categórico.

Timeseries

Evento

A API Timeseries Insights usa eventos como entrada de dados básica. Cada evento tem um carimbo de data/hora e um conjunto de dimensões, ou seja, pares de chave-valor em que a chave é o nome da dimensão. Essa representação simples nos permite gerenciar dados na escala de trilhões. Por exemplo, o data center, o usuário, os nomes de jobs e os números das tarefas são incluídos para representar totalmente um único evento. A figura acima mostra uma série de eventos registrados para um único job, ilustrando um subconjunto de dimensões.

{"name":"user","stringVal":"user_64194"},
{"name":"job","stringVal":"job_45835"},
{"name":"data_center","stringVal":"data_center_30389"},
{"name":"task_num","longVal":19},
{"name":"cpu","doubleVal":3840787.5207877564},
{"name":"ram","doubleVal":1067.01},
{"name":"state","stringVal":"idle"}

DataSet

Um DataSet é uma coleção de eventos. As consultas são realizadas no mesmo conjunto de dados. Cada projeto pode ter vários conjuntos de dados.

Um conjunto de dados é criado a partir de dados em lote e de streaming. O build de dados em lote faz leituras de vários URIs do Cloud Storage como fontes de dados. Após a conclusão da criação em lote, o conjunto de dados pode ser atualizado com dados de streaming. Usando a criação em lote para dados históricos, o sistema pode evitar problemas de inicialização a frio.

Um conjunto de dados precisa ser criado ou indexado antes de ser consultado ou atualizado. A indexação começa quando o conjunto de dados é criado e costuma levar de minutos a horas para ser concluída, dependendo da quantidade de dados. Mais especificamente, as fontes de dados são verificadas uma vez durante a indexação inicial. Se o conteúdo dos URIs do Cloud Storage mudar após a conclusão da indexação inicial, eles não serão verificados novamente. Use atualizações de streaming para ter mais dados. As atualizações por streaming são indexadas continuamente quase em tempo real.

Detecção de séries temporais e anomalias

Frações

Na API Timeseries Insights, uma fração é um conjunto de eventos com uma determinada combinação de valores de dimensão. Estamos interessados em uma medida dos eventos que se enquadram nessas fatias ao longo do tempo.

Em uma determinada fração, os eventos são agregados em valores numéricos por resolução de intervalos de tempo especificada pelo usuário, que são as série temporal para detectar anomalias. A figura anterior ilustra diferentes opções de frações resultantes de diferentes combinações de dimensões "user", "job" e "data_center".

Séries temporais e anomalia

Uma anomalia acontece para uma determinada fração se o valor numérico do intervalo de interesse for significativamente diferente dos valores no passado. A figura acima ilustra uma série temporal com base nas temperaturas medidas em todo o mundo ao longo de 10 anos. Suponha que estejamos interessados em saber se o último mês de 2015 é uma anomalia. Uma consulta ao sistema especifica o período de interesse, detectionTime, como "2015/12/01" e granularity como "1 mês". A série temporal recuperada antes da detectionTime é particionada em um período de treinamento anterior seguido por um período de retenção. O sistema usa os dados do período de treinamento para treinar um modelo e o período de validação para verificar se o modelo pode prever os próximos valores com segurança. Para este exemplo, o período de retenção é de um ano. A imagem mostra os dados reais e os valores previstos do modelo com limites superior e inferior. A temperatura para 2015/12 é marcada como anomalia porque o valor real está fora dos limites previstos.

A seguir