Conceptos relacionados con las consultas programadas - Amazon Timestream

Para obtener capacidades similares a las de Amazon Timestream, considere Amazon Timestream LiveAnalytics para InfluxDB. Ofrece una ingesta de datos simplificada y tiempos de respuesta a las consultas en milisegundos de un solo dígito para realizar análisis en tiempo real. Obtenga más información aquí.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Conceptos relacionados con las consultas programadas

Cadena de consulta: se trata de la consulta cuyo resultado usted está precalculando y almacenando en otra tabla de Timestream para LiveAnalytics. Puede definir una consulta programada utilizando toda la superficie de SQL de Timestream para LiveAnalytics, lo que le proporciona la flexibilidad de escribir consultas con expresiones de tabla comunes, consultas anidadas, funciones de ventana o cualquier tipo de función agregada y escalar que sea compatible con el lenguaje de consulta de Timestream para LiveAnalytics.

Expresión de programación: le permite especificar cuándo se ejecutarán las instancias de consulta programada. Puede especificar las expresiones mediante una expresión cron (como ejecutar todos los días a las 8 a. m. UTC) o una expresión de frecuencia (como ejecutar cada 10 minutos).

Configuración de destino: le permite especificar cómo asignar el resultado de una consulta programada a la tabla de destino, donde se almacenarán los resultados de dicha consulta.

Configuración de notificaciones: Timestream para LiveAnalytics ejecuta automáticamente las instancias de una consulta programada en función de la expresión de programación. Recibirá una notificación por cada consulta de este tipo que se ejecute en un tema de SNS que configure al crear una consulta programada. Esta notificación especifica si la instancia se ejecutó correctamente o si se produjo algún error. Además, proporciona información como los bytes medidos, los datos escritos en la tabla de destino, la hora de la próxima invocación, etc.

A continuación, se muestra un ejemplo de este tipo de mensaje de notificación.

