Concepts de requêtes planifiées

Chaîne de requête : il s'agit de la requête dont vous précalculez le résultat et que vous stockez dans un autre Timestream pour une table. LiveAnalytics Vous pouvez définir une requête planifiée en utilisant toute la SQL surface de Timestream for LiveAnalytics, ce qui vous permet d'écrire des requêtes avec des expressions tabulaires communes, des requêtes imbriquées, des fonctions de fenêtre ou tout autre type de fonction agrégée et scalaire prise en charge par Timestream pour le langage de requête. LiveAnalytics

Expression de planification : vous permet de spécifier le moment où vos instances de requête planifiées sont exécutées. Vous pouvez spécifier les expressions à l'aide d'une expression cron (telle qu'une exécution à 8 heures du matin UTC tous les jours) ou d'une expression de débit (telle qu'une exécution toutes les 10 minutes).

Configuration cible : vous permet de spécifier comment mapper le résultat d'une requête planifiée dans la table de destination dans laquelle les résultats de cette requête planifiée seront stockés.

Configuration des notifications -Timestream pour exécuter LiveAnalytics automatiquement les instances d'une requête planifiée en fonction de votre expression de planification. Vous recevez une notification pour chaque requête exécutée sur un SNS sujet que vous configurez lorsque vous créez une requête planifiée. Cette notification indique si l'instance a été exécutée avec succès ou si elle a rencontré des erreurs. En outre, il fournit des informations telles que les octets mesurés, les données écrites dans la table cible, l'heure du prochain appel, etc.

Voici un exemple de ce type de message de notification.

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

Ce message de notification bytesMetered contient les octets analysés par la requête sur la table source et dataWrites les octets écrits dans la table cible.

Emplacement du rapport d'erreur : les requêtes planifiées s'exécutent de manière asynchrone et stockent les données dans la table cible. Si une instance rencontre des erreurs (par exemple, des données non valides qui n'ont pas pu être stockées), les enregistrements contenant des erreurs sont consignés dans un rapport d'erreurs à l'emplacement du rapport d'erreurs que vous spécifiez lors de la création d'une requête planifiée. Vous spécifiez le compartiment S3 et le préfixe de l'emplacement. Timestream for LiveAnalytics ajoute le nom de la requête planifiée et l'heure d'invocation à ce préfixe pour vous aider à identifier les erreurs associées à une instance spécifique d'une requête planifiée.

Balisage : vous pouvez éventuellement spécifier des balises que vous pouvez associer à une requête planifiée. Pour plus de détails, voir Tagging Timestream for Resources. LiveAnalytics

Exemple

Dans l'exemple suivant, vous calculez un agrégat simple à l'aide d'une requête planifiée :

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- Dans cet exemple, vous remarquerez que la requête accepte un paramètre nommé spécial@scheduled_runtime. Il s'agit d'un paramètre spécial (de type Timestamp) que le service définit lors de l'appel d'une instance spécifique d'une requête planifiée afin que vous puissiez contrôler de manière déterministe la plage de temps pour laquelle une instance spécifique d'une requête planifiée analyse les données de la table source. Vous pouvez l'utiliser @scheduled_runtime dans votre requête à n'importe quel endroit où un type d'horodatage est attendu.

Prenons un exemple où vous définissez une expression de planification : cron (0/5 * * * ? *) où la requête planifiée sera exécutée à la minute 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55 de chaque heure. Pour l'instance déclenchée le 2021-12-01 00:05:00, le paramètre @scheduled_runtime est initialisé à cette valeur, de telle sorte que l'instance fonctionne actuellement sur des données comprises entre le 2021-11-30 23:55:00 et le 2021-12-01 00:06:00.

Instances dont les plages temporelles se chevauchent : comme vous le verrez dans cet exemple, deux instances suivantes d'une requête planifiée peuvent se chevaucher dans leurs plages temporelles. C'est quelque chose que vous pouvez contrôler en fonction de vos besoins, des prédicats temporels que vous spécifiez et de l'expression de planification. Dans ce cas, ce chevauchement permet à ces calculs de mettre à jour les agrégats en fonction des données dont l'arrivée a été légèrement retardée, jusqu'à 10 minutes dans cet exemple. L'exécution de la requête déclenchée le 2021-12-01 00:00:00 couvrira la plage de temps 2021-11-30 23:50:00 à 2021-12-30 00:01:00 et l'exécution de la requête déclenchée le 2021-12-01 00:05:00 couvrira la plage 2021-11-30 23:55:00 à 2021-12-01 00:06:00.

Pour garantir l'exactitude et s'assurer que les agrégats stockés dans la table cible correspondent aux agrégats calculés à partir de la table source, Timestream for LiveAnalytics garantit que le calcul du 2021-12-01 00:05:00 ne sera effectué qu'une fois le calcul du 2021-12-01 00:00:00 terminé. Les résultats de ces derniers calculs peuvent mettre à jour tout agrégat déjà matérialisé si une nouvelle valeur est générée. En interne, Timestream for LiveAnalytics utilise des versions d'enregistrement où les enregistrements générés par les dernières instances d'une requête planifiée se verront attribuer un numéro de version supérieur. Par conséquent, les agrégats calculés par l'appel au 2021-12-01 00:05:00 peuvent mettre à jour les agrégats calculés par l'appel au 2021-12-01 00:00:00, en supposant que des données plus récentes soient disponibles dans la table source.

Déclencheurs automatiques ou déclencheurs manuels - Une fois qu'une requête planifiée est créée, Timestream for exécute LiveAnalytics automatiquement les instances en fonction du calendrier spécifié. Ces déclencheurs automatisés sont entièrement gérés par le service.

Toutefois, il peut arriver que vous souhaitiez lancer manuellement certaines instances d'une requête planifiée. Par exemple, si une instance spécifique a échoué lors d'une exécution de requête, si des données sont arrivées en retard ou des mises à jour sont apparues dans la table source après l'exécution de la planification automatique, ou si vous souhaitez mettre à jour la table cible pour les plages de temps non couvertes par les exécutions de requêtes automatisées (par exemple, pour les plages de temps avant la création d'une requête planifiée).

Vous pouvez utiliser le ExecuteScheduledQuery API pour lancer manuellement une instance spécifique d'une requête planifiée en transmettant le InvocationTime paramètre, qui est une valeur utilisée pour le paramètre @scheduled_runtime. Voici quelques points importants à prendre en compte lors de l'utilisation du ExecuteScheduledQuery API :