Tras considerarlo detenidamente, hemos decidido dejar de utilizar Amazon Kinesis Data Analytics para aplicaciones SQL:
1. A partir del **1 de septiembre de 2025,** no proporcionaremos ninguna corrección de errores para las aplicaciones de Amazon Kinesis Data Analytics for SQL porque tendremos un soporte limitado debido a la próxima discontinuación.
2. A partir del **15 de octubre de 2025,** no podrá crear nuevas aplicaciones de Kinesis Data Analytics for SQL.
3. Eliminaremos sus aplicaciones a partir del **27 de enero de 2026**. No podrá iniciar ni utilizar sus aplicaciones de Amazon Kinesis Data Analytics para SQL. A partir de ese momento, el servicio de soporte de Amazon Kinesis Data Analytics para SQL dejará de estar disponible. Para obtener más información, consulte [Retirada de las aplicaciones de Amazon Kinesis Data Analytics para SQL](discontinuation.md).
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](windowed-sql.md).
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](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/get-started-exercise.html). 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 que conserve los resultados en un flujo 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\$11), aunque un registro haya llegado tarde.