Visão geral

Introdução

A previsão e a detecção de anomalias em bilhões de série temporal exigem muitos recursos computacionais. A maioria dos sistemas atuais executa a previsão e a detecção de anomalias como jobs em lote (por exemplo, pipelines de risco, previsão de tráfego, planejamento de demanda etc.). Isso limita bastante o tipo de análise que você pode realizar on-line, como decidir se vai enviar um alerta com base em um aumento ou diminuição repentina em um conjunto de dimensões de eventos.

Os principais objetivos da API Timeseries Insights são:

  • Escale para bilhões de série temporal que são criadas dinamicamente a partir de eventos brutos e suas propriedades com base em parâmetros de consulta.
  • Forneça 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
    • Indexar e carregar um conjunto de dados que consiste em várias fontes de dados armazenadas no Cloud Storage. Permitir a adição de novos eventos em streaming.
    • Descarregue um conjunto de dados que não é mais necessário.
    • Perguntar sobre o status de processamento de um conjunto de dados.
  • Consultar conjuntos de dados
    • Extraia a série temporal que corresponde aos valores de propriedade fornecidos. A série temporal é prevista até um horizonte de tempo especificado. A série temporal também é avaliada quanto a anomalias.
    • Detectar automaticamente combinações de valores de propriedade para anomalias.
  • Atualizar conjuntos de dados
    • Faça a ingestão de novos eventos ocorridos recentemente e incorpore-os ao índice quase em tempo real (atraso de segundos a minutos).

Recuperação de desastres

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

Após uma interrupção regional, o serviço faz o melhor esforço possível para a recuperação. Os metadados (informações sobre o conjunto de dados e o status operacional) e os dados do usuário transmitidos por streaming atualizados em até 24 horas após o início da interrupção podem não ser recuperados.

Durante a recuperação, as consultas e as atualizações de streaming para 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 de CPU, de memória e o status de um único job em execução em um data center a 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 a 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 processar dados na escala de trilhões. Por exemplo, o data center, o usuário, os nomes de jobs e os números de 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 que ilustra 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 com base em dados em lote e de streaming. A criação de dados em lote lê de vários URIs do Cloud Storage como fontes de dados. Depois que o build em lote for concluído, o conjunto de dados poderá ser atualizado com dados de streaming. Usando o build 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 geralmente leva de alguns 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 indexação inicial ser concluída, eles não serão verificados novamente. Use atualizações de streaming para mais dados. As atualizações de streaming são indexadas continuamente quase em tempo real.

Séries temporais e detecção de anomalias

Frações

Para a API Timeseries Insights, um corte é uma coleção de eventos com uma determinada combinação de valores de dimensão. Nosso interesse é uma medida de eventos que se encaixam nessas fatias ao longo do tempo.

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

Séries temporais e anomalias

Uma anomalia acontece em uma determinada fatia se o valor numérico do intervalo de tempo de interesse for significativamente diferente dos valores anteriores. A figura acima ilustra uma série temporal com base nas temperaturas medidas em todo o mundo por mais de 10 anos. Suponha que você queira saber se o último mês de 2015 é uma anomalia. Uma consulta ao sistema especifica que o período de interesse, detectionTime, é "2015/12/01" e que o granularity é "1 mês". A série temporal recuperada antes do detectionTime é dividida em um período anterior de treinamento seguido por um período de holdout. O sistema usa dados do período de treinamento para treinar um modelo e usa o período de holdout para verificar se o modelo pode prever com precisão os próximos valores. Neste exemplo, o período de espera é de um ano. A imagem mostra os dados reais e os valores previstos do modelo com limites superior e inferior. A temperatura de 2015/12 está marcada como anormal porque o valor real está fora dos limites previstos.

A seguir