Na última década, o crescimento e o sucesso do aprendizado de máquina foram fenomenais, impulsionados principalmente pela disponibilidade de grandes quantidades de dados e poder computacional avançado. Esse aumento foi causado pela digitalização de vários setores, levando a uma explosão de dados digitais – tudo, desde postagens em mídias sociais até transações online e dados de sensores.

Os avanços nas técnicas de aprendizado de máquina, principalmente no aprendizado profundo, facilitaram o desenvolvimento de modelos mais complexos e versáteis. Consequentemente, os aplicativos de aprendizado de máquina tornaram-se onipresentes, contribuindo para melhorar a eficiência e os recursos em vários setores, incluindo saúde, finanças e transporte.

Trabalhar com essas enormes quantidades de dados baseados em eventos e derivar valor dos próprios eventos e seu contexto no tempo – outros eventos acontecendo nas proximidades – ainda é difícil. Fazer isso em tempo real ou em streaming é ainda mais difícil. Freqüentemente, você deve usar APIs complexas de baixo nível ou contornar as limitações de uma linguagem de consulta de nível superior projetada para resolver problemas muito diferentes, como SQL.

Para enfrentar esses desafios, introduzimos uma nova abstração para dados baseados em tempo, chamada de timelines. As linhas do tempo organizam os dados por tempo e entidade, oferecendo uma estrutura ideal para dados baseados em eventos com um modelo mental gráfico intuitivo. As linhas de tempo simplificam o raciocínio sobre o tempo, alinhando seu modelo mental com o domínio do problema, permitindo que você se concentre no que calcular, em vez de como expressá-lo.

Nesta postagem, apresentamos cronogramas como uma maneira natural de organizar dados baseados em eventos e extrair valor – diretamente e como entradas para aprendizado de máquina e engenharia imediata. Aprofundamos o conceito de linha do tempo, sua interação com armazenamentos de dados externos (entradas e saídas) e o ciclo de vida das consultas usando linhas do tempo.

Esta postagem é a primeira de uma série sobre Kaskada , um mecanismo de processamento de eventos de código aberto projetado em torno da abstração da linha do tempo. Continuaremos com uma explicação de como o Kaskada constrói uma linguagem de consulta temporal expressiva na abstração da linha do tempo, como o modelo de dados da linha do tempo permite que o Kaskada execute consultas temporais com eficiência e, finalmente, como as linhas do tempo permitem que o Kaskada seja executado de forma incremental em fluxos de eventos.

Fazendo sentido do tempo

Lidar com uma grande variedade de eventos é difícil ao tratar cada tipo de evento como uma tabela de dados separada e não ordenada – a maneira como o SQL vê o mundo. É difícil entender o que motivou Carla a fazer compras ou o que levou Aaron a se envolver com outros usuários por meio de mensagens.

Ao organizar os dados – por tempo e usuário – fica muito mais fácil identificar padrões. Aaron envia mensagens após a vitória. Carla faz compras frustrada por uma série de prejuízos. Também vemos que Brad pode ter parado de jogar.

Ao organizar os dados – por tempo e usuário – fica muito mais fácil identificar padrões. Aaron envia mensagens após a vitória. Carla faz compras frustrada por uma série de prejuízos. Também vemos que Brad pode ter parado de jogar.

Ao organizar os eventos de forma natural – por tempo e usuário – conseguimos identificar padrões. Essa mesma organização nos permite expressar valores de recursos calculados a partir dos eventos e usá-los para treinar e aplicar modelos de aprendizado de máquina ou calcular valores para usar em um prompt.

A abstração da linha do tempo

Raciocinar sobre o tempo – por exemplo, causa e efeito entre eventos – requer mais do que apenas um conjunto desordenado de dados de eventos. Para consultas temporais, precisamos incluir o tempo como uma parte de primeira classe da abstração. Isso permite raciocinar sobre quando um evento aconteceu e a ordem – e o tempo – entre os eventos.

