Après mûre réflexion, nous avons décidé de mettre fin à Amazon Kinesis Data Analytics pour les applications SQL :
1. À compter du **1er septembre 2025,** nous ne fournirons aucune correction de bogue pour les applications Amazon Kinesis Data Analytics for SQL, car leur support sera limité, compte tenu de l'arrêt prochain.
2. À compter du **15 octobre 2025,** vous ne pourrez plus créer de nouvelles applications Kinesis Data Analytics for SQL.
3. Nous supprimerons vos candidatures à compter **du 27 janvier 2026**. Vous ne serez pas en mesure de démarrer ou d'utiliser vos applications Amazon Kinesis Data Analytics for SQL. Support ne sera plus disponible pour Amazon Kinesis Data Analytics for SQL à partir de cette date. Pour de plus amples informations, veuillez consulter [Arrêt d'Amazon Kinesis Data Analytics pour les applications SQL](discontinuation.md).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Horodatages et colonne ROWTIME
Les flux intégrés à l'application incluent une colonne spéciale appelée `ROWTIME`. Celle-ci stocke un horodatage quand Amazon Kinesis Data Analytics insère une ligne dans le premier flux intégré à l’application. `ROWTIME` reflète l’horodatage du moment où Amazon Kinesis Data Analytics a inséré un enregistrement dans le premier flux intégré à l’application après la lecture de la source de streaming. Cette valeur `ROWTIME` est ensuite gérée tout au long de votre application.
**Note**
Lorsque vous pompez des enregistrements d’un flux intégré à l’application dans un autre, vous n’avez pas besoin de copier explicitement la colonne `ROWTIME` ; Amazon Kinesis Data Analytics copie cette colonne pour vous.
Amazon Kinesis Data Analytics s’assure que les valeurs `ROWTIME` augmentent de façon monotone. Vous utilisez cet horodatage dans des requêtes à fenêtres temporelles. Pour de plus amples informations, veuillez consulter [Requêtes à fenêtres](windowed-sql.md).
Vous pouvez accéder à la colonne ROWTIME dans votre instruction `SELECT` comme à toutes les autres colonnes dans votre flux intégré à l'application. Par exemple :
```
SELECT STREAM ROWTIME,
some_col_1,
some_col_2
FROM SOURCE_SQL_STREAM_001
```
## Présentation des différents types d'heure dans les analyses de diffusion
En plus de `ROWTIME`, il existe d'autres types d'heure dans les applications de diffusion en temps réel. Il s'agit des types suivants :
+ **Heure de l’événement** : Horodatage du moment où l’événement s’est produit. Ce type d'heure est parfois appelé *heure côté client*. Il est souvent préférable d'utiliser cette heure dans les analyses car il s'agit du moment où un événement s'est produit. Cependant, de nombreuses sources d'événements, telles que les téléphones mobiles et les clients web, n'ont pas horloges fiables, ce qui peut entraîner des heures inexactes. En outre, des problèmes de connectivité peuvent provoquer le fait que des enregistrements figurant dans un flux ne sont pas dans le même ordre que celui où les événements se sont produits.
+ **Heure d’intégration** : Horodatage auquel l’enregistrement a été ajouté à la source de streaming. Amazon Kinesis Data Streams inclut un champ appelé `APPROXIMATE_ARRIVAL_TIME` dans chaque enregistrement qui fournit cet horodatage. Ce type d'heure est parfois appelé *heure côté serveur*. Cette heure d'intégration est souvent une approximation proche de l'heure de l'événement. Si un retard a lieu dans l'intégration d'enregistrement dans le flux, cela peut conduire à des inexactitudes, qui sont généralement rares. De plus, l'heure d'intégration est rarement dans le mauvais ordre, mais cela peut se produire en raison de la nature distribuée des données de diffusion. Par conséquent, l'heure d'intégration est la réflexion la plus exacte et dans l'ordre de l'heure de l'événement.
+ **Heure de traitement** : Horodatage auquel Amazon Kinesis Data Analytics insère une ligne dans le premier flux intégré à l’application. Amazon Kinesis Data Analytics fournit cet horodatage dans la colonne `ROWTIME` qui existe dans chaque flux intégré à l’application. L’heure de traitement augmente toujours de façon monotone. Mais elle ne sera pas exacte si votre application est en retard. (Si une application est en retard, l'heure de traitement ne reflète pas avec précision l'heure de l'événement). Cette valeur `ROWTIME` est très précise en ce qui concerne l'horloge, mais elle peut ne pas correspondre à l'heure où l'événement s'est réellement produit.
L'utilisation de chacun de ces types d'heure dans des requêtes à fenêtres temporelles présente des avantages et des inconvénients. Nous vous recommandons de sélectionner un ou plusieurs de ces types d'heure, et une stratégie pour traiter les inconvénients correspondant à votre scénario d'utilisation.
**Note**
Si vous utilisez des fenêtres basées sur les lignes, le temps ne constitue pas un problème et vous pouvez ignorer cette section.
Nous vous recommandons une stratégie à deux fenêtres qui utilise deux types d'heure, `ROWTIME` et l'un des autres types d'heure (heure d'intégration ou de l'événement).
+ Utilisez `ROWTIME`comme première fenêtre, qui contrôle la fréquence à laquelle la requête émet les résultats, comme illustré dans l'exemple suivant. Cette valeur n'est pas utilisée comme une heure logique.
+ Utilisez l'un des autres types d'heure comme heure logique à associer à vos analyses. Cette heure représente le moment où l'événement s'est produit. Dans l'exemple suivant, l'objectif de l'analyse est de regrouper les enregistrements et de renvoyer un comptage par symbole boursier.
L'avantage de cette stratégie est qu'elle peut utiliser une heure qui représente le moment où l'événement s'est produit. Elle peut correctement procéder au traitement quand votre application est en retard ou quand des événements arrivent dans le mauvais ordre. Si l'application est en retard pour insérer des enregistrements dans le flux intégré à l'application, les enregistrements sont quand-même regroupés par heure logique dans la deuxième fenêtre. La requête utilise `ROWTIME` pour garantir l'ordre de traitement. Les enregistrements qui sont en retard (l'horodatage d'intégration affiche une valeur antérieure à celle de `ROWTIME`) sont également traités avec succès.
Envisagez d'exécuter la requête suivante sur le flux de démonstration utilisé dans l'[exercice de mise en route](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/get-started-exercise.html). La requête utilise la clause `GROUP BY` et renvoie un nombre de symboles boursiers dans une fenêtre bascule d'une minute.
```
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);
```
Dans `GROUP BY`, vous regroupez d'abord les enregistrements en fonction de `ROWTIME` dans une fenêtre d'une minute, puis par `APPROXIMATE_ARRIVAL_TIME`.
Les valeurs d'horodatage dans le résultat sont arrondies à l'intervalle de 60 secondes inférieur le plus proche. Le résultat du premier groupe renvoyé par la requête affiche les enregistrements dans la première minute. Le deuxième groupe de résultats renvoyé affiche les enregistrements de la minute suivante en fonction de `ROWTIME`. Le dernier enregistrement indique que l'application était en retard pour insérer l'enregistrement dans le flux intégré à l'application (il affiche une valeur `ROWTIME` en retard par rapport à l'horodatage d'intégration).
```
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.
```
Vous pouvez combiner les résultats pour obtenir un comptage exact final par minute en transmettant les résultats à une base de données en aval. Par exemple, vous pouvez configurer la sortie de l'application pour conserver les résultats dans un flux de diffusion Firehose qui peut écrire dans une table Amazon Redshift. Une fois que les résultats sont dans une table Amazon Redshift, vous pouvez interroger la table pour calculer le groupe de comptage total par `Ticker_Symbol`. Dans la cas d'`XYZ`, le total est exact (6\$11), même si un enregistrement est arrivé en retard.