{ "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 } } }

En este mensaje de notificación, bytesMetered son los bytes que la consulta escaneó en la tabla de origen y dataWrites son los bytes escritos en la tabla de destino.

nota

Si consume estas notificaciones mediante programación, tenga en cuenta que podrían añadirse nuevos campos al mensaje de notificación en el futuro.

Ubicación del informe de errores: las consultas programadas se ejecutan y almacenan datos en la tabla de destino, todo de forma asíncrona. Si una instancia encuentra algún error (por ejemplo, datos no válidos que no se pudieron almacenar), los registros que detectaron errores se escriben en un informe de errores en la ubicación del informe de errores que usted especifique al crear una consulta programada. Debe especificar el bucket de S3 y el prefijo de la ubicación. Timestream para LiveAnalytics añade el nombre de la consulta programada y la hora de invocación a este prefijo para ayudarle a identificar los errores asociados a una instancia específica de una consulta programada.

Etiquetado: si lo desea, es posible especificar etiquetas que puede asociar a una consulta programada. Para obtener más información, consulte Etiquetar recursos de Timestream para LiveAnalytics.

Ejemplo

En el siguiente ejemplo, se calcula una agregación simple mediante una consulta programada:

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: en este ejemplo, observará que la consulta acepta un parámetro con un nombre especial @scheduled_runtime. Se trata de un parámetro especial (del tipo marca de tiempo) que el servicio establece al invocar una instancia específica de una consulta programada, de forma que se pueda controlar de forma determinista el intervalo de tiempo durante el que una instancia específica de una consulta programada analiza los datos de la tabla de origen. Puede usar @scheduled_runtime en su consulta en cualquier ubicación en la que se espere un tipo de marca de tiempo.

Considere un ejemplo en el que se establece una expresión de programación: cron(0/5 * * * ? *) donde la consulta programada se ejecutará en los minutos 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55 de cada hora. Para la instancia que se activa el 01/12/2021 a las 00:05:00, el parámetro @scheduled_runtime se inicializa con este valor, de forma que la instancia en este momento trabaje con los datos comprendidos en el intervalo del 30/11/2021 a las 23:55:00 al 01/12/2021 a las 00:06:00.

Instancias con intervalos de tiempo superpuestos: como verá en este ejemplo, dos instancias sucesivas de una consulta programada pueden superponerse en sus intervalos de tiempo. Esto es algo que puede controlar en función de sus requisitos, los predicados de tiempo que especifique y la expresión de cronograma. En este caso, esta superposición permite que estos cálculos actualicen las agregaciones en función de cualquier dato que haya llegado con un ligero retraso (hasta 10 minutos en este ejemplo). La ejecución de la consulta que se desencadena el 01/12/2021 a las 00:00:00 cubrirá el intervalo de tiempo de las 23:50:00 del 30/11/2021 a las 00:01:00 del 30/12/2021, y la ejecución de la consulta que se desencadena el 01/12/2021 a las 00:05:00 cubrirá el intervalo comprendido entre las 23:55:00 del 30/11/2021 y las 00:06:00 del 01/12/2021.

Para garantizar la exactitud y asegurarse de que las agregaciones almacenadas en la tabla de destino coinciden con aquellas calculadas a partir de la tabla de origen, Timestream para LiveAnalytics garantiza que el cálculo del 01/12/2021 a las 00:05:00 se realice solo después de que se haya completado el cálculo del 01/12/2021 a las 00:00:00. Los resultados de estos últimos cálculos pueden actualizar cualquier agregación previamente materializada si se genera un valor más nuevo. Internamente, Timestream para LiveAnalytics utiliza versiones de registros, en las que a los registros generados por las últimas instancias de una consulta programada se les asigna un número de versión superior. Por lo tanto, las agregaciones calculadas por la invocación del 01/12/2021 a las 00:05:00 pueden actualizar aquellas calculadas por la invocación del 01/12/2021 a las 00:00:00, suponiendo que haya datos más recientes disponibles en la tabla de origen.

Desencadenadores automáticos frente a desencadenadores manuales: después de crear una consulta programada, Timestream para LiveAnalytics ejecutará automáticamente las instancias según la programación especificada. Estos desencadenadores automáticos son administrados en su totalidad por el servicio.

Sin embargo, puede que haya situaciones en las que desee iniciar manualmente algunas instancias de una consulta programada. Entre los ejemplos se incluyen si una instancia específica falló en la ejecución de una consulta, si los datos llegaron tarde o si hubo actualizaciones en la tabla de origen tras la ejecución programada automática, o si desea actualizar la tabla de destino para intervalos de tiempo que no están cubiertos por las ejecuciones de consultas automatizadas (por ejemplo, para los intervalos de tiempo anteriores a la creación de una consulta programada).

Puede usar la API ExecuteScheduledQuery para iniciar manualmente una instancia específica de una consulta programada pasando el parámetro InvocationTime, que es un valor que se usa para el parámetro @scheduled_runtime. A continuación, presentamos algunas consideraciones importantes al utilizar la API ExecuteScheduledQuery:

  • Si va a desencadenar varias de estas invocaciones, debe asegurarse de que estas no generen resultados en intervalos de tiempo superpuestos. Si no puede garantizar que los intervalos de tiempo no se superpongan, asegúrese de que las ejecuciones se activen de manera secuencial una tras otra. Si inicia simultáneamente varias ejecuciones de consultas que se superponen en sus intervalos de tiempo, puede experimentar errores desencadenantes y, por lo tanto, conflictos de versiones en los informes de errores de estas ejecuciones de consultas.

  • Puede iniciar las invocaciones con cualquier valor de marca de tiempo para @scheduled_runtime. Por lo tanto, es su responsabilidad establecer los valores de manera adecuada para que los intervalos de tiempo adecuados se actualicen en la tabla derivada correspondiente a los intervalos en los que se actualizaron los datos en la tabla de origen.

  • La API ExecuteScheduledQuery funciona de forma asíncrona. Tras una llamada correcta, el servicio envía una respuesta 200 y procede a ejecutar la consulta. Sin embargo, si hay varias ejecuciones de consultas programadas ejecutándose simultáneamente, prevea posibles demoras en las ejecuciones programadas que se activan manualmente.