Limite de atualização de tabelas dinâmicas¶

Visão geral¶

Por padrão, quando uma tabela dinâmica lê de outra tabela dinâmica, o Snowflake:

• Atualiza as duas tabelas juntas como parte de um único pipeline.

• Coordena atualizações para que tabelas dinâmicas a downstream vejam o isolamento de instantâneos em todas as tabelas dinâmicas upstream no pipeline.

• Impõe regras no nível do pipeline, como verificações de atraso no destino.

Em alguns pipelines, você não quer que cada relacionamento faça com que ambas as tabelas dinâmicas sejam atualizadas juntas. Exemplos comuns incluem:

• ** Pipelines entre equipes** em que uma equipe publica uma tabela dinâmica que outra equipe consome, mas a tabela dinâmica downstream não deve influenciar ou herdar o pipeline upstream.

• Migrações incrementais em que você converte uma etapa de pipeline upstream em uma tabela dinâmica, mas não que os consumidores downstream comecem a coordenar atualizações com ela.

• Padrões Dynamic-table-on-view-on-dynamic-table, em que uma tabela dinâmica lê uma exibição que consulta outra tabela dinâmica. Esse padrão não é compatível, exceto se a exibição estiver agrupada em DYNAMIC_TABLE_REFRESH_BOUNDARY().

Um limite de atualização torna essa separação explícita: as entradas dentro do limite são tratadas como pertencentes a um pipeline separado e lidas como tabelas regulares.

Sintaxe¶

DYNAMIC_TABLE_REFRESH_BOUNDARY( <object_name> )

Onde:

object_name

Um nome de tabela, exibição, tabela dinâmica ou expressão de tabela comum (CTE).

Use esta palavra-chave na cláusula FROM / JOIN (incluindo em ramificações CTEs e UNION) de uma definição de tabela dinâmica.

Exemplos¶

O exemplo a seguir lê uma exibição que consulta outra tabela dinâmica. Sem um limite de atualização, não é possível criar uma tabela dinâmica que lê uma exibição em outra tabela dinâmica. Delimitar a exibição em DYNAMIC_TABLE_REFRESH_BOUNDARY() torna esse padrão possível:

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);

O exemplo a seguir une uma tabela dinâmica referenciada diretamente a uma visualização cuja tabela dinâmica upstream é atualizada em intervalos mais longos. Delimitar a exibição em DYNAMIC_TABLE_REFRESH_BOUNDARY() evita que a tabela dinâmica downstream acione a atualização cara upstream a cada 5 minutos, ao mesmo tempo em que permite que ela leia a versão mais recente disponível. O isolamento de instantâneos não é garantido além do limite de atualização:

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;

Comportamento¶

Casos de uso¶

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;

Atraso no destino¶

Os limites de atualização também influenciam como o atraso de destino é aplicado.

O atraso de destino de uma tabela dinâmica upstream deve ser o mesmo ou menor que o de qualquer tabela dinâmica downstream no mesmo pipeline. Tabelas dinâmicas referenciadas por DYNAMIC_TABLE_REFRESH_BOUNDARY() não pertencem ao mesmo pipeline, então essa regra não se aplica além do limite.

As tabelas dinâmicas upstream em um limite de atualização mantêm seu próprio atraso no destino e comportamento de agendamento; as escolhas downstream no limite não afetam essas tabelas.

Restrições e limitações¶

Os limites de atualização estão sujeitos a algumas regras importantes:

Não é permitido que a mesma tabela dinâmica esteja dentro e fora de um limite de atualização

Todas as referências à mesma tabela dinâmica upstream em uma única definição devem estar diretamente na definição ou delimitadas em DYNAMIC_TABLE_REFRESH_BOUNDARY(). Caso as referências estejam nos dois, versões diferentes da mesma tabela dinâmica poderiam ser lidas. O Snowflake bloqueia essas definições e retorna um erro descritivo.

Destinos de limite incompatíveis

DYNAMIC_TABLE_REFRESH_BOUNDARY() deve delimitar um objeto nomeado (tabela, exibição, tabela dinâmica ou CTE). Ele não pode delimitar:

• Subconsultas em linha.

• Funções de tabela ou UDTFs.

• Chamadas TABLE(...) arbitrárias.

Efeito fora das tabelas dinâmicas

Você pode chamar DYNAMIC_TABLE_REFRESH_BOUNDARY() em consultas SELECT regulares, mas fora de uma definição de tabela dinâmica isso não é uma operação.

Práticas recomendadas¶

Ao usar limites de atualização em pipelines de tabela dinâmica:

Use um limite de atualização quando:

• Você quiser consumir a tabela dinâmica de outra equipe sem ingressar no pipeline.

• Você não precisa isolar instantâneos de uma dependência upstream específica.

• Uma tabela dinâmica depende de uma exibição que faz referência a outra tabela dinâmica. Esse padrão só é compatível quando a exibição ou a tabela dinâmica upstream é delimitada em DYNAMIC_TABLE_REFRESH_BOUNDARY().

Evite usar um limite de atualização quando:

• Você precisa isolar instantâneos nessa dependência.

• Você quer que as atualizações downstream sejam coordenadas com as tabelas dinâmicas upstream e, se necessário, com as atualizações em cascata.

• Você depende das relações de atraso no destino globais em todo o pipeline.