Utiliser des horodatages de lignes pour mesurer la latence dans vos pipelines¶

Les horodatages de lignes fournissent un enregistrement chronologique précis de la dernière mise à jour de chaque ligne d’une table. Les lignes modifiées dans la même transaction partagent exactement le même horodatage, et les lignes modifiées dans des transactions différentes sont classées en fonction du moment où elles ont été validées.

Les principaux cas d’utilisation sont les suivants :

Observabilité des pipelines : mesurez la latence de bout en bout et le niveau d’actualisation des données pour l’ingestion de flux, la CDC, et les charges de travail ETL avec une plus grande précision que les horodatages côté client.
Traitement incrémentiel fiable : capturez les enregistrements retardés ou remplis que les horodatages d’événements pourraient ignorer en utilisant des temps de validation définitifs.
Pistes d’audit définitives : établissez un ordre chronologique des événements pour la conformité réglementaire ou le balisage de style SCD2.

Pour définir des horodatages de lignes sur vos tables, sélectionnez l’une des options suivantes :

Définir des horodatages de lignes sur une table : en utilisant un rôle qui dispose du privilège OWNERSHIP sur la table, définissez la propriété ROW_TIMESTAMP sur TRUE lors de l’exécution de la commande CREATE TABLE ou ALTER TABLE.

Par exemple, CREATE TABLE … ROW_TIMESTAMP = TRUE ou ALTER TABLE … SET ROW_TIMESTAMP = TRUE
Définir des horodatages de lignes par défaut pour les nouvelles tables dans un conteneur : définissez la propriété ROW_TIMESTAMP_DEFAULT sur TRUE sur le conteneur.

Par exemple, ALTER SCHEMA … SET ROW_TIMESTAMP_DEFAULT = TRUE signifie que chaque nouvelle table créée dans le schéma après avoir défini le paramètre aura des horodatages de lignes activés par défaut.
Activer les horodatages de lignes de manière groupée sur les tables existantes : utilisez la fonction système SELECT SYSTEM$SET_ROW_TIMESTAMP_ON_ALL_SUPPORTED_TABLES.

Par exemple, SELECT SYSTEM$SET_ROW_TIMESTAMP_ON_ALL_SUPPORTED_TABLES('schema', '{my_db}.my_schema').
- Le premier argument est de niveau : un de schema,:code:database ou account.
- Le deuxième argument est le nom entièrement qualifié du conteneur.
Cette fonction ajoute la colonne d’horodatage des lignes à toutes les tables éligibles existantes dans le conteneur et veille à ce que l’horodatage des lignes des tables nouvellement créées soit automatiquement activé.

Pour exécuter correctement la fonction, vous avez besoin des privilèges MODIFY sur le conteneur sur lequel vous appelez la fonction.

Une fois les horodatages de lignes activés, les tables exposent la colonne METADATA$ROW_LAST_COMMIT_TIME, qui renvoie l’horodatage de la dernière modification de chaque ligne. Cela permet le suivi des modifications, le traitement incrémentiel et les requêtes Time Travel basées sur l’heure de modification des lignes.

Note

Dans un scénario de partage de données, les consommateurs ne peuvent pas sélectionner METADATA$ROW_LAST_COMMIT_TIME, même si l’horodatage de lignes est activé dans la table des producteurs. Les producteurs doivent créer une vue qui sélectionne METADATA$ROW_LAST_COMMIT_TIME, puis partager la vue s’ils souhaitent partager les horodatages de lignes avec des consommateurs.

Les instructions suivantes montrent comment créer une table qui prend en charge les horodatages de lignes. Les instructions insèrent des données dans la table et récupèrent l’horodatage de chaque ligne.

CREATE OR REPLACE TABLE table1(value1 STRING)
  ROW_TIMESTAMP = TRUE;

INSERT INTO table1 VALUES('some-value-a');

INSERT INTO table1 VALUES('some-value-b');

SELECT METADATA$ROW_LAST_COMMIT_TIME AS row_timestamp, *
  FROM table1
  ORDER BY 1;

Copy

Cas d’utilisation principaux¶

La colonne de métadonnées METADATA$ROW_LAST_COMMIT_TIME permet de suivre la latence. Par exemple, si vous visez une latence totale de cinq secondes, cette colonne vous aide à déterminer la contribution de Snowflake à cette latence.

Les cas d’utilisation clés incluent :

Mesure de la latence d’ingestion : Suivez le temps entre le moment où une ligne est créée sur le client et le moment où elle devient visible dans Snowflake, permettant ainsi aux utilisateurs de calculer le temps d’ingestion des données.
Mesure de la latence de bout en bout : Combinez la latence d’ingestion et la latence de pipeline pour mesurer le temps total de la génération des données jusqu’à leur état final.
Mesure de la latence du pipeline : Suivez les horodatages au fur et à mesure que les données se déplacent dans un pipeline. En comparant l’horodatage de la table initiale à la table finale, les utilisateurs peuvent mesurer le temps nécessaire au pipeline pour traiter les données.
- Prise en charge pour les pipelines basés sur des flux, des tables dynamiques et des tâches.

Exemple : mesure de la latence d’ingestion¶

Pour mesurer la latence d’ingestion à l’aide de la colonne de métadonnées METADATA$ROW_LAST_COMMIT_TIME, procédez comme suit :