Kaskada é construído sobre a abstração da linha do tempo: um multiconjunto ordenado por tempo e agrupado por entidade. As linhas do tempo têm uma visualização natural, mostrada abaixo. O tempo é mostrado no eixo x e os valores correspondentes no eixo y. Considere eventos de compra de duas pessoas: Ben e Davor. Estes são mostrados como pontos discretos que refletem o tempo e o valor da compra. Chamamos essas linhas de tempo discretas porque elas representam pontos discretos.

O eixo de tempo de uma linha do tempo reflete o tempo do resultado de um cálculo. Por exemplo, a qualquer momento podemos perguntar “qual é a soma de todas as compras?” As agregações ao longo dos cronogramas são cumulativas – à medida que os eventos são observados, a resposta à pergunta muda. Chamamos isso de linhas de tempo contínuas porque cada valor continua até a próxima mudança.

Em comparação com o SQL, as linhas de tempo apresentam dois requisitos: ordenação por tempo e agrupamento por entidade. Embora a relação SQL – um multiconjunto ou bolsa não ordenada – seja útil para dados não ordenados, os requisitos adicionais das linhas de tempo as tornam ideais para raciocinar sobre causa e efeito. As linhas do tempo são para os dados temporais o que as relações são para os dados estáticos.

Adicionar esses requisitos significa que os cronogramas não são adequados para todas as tarefas de processamento de dados. Em vez disso, eles permitem que os cronogramas sejam mais adequados para tarefas de processamento de dados que trabalham com eventos e tempo. Na verdade, a maioria dos fluxos de eventos (por exemplo, Apache Kafka, Apache Pulsar, AWS Kinesis etc.) fornece ordenação e particionamento por chave.

Ao pensar em eventos e tempo, você provavelmente já imagina algo como uma linha do tempo. Ao combinar a maneira como você já pensa sobre o tempo, as linhas de tempo simplificam o raciocínio sobre eventos e tempo. Construindo os requisitos de tempo e ordenação, a abstração da linha do tempo permite que consultas temporais expressem intuitivamente causa e efeito.

Usando linhas do tempo para consultas temporais

As linhas de tempo são a abstração usada no Kaskada para criar consultas temporais, mas os dados começam e terminam fora do Kaskada. É importante entender o fluxo de dados da entrada, para as linhas do tempo e, finalmente, para a saída.

Cada consulta começa a partir de uma ou mais fontes de dados de entrada. Cada entrada – sejam eventos chegando em um fluxo ou armazenados em uma tabela, ou fatos armazenados em uma tabela – pode ser convertida em uma linha do tempo sem perder um contexto importante, como o horário de cada evento.

A própria consulta é expressa como uma sequência de operações. Cada operação cria uma linha do tempo a partir de linhas do tempo. O resultado da operação final é usado como resultado da consulta. Assim, a consulta produz uma linha do tempo que pode ser discreta ou contínua.

O resultado de uma consulta é uma linha do tempo, que pode ser enviada para um coletor. As linhas gravadas no coletor podem ser um histórico que reflete as alterações em uma linha do tempo ou um instantâneo que reflete os valores em um ponto específico no tempo.

Inserindo cronogramas

Antes de uma consulta ser executada, cada entrada é mapeada para uma linha do tempo. Cada entrada – sejam eventos de um fluxo ou tabela ou fatos em uma tabela – pode ser mapeada para uma linha do tempo sem perder as informações temporais importantes, como quando os eventos aconteceram. Os eventos tornam-se linhas de tempo discretas, com o(s) valor(es) de cada evento ocorrendo no momento do evento. Os fatos tornam-se linhas de tempo contínuas, refletindo o tempo durante o qual cada fato se aplica. Ao representar sem perdas todos os tipos de entradas temporais, as linhas de tempo permitem que as consultas se concentrem na computação em vez do tipo de entrada.

Saída de cronogramas

Depois de executar uma consulta, a linha do tempo resultante deve ser enviada para um sistema externo para consumo. O coletor para cada destino permite a configuração da gravação de dados, com especificidades dependendo do coletor e do destino (consulte esta documentação do conector para mais).

