Explicando as restrições de imutabilidade

As restrições de imutabilidade permitem que você marque partes de uma tabela dinâmica como estáticas. Quando você define uma restrição de imutabilidade, o Snowflake ignora essas linhas durante a atualização, o que melhora o desempenho, especialmente para tabelas que contêm grandes quantidades de dados históricos.

Você define as restrições de imutabilidade com a cláusula IMMUTABLE WHERE quando cria ou altera uma tabela dinâmica. A cláusula especifica uma condição, ou um predicado, que identifica quais linhas são imutáveis.

Principais comportamentos:

  • Atualização inicial: o Snowflake ignora o predicado IMMUTABLE WHERE durante a atualização inicial, mas o aplica a todas as atualizações subsequentes.

  • Modo de atualização completa: o predicado limita a nova computação apenas às linhas que não correspondem à condição.

  • Atualização incremental: fluxos e tabelas dinâmicas de atualização incremental podem ler tabelas dinâmicas de atualização completa que têm restrições de imutabilidade.

  • Clonagem e replicação: o Snowflake copia as restrições IMMUTABLE WHERE sem limitações.

Para obter informações sobre custos de computação, consulte Calcular o custo de restrições de imutabilidade.

Quando usar restrições de imutabilidade

As restrições de imutabilidade são úteis nos seguintes cenários:

Evitar reprocessamento de dados históricos

Quando a tabela dinâmica contiver dados históricos que você não deseja reprocessar, marque as linhas mais antigas como imutáveis.

Otimizar o modo de atualização completa

Tabelas dinâmicas que usam o modo de atualização completa costumam recomputar todas as linhas durante cada atualização. As restrições de imutabilidade limitam a recomputação apenas às linhas mutáveis, reduzindo significativamente o trabalho quando a maioria dos dados é histórica.

Facilitar atualizações incrementais downstream

Algumas construções de consulta, como funções de tabela definidas pelo usuário em Python, exigem uma tabela dinâmica para usar o modo de atualização completa. Normalmente, isso impede que tabelas downstream se beneficiem da atualização incremental. Quando a tabela upstream tem restrições de imutabilidade, as tabelas downstream ainda podem se beneficiar do processamento incremental.

Usar preenchimento com imutabilidade

O preenchimento estende as restrições de imutabilidade. O preenchimento é uma operação de cópia zero que permite copiar instantaneamente os dados existentes em uma tabela dinâmica sem recomputá-los. Use-o para migrar pipelines existentes, alterar definições de tabelas dinâmicas ou evitar inicializações caras ao criar tabelas com anos de dados históricos.

Os dados preenchidos não podem ser alterados durante atualizações futuras.

Quando você cria uma tabela dinâmica com ambos IMMUTABLE WHERE e BACKFILL FROM:

  • O preenchimento copia a região imutável da tabela de origem. A região imutável consiste em linhas que correspondem à condição IMMUTABLE WHERE.

  • A definição de consulta computa a região variável. A região imutável consiste nas linhas que não correspondem à condição.

Interação com chave primária e restrições exclusivas (RELY)

As tabelas dinâmicas podem ter chave primária e restrições exclusivas com a propriedade RELY. Quando as duas situações a seguir são verdadeiras em uma tabela dinâmica:

  • Um predicado IMMUTABLE WHERE está definido e

  • Pelo menos uma restrição de chave primária ou exclusiva tem a propriedade RELY definida,

as colunas referenciadas no predicado IMMUTABLE WHERE devem ser um subconjunto das colunas referenciadas no conjunto de todas as restrições exclusivas RELY e a chave primária RELY nessa tabela. Somente as restrições com a propriedade RELY são incluídas no conjunto de colunas permitidas, se houver. Considere os seguintes exemplos:

  • Se a tabela tiver uma chave primária RELY na coluna A e uma restrição exclusiva NORELY na coluna B, o predicado IMMUTABLE WHERE só poderá fazer referência à coluna A (ou a um subconjunto de colunas de restrição RELY).

  • Se a tabela tiver uma chave primária RELY na coluna A, uma restrição exclusiva RELY na coluna B e uma restrição exclusiva NORELY na coluna C, o predicado IMMUTABLE WHERE só poderá fazer referência a A e B ou a qualquer subconjunto dessas colunas.

A validade é verificada quando uma restrição RELY ou o predicado IMMUTABLE WHERE é adicionado ou alterado. Se o estado resultante violar a regra (por exemplo, o predicado faz referência a uma coluna que não está em nenhuma restrição RELY), haverá falha na instrução com um erro.

Próximos passos

Para obter orientação e exemplos de implementação, consulte Exemplos de preenchimento e Restrições de imutabilidade.