Limite de l’actualisation des tables dynamiques¶

Vue d’ensemble¶

Par défaut, lorsqu’une table dynamique lit à partir d’une autre table dynamique, Snowflake :

• Actualise les deux tables ensemble dans un seul pipeline.

• Coordonne les actualisations de sorte que les tables dynamiques en aval voient l’isolation de l’instantané sur toutes les tables dynamiques en amont du pipeline.

• Applique des règles au niveau du pipeline, telles que les contrôles de latence cible.

Dans certains pipelines, il est préférable que chaque relation n’entraîne pas l’actualisation simultanée des deux tables dynamiques. En voici quelques exemples courants :

• Pipelines inter-équipes dans lesquels une équipe publie une table dynamique qu’une autre équipe consomme, mais la table dynamique en aval ne doit pas influencer ou hériter du pipeline en amont.

• Les migrations incrémentielles : vous convertissez une étape de pipeline en amont en table dynamique, mais vous ne souhaitez pas que les consommateurs en aval commencent à coordonner les actualisations avec cette table.

• Les modèles Dynamic-table-on-view-on-dynamic-table, où une table dynamique lit une vue qui interroge une autre table dynamique. Ce modèle n’est pas pris en charge à moins que la vue ne soit définie dans DYNAMIC_TABLE_REFRESH_BOUNDARY().

Une limite d’actualisation rend cette séparation explicite : les entrées à l’intérieur de la limite sont traitées comme appartenant à un pipeline séparé et sont lues comme des tables régulières.

Syntaxe¶

DYNAMIC_TABLE_REFRESH_BOUNDARY( <object_name> )

Où :

object_name

Un nom de table, de vue, de table dynamique ou d’expression de table commune (CTE).

Utilisez ce mot-clé dans la clause FROM/JOIN (y compris dans les CTEs et les branches UNION) d’une définition de table dynamique.

Exemples¶

L’exemple suivant lit une vue qui interroge une autre table dynamique. Sans limite d’actualisation, la création d’une table dynamique qui lit une vue sur une autre table dynamique n’est pas prise en charge. Intégrer la vue dans DYNAMIC_TABLE_REFRESH_BOUNDARY() rend ce modèle possible :

CREATE DYNAMIC TABLE analytics.click_analytics_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '5 minutes'
AS
SELECT *
FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(analytics.enriched_clicks_view);

L’exemple suivant joint une table dynamique directement référencée à une vue dont la table dynamique en amont est actualisée selon une planification plus longue. L’intégration de la vue dans DYNAMIC_TABLE_REFRESH_BOUNDARY() empêche la table dynamique en aval de déclencher l’actualisation coûteuse en amont toutes les 5 minutes, tout en lui permettant de lire la dernière version disponible. L’isolation des instantanés n’est pas garantie au-delà de l’actualisation :

CREATE DYNAMIC TABLE data_eng.enriched_clicks_dt
  WAREHOUSE = de_wh
  TARGET_LAG = '5 minutes'
AS
SELECT
  c.*,
  p.product_name
FROM data_eng.clickstream_dt AS c
LEFT JOIN DYNAMIC_TABLE_REFRESH_BOUNDARY(product_db.active_products_view) AS p
  ON c.product_id = p.product_id;

Comportement¶

Cas d’utilisation¶

CREATE VIEW v_orders AS
SELECT *
FROM orders_dt;

CREATE DYNAMIC TABLE order_summary_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '15 minutes'
AS
SELECT
  customer_id,
  COUNT(*) AS num_orders
FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(v_orders)
GROUP BY customer_id;

-- Team A: owns product_catalog_dt and publishes a boundary view
CREATE DYNAMIC TABLE product.product_catalog_dt
  WAREHOUSE = product_wh
  TARGET_LAG = '1 hour'
AS
SELECT *
FROM product.raw_products;

CREATE VIEW product.active_products_public_v AS
SELECT * FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(product.product_catalog_dt)
WHERE is_active = TRUE;

-- Team B: consumes Team A's view in their own dynamic table
CREATE DYNAMIC TABLE analytics.active_product_clicks_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '5 minutes'
AS
SELECT
  c.*,
  p.product_name
FROM analytics.clickstream_dt AS c
JOIN product.active_products_public_v AS p
  ON c.product_id = p.product_id;

Latence cible¶

Les limites d’actualisation influencent également la manière dont la latence cible est appliquée.

La latence cible d’une table dynamique en amont doit égale ou plus courte que celle de toute table dynamique en aval dans le même pipeline. Les tables dynamiques référencées via DYNAMIC_TABLE_REFRESH_BOUNDARY() n’appartiennent pas au même pipeline, donc cette règle ne s’applique pas au-delà de la limite.

Les tables dynamiques en amont à l’intérieur d’une limite d’actualisation conservent leur propre latence cible et leur propre comportement de planification. elles ne sont pas resserrées ou élargies par les choix en aval au-delà de la limite.

Restrictions et limitations¶

Les limites d’actualisation sont soumises à quelques règles importantes :

La même table dynamique à l’intérieur et à l’extérieur d’une limite d’actualisation n’est pas autorisée

Toutes les références à la même table dynamique en amont dans une seule définition doivent être soit directement dans la définition, soit englobées dans DYNAMIC_TABLE_REFRESH_BOUNDARY() . En combinant les deux, il serait possible de consulter la même table dynamique sous différentes versions. Snowflake bloque ces définitions et renvoie une erreur descriptive.

Cibles de limites non prises en charge*

DYNAMIC_TABLE_REFRESH_BOUNDARY() doit englober un objet nommé (table, vue, table dynamique ou CTE). Elle ne peut pas englober :

• Les sous-requêtes en ligne.

• Les fonctions de table ou les UDTFs.

• Les appels de TABLE(...) arbitraires.

Effet en dehors des tables dynamiques

Vous pouvez appeler DYNAMIC_TABLE_REFRESH_BOUNDARY() dans des requêtes SELECT ordinaires, mais en dehors d’une définition de table dynamique, cela n’a aucun effet.

Meilleures pratiques¶

Lors de l’utilisation de limites d’actualisation dans les pipelines de tables dynamiques :

Utilisez une limite d’actualisation lorsque :

• Vous souhaitez consommer la table dynamique d’une autre équipe sans joindre son pipeline.

• Vous n’avez pas besoin d’isoler l’instantané d’une dépendance particulière en amont.

• Une table dynamique dépend d’une vue qui fait référence à une autre table dynamique. Ce modèle n’est pris en charge que lorsque la vue ou la table dynamique en amont est intégrée dans DYNAMIC_TABLE_REFRESH_BOUNDARY().

Évitez une limite d’actualisation lorsque :

• Vous avez besoin d’une isolation des instantanés pour cette dépendance.

• Vous souhaitez que les actualisations en aval soient coordonnées avec les tables dynamiques en amont et, si nécessaire, que les actualisations se déclenchent en cascade.

• Vous comptez sur des relations de latence cible globales dans l’ensemble du pipeline.