Comprendre les clés primaires des tables dynamiques

Snowflake peut utiliser des clés primaires dans les tables dynamiques et les tables Iceberg dynamiques pour suivre plus efficacement les modifications au niveau des lignes et pour permettre l’actualisation incrémentielle en aval des tables dynamiques à actualisation complète. Au lieu de s’appuyer sur des colonnes de suivi des modifications, Snowflake utilise des clés primaires comme identificateurs de lignes stables pour calculer l’ensemble minimal de modifications entre les actualisations.

Ceci est particulièrement utile dans les scénarios suivants :

  • Les tables de base sont réécrites périodiquement via INSERTOVERWRITE plutôt que mises à jour sur place, ce qui empêche normalement Snowflake de détecter ce qui a changé entre les versions.

  • Le pipeline lit les données à partir d’une table Apache Iceberg™ v2 gérée en externe, ce qui permet de tracer la provenance des lignes.

  • Certaines tables dynamiques doivent utiliser le mode d’actualisation complet en raison de constructions incrémentielles non prises en charge, mais les tables en aval bénéficieraient d’un traitement incrémentiel.

Types de clés primaires dans les tables dynamiques

Snowflake prend en charge deux types de cas d’utilisation de clés primaires pour les tables dynamiques : 1) le suivi des modifications au niveau des lignes et 2) la dérivation d’une clé unique pour la table dynamique elle-même.

Suivi des modifications basé sur la lignée au niveau des lignes de clés primaires

Lorsqu’une table de base présente une contrainte de clé primaire avec la propriété RELY définie, Snowflake utilise cette clé pour le suivi des modifications au niveau des lignes dans les tables dynamiques en aval. Ceci est particulièrement utile lorsque la table de base est réécrite périodiquement via INSERTOVERWRITE, ce qui empêche normalement le suivi des modifications entre les versions de table.

Avec une clé primaire fiable, Snowflake identifie les lignes qui ont changé entre les actualisations en comparant les valeurs de clés primaires au lieu de s’appuyer sur des colonnes internes de suivi des modifications. Cela permet un traitement incrémentiel même lorsque les données sous-jacentes sont entièrement remplacées.

Pour définir la propriété RELY sur une clé primaire de table de base :

ALTER TABLE my_base_table ALTER CONSTRAINT my_pk_constraint RELY;

Dérivation de clé unique

Snowflake peut dériver automatiquement une clé unique fiable à partir de la définition de requête d’une table dynamique. Par exemple, les constructions SQL suivantes produisent des clés uniques dérivées :

  • GROUP BY : Les colonnes de regroupement forment une clé unique car chaque groupe produit exactement une seule ligne de sortie.

  • QUALIFY ROW_NUMBER() = 1 : Les colonnes partition-by forment une clé unique car le filtre conserve exactement une ligne par partition.

  • Clés primaires de table de base fiables : La clé primaire de la table de base est utilisée comme clé unique de la table dynamique.

Snowflake enregistre les clés primaires dérivées comme des contraintes uniques sur la table dynamique. Comme ces contraintes proviennent de la structure de la requête, elles sont totalement fiables sans validation supplémentaire.

Pour vérifier si une table dynamique dispose d’une clé primaire dérivée, exécutez :

SHOW UNIQUE KEYS IN my_dynamic_table;

Quand utiliser les clés primaires

Les clés primaires sont utiles dans les scénarios suivants :

Améliorer le suivi des modifications pour les charges de travail INSERTOVERWRITE

Lorsqu’une table de base est réécrite périodiquement via INSERTOVERWRITE, Snowflake ne peut pas utiliser les colonnes de suivi des modifications standard pour détecter ce qui a changé. Une clé primaire permet à Snowflake de comparer les lignes par valeur de clé et de ne traiter que les modifications réelles, évitant ainsi un nouveau calcul complet de la table dynamique.

Activer l’actualisation incrémentielle en aval de l’actualisation complète des tables dynamiques

En principe, une table dynamique en mode d’actualisation incrémentielle ne peut pas être en aval d’une table dynamique en mode d’actualisation complet. Lorsque la table dynamique à actualisation complète en amont possède une clé unique dérivée du système, Snowflake peut calculer les modifications entre les actualisations complètes, ce qui permet aux tables en aval de s’actualiser de manière incrémentielle. Cela supprime un blocage important pour les pipelines incrémentiels.

Réduire la propagation des modifications dans les pipelines

Les clés primaires permettent la réduction des modifications basée sur la valeur à chaque étape d’un pipeline. Snowflake peut filtrer les lignes où la clé primaire existe à la fois dans l’ancienne et dans la nouvelle version avec des valeurs identiques, réduisant ainsi le volume des modifications qui se propagent aux tables en aval.

Principaux comportements

  • Activer l’actualisation incrémentielle en aval : Pour utiliser l’actualisation incrémentielle sur une table dynamique qui lit une table dynamique à actualisation complète avec une clé unique dérivée, vous devez explicitement définir``REFRESH_MODE = INCREMENTAL`` sur la table en aval. Le paramètre REFRESH_MODE = AUTO continue d’être défini sur FULL.

  • Vérifiez la prise en charge du suivi des modifications basé sur les clés primaires : Utilisez SHOW UNIQUE KEYS IN <dt_name> pour vérifier si une table dynamique possède une clé unique dérivée. Vous pouvez également créer une table dynamique en aval à l’aide de REFRESH_MODE = INCREMENTAL et vérifier si la création réussit.

  • Politiques de masquage : Les politiques de masquage qui masquent les colonnes de clé primaire empêchent Snowflake d’utiliser ces clés pour le suivi des modifications. Dans ce cas, Snowflake revient aux colonnes standard de suivi des modifications.

Prochaines étapes

Pour des exemples et des conseils de mise en œuvre, voir Utiliser des clés primaires pour optimiser les pipelines de tables dynamiques.

Pour la syntaxe complète de CREATE DYNAMICTABLE, voir CREATE DYNAMIC TABLE.