Entendendo o atraso de destino da tabela dinâmica¶

Dynamic table refresh is triggered by the data’s target lag, which determines how outdated it can be. You can set a fixed target lag or set the dynamic table to DOWNSTREAM, making its refresh timing depend on the dynamic tables that depend on it.

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¶

You specify target lag in one of the following ways. Target lag is inversely proportional to the dynamic table’s refresh frequency: frequent refreshes imply a lower lag.

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: Specifies that the dynamic table should refresh on demand when downstream tables (tables that depend on this table) refresh. This refresh can be triggered by initialization at creation, manual refresh, or scheduled refresh of a downstream table.

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 Example: Target lag for dynamic table chains.

Como o Snowflake agenda atualizações¶

Snowflake schedules refreshes slightly earlier than the target lag to allow time for the refresh to complete. For example, if you set the target lag to 5 minutes, the table might refresh more frequently than every five minutes. Actual refresh intervals are often shorter than the specified lag.

Nota

Target lag is a target, not a guarantee. Snowflake attempts to keep data within the target lag, but actual lag may exceed the target because of factors such as warehouse size, data volume, and query complexity.

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.

Example: Target lag for dynamic table chains¶

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.