Marcas temporales y la comuna ROWTIME - Guía para desarrolladores de Amazon Kinesis Data Analytics SQL para aplicaciones
Descripción de los distintos tiempos en análisis de streaming

Tras considerarlo detenidamente, hemos decidido interrumpir Amazon Kinesis Data Analytics SQL para aplicaciones en dos pasos:

1. A partir del 15 de octubre de 2025, no podrá crear nuevos Kinesis Data Analytics SQL para aplicaciones.

2. Eliminaremos sus aplicaciones a partir del 27 de enero de 2026. No podrá iniciar ni utilizar Amazon Kinesis Data Analytics SQL para aplicaciones. A partir de ese momento, el soporte para Amazon Kinesis Data Analytics dejará SQL de estar disponible. Para obtener más información, consulte Suspensión de Amazon Kinesis Data Analytics SQL for Applications.

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.

Marcas temporales y la comuna ROWTIME

Las secuencias en la aplicación incluyen una columna especial llamada ROWTIME. Almacena una marca temporal cuando Amazon Kinesis Data Analytics inserta una fila en la primera secuencia en la aplicación. ROWTIME refleja la marca temporal en la que Amazon Kinesis Data Analytics insertó un registro en la primera secuencia en la aplicación después de leer desde el origen de streaming. Este valor ROWTIME se mantiene en toda su aplicación.

nota

Cuando se bombean registros de una secuencia en la aplicación a otra, no es necesario copiar la columna ROWTIME porque ya lo hace Amazon Kinesis Data Analytics.

Amazon Kinesis Data Analytics garantiza que los valores de ROWTIME aumentan de forma monotómica. Puede utilizar esta marca temporal en las consultas en ventana basadas en el tiempo. Para obtener más información, consulte Consultas en ventana.

Puede tener acceso a la columna ROWTIME en la instrucción SELECT al igual que con cualquier otra columna de la secuencia en la aplicación. Por ejemplo:

SELECT STREAM ROWTIME, 
              some_col_1, 
              some_col_2
FROM  SOURCE_SQL_STREAM_001

Descripción de los distintos tiempos en análisis de streaming

Además de ROWTIME, existen otros tipos de tiempo en aplicaciones de streaming en tiempo real. Estos son:

  • Tiempo de eventos: la marca temporal de cuando se produjo el evento. A esto también se le llama el lado de tiempo del cliente. Suele ser conveniente utilizar estos momentos en análisis, ya que es el momento en el que se produjo un evento. No obstante, muchas fuentes de eventos como, por ejemplo, clientes de teléfonos móviles y web, no tienen relojes de confianza, lo que puede provocar tiempos inexactos. Además, los problemas de conectividad pueden hacer que los registros aparezcan en la secuencia y no lo en el mismo orden los eventos.

     

  • Tiempo de ingestión: la marca temporal de cuándo se añadió un registro a un origen de streaming. Amazon Kinesis Data Streams incluye un campo llamado APPROXIMATE_ARRIVAL_TIME en todos los registros que proporciona esta marca temporal. Esto también se denomina a veces tiempo del servidor. Este tiempo de ingestión suele ser una aproximación cercana al tiempo de evento. Si existe algún tipo de retraso en la adquisición de registros en la secuencia, se pueden producir inexactitudes, que suelen ser raras. Además, el tiempo de ingestión no suele estar fuera de lugar, si bien eso puede ocurrir debido a la naturaleza distribuida del streaming de datos. Por lo tanto, el tiempo de ingestión es un reflejo bastante preciso y en orden del tiempo de evento.

     

  • Tiempo de procesamiento: la marca temporal de cuando Amazon Kinesis Data Analytics inserta un fila en la primera secuencia en la aplicación. Amazon Kinesis Data Analytics proporciona esta marca temporal en la columna ROWTIME de cada secuencia en la aplicación. El tiempo de procesamiento aumenta siempre de forma monótona. Sin embargo, no será preciso si la aplicación se rezaga. (Si una aplicación se rezaga, el tiempo de procesamiento no refleja con precisión la hora del evento). Este ROWTIME es preciso en relación con el reloj, pero podría no ser el momento en el que el evento en que el evento realmente ocurrió.

Utilizar cada uno de estos tiempos en las consultas en ventana basadas en el tiempo tiene ventajas y desventajas. Le recomendamos que elija uno o varios de estos tiempos, y una estrategia para abordar las posibles desventajas en función de su caso de uso.

nota

Si utiliza ventanas basadas en filas, el tiempo no será un problema y puede ignorar esta sección.