Créez un pipeline d’ingestion qui envoie des données à Snowflake à l’aide de l’une des méthodes suivantes :
- Snowpipe Streaming Ingest SDK. Pour un exemple simple qui montre comment le client SDK peut être utilisé pour construire une application Snowpipe Streaming, voir ce fichier Java (GitHub).
- Snowpipe
- Commande COPY INTO <table>

Exécutez ce qui suit :

ALTER SESSION SET TIMESTAMP_TZ_OUTPUT_FORMAT = 'YYYY-MM-DDTHH:MI:SS.FF3 TZH';

ALTER SESSION SET TIMEZONE = 'UTC';

CREATE OR REPLACE DATABASE mydb;

CREATE OR ALTER SCHEMA myschema;

CREATE OR REPLACE TABLE table1(record_id STRING, client_timestamp TIMESTAMP_LTZ);

-- The rows inserted from server-side-insert-1 up to this point will not have a valid METADATA$ROW_LAST_COMMIT_TIME timestamp.
INSERT INTO table1 VALUES('server-side-insert-1', current_timestamp());

Copy

Modifiez la table pour activer la fonctionnalité METADATA$ROW_LAST_COMMIT_TIME.
```
ALTER TABLE table1 SET ROW_TIMESTAMP = TRUE;
```
Copy
Ingérez des données comprenant les colonnes record_id et``client_timestamp`` vers votre table Snowflake en utilisant le pipeline d’ingestion défini à l’étape 1.
Insérez une nouvelle ligne comme exemple immédiat si vous n’utilisez pas de pipeline d’ingestion. Contrairement à l’insertion à l’étape 2, cette insertion aura un horodatage METADATA$ROW_LAST_COMMIT_TIME valide, car la propriété de table est activée.
```
INSERT INTO table1 VALUES('server-side-insert-2', current_timestamp());
```
Copy

Exécutez à nouveau votre programme côté client, puis procédez comme suit :

SELECT *, METADATA$ROW_LAST_COMMIT_TIME AS ROW_TIMESTAMP, TIMESTAMPDIFF(ms, CLIENT_TIMESTAMP, ROW_TIMESTAMP)
  AS INGEST_LATENCY FROM table1 ORDER BY 2;

Copy

Cas d’utilisation secondaires¶

Les horodatages de lignes peuvent également être utilisés dans les cas suivants :

Conservation des données : Les horodatages de lignes peuvent aider à supprimer les anciens enregistrements pour réduire les coûts de stockage.
Ordre des événements et suivi des modifications : Vous pouvez utiliser des horodatages de lignes pour suivre les modifications. La ligne avec l’horodatage le plus grand représente la dernière modification.
Données d’ajout uniquement : Si les lignes sont uniquement ajoutées, les horodatages de lignes peuvent aider à filtrer les états de la table à des moments spécifiques, ce qui vous permet d’utiliser Time Travel quelle que soit la politique de conservation des données.

Limites et considérations¶

Les horodatages de lignes ne sont garantis que pour maintenir l’ordre chronologique dans la même table, sauf en cas de basculement où l’ordre n’est pas garanti. L’ordre entre les tables, les différentes régions ou d’autres sources temporelles n’est pas garanti. Vous ne devez pas comparer les horodatages de lignes entre des tables ou d’autres sources, car cela peut entraîner des incohérences.
Les horodatages de lignes reflètent l’heure de la dernière mise à jour, et non l’heure de la création. Par exemple, si la ligne de données est mise à jour après avoir été validée, l’horodatage de la ligne reflète l’heure de la dernière mise à jour, et non l’heure de création des données.
Les horodatages de lignes créées avant l’activation des horodatages de lignes pour une table sont définis sur NULL.
Les horodatages de lignes sont stockés à condition que les lignes soient stockées.
Définir la propriété ROW_TIMESTAMP sur FALSE supprime définitivement toutes les valeurs METADATA$ROW_LAST_COMMIT_TIME stockées. Sa réactivation ne les restaurera pas et les requêtes Time Travel ne renverront rien.
Les horodatages de lignes ne sont pas pris en charge pour les tables Apache Iceberg™, les tables externes, les tables hybrides, les flux ou les vues.
La colonne de métadonnées METADATA$ROW_LAST_COMMIT_TIME ne peut pas être référencée dans ce qui suit :
- Clause CHANGES
- Politiques, y compris les politiques d’accès aux lignes ou aux colonnes et les politiques de cycle de vie du stockage
- Contraintes
- Expressions CLUSTER BY
Les horodatages de lignes ne peuvent pas être restaurés par la restauration de la table d’archivage. Comme solution de contournement, vous pouvez matérialiser METADATA$ROW_LAST_COMMIT_TIME en tant que colonne persistante d’une autre table à utiliser pour la restauration d’archives.

Considérations relatives au clonage pour les horodatages de lignes¶

Le clonage d’une table préserve l’exactitude des horodatages de lignes. Les opérations qui créent une copie physique des données, telles que CREATE TABLE AS SELECT (CTAS) etINSERT INTO … SELECT, attribuent des horodatages de lignes récents reflétant la date à laquelle la copie a été effectuée. Les horodatages de lignes d’origine de la table source ne sont pas préservés. Si vous souhaitez en garder un enregistrement, sélectionnez-les explicitement dans une colonne persistante, comme indiqué dans l’exemple suivant :

CREATE TABLE my_archive AS
 SELECT *, METADATA$ROW_LAST_COMMIT_TIME AS original_commit_time
 FROM my_source_table;

Copy