Entendendo o atraso de destino da tabela dinâmica¶

A atualização da tabela dinâmica é acionada pelo atraso de destino dos dados, que determina o quanto podem estar desatualizados. Você pode definir um atraso de destino fixo ou definir a tabela dinâmica para DOWNSTREAM, fazendo com que o tempo de atualização dela dependa das tabelas dinâmicas que dependem dela.

O atraso de destino de uma tabela dinâmica é medido em relação às tabelas dinâmicas na raiz do gráfico, não às tabelas dinâmicas diretamente a montante. Para ver o gráfico de tabelas conectadas à sua tabela dinâmica, consulte Visualize o gráfico das tabelas conectadas às suas tabelas dinâmicas.

O Snowflake agenda atualizações para manter o atraso real de suas tabelas dinâmicas abaixo do atraso de destino. A duração de cada atualização depende da consulta, do padrão de dados e do tamanho do warehouse. Ao escolher um atraso de destino, considere o tempo necessário para atualizar cada tabela dinâmica em uma cadeia até a raiz. Caso contrário, algumas atualizações poderão ser ignoradas, resultando em um maior atraso real.

Tipos de atraso de destino¶

Você especifica o atraso de destino de uma das seguintes maneiras. O atraso de destino é inversamente proporcional à frequência de atualização da tabela dinâmica: atualizações frequentes implicam em um atraso menor.

Medida de atualidade: Define a quantidade máxima de tempo que o conteúdo da tabela dinâmica deve atrasar as atualizações nas tabelas base.
O exemplo a seguir define my_dynamic_table para atualizar e manter a atualidade a cada hora:
ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = '1 hour';
Copy
Downstream: especifica que a tabela dinâmica deve ser atualizada sob demanda quando as tabelas downstream (tabelas que dependem desta tabela) forem atualizadas. Essa atualização pode ser acionada por inicialização na criação, atualização manual ou atualização agendada de uma tabela downstream.

Quando refresh_mode é definido como downstream, o cronograma de atualização de uma tabela dinâmica é determinado pela latência menor (mais exigente) de suas dependentes downstream. Por exemplo, se uma tabela dependente downstream exigir dados com no máximo 10 minutos de idade e outra tabela dependente downstream exigir dados com no máximo 1 hora, a programação de atualização dessa tabela dinâmica será a cada 10 minutos, pois esse é o menor atraso entre as tabelas dependentes downstream.

No exemplo a seguir, my_dynamic_table está configurada para atualizar com base no atraso de destino de suas tabelas dinâmicas downstream. Se my_dynamic_table não tiver nenhuma tabela dinâmica que dependa dela, ela não será atualizada.
```
ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = DOWNSTREAM;
```
Copy
Para obter mais exemplos de atraso de destino downstream, consulte Exemplo: atraso de destino para cadeias de tabelas dinâmicas.

Como o Snowflake agenda atualizações¶

O Snowflake agenda atualizações um pouco antes do atraso de destino para dar tempo de elas serem concluídas. Por exemplo, se você definir o atraso de destino para cinco minutos, a tabela poderá ser atualizada com mais frequência do que a cada cinco minutos. Os intervalos de atualização reais geralmente são menores do que o atraso especificado.

Nota

O atraso de destino é uma meta, não uma garantia. O Snowflake tenta manter os dados dentro do atraso de destino, mas o atraso real pode exceder a meta devido a fatores como tamanho do warehouse, volume de dados e complexidade da consulta.

Para obter orientações sobre como ajustar o atraso de destino para sua carga de trabalho, consulte Altere o warehouse ou o atraso de destino das tabelas dinâmicas. Para obter informações sobre como otimizar o atraso de destino, consulte Identificação do atraso correto no destino.

Como os relacionamentos upstream e downstream afetam o atraso de destino¶

O diagrama a seguir ilustra operações de suspensão, retomada e atualização manual no contexto de relacionamentos a montante e a jusante com outras tabelas dinâmicas.

Relacionamento entre tabelas dinâmicas. Usado para ajudar a explicar a suspensão, a retomada e a atualização manual.

O diagrama descreve um pipeline de dados declarativos simples criado com tabelas dinâmicas:

DT2 é descrito como downstream de DT1 porque depende dessa tabela dinâmica, e como upstream de DT3, que depende dela.
DT3 está a jusante de DT2 e DT1 porque depende de DT2 diretamente e de DT1 indiretamente.
DT1 está direta ou indiretamente a montante das outras tabelas dinâmicas.

Exemplo: atraso de destino para cadeias de tabelas dinâmicas¶

Considere o exemplo a seguir, em que uma tabela dinâmica (DT2) lê de outra tabela dinâmica (DT1) para materializar seu conteúdo. Nesse cenário, um relatório consome os dados da DT2 por meio de uma consulta.

Exemplo simples de duas tabelas dinâmicas: DT2, que é definida com base em DT1.

Os seguintes resultados são possíveis, dependendo de como cada tabela dinâmica especifica seu atraso:

`DT1`	`DT2`	Atualizar resultados
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = 10minutes`	`DT2` é atualizada pelo menos a cada 10 minutos. `DT1` infere seu atraso a partir de `DT2` e é atualizada sempre que `DT2` requer atualizações.
`TARGET_LAG = 10minutes`	`TARGET_LAG = DOWNSTREAM`	Este cenário deve ser evitado. A consulta do relatório não receberá nenhum dado. DT1 é atualizada com frequência e `DT2` não é atualizada porque não há uma tabela dinâmica baseada em `DT2`.
`TARGET_LAG = 5minutes`	`TARGET_LAG = 10minutes`	`DT2` é atualizado aproximadamente a cada 10 minutos com dados de `DT1`, ou seja, no máximo 5 minutos.
`TARGET_LAG = DOWNSTREAM`	`TARGET_LAG = DOWNSTREAM`	Nem `DT1` nem `DT2` são atualizadas periodicamente porque ambas têm um atraso de downstream e nenhuma delas tem um consumidor downstream com um atraso definido.