Existem várias opções para converter a linha do tempo em linhas de dados, afetando o número de linhas produzidas:

1. Inclua todo o histórico de alterações em um intervalo ou apenas um instantâneo do valor em algum momento.
2. Inclua apenas eventos (mudanças) que ocorrem após um determinado período de tempo na saída.
3. Inclua apenas eventos (alterações) até um horário específico na saída.

Um histórico completo de alterações ajuda a visualizar ou identificar padrões nos valores do usuário ao longo do tempo. Por outro lado, um instantâneo em um horário específico é útil para painéis online ou para classificar usuários semelhantes.

A inclusão de eventos após um certo tempo reduz o tamanho da saída quando o destino já possui dados até aquele momento ou quando os pontos anteriores são irrelevantes. Isso é particularmente útil ao executar novamente uma consulta para materializar em um armazenamento de dados.

A inclusão de eventos até um horário específico também limita o tamanho da saída e permite a escolha de um instantâneo pontual. Com a execução incremental, selecionar um horário ligeiramente anterior ao horário atual reduz o processamento tardio de dados.

As opções “alterado desde” e “atualizado” são especialmente úteis com a execução incremental, que discutiremos em um próximo artigo.

História

O histórico – o conjunto de todos os pontos na linha do tempo – é útil quando você se preocupa com pontos passados. Por exemplo, isso pode ser necessário para visualizar ou identificar padrões de como os valores de cada usuário mudam ao longo do tempo. O histórico é particularmente útil para gerar exemplos de treinamento a serem usados na criação de um modelo.

Qualquer linha do tempo pode ser produzida como um histórico. Para uma linha do tempo discreta, o histórico é a coleção de eventos na linha do tempo. Para uma linha de tempo contínua, o histórico contém os pontos nos quais um valor muda – é efetivamente um changelog.

Instantâneos

Um instantâneo – o valor de cada entidade em um ponto específico no tempo – é útil quando você se preocupa apenas com os valores mais recentes. Por exemplo, ao atualizar um painel ou preencher um armazenamento de recursos para conectar-se ao serviço de modelo.

Qualquer linha do tempo pode ser gerada como um instantâneo. Para uma linha do tempo discreta, o instantâneo inclui linhas para cada evento que está acontecendo naquele momento. Para uma linha de tempo contínua, o instantâneo inclui uma linha para cada entidade com o valor dessa entidade naquele momento.

Conclusão

Esta postagem no blog destacou a importância dos recursos temporais ao criar modelos de ML a partir de dados baseados em eventos. O tempo e o contexto temporal dos eventos são críticos para ver os padrões na atividade. Este post introduziu a abstração da linha do tempo, que permite trabalhar com os eventos e o contexto temporal. As linhas de tempo organizam os dados por tempo e entidade, fornecendo uma estrutura mais adequada para dados baseados em eventos em comparação com multiconjuntos.

A abstração da linha do tempo é uma progressão natural no processamento de fluxo, permitindo que você raciocine sobre o tempo e as relações de causa e efeito com mais eficiência. Também exploramos o fluxo de dados em uma consulta temporal, da entrada à saída, e discutimos as várias opções de saída de cronogramas para sistemas externos.

Em vez de aplicar uma consulta tabular (estática) a uma sequência de instantâneos, o Kaskada opera no histórico (o fluxo de mudança). Isso torna natural operar no tempo entre os instantâneos, em vez de apenas nos dados contidos no instantâneo. O uso de linhas de tempo como abstração principal simplifica o trabalho com dados baseados em eventos e permite transições contínuas entre fluxos e tabelas.

Você pode iniciar experimentando suas próprias consultas temporais hoje. Junte-se à comunidade Slack e deixe-nos saber o que você pensa sobre a abstração da linha do tempo. Em uma próxima postagem, vamos nos aprofundar na linguagem de consulta Kaskada e seus recursos em consultas temporais expressivas.

Por Ben Chambers e Therapon Skoteiniotis, DataStax