Compreensão da inicialização e atualização de tabelas dinâmicas¶
O conteúdo de uma tabela dinâmica é definido por uma consulta e é atualizado automaticamente – chamado de atualização – quando os dados subjacentes são alterados. Esse processo analisa a consulta para manter a tabela atualizada.
As seções a seguir explicam a atualização dinâmica da tabela com mais detalhes:
Seção |
Descrição |
---|---|
Introduz a inicialização ou, em outras palavras, a população inicial de dados quando você cria uma tabela dinâmica. Você pode especificar quando ocorre a atualização inicial. |
|
Uma visão geral da atualização dinâmica de tabelas. As tabelas dinâmicas são atualizadas em um cronograma, a menos que sejam atualizadas manualmente. |
|
As tabelas dinâmicas oferecem suporte a dois modos de atualização: incremental e total. Você pode definir o modo de atualização como AUTO ou defini-lo explicitamente. Aprenda as práticas recomendadas para escolher o modo de atualização e como visualizar o modo de atualização usado. |
|
Como os dados são atualizados quando uma tabela dinâmica depende de outras tabelas dinâmicas |
Saiba como as tabelas dinâmicas são atualizadas em relação às suas dependências. |
Como compreender os efeitos das alterações nas colunas das tabelas de base |
Saiba mais sobre o impacto das alterações nas tabelas base. |
Uma lista de práticas recomendadas para atualização dinâmica de tabelas. |
Compreensão da inicialização de tabelas dinâmicas¶
Quando você cria uma tabela dinâmica, a atualização inicial ocorre de forma síncrona na criação ou em um horário programado. O preenchimento inicial de dados, ou inicialização, depende de quando a atualização inicial ocorre.
As tabelas dinâmicas são atualizadas com base no atraso de destino especificado, que define o atraso máximo permitido entre as atualizações das tabelas base e o conteúdo da tabela dinâmica. Se você definir INITIALIZE = ON_CREATE
(padrão), a tabela será inicializada imediatamente. Se você definir INITIALIZE = ON_SCHEDULE
, a inicialização ocorrerá dentro do período de atraso de destino especificado.
Por exemplo, considere uma tabela dinâmica, DT1
, com um atraso de destino de 30 minutos. O preenchimento inicial de dados para DT1
pode ocorrer da seguinte forma:
Se
DT1
estiver configurada para ser atualizada de forma síncrona na criação (ON_CREATE
), ela será inicializada na criação.Se
DT1
estiver configurada para ser atualizada em um horário programado (ON_SCHEDULE
), ela será inicializada em 30 minutos.
Em cenários com dependências downstream, o comportamento de atualização depende das dependências. Por exemplo, se a tabela dinâmica DT1
tiver um atraso de destino downstream e DT2
, que depende de DT1
, tiver um atraso de destino de 30 minutos, DT1
será atualizada somente quando DT2
for atualizada.
Para DT1
:
Se for definido para atualizar de forma síncrona na criação, ela será inicializada imediatamente. Se a inicialização falhar, o processo de criação será interrompido, fornecendo feedback imediato sobre quaisquer erros.
Se for definida para atualizar em um horário programado, a inicialização dependerá de quando
DT2
for atualizada.
A inicialização pode levar algum tempo, dependendo da quantidade de dados digitalizados. Para acompanhar o progresso, consulte Solução de problemas de criação de tabela dinâmica.
Entendendo as opções de atualização manual e programada¶
As tabelas dinâmicas são atualizadas em um cronograma determinado pelo atraso de destino. Toda vez que uma tabela dinâmica é lida, a atualização dos dados está dentro do período de tempo definido pelo atraso de destino.
Você pode atualizar manualmente suas tabelas dinâmicas para obter os dados mais recentes usando o comando ALTER DYNAMIC TABLE … REFRESH ou Snowsight. Para obter mais informações, consulte Atualize manualmente as tabelas dinâmicas.
Os tempos limite de atualização de tabela dinâmica são controlados pelo parâmetro STATEMENT_TIMEOUT_IN_SECONDS, que define a duração máxima permitida no nível da conta ou do warehouse antes que uma atualização seja automaticamente cancelada.
Como o atraso de destino afeta as atualizações programadas¶
A atraso de destino controla a frequência das atualizações programadas. Para gerenciar manualmente as atualizações, defina a atraso de destino de sua tabela dinâmica como DOWNSTREAM e certifique-se de que todas as tabelas dinâmicas downstream também estejam definidas como DOWNSTREAM.
Definir o atraso de destino de todo o gráfico acíclico dirigido (DAG) como DOWNSTREAM basicamente desativa as atualizações programadas porque a tabela dinâmica final controla o cronograma de atualização. Se nenhuma tabela dinâmica tiver um atraso de destino baseado em tempo, o pipeline será suspenso para atualizações programadas. Nesse caso, a atualização manual da tabela mais downstream atualiza automaticamente todas as dependências upstream.
Definir a atraso de destino para DOWNSTREAM não especifica o tempo exato. Em vez disso, o Snowflake escolhe uma cadência de atualização para tentar manter o atraso abaixo do valor de destino. Por exemplo, uma tabela dinâmica com um atraso de destino de 4 horas pode ser atualizada a cada 3,5 horas.
Como solução alternativa, você pode usar uma tarefa com um cronograma CRON. Por exemplo:
CREATE TASK my_task
SCHEDULE = 'USING CRON <expr> <time_zone>'
AS
ALTER DYNAMIC TABLE my_dynamic_table REFRESH;
Modos de atualização de tabelas dinâmicas¶
As tabelas dinâmicas oferecem suporte a dois modos de atualização: incremental e total. Você pode definir o modo de atualização como AUTO ou defini-lo explicitamente:
Modo de atualização AUTO: quando você usa o parâmetro
AUTO
, o Snowflake seleciona automaticamente o modo de atualização mais econômico e eficiente em termos de tempo com base na complexidade da consulta, nas construções compatíveis, nos operadores, nas funções e no desempenho esperado. Se a atualização incremental não for compatível ou tiver um desempenho ruim, o Snowflake seleciona automaticamente a atualização completa.Modo de atualização incremental: esse modo analisa a consulta da tabela dinâmica e calcula as alterações desde a última atualização. Em seguida, ele mescla essas alterações na tabela.
Modo de atualização completa: esse modo executa a consulta da tabela dinâmica e substitui completamente os resultados materializados anteriormente.
Após criar uma tabela dinâmica, você pode monitorar a tabela para determinar se atualizações incrementais ou completas são usadas para atualizar essa tabela.
Práticas recomendadas para escolher os modos de atualização da tabela dinâmica¶
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.
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.
Recomendamos enfaticamente o uso de
AUTO
para a maioria dos casos de uso, pois ele permite que o Snowflake otimize o comportamento de atualização sem ajuste manual. Para obter um comportamento consistente, defina explicitamente o modo de atualização em todas as tabelas de produção. O comportamento deAUTO
pode mudar entre os lançamentos do Snowflake, o que pode causar alterações inesperadas no desempenho se for 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
eGROUP 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 determinar o melhor modo para seu caso de uso, experimente recomendações automáticas e modos de atualização concretos (completa e incremental).
Importante
As tabelas dinâmicas em modo de atualização incremental não podem ser downstream de tabelas dinâmicas com modo de atualização completa. Isso ocorre porque o modo de atualização incremental é incompatível com as alterações completas de linha que ocorrem durante cada atualização de uma tabela de atualização upstream completa.
Para verificar o modo de atualização de suas tabelas dinâmicas, consulte Exibição do modo de atualização de tabela dinâmica.
Exibição do modo de atualização de tabela dinâmica¶
Você define o modo de atualização quando cria uma tabela dinâmica. Após a criação, você pode verificar se a tabela dinâmica usa atualizações incrementais ou completas usando um dos seguintes métodos, com uma função que tenha os privilégios necessários:
Executar o comando SHOW DYNAMIC TABLES:
SHOW DYNAMIC TABLES;
Na saída:
A coluna
text
mostra o modo de atualização especificado pelo usuário.A coluna
refresh_mode
mostra o modo de atualização real.A coluna
refresh_mode_reason
mostra por que o modo de atualização real foi escolhido.
No menu de navegação, selecione Monitoring » Dynamic Tables, e, em seguida, selecione sua tabela dinâmica.
Você pode visualizar o modo de atualização da tabela dinâmica no cabeçalho do objeto, na parte superior da página. Para atualizações completas, o motivo do modo de atualização fica visível ao passar o mouse sobre o modo.
Como os dados são atualizados quando uma tabela dinâmica depende de outras tabelas dinâmicas¶
Quando o atraso de uma tabela dinâmica é definido como uma medida de tempo, o processo de atualização automatizado programa as atualizações para melhor atender aos tempos de atraso de destino.
Para manter os dados consistentes nos casos em que uma tabela dinâmica depende de outra, o processo atualiza todas as tabelas dinâmicas em uma conta em horários compatíveis. O momento das atualizações menos frequentes coincide com o momento das atualizações mais frequentes. Se as atualizações demorarem muito, o agendador poderá ignorar as atualizações para tentar se manter atualizado. No entanto, o isolamento do instantâneo é preservado.
Por exemplo, suponha que a tabela dinâmica DT1
tenha um atraso de destino de dois minutos e consulte a tabela dinâmica DT2
, que tem um atraso de destino de um minuto. O processo pode determinar que DT1
deve ser atualizada a cada 96 segundos e DT2
a cada 48 segundos. Como resultado, o processo pode aplicar o seguinte cronograma:
Ponto específico no tempo |
Tabelas dinâmicas atualizadas |
---|---|
2022-12-01 00:00:00 |
DT1, DT2 |
2022-12-01 00:00:48 |
DT2 |
2022-12-01 00:01:36 |
DT1, DT2 |
2022-12-01 00:02:24 |
DT2 |
Isso significa que, a qualquer momento, ao consultar um conjunto de tabelas dinâmicas que dependem umas das outras, você está consultando o mesmo “instantâneo” dos dados nessas tabelas.
Observe que a meta de atraso de uma tabela dinâmica não pode ser menor que a meta de atraso das tabelas dinâmicas das quais ela depende. Por exemplo, suponha que você especifique o seguinte:
DT1
consulta as tabelas dinâmicasDT2
eDT3
.DT2
tem um atraso de destino de cinco minutos.DT3
tem um atraso de destino de um minuto.
Isso significa que o tempo de atraso de destino para DT1
não deve ser inferior a cinco minutos (ou seja, não deve ser inferior ao maior dos tempos de atraso para DT2
e DT3
).
Se você definir o atraso para DT1
para cinco minutos, o processo define um cronograma de atualização com essas metas:
Atualize a
DT3
com frequência suficiente para manter o atraso abaixo de um minuto.Atualize
DT1
eDT2
juntas e com frequência suficiente para manter seus atrasos abaixo de cinco minutos.Certifique-se de que a atualização de
DT1
eDT2
coincida com uma atualização deDT3
para garantir o isolamento do instantâneo.
Importante
As tabelas dinâmicas em modo de atualização incremental não podem ser downstream de tabelas dinâmicas com modo de atualização completa. Isso ocorre porque o modo de atualização incremental é incompatível com as alterações completas de linha que ocorrem durante cada atualização de uma tabela de atualização upstream completa.
Como compreender os efeitos das alterações nas colunas das tabelas de base¶
Quando os objetos subjacentes associados a uma tabela dinâmica mudam, os seguintes comportamentos se aplicam:
Mudança |
Impacto |
---|---|
|
Nenhum. Se uma nova coluna for adicionada à tabela de base ou uma coluna não utilizada for excluída, nenhuma ação ocorrerá e as atualizações continuarão como antes. |
|
Reinicialização: a primeira atualização após a recriação é a inicialização. |
|
As atualizações futuras da tabela dinâmica falharão. A tabela dinâmica deve ser recriada para responder à alteração. |
Práticas recomendadas para atualização de tabelas dinâmicas¶
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 Entendendo o atraso de destino da tabela dinâmica.