Entendendo o atraso de destino da tabela dinâmica¶

A atualização dinâmica da tabela é acionada pelo atraso de destino dos dados, que determina o quão desatualizados eles podem estar. Você pode definir um atraso de destino fixo ou definir a tabela dinâmica como DOWNSTREAM, fazendo com que o tempo de atualização dependa de outras 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.

Nota

A meta de atraso não é uma garantia. Em vez disso, é uma meta que o Snowflake tenta atingir. Os dados em tabelas dinâmicas são atualizados o mais próximo possível da meta de atraso. No entanto, a meta de atraso pode ser excedido devido a fatores como tamanho do warehouse, tamanho dos dados, complexidade da consulta e fatores semelhantes.

Tipos de atraso de destino¶

A atraso de destino é especificado 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 outras tabelas dinâmicas dependentes forem atualizadas. Essa atualização pode ser acionada por inicialização na criação, atualização manual ou atualização programada de uma tabela dinâmica 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

Determinação da meta de atraso ideal para uma tabela dinâmica¶

O atraso de destino definido por você afeta a frequência das atualizações programadas da tabela dinâmica.

O Snowflake agenda as atualizações um pouco mais cedo para dar tempo para que a atualização seja concluída. Por exemplo, se você definir o atraso de destino como 5 minutos, isso não significa que a tabela será atualizada exatamente a cada 5 minutos. Os intervalos reais de atualização podem ser menores do que o intervalo especificado. Se você quiser atualizações de 5 minutos mais consistentes, considere aumentar um pouco o atraso de destino.

Você pode usar a função de tabela DYNAMIC_TABLE_REFRESH_HISTORY em INFORMATION_SCHEMA ou no Snowsight para determinar o tempo de atraso de destino ideal de acordo com suas necessidades. Por exemplo, ao analisar os detalhes da atualização, incluindo a duração e as atualizações ignoradas, para tomar uma decisão informada.

Para obter informações sobre o monitoramento de atualizações de tabelas dinâmicas e a solução de problemas, consulte Monitoramento de tabelas dinâmicas e Diagnóstico de problemas comuns de atualização dinâmica de tabelas.

A função DYNAMIC_TABLE_REFRESH_HISTORY retorna informações sobre cada atualização de uma tabela dinâmica, incluindo o tempo necessário para a atualização e quais atualizações foram ignoradas.

SELECT
    name
FROM
  TABLE (
    INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY (
      NAME_PREFIX => 'MYDB.MYSCHEMA.', ERROR_ONLY => TRUE
    )
  );

Copy

A saída reflete as atualizações ao longo do tempo. Cada linha representa uma atualização. Uma nova linha é adicionada sempre que a tabela dinâmica é atualizada.

Altere o atraso de destino¶

Você pode querer ajustar o atraso de destino de uma tabela dinâmica por qualquer um dos seguintes motivos:

Você precisa de dados mais atualizados. A redução do atraso de destino garante que a tabela dinâmica seja atualizada com mais frequência, fornecendo dados mais atualizados e mais próximos do tempo real.
Você deseja otimizar os recursos. Aumentar o atraso de destino pode reduzir a frequência das atualizações, economizando recursos de computação, o que é útil para cargas de trabalho que não precisam de atualizações constantes ou em que os dados são alterados com pouca frequência. Por exemplo, se uma tabela dinâmica é atualizada a cada 20 minutos, mas só precisa estar dentro de uma hora das tabelas de origem, a configuração de um atraso de destino de uma hora pode reduzir os custos.
Você deseja que o atraso de destino se alinhe ao pipeline de dados. Se a sua tabela dinâmica depender de outras tabelas com intervalos de atualização mais longos, o ajuste do atraso de destino garante que ela se alinhe às dependências.

Para alterar o atraso de destino, use o comando ALTER DYNAMIC TABLE. Para obter mais informações, consulte Altere o warehouse ou o atraso de destino das tabelas dinâmicas.

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.