Simple Log Service:Scheduled SQL

Simple Log Service propose la fonctionnalité Scheduled SQL. Utilisez cette fonctionnalité pour analyser automatiquement les données à des heures planifiées et agréger les résultats en vue de leur stockage. Vous pouvez également l'utiliser pour projeter et filtrer les données. Cette rubrique présente le contexte, les fonctionnalités, la terminologie, les scénarios de planification et d'exécution, ainsi que les notes d'utilisation de Scheduled SQL.

Contexte

Les données temporelles, telles que les journaux et les métriques, peuvent s'accumuler en volumes excessifs. Par exemple, la génération de 10 millions d'enregistrements par jour représente environ 3,6 milliards d'enregistrements par an. La conservation des données à long terme nécessite un espace de stockage important. Réduire la période de rétention des données permet de diminuer l'espace requis et donc les coûts de stockage. Toutefois, cette approche peut entraîner la perte de données précieuses. De plus, de grands volumes de données peuvent dégrader les performances d'analyse.

Pour répondre à ces exigences, Simple Log Service met à disposition la fonctionnalité Scheduled SQL. Elle vous permet de compresser les données historiques haute précision en données basse précision et de stocker ces dernières sur le long terme. Après avoir activé Scheduled SQL, réduisez la période de rétention d'un Logstore ou d'un Metricstore source (par exemple à 15 jours) selon vos besoins métier, tout en définissant la période de rétention d'un Logstore ou d'un Metricstore de destination comme permanente. Cette approche réduit la latence lors de l'analyse des données conservées longtemps et diminue les coûts de stockage.

Fonctionnalités

Terminologie

• Tâche (Job) : chaque tâche Scheduled SQL correspond à un job. Un job inclut des informations telles que les configurations de calcul et de planification.

• Instance : un job Scheduled SQL génère des instances selon les configurations de planification. Chaque instance effectue un calcul SQL sur les données brutes et écrit les résultats dans le Logstore ou le Metricstore de destination.

• ID d'instance : identifiant unique d'une instance.

• Heure de création : moment où une instance est créée. Généralement, une instance est créée selon les règles de planification configurées. Si des données historiques doivent être traitées ou si une latence doit être compensée, une instance est créée immédiatement.

• Heure de début : moment où une instance commence à s'exécuter. En cas de nouvelle tentative d'un job, l'heure de début correspond au moment où la dernière instance du job commence son exécution.

• Heure de fin : moment où une instance arrête son exécution. En cas de nouvelle tentative d'un job, l'heure de fin correspond au moment où la dernière instance du job termine son exécution.

• Heure planifiée : heure à laquelle un job est programmé. L'heure planifiée d'une instance est générée selon les règles de planification du job, indépendamment du dépassement du délai, du retard ou du traitement de données historiques par l'instance précédente.

  Généralement, les heures planifiées des instances générées successivement sont consécutives, permettant aux instances successives de traiter un jeu de données complet.

• Fenêtre temporelle SQL : plage de temps des données analysées lors de l'exécution d'un job Scheduled SQL. Simple Log Service n'analyse pas les données en dehors de cette plage. Une fenêtre temporelle SQL est un intervalle fermé à gauche et ouvert à droite, calculé à partir de l'heure planifiée d'une instance. Elle est indépendante de l'heure de création et de l'heure de début de l'instance. Par exemple, si l'heure planifiée d'une instance est 2021/01/01 10:00:00 et que l'expression de la fenêtre temporelle SQL est [@m - 10m, @m), la fenêtre temporelle SQL de l'instance est [2021/01/01 09:50:00, 2021/01/01 10:00:00).

• Statut : état d'une instance Scheduled SQL. Une instance peut être dans l'état RUNNING, STARTING, SUCCEEDED ou FAILED.

• Exécution différée : paramètre configurable pour un job Scheduled SQL. Si vous définissez ce paramètre sur N, l'instance commence à s'exécuter N secondes après l'heure planifiée. Cela permet d'éviter des résultats de calcul inexacts dus à la latence des données. Si aucun délai n'est nécessaire, définissez le paramètre Delay Task sur 0 Seconds.

  Par exemple, si vous définissez le paramètre Specify Scheduling Interval sur Hourly et le paramètre Delay Task sur 30 Seconds, 24 instances sont générées par jour. Si l'heure planifiée d'une instance est 2021/4/6 12:00:00, l'heure de début de l'instance sera 2021/4/6 12:00:30.

Scénarios de planification et d'exécution

Chaque job peut générer plusieurs instances. Une seule instance d'un job peut être dans l'état RUNNING à la fois, que le job soit planifié normalement ou qu'une instance fasse l'objet d'une nouvelle tentative suite à une exception. Plusieurs instances ne peuvent pas s'exécuter simultanément. Les exemples suivants illustrent les scénarios typiques de planification et d'exécution :

• Scénario 1 : Différer l'exécution d'une instance

  L'heure planifiée d'une instance est générée à l'avance selon les règles de planification du job, indépendamment d'un éventuel retard d'exécution. Si une instance est retardée, les instances suivantes peuvent également l'être. Toutefois, ce retard peut être progressivement compensé par une exécution plus rapide des instances suivantes jusqu'à ce qu'une instance s'exécute à l'heure prévue.

  

• Scénario 2 : Planifier un job Scheduled SQL à partir d'un point historique

  Lors de la création d'un job Scheduled SQL, configurez des règles de planification pour permettre le traitement des données historiques. Lorsque le job est planifié pour le point de départ historique, une instance est générée pour traiter ces données. D'autres instances sont ensuite créées pour traiter les données historiques restantes. Les instances s'exécutent séquentiellement jusqu'à ce qu'une instance s'exécute à l'heure prévue.

  

• Scénario 3 : Planifier un job Scheduled SQL sur une période donnée

  Si vous souhaitez planifier un job pour traiter les journaux sur une période spécifique, indiquez cette période de planification. Si vous spécifiez une heure de fin de planification, le job ne génère plus d'instances après l'exécution de la dernière instance. L'heure planifiée de la dernière instance ne peut pas être identique ou postérieure à l'heure de fin de planification.

  

• Scénario 4 : Modifier les configurations de planification

  Après modification des configurations de planification d'un job, celui-ci génère une instance selon les nouvelles configurations. Pour garantir la continuité des fenêtres temporelles SQL entre les instances, modifiez la fenêtre temporelle SQL et la fréquence de planification dans les configurations.

  

• Scénario 5 : Nouvelle tentative pour une instance ayant échoué

  Généralement, un job Scheduled SQL génère des instances dans l'ordre chronologique selon l'heure planifiée. Si une instance échoue en raison d'autorisations insuffisantes, de l'absence du Logstore ou du Metricstore source ou de destination, ou d'une syntaxe SQL invalide, le système tente automatiquement de relancer l'instance. Si le nombre de tentatives dépasse la limite supérieure spécifiée ou si la durée des tentatives excède le temps maximal défini, l'instance arrête les nouvelles tentatives et passe à l'état FAILED. L'instance suivante commence alors à s'exécuter.

  Configurez des alertes pour les instances ayant échoué et relancez-les manuellement. Consultez et relancez les instances générées au cours des sept derniers jours. Après exécution, le système met à jour le statut des instances sur SUCCEEDED ou FAILED selon les résultats de la nouvelle tentative. Pour plus d'informations, consultez Relancer une instance d'une job Scheduled SQL.

Notes d'utilisation