É possível criar PDTs incrementais no seu projeto, se o dialeto for compatível. Uma PDT incremental é uma tabela derivada persistente (PDT, na sigla em inglês) criada pelo Looker anexando novos dados à tabela, em vez de recriar a tabela inteira. Consulte a página de documentação de PDTs incrementais para mais informações.

increment_key é o parâmetro que transforma um PDT em um PDT incremental especificando o incremento de tempo para o qual dados novos devem ser consultados e anexados ao PDT. Além do increment_key, também é possível fornecer um increment_offset para especificar o número de períodos anteriores (com granularidade da chave de incremento) que são recriados para considerar os dados atrasados.

O increment_key de um PDT é independente do gatilho de persistência do PDT. Consulte a página de documentação de PDTs incrementais para ver alguns exemplos de interação que mostram a interação de increment_key, increment_offset e a estratégia de persistência.

O parâmetro increment_key funciona somente com dialetos compatíveis e com tabelas que têm uma estratégia de persistência, como PDT e tabelas de agregação, que são um tipo de PDT.

O increment_key precisa especificar uma dimensão LookML com base no tempo:

Para PDTs baseados em LookML, o increment_key deve se basear em uma dimensão LookML definida na visualização em que o explore_source do PDT se baseia. Consulte a seção Como criar um PDT incremental com base em LookML nesta página para ver um exemplo.
Para tabelas agregadas, a increment_key precisa se basear em uma dimensão LookML definida na visualização em que o recurso Explorar da tabela agregada se baseia. Consulte a seção Como criar uma tabela de agregação incremental nesta página para ver um exemplo.
Para PDTs baseados em SQL, o increment_key precisa ser baseado em uma dimensão LookML definida no arquivo de visualização do PDT. Consulte Como criar um PDT incremental baseado em SQL nesta página para ver um exemplo.

Além disso, o increment_key precisa ser:

Uma hora absoluta truncada, como dia, mês, ano, trimestre fiscal e assim por diante. Períodos como dia da semana não são compatíveis.
Um carimbo de data/hora que aumenta de modo previsível com novos dados, como a data de criação do pedido. Em outras palavras, um carimbo de data/hora deverá ser usado como uma chave de incremento somente se os dados mais recentes adicionados à tabela também tiverem o carimbo de data/hora mais recente. Um carimbo de data/hora como data de aniversário não funciona como uma chave de incremento, já que um carimbo de data/hora de aniversário não aumenta de maneira confiável com novos usuários adicionados à tabela.

Como criar um PDT incremental com base em LookML

Para transformar uma PDT baseada em LookML (nativa) em uma PDT incremental, use o parâmetro increment_key para especificar o nome de uma dimensão LookML baseada em tempo. A dimensão precisa ser definida na visualização em que o explore_source do PDT se baseia.

Por exemplo, veja um arquivo de visualização para uma PDT com base no LookML, usando o parâmetro LookML explore_source. O PDT é criado na exploração flights, que, neste caso, se baseia na visualização flights:

view: flights_lookml_incremental_pdt {
  derived_table: {
    indexes: ["id"]
    increment_key: "departure_date"
    increment_offset: 3
    datagroup_trigger: flights_default_datagroup
    distribution_style: all
    explore_source: flights {
      column: id {}
      column: carrier {}
      column: departure_date {}
    }
  }

  dimension: id {
    type: number
  }
  dimension: carrier {
    type: string
  }
  dimension: departure_date {
    type: date
  }
}

Esta tabela será criada na primeira vez que uma consulta for executada. Depois disso, a PDT será recriada em incrementos de um dia (increment_key: departure_date), voltando três dias (increment_offset: 3).

Na verdade, a dimensão departure_date é o período date do grupo de dimensões departure. Consulte a página de documentação do parâmetro dimension_group para ter uma visão geral de como os grupos de dimensões funcionam. O grupo de dimensões e o período são definidos na visualização flights, que é o explore_source desse PDT. Veja como o grupo de dimensões departure é definido no arquivo de visualização flights:

