Como é feita a atualização de tabela dinâmica¶

Modos de atualização de tabelas dinâmicas¶

O processo de atualização da tabela dinâmica ocorre de duas maneiras:

1. Atualização incremental: esse processo automatizado 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. Consulte Consultas suportadas na atualização incremental para obter detalhes sobre consultas suportadas.

2. Atualização completa: quando o processo automatizado não consegue realizar uma atualização incremental, ele realiza uma atualização completa. Isso envolve a execução da consulta da tabela dinâmica e a substituição completa dos resultados materializados anteriores.

As construções usadas na consulta determinam se uma atualização incremental pode ser usada. Depois de 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.

Compreensão da meta de atraso¶

A atualização de tabelas dinâmicas é acionada com base em como os dados podem estar desatualizados, ou o que é comumente referido como atraso de destino. O atraso de destino para uma tabela dinâmica é medido em relação às tabelas base na raiz do gráfico, não em relação às tabelas dinâmicas diretamente upstream. 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.

Para ver o gráfico de tabelas conectadas à sua tabela dinâmica, consulte Uso do Snowsight para examinar o gráfico de tabelas dinâmicas.

O atraso de destino é especificado de uma das seguintes maneiras:

1. 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 a tabela dinâmica product para atualizar e manter a atualidade a cada hora:

   ALTER DYNAMIC TABLE product SET TARGET_LAG = '1 hour';
   

   Copy

2. 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 pela atualização manual ou agendada de uma tabela dinâmica downstream.

   No exemplo a seguir, product é baseado em outras tabelas dinâmicas e é definido para atualizar com base no atraso de destino de suas tabelas dinâmicas downstream:

   ALTER DYNAMIC TABLE product SET TARGET_LAG = DOWNSTREAM;
   

   Copy

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

Considere o seguinte exemplo em que a tabela dinâmica 2 (DT2) é definida com base na tabela dinâmica 1 (DT1). DT2 deve ler DT1 para materializar seu conteúdo. Além disso, um relatório consome dados do DT2 por meio de uma consulta.

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

Consultas suportadas na atualização incremental¶

A tabela a seguir descreve as expressões, palavras-chave e cláusulas que atualmente oferecem suporte à atualização incremental. Para obter uma lista de consultas que não oferecem suporte à atualização incremental, consulte Limitações ao suporte para atualização incremental.

Atualmente, junções laterais não são aceitas com atualização incremental. No entanto, você pode usar LATERAL com FLATTEN() configurando o modo de atualização como INCREMENTAL.

Por exemplo:

CREATE TABLE persons
  AS
    SELECT column1 AS id, parse_json(column2) AS entity
    FROM values
      (12712555,
      '{ name:  { first: "John", last: "Smith"},
        contact: [
        { business:[
          { type: "phone", content:"555-1234" },
          { type: "email", content:"j.smith@company.com" } ] } ] }'),
      (98127771,
      '{ name:  { first: "Jane", last: "Doe"},
        contact: [
        { business:[
          { type: "phone", content:"555-1236" },
          { type: "email", content:"j.doe@company.com" } ] } ] }') v;

CREATE DYNAMIC TABLE example
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = mywh
  REFRESH_MODE = INCREMENTAL
  AS
    SELECT p.id, f.value, f.path
    FROM persons p,
    LATERAL FLATTEN(input => p.entity) f;

Como os operadores atualizam incrementalmente¶

A tabela a seguir descreve como cada operador é incrementalizado (ou seja, como ele é transformado em um novo fragmento de consulta que gera alterações em vez de resultados completos) e seu desempenho e outros fatores importantes a serem considerados.

CREATE DYNAMIC TABLE sums
  AS
    SELECT date_trunc(minute, ts), sum(c1) FROM table
    GROUP BY 1;

CREATE DYNAMIC TABLE intermediate
  AS
    SELECT date_trunc(minute, ts) ts_min, c1 FROM table;

CREATE DYNAMIC TABLE sums
  AS
    SELECT ts_min, sum(c1) FROM intermediate
    GROUP BY 1;

Funções não determinísticas suportadas em atualização completa¶

As seguintes funções não determinísticas são suportadas em tabelas dinâmicas. Observe que essas funções são suportadas apenas para atualizações completas. Para obter uma lista do que não é compatível com atualização incremental, consulte Limitações ao suporte para atualização incremental.

• Funções definidas pelo usuário VOLATILE

• Funções de sequência (por exemplo, SEQ1, SEQ2)

• As seguintes funções de contexto:

  • CURRENT_ROLE

  • CURRENT_WAREHOUSE

  • CURRENT_ACCOUNT

  • CURRENT_REGION

• As seguintes funções de data e hora (com seus respectivos aliases):

  • CURRENT_DATE

  • CURRENT_TIME

  • CURRENT_TIMESTAMP

Como os dados são atualizados quando as tabelas dinâmicas dependem de outras tabelas dinâmicas¶

Quando um atraso de tabela dinâmica é especificado como uma medida de tempo, o processo de atualização automatizado determina o planejamento para atualizações, com base nos tempos de atraso de destino das tabelas dinâmicas. O processo escolhe um cronograma que melhor atenda aos tempos da meta de atraso das tabelas.

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.

Por exemplo, suponha que a tabela dinâmica A tenha uma meta de atraso de dois minutos e consulte a tabela dinâmica B que tenha uma meta de atraso de um minuto. O processo pode determinar que A deve ser atualizado a cada 96 segundos e B a cada 48 segundos. Como resultado, o processo pode aplicar o seguinte cronograma:

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:

• A tabela dinâmica A consulta as tabelas dinâmicas B e C.

• Tabela dinâmica B tem uma meta de atraso de cinco minutos.

• Tabela dinâmica C tem uma meta de atraso de um minuto.

Isso significa que o tempo da meta de atraso para A não deve ser inferior a cinco minutos (ou seja, não menor que o maior dos tempos de atraso para B e C).

Se você definir o atraso de A para cinco minutos, o processo configurará um cronograma de atualização com estes objetivos:

• Atualize C com frequência suficiente para manter o atraso abaixo de um minuto.

• Atualize A e B juntos e com frequência suficiente para manter seus atrasos abaixo de cinco minutos.

• Certifique-se de que a atualização de A e B coincida com uma atualização de C para garantir o isolamento do instantâneo.

Observação: se as atualizações demorarem muito, o agendador poderá ignorá-las para tentar se manter atualizado. No entanto, o isolamento do instantâneo é preservado.