Recomendamos una estrategia de dos ventanas que utilice dos ventanas basadas en el tiempo: una ROWTIME y una para los otros tiempos (tiempo de ingestión o de evento).

  • Utilice ROWTIME como la primera ventana, que controla la frecuencia con la que la consulta emite los resultados, tal y como se muestra en el siguiente ejemplo. No se utiliza como tiempo lógico.

  • Utilice uno de los otros tiempos que es el tiempo lógico que desea asociar a su análisis. Este tiempo representa cuándo se produjo el evento. En el siguiente ejemplo, el objetivo de análisis es agrupar los registros y devolver un recuento por cada símbolo.

La ventaja de esta estrategia es que puede utilizar una hora que represente cuándo se produjo el evento. Puede gestionar adecuadamente situaciones en las que la aplicación se queda rezagada o cuando los eventos llegan desordenados. Si la aplicación se rezaga al traer registros en la secuencia en la aplicación, estos se siguen agrupando por el momento lógico en la segunda ventana. La consulta utiliza ROWTIME para garantizar el orden de procesamiento. Los registros que están retrasados (la marca temporal de ingestión muestra un valor anteriores comparación con el ROWTIME valor) también se procesan correctamente.

Considere realizar la siguiente consulta con a la secuencia de demostración utilizada en el ejercicio de introducción. La consulta utiliza la cláusula GROUP BY y emite el recuento de cada símbolo en una ventana de saltos de un minuto. 

CREATE OR REPLACE STREAM "DESTINATION_SQL_STREAM" 
    ("ingest_time"    timestamp,
    "APPROXIMATE_ARRIVAL_TIME" timestamp,
    "ticker_symbol"  VARCHAR(12), 
    "symbol_count"        integer);
            
            
CREATE OR REPLACE PUMP "STREAM_PUMP" AS
    INSERT INTO "DESTINATION_SQL_STREAM"
    SELECT STREAM STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '60' SECOND) AS "ingest_time",
        STEP("SOURCE_SQL_STREAM_001".APPROXIMATE_ARRIVAL_TIME BY INTERVAL '60' SECOND) AS "APPROXIMATE_ARRIVAL_TIME",
        "TICKER_SYMBOL",
        COUNT(*) AS "symbol_count"
    FROM "SOURCE_SQL_STREAM_001"
    GROUP BY "TICKER_SYMBOL",
        STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '60' SECOND),
        STEP("SOURCE_SQL_STREAM_001".APPROXIMATE_ARRIVAL_TIME BY INTERVAL '60' SECOND);

En GROUP BY, primero agrupe los registros según ROWTIME en una ventana de un minuto y, a continuación, según APPROXIMATE_ARRIVAL_TIME.

Los valores de marca temporal del resultado se redondean hacia abajo al intervalo de 60 segundos más próximo. El primer grupo de resultados emitido por la consulta muestra registros del primer minuto. El segundo grupo de resultados emitido muestra registros de los minutos siguientes según ROWTIME. El último registro indica que la aplicación se retrasó al traer el registro en la secuencia en la aplicación (muestra un valor ROWTIME con retraso en comparación la marca temporal de la ingestión).

ROWTIME                  INGEST_TIME     TICKER_SYMBOL  SYMBOL_COUNT

--First one minute window.
2016-07-19 17:05:00.0    2016-07-19 17:05:00.0    ABC      10
2016-07-19 17:05:00.0    2016-07-19 17:05:00.0    DEF      15
2016-07-19 17:05:00.0    2016-07-19 17:05:00.0    XYZ      6
–-Second one minute window.
2016-07-19 17:06:00.0    2016-07-19 17:06:00.0    ABC      11
2016-07-19 17:06:00.0    2016-07-19 17:06:00.0    DEF      11
2016-07-19 17:06:00.0    2016-07-19 17:05:00.0    XYZ      1  *** 

***late-arriving record, instead of appearing in the result of the 
first 1-minute windows (based on ingest_time, it is in the result 
of the second 1-minute window.

Puede combinar los resultados para obtener un recuento preciso por minuto insertando los resultados en una base de datos posterior. Por ejemplo, puede configurar la salida de la aplicación para conservar los resultados en una transmisión de entrega de Firehose que pueda escribir en una tabla de Amazon Redshift. Una vez que los resultados estén en la tabla de Amazon Redshift puede consultar la tabla para calcular el grupo de recuento total por Ticker_Symbol. En el caso de XYZ, el total es correcto (6+1), aunque un registro haya llegado tarde.