...
  dimension_group: departure {
    type: time
    timeframes: [
      raw,
      date,
      week,
      month,
      year
    ]
    sql: ${TABLE}.dep_time ;;
  }
...

Como criar um PDT incremental com base em SQL

O Looker sugere o uso de tabelas derivadas baseadas em LookML (nativo) como base para PDTs incrementais, em vez de tabelas derivadas baseadas em SQL. Tabelas derivadas nativas processam inerentemente a lógica complexa necessária para PDTs incrementais. Os PDTs baseados em SQL dependem da lógica criada manualmente, que é propensa a erros quando usada com funcionalidade altamente complexa.

Para definir um PDT incremental baseado em SQL, use increment_key e, como opção, increment_offset, como você faria com um PDT baseado em LookML. No entanto, como as PDTs baseadas em SQL não são baseadas em arquivos de visualização do LookML, há outros requisitos para transformar uma PDT baseada em SQL em uma PDT incremental:

A chave do incremento precisa ser baseada em uma dimensão LookML com base no tempo que você define no arquivo de visualização do PDT.
É necessário fornecer um filtro Líquido {% incrementcondition %} no PDT para conectar a chave de incremento à coluna de horário do banco de dados em que a chave do incremento é baseada. O filtro {% incrementcondition %} precisa especificar o nome da coluna no seu banco de dados, não um alias SQL nem o nome de uma dimensão com base na coluna (consulte o exemplo a seguir).

O formato básico do filtro Líquido é:

   WHERE {% incrementcondition %} database_table_name.database_time_column {% endincrementcondition %}

Por exemplo, veja o arquivo de visualização de uma PDT baseada em SQL que é recriada em incrementos de um dia (increment_key: "dep_date"), onde os dados dos últimos três dias serão adicionados à tabela quando for recriado (increment_offset: 3):

view: sql_based_incremental_date_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "dep_date"
    increment_offset: 3
    distribution_style: all
    sql: SELECT
        flights.id2  AS "id",
        flights.origin  AS "origin",
        DATE(flights.leaving_time )  AS "departure"
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
          ;;
  }

  dimension_group: dep {
    type: time
    timeframes: [raw, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

Observe o seguinte sobre este exemplo:

A tabela derivada é baseada em uma instrução SQL. A instrução SQL cria uma coluna na tabela derivada com base na coluna flights.leaving_time no banco de dados. A coluna recebe o alias departure.
O arquivo de visualização do PDT define um grupo de dimensões chamado dep.
- O parâmetro sql do grupo de dimensões indica que ele está baseado na coluna departure da tabela derivada.
- O parâmetro timeframes do grupo de dimensões inclui date como um período.
O increment_key da tabela derivada usa a dimensão dep_date, que é baseada no período do date do grupo de dimensões dep. Consulte a página de documentação do parâmetro dimension_group para ter uma visão geral de como os grupos de dimensões funcionam.
O filtro Liquid {% incrementcondition %} é usado para conectar a chave de incremento à coluna flights.leaving_time no banco de dados.
- O {% incrementcondition %} precisa especificar o nome de uma coluna TIMESTAMP no seu banco de dados ou ser avaliado como uma coluna TIMESTAMP no seu banco de dados.
- {% incrementcondition %} precisa avaliar o que está disponível na cláusula FROM que define o PDT, como colunas da tabela especificada na cláusula FROM. O {% incrementcondition %} não pode se referir ao resultado da instrução SELECT, como um alias atribuído a uma coluna na instrução SQL ou o nome de uma dimensão que é baseada na coluna. No exemplo acima, o {% incrementcondition %} é flights.leaving_time. Como a cláusula FROM especifica a tabela flights, o {% incrementcondition %} pode se referir a colunas da tabela flights.
- O {% incrementcondition %} precisa apontar para a mesma coluna do banco de dados usada para a chave de incremento. Neste exemplo, a chave de incremento é dep_date, uma dimensão definida pela coluna departure na PDT, que é um alias para a coluna flights.leaving_time no banco de dados. Portanto, o filtro aponta para flights.leaving_time:

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

É possível adicionar à cláusula WHERE para criar outros filtros. Por exemplo, se a tabela do banco de dados reaparece há muitos anos, você pode criar um filtro para que o build inicial da PDT use somente dados após uma determinada data. Este WHERE cria um PDT com dados a partir de 1o de janeiro de 2020:

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
  AND flights.leaving_time > '2020-01-01'

Também é possível usar a cláusula WHERE para analisar dados no SQL em um carimbo de data/hora e atribuir um alias a ele. Por exemplo, o PDT incremental a seguir usa um incremento de 15 minutos baseado em text_column, que são dados de string que foram analisados em dados de carimbo de data/hora:

view: sql_based_incremental_15min_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "event_minute15"
    increment_offset: 1
    sql: SELECT PARSE_TIMESTAMP("%c", flights.text_column) as parsed_timestamp_column,
        flights.id2  AS "id",
        flights.origin  AS "origin",
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} PARSE_TIMESTAMP("%c", flights.text_column)
          {% endincrementcondition %} ;;
  }

  dimension_group: event {
    type: time
    timeframes: [raw, minute15, hour, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.parsed_timestamp_column ;;
  }
  dimension: id {
    type: number
  }
  dimension: origin {
    type: string
  }
}

