Horodatages et colonne ROWTIME - Guide du développeur d'Amazon Kinesis Data Analytics SQL pour applications
Présentation des différents types d'heure dans les analyses de diffusion

Pour les nouveaux projets, nous vous recommandons d'utiliser le nouveau service géré pour Apache Flink Studio plutôt que Kinesis Data Analytics SQL for Applications. Le service géré pour Apache Flink Studio allie facilité d’utilisation et capacités analytiques avancées, ce qui vous permet de créer des applications sophistiquées de traitement des flux en quelques minutes.

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.

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 ROWTIMEcomme 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. 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+1), même si un enregistrement est arrivé en retard.