Práticas recomendadas para tabelas dinâmicas¶

Use o privilégio MONITOR para visualizar metadados¶

Para cenários em que o usuário só precisa visualizar os metadados e a exibição Information Schema de uma tabela dinâmica (por exemplo, funções ocupadas por cientistas de dados), use uma função que tenha o privilégio MONITOR nessa tabela dinâmica. Embora o privilégio OPERATE conceda esse acesso, ele também inclui a capacidade de alterar tabelas dinâmicas, tornando MONITOR a opção mais adequada para cenários em que um usuário não precisa alterar uma tabela dinâmica.

Para obter mais informações, consulte Controle de acesso a tabelas dinâmicas.

Simplificar expressões compostas em chaves de agrupamento¶

Se uma chave de agrupamento contiver uma expressão composta em vez de uma coluna base, materialize a expressão em uma tabela dinâmica e, em seguida, aplique a operação de agrupamento na coluna materializada em outra tabela dinâmica. Para obter mais informações, consulte Como os operadores atualizam incrementalmente.

Uso de tabelas dinâmicas para implementar dimensões de alteração lenta¶

Tabelas dinâmicas podem ser usadas para implementar dimensões de alteração lenta (SCDs) do tipo 1 e 2. Ao ler um fluxo de alterações, use funções de janela em vez de chaves por registro ordenadas por um carimbo de data/hora de alteração. Ao usar esse método, as tabelas dinâmicas manipulam sem interrupções inserções, exclusões e atualizações que ocorrem fora de ordem para simplificar a criação de SCD. Para mais informações, consulte Dimensões de alteração lenta com tabelas dinâmicas.

Como encadear pipelines de tabelas dinâmicas¶

Ao definir uma nova tabela dinâmica, em vez de definir uma tabela dinâmica grande com muitas instruções aninhadas, use tabelas dinâmicas pequenas com pipelines.

Você pode configurar uma tabela dinâmica para consultar outras tabelas dinâmicas. Por exemplo, imagine um cenário em que seu pipeline de dados extrai dados de uma tabela de preparação para atualizar várias tabelas de dimensão (por exemplo, cliente, produto, data e hora). Além disso, seu pipeline atualiza uma tabela de vendas agregadas com base nas informações dessas tabelas de dimensão. Ao configurar as tabelas de dimensão para consultar a tabela de preparação e a tabela de vendas agregadas para consultar as tabelas de dimensão, você cria um efeito cascata semelhante a um gráfico de tarefa.

Nessa configuração, a atualização da tabela de vendas agregadas é executada somente após as atualizações das tabelas de dimensão serem concluídas com sucesso. Isso garante a consistência dos dados e atende às metas de atraso. Por meio de um processo de atualização automatizado, quaisquer alterações nas tabelas de origem acionam atualizações em todas as tabelas dependentes nos momentos apropriados.

Uso de uma tabela dinâmica de “controlador” para os gráficos de tarefa complexos¶

Quando você tem um gráfico complexo de tabelas dinâmicas com muitas raízes e folhas e deseja executar operações (por exemplo, alteração de atraso, atualização manual, suspensão) no gráfico de tarefa completo com um único comando, faça o seguinte:

1. Defina o valor para o TARGET_LAG de todas as suas tabelas dinâmicas para DOWNSTREAM.

2. Crie uma tabela dinâmica de “controlador” que leia todas as folhas em seu gráfico de tarefa. Para garantir que este controlador não consuma recursos, faça o seguinte:

   CREATE DYNAMIC TABLE controller
     TARGET_LAG = <target_lag>
     WAREHOUSE = <warehouse>
     AS
       SELECT 1 A FROM <leaf1>, …, <leafN> LIMIT 0;
   

   Copy

3. Use o controlador para controlar o gráfico inteiro. Por exemplo:

• Defina um novo atraso de destino para o gráfico de tarefa.

  ALTER DYNAMIC TABLE controller SET
    TARGET_LAG = <new_target_lag>
  

  Copy

• Atualize manualmente o gráfico de tarefa.

  ALTER DYNAMIC TABLE controller REFRESH
  

  Copy

Sobre clonagem de pipelines de tabelas dinâmicas¶

Clone todos os elementos do pipeline da tabela dinâmica com o mesmo comando de clonagem para evitar reinicializações de seu pipeline. Você pode fazer isso consolidando todos os elementos do pipeline (por exemplo, tabelas base, visualizações e tabelas dinâmicas) no mesmo esquema ou banco de dados. Para obter mais informações, consulte Limitações conhecidas para tabelas dinâmicas.

Uso de tabelas dinâmicas transitórias para reduzir o custo de armazenamento¶

Tabelas dinâmicas transitórias mantêm os dados confiáveis ao longo do tempo e oferecem suporte à Time Travel dentro do período de retenção de dados, mas não retêm os dados além do período de fail-safe. Por padrão, os dados da tabela dinâmica são retidos por 7 dias em armazenamento fail-safe. Para tabelas dinâmicas com alta taxa de atualização, isso pode aumentar significativamente o consumo de armazenamento. Portanto, você deve tornar uma tabela dinâmica transitória somente se seus dados não precisarem do mesmo nível de proteção e recuperação de dados fornecido pelas tabelas permanentes.

Você pode criar uma tabela dinâmica transitória ou clonar tabelas dinâmicas existentes para tabelas dinâmicas transitórias usando a instrução CREATE DYNAMIC TABLE.

Uso de warehouses dedicados a atualizações¶

As tabelas dinâmicas exigem um warehouse virtual para realizar atualizações. Para entender claramente os custos relacionados aos seus pipelines de tabelas dinâmicas, você deve testar suas tabelas dinâmicas usando warehouses dedicados para que o consumo do warehouse virtual atribuído às tabelas dinâmicas possa ser isolado. Para obter mais informações, consulte Compreensão do custo de tabelas dinâmicas.

Uso do atraso downstream¶

O atraso downstream indica que a tabela dinâmica deve ser atualizada quando outras tabelas dinâmicas dependentes precisarem ser atualizadas. Você deve usar o atraso downstream como uma prática recomendada devido à sua facilidade de uso e custo-benefício. Sem o atraso downstream, gerenciar uma cadeia de tabelas dinâmicas complexas exigiria atribuir individualmente a cada tabela seu próprio atraso de destino e gerenciar as restrições associadas, em vez de apenas monitorar a atualidade dos dados da tabela final. Para obter mais informações, consulte Compreensão da meta de atraso.

Definição do modo de atualização para todas as tabelas dinâmicas de produção¶

O modo de atualização real da tabela dinâmica é determinado no momento da criação e não pode ser alterado posteriormente. Se não for especificado explicitamente, o modo de atualização será definido como AUTO por padrão, selecionando um modo de atualização com base em vários fatores, como complexidade da consulta ou construções, operadores ou funções incompatíveis.

Para determinar o melhor modo para seu caso de uso, experimente modos de atualização e recomendações automáticas. Para um comportamento consistente em todas as versões do Snowflake, defina explicitamente o modo de atualização em todas as tabelas de produção. O comportamento do AUTO pode mudar entre as versões do Snowflake, o que pode causar mudanças inesperadas no desempenho se usado em pipelines de produção.

Para verificar o modo de atualização de suas tabelas dinâmicas, consulte Exibição do modo de atualização de tabela dinâmica.

Escolher entre modos de atualização¶

Para determinar o melhor modo para seu caso de uso, experimente recomendações automáticas e modos de atualização concretos (completa e incremental). O melhor modo para o desempenho das suas tabelas dinâmicas depende do volume de alterações de dados e da complexidade das consultas. Além disso, testar diferentes modos de atualização com um warehouse dedicado ajuda a isolar custos e melhorar o ajuste de desempenho com base nas cargas de trabalho reais.

Para verificar o modo de atualização de suas tabelas dinâmicas, consulte Exibição do modo de atualização de tabela dinâmica.

• Modo de atualização AUTO: o sistema tenta aplicar a atualização incremental por padrão. Quando a atualização incremental não é aceita ou se é possível que não tenha um bom desempenho, a tabela dinâmica seleciona automaticamente a atualização completa.

  • Para um comportamento consistente, defina explicitamente o modo de atualização em todas as tabelas de produção. O comportamento do AUTO pode mudar entre as versões do Snowflake, o que pode causar mudanças inesperadas no desempenho se usado em pipelines de produção.

• Atualização incremental: atualiza a tabela dinâmica apenas com as alterações desde a última atualização, tornando-a ideal para grandes conjuntos de dados com pequenas atualizações frequentes.

  • Melhor para consultas compatíveis com atualização incremental (por exemplo, funções determinísticas, junções simples e expressões básicas em SELECT, WHERE e GROUP BY). Se houver recursos não compatíveis e o modo de atualização estiver definido como incremental, o Snowflake não conseguirá criar a tabela dinâmica.

  • Uma prática essencial para otimizar o desempenho com a atualização incremental é limitar o volume de alterações a cerca de 5% dos dados de origem e fazer cluster dos seus dados pelas chaves de agrupamento para reduzir a sobrecarga de processamento.

  • Considere que certas combinações de operações, como agregações sobre muitas junções, podem não ser executadas de forma eficiente.

• Atualização completa: reprocessa todo o conjunto de dados e atualiza a tabela dinâmica com o resultado de consulta. Use para consultas complexas ou para quando alterações significativas de dados exigirem uma atualização completa.

  • Útil quando a atualização incremental não é possível devido a consultas complexas, funções não determinísticas ou grandes alterações nos dados.

Para obter mais informações, consulte Como o modo de atualização afeta o desempenho da tabela dinâmica.

Desempenho de atualização completa¶

As tabelas dinâmicas de atualização completa têm um desempenho semelhante a CREATE TABLE … AS SELECT (também chamado de CTAS). Elas podem ser otimizadas como qualquer outra consulta Snowflake.

Desempenho de atualização incremental¶

Para ajudar a atingir o desempenho ideal de atualização incremental para suas tabelas dinâmicas:

• Mantenha as alterações entre as atualizações mínimas, de preferência menos de 5% do conjunto de dados total, tanto para as fontes quanto para a tabela dinâmica.

• Considere o número de micropartições modificadas, não apenas a contagem de linhas. A quantidade de trabalho que uma atualização incremental deve fazer é proporcional ao tamanho dessas micropartições, não apenas das linhas que foram alteradas.

• Minimize as operações de agrupamento como junções, GROUP BYs e PARTITION BYs em sua consulta. Divida grandes expressões de tabela comuns (CTEs) em partes menores e crie uma tabela dinâmica para cada uma. Evite sobrecarregar uma única tabela dinâmica com agregações ou junções excessivas.

• Garanta a localidade dos dados alinhando as alterações de tabela com as chaves de consulta (por exemplo, para junções, GROUP BYs, PARTITION BYs). Se suas tabelas não forem naturalmente clusterizadas por essas chaves, considere habilitar o clustering automático.