É possível usar o alias para o SQL na definição sql do grupo de dimensões, mas é necessário usar a expressão SQL na cláusula WHERE. Então, como minute15 foi configurado como um intervalo de tempo no grupo de dimensões event, é possível usar event_minute15 como a chave de incremento para receber um incremento de 15 minutos para o PDT.

Como criar uma tabela agregada incremental

Para criar uma tabela agregada incremental, adicione increment_key e, opcionalmente, increment_offset no parâmetro materialization do parâmetro aggregate_table. Use o parâmetro increment_key para especificar o nome de uma dimensão LookML com base no tempo. A dimensão precisa ser definida na visualização em que o recurso "Explorar" da tabela agregada se baseia.

Por exemplo, essa tabela agregada se baseia na exploração accidents, que, nesse caso, é baseada na visualização accidents. A tabela agregada é recriada em incrementos de uma semana (increment_key: event_week), voltando em duas semanas (increment_offset: 2):

explore: accidents {
  . . .
  aggregate_table: accidents_daily {
    query: {
      dimensions: [event_date, id, weather_condition]
      measures: [count]
    }
    materialization: {
      datagroup_trigger: flights_default_datagroup
      increment_key: "event_week"
      increment_offset: 2
    }
  }
}

A chave de incremento usa a dimensão event_week, que é baseada no período week do grupo de dimensões event. Consulte a página de documentação do parâmetro dimension_group para ter uma visão geral de como os grupos de dimensões funcionam. O grupo de dimensões e o período são definidos na visualização accidents:

. . .
view: accidents {
  . . .
  dimension_group: event {
      type: time
      timeframes: [
        raw,
        date,
        week,
        year
      ]
      sql: ${TABLE}.event_date ;;
  }
  . . .
}

Considerações

Otimizar a tabela de origem para consultas baseadas em tempo

Verifique se a tabela de origem do PDT incremental está otimizada para consultas baseadas em tempo. Especificamente, a coluna com base em tempo usada para a chave de incremento precisa ter uma estratégia de otimização, como particionamento, ordlas, índices ou qualquer outra estratégia de otimização compatível com seu dialeto. A otimização da tabela de origem é altamente recomendada porque toda vez que a tabela incremental é atualizada, o Looker consulta a tabela de origem para determinar os valores mais recentes da coluna de tempo usada para a chave de incremento. Se a tabela de origem não estiver otimizada para essas consultas, a consulta do Looker sobre os valores mais recentes pode ser lenta e cara.

Dialetos de banco de dados compatíveis com PDTs incrementais

Para que o Looker ofereça suporte a PDTs incrementais no seu projeto do Looker, o dialeto do banco de dados precisa ser compatível com os comandos da Linguagem de definição de dados (DDL) que permitem a exclusão e a inserção de linhas.

A tabela a seguir mostra quais dialetos são compatíveis com PDTs incrementais na versão mais recente do Looker: