Para recursos semelhantes aos do Amazon Timestream para LiveAnalytics, considere o Amazon Timestream para InfluxDB. Ele oferece ingestão de dados simplificada e tempos de resposta de consulta de um dígito em milissegundos para análises em tempo real. Saiba mais aqui.
Conceitos de consulta programada
String de consulta - essa é a consulta cujo resultado você está pré-computando e armazenando em outra tabela Timestream para LiveAnalytics. Você pode definir uma consulta agendada usando toda a área de superfície SQL do Timestream for LiveAnalytics, que fornece a flexibilidade de escrever consultas com expressões de tabela comuns, consultas aninhadas, funções de janela ou qualquer tipo de função agregada e escalar compatível com a linguagem de consulta Timestream para LiveAnalytics.
Expressão de agendamento - permite que você especifique quando suas instâncias de consulta agendadas serão executadas. Você pode especificar as expressões usando uma expressão cron (como executar às 8h UTC todos os dias) ou uma expressão rate (como executar a cada 10 minutos).
Configuração de destino - permite especificar como mapear o resultado de uma consulta agendada na tabela de destino em que os resultados dessa consulta agendada serão armazenados.
Configuração de notificação - o Timestream para LiveAnalytics executa automaticamente instâncias de uma consulta agendada com base em sua expressão de agendamento. Ao criar uma consulta agendada, você recebe uma notificação para cada consulta realizada em um tópico do SNS que você definiu. Essa notificação especifica se a instância foi executada com sucesso ou se encontrou algum erro. Além disso, ele fornece informações como os bytes medidos, os dados gravados na tabela de destino, a hora da próxima invocação e assim por diante.
A seguir está um exemplo deste tipo de mensagem de notificação.
{ "type":"AUTO_TRIGGER_SUCCESS", "arn":"arn:aws:timestream:us-east-1:123456789012:scheduled-query/ PT1mPerMinutePerRegionMeasureCount-9376096f7309", "nextInvocationEpochSecond":1637302500, "scheduledQueryRunSummary": { "invocationEpochSecond":1637302440, "triggerTimeMillis":1637302445697, "runStatus":"AUTO_TRIGGER_SUCCESS", "executionStats": { "executionTimeInMillis":21669, "dataWrites":36864, "bytesMetered":13547036820, "recordsIngested":1200, "queryResultRows":1200 } } }
Nessa mensagem de notificação, bytesMetered estão os bytes que a consulta examinou na tabela de origem e dataWrites são os bytes gravados na tabela de destino.
nota
Caso você consuma essas notificações de forma programática, esteja ciente de que novos campos poderão ser incluídos na mensagem de notificação no futuro.
Local do relatório de erros - as consultas agendadas são executadas e armazenadas de forma assíncrona na tabela de destino. Caso uma instância encontre algum erro (como dados inválidos que não puderam ser armazenados), os registros que apresentaram falhas serão registrados em um relatório de erros, no local indicado para o relatório de erros ao criar uma consulta agendada. Você especifica o bucket S3 e o prefixo para o local. O Timestream para LiveAnalytics acrescenta o nome da consulta agendada e a hora da invocação a esse prefixo para ajudar você a identificar os erros associados a uma instância específica de uma consulta agendada.
Marcação - como opção, você pode especificar tags que podem ser associadas a uma consulta agendada. Para mais detalhes, consulte Como marcar o Timestream para recursos do LiveAnalytics.
Exemplo
No exemplo a seguir, você calcula um agregado simples usando uma consulta agendada:
SELECT region, bin(time, 1m) as minute, SUM(CASE WHEN measure_name = 'metrics' THEN 20 ELSE 5 END) as numDataPoints FROM raw_data.devops WHERE time BETWEEN @scheduled_runtime - 10m AND @scheduled_runtime + 1m GROUP BY bin(time, 1m), region
@scheduled_runtime parameter- Neste exemplo, você notará que a consulta aceita um parâmetro com nome especial @scheduled_runtime. Esse é um parâmetro especial (do tipo Timestamp) que o serviço define ao invocar uma instância específica de uma consulta agendada. Assim, você pode controlar deterministicamente o intervalo de tempo durante o qual uma instância específica de uma consulta agendada analisa os dados na tabela de origem. Você pode usar @scheduled_runtime em sua consulta em qualquer local onde um tipo de carimbo de data/hora seja esperado.
Considere um exemplo em que você estabelece uma expressão de cronograma: cron (0/5 * * *? *) onde a consulta agendada será executada no minuto 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55 de cada hora. Para a instância que é acionada em 01/12/2021 00:05:00, o parâmetro @scheduled_runtime é inicializado com esse valor, de forma que a instância neste momento opere com dados no intervalo 2021-11-30 23:55:00 a 2021-12-01 00:06:00.
Instâncias com intervalos de tempo sobrepostos - como você verá neste exemplo, duas instâncias subsequentes de uma consulta agendada podem se sobrepor em seus intervalos de tempo. Trata-se de um aspecto que pode ser regulado conforme suas exigências, os critérios temporais que você determina e a configuração do cronograma. Nesse caso, essa sobreposição permite que esses cálculos atualizem os agregados com base em qualquer dado cuja chegada tenha sido um pouco atrasada, até 10 minutos neste exemplo. A execução da consulta acionada em 2021-12-01 00:00:00 cobrirá o intervalo de tempo 2021-11-30 23:50:00 a 2021-12-30 00:01:00 e a execução da consulta acionada em 2021-12-01 00:05:00 cobrirá o intervalo 2021-11-30 23:55:00 a 2021-12-01 00:06:00.
Para garantir a exatidão e garantir que os agregados armazenados na tabela de destino correspondam aos agregados calculados a partir da tabela de origem, o Timestream para LiveAnalytics garante que o cálculo em 01/12/2021 00:05:00 seja executado somente após a conclusão do cálculo em 01/12/2021 00:00:00. Os resultados dos últimos cálculos podem atualizar qualquer agregado materializado anteriormente se um valor mais novo for gerado. Internamente, o Timestream para LiveAnalytics usa versões de registro em que os registros gerados pelas últimas instâncias de uma consulta agendada receberão um número de versão maior. Portanto, os agregados calculados pela invocação em 01/12/2021 00:05:00 podem atualizar os agregados calculados pela invocação em 01/12/2021 00:00:00, desde que a tabela de origem contenha dados mais recentes.
Acionadores automáticos versus acionadores manuais- depois que uma consulta agendada for criada, o Timestream for LiveAnalytics executará automaticamente as instâncias com base na programação especificada. Esses gatilhos automatizados são gerenciados inteiramente pelo serviço.
No entanto, pode haver cenários em que talvez você queira iniciar manualmente algumas instâncias de uma consulta programada. Os exemplos abrangem situações como a falha de uma instância específica ao executar uma consulta, a chegada tardia de dados ou atualizações na tabela de origem após a execução automática do agendamento. Também incluem a necessidade de atualizar a tabela de destino para períodos que não são atendidos pelas execuções de consultas automatizadas, como intervalos anteriores à criação de uma consulta agendada.
Você pode usar a API ExecuteScheduledQuery para iniciar manualmente uma instância específica de uma consulta agendada transmitindo o parâmetro InvocationTime, que é um valor usado para o parâmetro @scheduled_runtime. Ao usar a API ExecuteScheduledQuery, leve em consideração o seguinte:
-
Se você estiver acionando várias dessas invocações, precisará garantir que essas invocações não gerem resultados em intervalos de tempo sobrepostos. Caso não seja possível garantir períodos sem sobreposição, assegure que as execuções das consultas sejam iniciadas de forma sequencial, uma após a outra. Ao iniciar várias execuções de consulta simultaneamente, com intervalos de tempo sobrepostos, você poderá observar falhas de acionamento e conflitos de versão nos relatórios de erro dessas execuções.
-
É possível iniciar as invocações com qualquer valor de timestamp para @scheduled_runtime. Assim, cabe a você estabelecer corretamente os valores para que os períodos adequados sejam atualizados na tabela de destino, correspondente aos períodos em que os dados foram atualizados na tabela de origem.
-
A API ExecuteScheduledQuery opera de forma assíncrona. Após uma chamada bem-sucedida, o serviço envia uma resposta de 200 e prossegue com a execução da consulta. No entanto, se houver várias execuções de consultas programadas em execução simultânea, antecipe possíveis atrasos na execução de execuções programadas acionadas manualmente.