Tabelas derivadas no Looker

No Looker, uma tabela derivada é uma consulta com resultados usados como se fosse uma tabela real no banco de dados.

Por exemplo, você pode ter uma tabela de banco de dados chamada orders com muitas colunas. Você quer calcular algumas métricas agregadas no nível do cliente, como quantos pedidos cada cliente fez ou quando cada cliente fez o primeiro pedido. Usando uma tabela derivada nativa ou uma tabela derivada baseada em SQL, é possível criar uma nova tabela de banco de dados chamada customer_order_summary que inclua essas métricas.

Você pode trabalhar com a tabela derivada customer_order_summary como se fosse qualquer outra tabela no banco de dados.

Para casos de uso comuns de tabelas derivadas, acesse Livros de receitas do Looker: como aproveitar ao máximo as tabelas derivadas no Looker.

Tabelas derivadas nativas e tabelas derivadas baseadas em SQL

Para criar uma tabela derivada no seu projeto do Looker, use o parâmetro derived_table em um parâmetro de visualização. Dentro do parâmetro derived_table, é possível definir a consulta para a tabela derivada de duas maneiras:

• Para uma tabela derivada nativa, defina a tabela derivada com uma consulta baseada no LookML.
• Para uma tabela derivada com base em SQL, você define a tabela derivada com uma consulta SQL.

Por exemplo, os arquivos de visualização a seguir mostram como usar o LookML para criar uma visualização a partir de uma tabela derivada de customer_order_summary. As duas versões do LookML ilustram como você pode criar tabelas derivadas equivalentes usando LookML ou SQL para definir a consulta para a tabela derivada:

• A tabela derivada nativa define a consulta com LookML no parâmetro explore_source. Neste exemplo, a consulta é baseada em uma visualização orders já existente, que é definida em um arquivo separado não mostrado neste exemplo. A consulta explore_source na tabela derivada nativa traz os campos customer_id, first_order e total_amount do arquivo de visualização orders.
• A tabela derivada baseada em SQL define a consulta usando SQL no parâmetro sql. Neste exemplo, a consulta SQL é uma consulta direta da tabela orders no banco de dados.

Versão de tabela derivada nativa

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

Versão da tabela derivada baseada em SQL

view: customer_order_summary {
  derived_table: {
    sql:
      SELECT
        customer_id,
        MIN(DATE(time)) AS first_order,
        SUM(amount) AS total_amount
      FROM
        orders
      GROUP BY
        customer_id ;;
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

As duas versões criam uma visualização chamada customer_order_summary que é baseada na tabela orders, com as colunas customer_id, first_order, e total_amount.

Além do parâmetro derived_table e dos subparâmetros, essa visualização customer_order_summary funciona como qualquer outro arquivo de visualização. Ao definir a consulta da tabela derivada com LookML ou SQL, você pode criar medidas e dimensões do LookML baseadas nas colunas da tabela derivada.

Depois de definir a tabela derivada, você pode usá-la como qualquer outra tabela em seu banco de dados.

Tabelas derivadas nativas

As tabelas derivadas nativas são baseadas em consultas que você define usando termos do LookML. Para criar uma tabela derivada nativa, use o parâmetro explore_source dentro do parâmetro derived_table de um parâmetro de visualização. Para criar as colunas da tabela derivada nativa, consulte as dimensões ou medidas do LookML no modelo. Consulte o arquivo nativo de visualização em tabela derivada no exemplo anterior.

Em comparação com as tabelas derivadas baseadas em SQL, as tabelas derivadas nativas são muito mais fáceis de ler e entender enquanto você modela seus dados.

Consulte a página de documentação Como criar tabelas derivadas nativas para detalhes sobre como criar tabelas derivadas nativas.

Tabelas derivadas baseadas em SQL

Para criar uma tabela derivada baseada em SQL, você define uma consulta em termos de SQL, criando colunas na tabela usando uma consulta SQL. Não é possível referenciar as dimensões e medidas do LookML em uma tabela derivada baseada em SQL. Consulte o arquivo de visualização em tabela derivada baseado em SQL no exemplo anterior.

Geralmente, você define a consulta SQL usando o parâmetro sql dentro do parâmetro derived_table de um parâmetro de visualização.

Um atalho útil para criar consultas baseadas em SQL no Looker é usar o SQL Runner para criar a consulta SQL e transformá-la em uma definição de tabela derivada.

Alguns casos extremos não permitem o uso do parâmetro sql. Nesses casos, o Looker aceita os seguintes parâmetros para definir uma consulta SQL para tabelas derivadas persistentes (TDPs):

• create_process: quando você usa o parâmetro sql para uma TDP, em segundo plano, o Looker une a CREATE TABLE instrução de linguagem de definição de dados (DDL) do dialeto para criar a TDP com base na consulta SQL. Alguns dialetos não são compatíveis com uma instrução SQL CREATE TABLE em uma única etapa. Para esses dialetos, não é possível criar uma TDP com o parâmetro sql. Em vez disso, é possível usar o parâmetro create_process para criar uma TDP em várias etapas. Consulte a página da documentação do parâmetro create_process para informações e exemplos.
• sql_create: se o caso de uso exigir comandos DDL personalizados e seu dialeto oferecer suporte a DDL (por exemplo, o BigQuery ML preditivo), use o parâmetro sql_create para criar uma TDP em vez de usar o parâmetro sql. Consulte a página de documentação do sql_create para mais informações e exemplos.

Independentemente de usar o parâmetro sql, create_process ou sql_create, em todos esses casos você está definindo a tabela derivada com uma consulta SQL. Portanto, todas são consideradas tabelas derivadas baseadas em SQL.

Ao definir uma tabela derivada baseada em SQL, forneça a cada coluna um alias limpo usando AS. Isso ocorre porque você precisará fazer referência aos nomes das colunas do seu conjunto de resultados em suas dimensões, como ${TABLE}.first_order. É por isso que o exemplo anterior usa MIN(DATE(time)) AS first_order em vez de simplesmente MIN(DATE(time)).

Observação :para ser usada como uma TDP incremental, uma tabela derivada com base em SQL precisa ser definida usando o parâmetro sql. Tabelas derivadas baseadas em SQL que são definidas com o parâmetro sql_create ou create_process não podem ser criadas de forma incremental.

Tabelas derivadas temporárias e persistentes

Além da distinção entre tabelas derivadas nativas e tabelas derivadas baseadas em SQL, há também uma distinção entre uma tabela derivada temporária, que não é gravada no banco de dados, e uma tabela derivada persistente (TDP) que é gravada em um esquema no seu banco de dados.

Tabelas derivadas nativas e tabelas derivadas baseadas em SQL podem ser temporárias ou persistentes.

Tabelas derivadas temporárias

As tabelas derivadas mostradas anteriormente são exemplos de tabelas derivadas temporárias. Elas são temporárias porque não há estratégia de persistência definida no parâmetro derived_table.

As tabelas derivadas temporárias não são gravadas no banco de dados. Quando um usuário executa uma consulta do Explore que envolve uma ou mais tabelas derivadas, o Looker constrói uma consulta SQL usando uma combinação específica de dialetos do SQL para as tabelas derivadas, além dos campos, mesclagens e valores de filtro solicitados. Se a combinação já tiver sido executada e os resultados ainda forem válidos no cache, o Looker vai usá-los. Para mais informações sobre o armazenamento em cache de consultas no Looker, consulte a página de documentação Consultas em cache.

Caso contrário, se o Looker não puder usar resultados armazenados em cache, será necessário fazer uma nova consulta no seu banco de dados sempre que um usuário solicitar dados de uma tabela derivada temporária. Por isso, verifique se as tabelas derivadas temporárias têm bom desempenho e não sobrecarregarão seu banco de dados. Nos casos em que a consulta leva algum tempo para ser executada, uma PDT costuma ser uma opção melhor.

Dialetos de banco de dados compatíveis com tabelas derivadas temporárias

Para que o Looker ofereça suporte a tabelas derivadas no seu projeto, o dialeto do seu banco de dados também precisa ter suporte para elas. A tabela a seguir mostra quais dialetos são compatíveis com tabelas derivadas na versão mais recente do Looker:

Dialeto	Compatível?
Avalanche	Sim
Amazon Athena	Sim
MySQL do Amazon Aurora	Sim
Amazon Redshift	Sim
Apache Druid	Sim
Apache Druid 0.13 ou superior	Sim
Apache Druid 0.18 ou superior	Sim
Apache Hive 2.3 ou superior	Sim
Apache Hive 3.1.2 ou superior	Sim
Apache Spark 3 ou mais recente	Sim
ClickHouse	Sim
Cloudera Impala 3.1 ou mais recente	Sim
Cloudera Impala 3.1+ com driver nativo	Sim
Cloudera Impala com driver nativo	Sim
DataVirtuality	Sim
Databricks	Sim
Denodo 7	Sim
Denodo 8	Sim
Dremio	Sim
Dremio 11 ou mais recente	Sim
Exasol	Sim
Fio de fogo	Sim
SQL legado do Google BigQuery	Sim
SQL padrão do Google BigQuery	Sim
PostgreSQL no Google Cloud	Sim
Google Cloud SQL	Sim
Google Spanner	Sim
Verde ameixa	Sim
HyperSQL	Sim
IBM Netezza	Sim
MariaDB	Sim
PostgreSQL do Microsoft Azure	Sim
Banco de dados SQL do Microsoft Azure	Sim
Análise do Microsoft Azure Synapse	Sim
Microsoft SQL Server 2008 ou mais recente	Sim
Microsoft SQL Server 2012 ou mais recente	Sim
Microsoft SQL Server 2016	Sim
Microsoft SQL Server 2017 ou mais recente	Sim
MongoBI	Sim
MySQL	Sim
MySQL 8.0.12 ou superior	Sim
Oracle	Sim
ADWC do Oracle	Sim
PostgreSQL 9.5 ou mais recente	Sim
PostgreSQL anterior à versão 9.5	Sim
PrestoDB	Sim
PrestoSQL	Sim
SAP HANA	Sim
SAP HANA 2 ou posterior	Sim
SingleStore	Sim
SingleStore 7 ou mais recente	Sim
Snowflake	Sim
Teradata	Sim
Trino	Sim
Vetor	Sim
Vertica	Sim

Tabelas derivadas persistentes

Uma tabela derivada persistente (TDP) é uma tabela derivada que é gravada em um esquema de rascunho no seu banco de dados e gerada novamente de acordo com a programação especificada por você com uma estratégia de persistência.

Uma TDP pode ser uma tabela derivada nativa ou uma tabela derivada baseada em SQL.

Requisitos para TDPs

Para usar tabelas derivadas persistentes (TDPs) no seu projeto do Looker, você precisa de:

• Um dialeto de banco de dados compatível com TDPs. Consulte a seção Dialetos de banco de dados compatíveis com TDPs posteriormente nesta página para ver as listas de dialetos compatíveis com tabelas derivadas persistentes baseadas em SQL e tabelas derivadas nativas persistentes.
• Um esquema de rascunho no banco de dados. Pode ser qualquer esquema no banco de dados, mas recomendamos criar um novo esquema que será usado somente para esse fim. O administrador do banco de dados precisa configurar o esquema com permissão de gravação para o usuário do banco de dados do Looker.
• Uma conexão com o Looker configurada com a opção Ativar TDPs ativada. Isso geralmente é feito durante a configuração inicial da conexão do Looker. Consulte instruções sobre o dialeto do banco de dados na página de documentação dialetos do Looker. No entanto, também é possível ativar as TDPs para sua conexão após a configuração inicial.

Dialetos de banco de dados compatíveis com TDPs

Para que o Looker ofereça suporte a tabelas derivadas persistentes (TDPs) no seu projeto, o dialeto do seu banco de dados também precisa ter suporte para elas.

Para oferecer suporte a qualquer tipo de TDPs (com base em LookML ou SQL), o dialeto precisa dar suporte a gravações no banco de dados, entre outros requisitos. Existem algumas configurações de banco de dados somente leitura que não permitem que a persistência funcione (normalmente, bancos de dados de réplica de hot-swap do Postgres). Nesses casos, use tabelas derivadas temporárias.

A tabela a seguir mostra os dialetos compatíveis com as tabelas derivadas baseadas em SQL persistentes na versão mais recente do Looker:

Dialeto	Compatível?
Avalanche	Sim
Amazon Athena	Sim
MySQL do Amazon Aurora	Sim
Amazon Redshift	Sim
Apache Druid	Não
Apache Druid 0.13 ou superior	Não
Apache Druid 0.18 ou superior	Não
Apache Hive 2.3 ou superior	Sim
Apache Hive 3.1.2 ou superior	Sim
Apache Spark 3 ou mais recente	Sim
ClickHouse	Não
Cloudera Impala 3.1 ou mais recente	Sim
Cloudera Impala 3.1+ com driver nativo	Sim
Cloudera Impala com driver nativo	Sim
DataVirtuality	Não
Databricks	Sim
Denodo 7	Não
Denodo 8	Não
Dremio	Não
Dremio 11 ou mais recente	Não
Exasol	Sim
Fio de fogo	Não
SQL legado do Google BigQuery	Sim
SQL padrão do Google BigQuery	Sim
PostgreSQL no Google Cloud	Sim
Google Cloud SQL	Sim
Google Spanner	Não
Verde ameixa	Sim
HyperSQL	Não
IBM Netezza	Sim
MariaDB	Sim
PostgreSQL do Microsoft Azure	Sim
Banco de dados SQL do Microsoft Azure	Sim
Análise do Microsoft Azure Synapse	Sim
Microsoft SQL Server 2008 ou mais recente	Sim
Microsoft SQL Server 2012 ou mais recente	Sim
Microsoft SQL Server 2016	Sim
Microsoft SQL Server 2017 ou mais recente	Sim
MongoBI	Não
MySQL	Sim
MySQL 8.0.12 ou superior	Sim
Oracle	Sim
ADWC do Oracle	Sim
PostgreSQL 9.5 ou mais recente	Sim
PostgreSQL anterior à versão 9.5	Sim
PrestoDB	Sim
PrestoSQL	Sim
SAP HANA	Sim
SAP HANA 2 ou posterior	Sim
SingleStore	Sim
SingleStore 7 ou mais recente	Sim
Snowflake	Sim
Teradata	Sim
Trino	Sim
Vetor	Sim
Vertica	Sim

Para dar suporte a tabelas derivadas nativas persistentes (que têm consultas baseadas em LookML), o dialeto também precisa oferecer suporte a uma função DDL CREATE TABLE. Confira uma lista dos dialetos compatíveis com as tabelas derivadas nativas (baseadas em LookML) persistentes na versão mais recente do Looker:

Dialeto	Compatível?
Avalanche	Sim
Amazon Athena	Sim
MySQL do Amazon Aurora	Sim
Amazon Redshift	Sim
Apache Druid	Não
Apache Druid 0.13 ou superior	Não
Apache Druid 0.18 ou superior	Não
Apache Hive 2.3 ou superior	Sim
Apache Hive 3.1.2 ou superior	Sim
Apache Spark 3 ou mais recente	Sim
ClickHouse	Não
Cloudera Impala 3.1 ou mais recente	Sim
Cloudera Impala 3.1+ com driver nativo	Sim
Cloudera Impala com driver nativo	Sim
DataVirtuality	Não
Databricks	Sim
Denodo 7	Não
Denodo 8	Não
Dremio	Não
Dremio 11 ou mais recente	Não
Exasol	Sim
Fio de fogo	Não
SQL legado do Google BigQuery	Sim
SQL padrão do Google BigQuery	Sim
PostgreSQL no Google Cloud	Sim
Google Cloud SQL	Não
Google Spanner	Não
Verde ameixa	Sim
HyperSQL	Não
IBM Netezza	Sim
MariaDB	Sim
PostgreSQL do Microsoft Azure	Sim
Banco de dados SQL do Microsoft Azure	Sim
Análise do Microsoft Azure Synapse	Sim
Microsoft SQL Server 2008 ou mais recente	Sim
Microsoft SQL Server 2012 ou mais recente	Sim
Microsoft SQL Server 2016	Sim
Microsoft SQL Server 2017 ou mais recente	Sim
MongoBI	Não
MySQL	Sim
MySQL 8.0.12 ou superior	Sim
Oracle	Sim
ADWC do Oracle	Sim
PostgreSQL 9.5 ou mais recente	Sim
PostgreSQL anterior à versão 9.5	Sim
PrestoDB	Sim
PrestoSQL	Sim
SAP HANA	Sim
SAP HANA 2 ou posterior	Sim
SingleStore	Sim
SingleStore 7 ou mais recente	Sim
Snowflake	Sim
Teradata	Sim
Trino	Sim
Vetor	Sim
Vertica	Sim

Observação :as TDPs não são compatíveis com conexões Snowflake que usam OAuth.

Criação de TDPs de forma incremental

Uma TDP incremental é uma tabela derivada persistente (TDP) que o Looker cria anexando dados novos à tabela em vez de recriá-la por completo.

Se o dialeto for compatível com TDPs incrementais e a TDP usar uma estratégia de persistência baseada em gatilho (datagroup_trigger, sql_trigger_value ou interval_trigger), você poderá definir a TDP como uma TDP incremental.

Observação: TDPs incrementais não são compatíveis com TDPs que usam a estratégia de persistência persist_for.

Consulte a página de documentação TDPs incrementais para mais informações.

Dialetos de banco de dados com suporte para TDPs incrementais

Para que o Looker ofereça suporte a TDPs incrementais no seu projeto, o dialeto do banco de dados também precisa oferecer suporte a elas. A tabela a seguir mostra quais dialetos são compatíveis com TDPs incrementais na versão mais recente do Looker:

Dialeto	Compatível?
Avalanche	Não
Amazon Athena	Não
MySQL do Amazon Aurora	Não
Amazon Redshift	Sim
Apache Druid	Não
Apache Druid 0.13 ou superior	Não
Apache Druid 0.18 ou superior	Não
Apache Hive 2.3 ou superior	Não
Apache Hive 3.1.2 ou superior	Não
Apache Spark 3 ou mais recente	Não
ClickHouse	Não
Cloudera Impala 3.1 ou mais recente	Não
Cloudera Impala 3.1+ com driver nativo	Não
Cloudera Impala com driver nativo	Não
DataVirtuality	Não
Databricks	Sim
Denodo 7	Não
Denodo 8	Não
Dremio	Não
Dremio 11 ou mais recente	Não
Exasol	Não
Fio de fogo	Não
SQL legado do Google BigQuery	Não
SQL padrão do Google BigQuery	Sim
PostgreSQL no Google Cloud	Sim
Google Cloud SQL	Não
Google Spanner	Não
Verde ameixa	Sim
HyperSQL	Não
IBM Netezza	Não
MariaDB	Não
PostgreSQL do Microsoft Azure	Sim
Banco de dados SQL do Microsoft Azure	Não
Análise do Microsoft Azure Synapse	Sim
Microsoft SQL Server 2008 ou mais recente	Não
Microsoft SQL Server 2012 ou mais recente	Não
Microsoft SQL Server 2016	Não
Microsoft SQL Server 2017 ou mais recente	Não
MongoBI	Não
MySQL	Sim
MySQL 8.0.12 ou superior	Sim
Oracle	Não
ADWC do Oracle	Não
PostgreSQL 9.5 ou mais recente	Sim
PostgreSQL anterior à versão 9.5	Sim
PrestoDB	Não
PrestoSQL	Não
SAP HANA	Não
SAP HANA 2 ou posterior	Não
SingleStore	Não
SingleStore 7 ou mais recente	Não
Snowflake	Sim
Teradata	Não
Trino	Não
Vetor	Não
Vertica	Sim

Criação de TDPs

Para transformar uma tabela derivada em uma tabela derivada persistente (TDP), defina uma estratégia de persistência para a tabela. Para otimizar a performance, você também deve adicionar uma estratégia de otimização.

Estratégias de persistência

A persistência de uma tabela derivada pode ser gerenciada pelo Looker ou, para dialetos compatíveis com visualizações materializadas, pelo seu banco de dados usando visualizações materializadas.

Para tornar uma tabela derivada persistente, adicione um dos seguintes parâmetros à definição de derived_table:

• Parâmetros de persistência gerenciados pelo Looker:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• Parâmetros de persistência gerenciados pelo banco de dados:
  • materialized_view: yes

Com estratégias de persistência baseadas em gatilho (datagroup_trigger, sql_trigger_value e interval_trigger), o Looker mantém a TDP no banco de dados até que ela seja acionada para recriação. Quando a TDP é acionada, o Looker a recria para substituir a versão anterior. Isso significa que, com TDPs baseadas em gatilhos, os usuários não precisam esperar a TDP ser criada para receber respostas para consultas do recurso Explorar da TDP.

Observação :alguns usuários podem substituir a configuração de persistência de uma TDP. Um usuário com a permissão develop pode usar a opção Recriar tabelas derivadas e executar no menu de uma Análise para substituir a configuração de persistência e recriar todas as TDPs necessárias para a consulta atual em Analisar. Consulte a seção Como recriar manualmente TDPs para uma consulta nesta página para mais detalhes.

datagroup_trigger

Datagroups são o método mais flexível de criação de persistência. Se você definiu um datagroup com sql_trigger ou interval_trigger, pode usar o parâmetro datagroup_trigger para iniciar a recriação das tabelas derivadas persistentes (TDPs).

O Looker mantém a TDP no banco de dados até que o grupo de dados seja acionado. Quando o grupo de dados é acionado, o Looker recria a TDP para substituir a versão anterior. Isso significa que, na maioria dos casos, os usuários não precisarão esperar a TDP ser criada. Se um usuário solicitar dados da TDP enquanto ela está sendo criada e os resultados da consulta não estiverem no cache, o Looker retornará os dados da TDP atual até que a nova TDP seja criada. Consulte Como armazenar consultas em cache para ter uma visão geral dos grupos de dados.

Consulte a seção O regenerador do Looker para mais informações sobre como ele cria TDPs.

sql_trigger_value

O parâmetro sql_trigger_value aciona a regeneração de uma tabela derivada persistente (TDP) com base em uma instrução SQL fornecida por você. Se o resultado da instrução SQL for diferente do valor anterior, a TDP será gerada novamente. Caso contrário, a TDP atual será mantida no banco de dados. Isso significa que, na maioria dos casos, os usuários não precisarão esperar a TDP ser criada. Se um usuário solicitar dados da TDP durante a criação e os resultados da consulta não estiverem no cache, o Looker retornará os dados da TDP atual até que a nova TDP seja criada.

Consulte a seção O regenerador do Looker para mais informações sobre como ele cria TDPs.

interval_trigger

O parâmetro interval_trigger aciona a regeneração de uma tabela derivada persistente (TDP) com base em um intervalo de tempo fornecido por você, como "24 hours" ou "60 minutes". Semelhante ao parâmetro sql_trigger, isso significa que geralmente a TDP será pré-criada quando os usuários a consultam. Se um usuário solicitar dados da TDP durante a criação e os resultados da consulta não estiverem no cache, o Looker retornará os dados da TDP atual até que a nova TDP seja criada.

persist_for

Outra opção é usar o parâmetro persist_for para definir por quanto tempo a tabela derivada precisa ser armazenada antes de ser marcada como expirada, para que ela não seja mais usada em consultas e seja descartada do banco de dados.

Uma tabela derivada persistente (TDP) persist_for é criada quando um usuário executa uma consulta nela pela primeira vez. Em seguida, o Looker mantém a TDP no banco de dados pelo período especificado no parâmetro persist_for da TDP. Se um usuário consultar a TDP no tempo de persist_for, o Looker usará os resultados armazenados em cache, se possível, ou executará a consulta na TDP.

Após o tempo persist_for, o Looker limpa a TDP do seu banco de dados, e ela é recriada na próxima vez que um usuário a consultar, o que significa que a consulta precisará esperar a recriação.

As TDPs que usam persist_for não são recriadas automaticamente pelo regerador do Looker, exceto no caso de uma cascata de dependência de TDPs. Quando uma tabela persist_for faz parte de uma cascata de dependências com TDPs baseadas em gatilho (TDPs que usam a estratégia de persistência datagroup_trigger, interval_trigger ou sql_trigger_value), o regenerador monitora e recria a tabela persist_for para recriar outras tabelas na cascata. Consulte a seção Como o Looker cria tabelas derivadas em cascata nesta página.

materialized_view: yes

Observação: a visualização materializada é um recurso avançado. Dependendo do seu dialeto, uma visualização materializada pode consumir grandes recursos, por isso é importante que você entenda a implementação de visualizações materializadas do seu dialeto. Consulte a documentação do seu dialeto para informações sobre o comportamento dele e a frequência com que ele atualiza dados para visualizações materializadas.

Com as visualizações materializadas, é possível aproveitar a funcionalidade do banco de dados para manter tabelas derivadas no projeto do Looker. Se o dialeto do banco de dados oferece suporte a visualizações materializadas e a conexão com o Looker está configurada com a opção Ativar TDPs ativada, é possível criar uma visualização materializada especificando materialized_view: yes para uma tabela derivada. As visualizações materializadas são compatíveis com tabelas derivadas nativas e tabelas derivadas baseadas em SQL.

Semelhante a uma tabela derivada persistente (TDP), uma visualização materializada é um resultado de consulta armazenado como uma tabela no esquema inicial do seu banco de dados. A principal diferença entre uma TDP e uma visualização materializada é a maneira como as tabelas são atualizadas:

• Para TDPs, a estratégia de persistência é definida no Looker, e a persistência é gerenciada por ele.
• Para visualizações materializadas, o banco de dados é responsável por manter e atualizar os dados da tabela.

Por esse motivo, a funcionalidade de visualização materializada requer conhecimento avançado de seu dialeto e seus recursos. Na maioria dos casos, o banco de dados atualizará a visualização materializada sempre que detectar novos dados nas tabelas consultadas pela visualização materializada. As visualizações materializadas são ideais para cenários que exigem dados em tempo real.

Consulte a página de documentação do parâmetro materialized_view para informações sobre suporte a dialetos, requisitos e considerações importantes.

Estratégias de otimização

Como as tabelas derivadas persistentes (TDPs) são armazenadas em seu banco de dados, você deve otimizar suas TDPs usando as seguintes estratégias, conforme compatível com seu dialeto:

• cluster_keys
• distribution
• distribution_style
• indexes
• partition_keys
• sortkeys

Por exemplo, para adicionar persistência ao exemplo de tabela derivada, você pode configurá-lo para recompilação quando o grupo de dados orders_datagroup for acionado e adicionar índices em customer_id e first_order, desta forma:

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      ...
    }
    datagroup_trigger: orders_datagroup
    indexes: ["customer_id", "first_order"]
  }
}

Se você não adicionar um índice (ou um equivalente para seu dialeto), o Looker vai avisar que é preciso fazer isso para melhorar o desempenho da consulta.

Casos de uso para TDPs

As tabelas derivadas persistentes (TDPs) são úteis porque podem melhorar o desempenho de uma consulta ao manter os resultados da consulta em uma tabela.

Como prática recomendada geral, os desenvolvedores devem tentar modelar dados sem usar TDPs até que seja absolutamente necessário.

Em alguns casos, os dados podem ser otimizados por outros meios. Por exemplo, adicionar um índice ou alterar o tipo de dados de uma coluna pode resolver um problema sem a necessidade de criar uma TDP. Analise os planos de execução de consultas lentas com a ferramenta Explain from SQL Runner.

Além de reduzir o tempo de consulta e a carga do banco de dados em consultas executadas com frequência, existem vários outros casos de uso para TDPs, incluindo:

• Como testar otimizações
• Pré-mesclar ou agregar dados

Também é possível usar uma TDP para definir uma chave primária nos casos em que não há uma maneira razoável de identificar uma linha única em uma tabela como uma chave primária.

Como usar TDPs para testar otimizações

É possível usar as TDPs para testar diferentes indexação, distribuições e outras opções de otimização sem precisar de muito suporte de seus desenvolvedores DBA ou ETL.

Considere um caso em que você tem uma tabela, mas quer testar índices diferentes. Seu LookML inicial para a visualização pode ser semelhante ao seguinte:

view: customer {
  sql_table_name: warehouse.customer ;;
}

Para testar estratégias de otimização, use o parâmetro indexes para adicionar índices ao LookML desta forma:

view: customer {
  # sql_table_name: warehouse.customer
  derived_table: {
    sql: SELECT * FROM warehouse.customer ;;
    persist_for: "8 hours"
    indexes: [customer_id, customer_name, salesperson_id]
  }
}

Consulte a visualização uma vez para gerar a TDP. Em seguida, execute suas consultas de teste e compare os resultados. Se os resultados forem favoráveis, peça à equipe de DBA ou ETL para adicionar os índices à tabela original.

Lembre-se de alterar o código de visualização de volta para remover a TDP.

Como usar TDPs para pré-mesclar ou agregar dados

Pode ser útil pré-mesclar ou pré-agregar dados para ajustar a otimização de consultas para grandes volumes ou vários tipos de dados.

Por exemplo, suponha que você queira gerar relatórios sobre clientes por coorte com base em quando eles fizeram o primeiro pedido. Essa consulta pode ser cara para ser executada várias vezes sempre que os dados forem necessários em tempo real. No entanto, é possível calcular a consulta apenas uma vez e reutilizar os resultados com uma TDP:

view: customer_order_facts {
  derived_table: {
    sql: SELECT
    c.customer_id,
    MIN(o.order_date) OVER (PARTITION BY c.customer_id) AS first_order_date,
    MAX(o.order_date) OVER (PARTITION BY c.customer_id) AS most_recent_order_date,
    COUNT(o.order_id) OVER (PARTITION BY c.customer_id) AS lifetime_orders,
    SUM(o.order_value) OVER (PARTITION BY c.customer_id) AS lifetime_value,
    RANK() OVER (PARTITION BY c.customer_id ORDER BY o.order_date ASC) AS order_sequence,
    o.order_id
    FROM warehouse.customer c LEFT JOIN warehouse.order o ON c.customer_id = o.customer_id
    ;;
    sql_trigger_value: SELECT CURRENT_DATE ;;
    indexes: [customer_id, order_id, order_sequence, first_order_date]
  }
}

Tabelas derivadas em cascata

É possível fazer referência a uma tabela derivada na definição de outra, criando uma cadeia de tabelas derivadas em cascata ou tabelas derivadas persistentes (TDPs) em cascata (TDPs) persistentes, conforme o caso. Um exemplo de tabelas derivadas em cascata seria uma tabela TABLE_D, que depende de outra tabela, TABLE_C, enquanto TABLE_C depende de TABLE_B e TABLE_B depende de TABLE_A.

Observação :antes de configurar tabelas derivadas em cascata, é importante saber como elas são recriadas automaticamente pelo regenerador do Looker e como podem ser recriadas manualmente pelos usuários. Há também outras considerações importantes para implementar tabelas mantidas. Todos esses tópicos serão abordados mais adiante nesta página.

Sintaxe para fazer referência a uma tabela derivada

Para fazer referência a uma tabela derivada em outra tabela derivada, use esta sintaxe:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

Nesse formato, SQL_TABLE_NAME é uma string literal. Por exemplo, é possível fazer referência à tabela derivada clean_events com esta sintaxe:

`${clean_events.SQL_TABLE_NAME}`

É possível usar essa mesma sintaxe para se referir a uma visualização do LookML. Novamente, neste caso, SQL_TABLE_NAME é uma string literal.

Observação :a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME} não tem suporte no parâmetro sql_trigger de um datagroup. Portanto, não é possível usar uma tabela derivada para acionar um grupo de dados. Mas é possível usar a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME} no parâmetro sql_trigger_value para acionar as recriações de TDP.

No próximo exemplo, a TDP clean_events é criada com base na tabela events do banco de dados. A TDP clean_events exclui linhas indesejadas da tabela do banco de dados events. Em seguida, uma segunda TDP é exibida. A TDP event_summary é um resumo da TDP clean_events. A tabela event_summary é gerada novamente sempre que novas linhas são adicionadas a clean_events.

A TDP event_summary e a TDP clean_events são TDPs em cascata, em que event_summary depende de clean_events, já que event_summary é definido usando a TDP clean_events. Esse exemplo específico poderia ser feito de forma mais eficiente em uma única TDP, mas é útil para demonstrar referências de tabelas derivadas.

view: clean_events {
  derived_table: {
    sql:
      SELECT *
      FROM events
      WHERE type NOT IN ('test', 'staff') ;;
    datagroup_trigger: events_datagroup
  }
}

view: events_summary {
  derived_table: {
    sql:
      SELECT
        type,
        date,
        COUNT(*) AS num_events
      FROM
        ${clean_events.SQL_TABLE_NAME} AS clean_events
      GROUP BY
        type,
        date ;;
    datagroup_trigger: events_datagroup
  }
}

Embora nem sempre seja obrigatório, ao se referir a uma tabela derivada dessa maneira, muitas vezes é útil criar um alias para a tabela usando este formato:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

O exemplo anterior faz isso:

${clean_events.SQL_TABLE_NAME} AS clean_events

É útil usar um alias porque, nos bastidores, as TDPs são nomeadas com códigos longos em seu banco de dados. Em alguns casos, especialmente com cláusulas ON, é fácil esquecer que você precisa usar a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME} para recuperar esse nome longo. Um alias pode ajudar a evitar esse tipo de erro.

Como o Looker cria tabelas derivadas em cascata

No caso de tabelas derivadas temporárias em cascata, se os resultados da consulta de um usuário não estiverem no cache, o Looker vai criar todas as tabelas derivadas necessárias para a consulta. Se você tiver um TABLE_D com uma definição que contém uma referência a TABLE_C, TABLE_D depende de TABLE_C. Isso significa que, se você consultar TABLE_D e a consulta não estiver no cache do Looker, o Looker vai recriar o TABLE_D. No entanto, primeiro ele precisa recriar TABLE_C.

Agora, vamos considerar um cenário de tabelas derivadas temporárias em cascata, em que TABLE_D depende de TABLE_C, que depende de TABLE_B, que depende de TABLE_A. Se o Looker não tiver resultados válidos para uma consulta em TABLE_C no cache, ele vai criar todas as tabelas necessárias para a consulta. O Looker vai criar TABLE_A, depois TABLE_B e TABLE_C:

Nesse cenário, a geração de TABLE_A precisa ser concluída antes que o Looker comece a gerar TABLE_B e assim por diante, até que a TABLE_C seja concluída e o Looker possa fornecer os resultados da consulta. Como TABLE_D não é necessário para responder a essa consulta, o Looker não vai recriar TABLE_D no momento.

Consulte a página de documentação do parâmetro datagroup para ver um exemplo de cenário de TDPs em cascata que usam o mesmo grupo de dados.

A mesma lógica básica se aplica às TDPs: o Looker cria qualquer tabela necessária para responder a uma consulta em toda a cadeia de dependências. Mas com TDPs, geralmente é o caso de que as tabelas já existem e não precisam ser recriadas. Com consultas padrão do usuário em TDPs em cascata, o Looker as recria na cascata somente se não houver uma versão válida das TDPs no banco de dados. Se você quiser forçar a recriação de todas as TDPs em cascata, é possível recriar manualmente as tabelas de uma consulta usando uma Análise.

Um ponto lógico importante a ser entendido é que, no caso de uma TDP em cascata, uma TDP dependente está essencialmente consultando a TDP de que depende. Isso é importante principalmente para TDPs que usam a estratégia persist_for. Normalmente, as TDPs persist_for são criadas quando um usuário as consulta, permanecem no banco de dados até que o intervalo de persist_for termine e não são recriadas até serem consultadas pela próxima vez. No entanto, se uma TDP persist_for fizer parte de uma cascata com TDPs baseadas em gatilho (TDPs que usam a estratégia de persistência datagroup_trigger, interval_trigger ou sql_trigger_value), a TDP persist_for é essencialmente consultada sempre que as TDPs dependentes são recriadas. Portanto, nesse caso, a TDP persist_for será recriada de acordo com a programação das TDPs dependentes. Isso significa que as TDPs do persist_for podem ser afetadas pela estratégia de persistência dos dependentes.

Como recriar manualmente tabelas persistentes para uma consulta

Os usuários podem selecionar a opção Recriar tabelas derivadas e executar no menu de uma Análise para substituir as configurações de persistência e recriar todas as tabelas derivadas persistentes (TDPs) e tabelas agregadas necessárias para a consulta atual no Explore:

Essa opção só fica visível para usuários com a permissão develop e somente após o carregamento da consulta "Explore".

A opção Recriar tabelas derivadas e executar recria todas as tabelas persistentes (todas as TDPs e tabelas de agregação) necessárias para responder à consulta, independentemente da estratégia de persistência. Isso inclui todas as tabelas de agregação e TDPs na consulta atual e também todas as tabelas de agregação e TDPs que são referenciadas pelas tabelas de agregação e TDPs na consulta atual.

No caso de TDPs incrementais, a opção Recriar tabelas derivadas e executar aciona a criação de um novo incremento. Com TDPs incrementais, um incremento inclui o período especificado no parâmetro increment_key e também o número de períodos anteriores especificados no parâmetro increment_offset, se houver. Consulte a página de documentação TDPs incrementais para ver alguns exemplos de cenários que mostram como as TDPs incrementais são criadas, dependendo da configuração.

No caso de TDPs em cascata, isso significa recriar todas as tabelas derivadas na cascata, começando pelo topo. Este é o mesmo comportamento de quando você consulta uma tabela em uma cascata de tabelas derivadas temporárias:

Observe o seguinte sobre a recriação manual de tabelas derivadas:

• Para o usuário que inicia a operação Recriar tabelas derivadas e executar, a consulta aguarda a recriação das tabelas antes de carregar os resultados. As consultas de outros usuários ainda usarão as tabelas existentes. Depois que as tabelas persistentes forem recriadas, todos os usuários usarão as tabelas recriadas. Embora esse processo tenha sido projetado para evitar a interrupção das consultas de outros usuários durante a recriação das tabelas, esses usuários ainda podem ser afetados pela carga adicional no seu banco de dados. Se você estiver em uma situação em que acionar uma recriação durante o horário comercial pode colocar uma pressão inaceitável no banco de dados, pode ser necessário informar aos usuários que eles nunca devem recriar determinadas TDPs ou tabelas de agregação durante esse período.

• Se um usuário estiver no Modo de Desenvolvimento e a Análise for baseada em uma tabela de desenvolvimento, a operação Recriar tabelas derivadas e executar recriará a tabela de desenvolvimento, não a tabela de produção, para a Análise. No entanto, se a Análise no Modo de Desenvolvimento estiver usando a versão de produção de uma tabela derivada, a tabela de produção será recriada. Consulte Tabelas mantidas no Modo de Desenvolvimento para mais informações sobre tabelas de desenvolvimento e de produção.

• Para instâncias hospedadas pelo Looker, se a recriação da tabela derivada levar mais de uma hora, ela não vai ser recriada corretamente e a sessão do navegador vai expirar. Consulte a seção Tempos limite de consulta e enfileiramento na página de documentação Configurações do administrador: consultas para mais informações sobre tempos limite que podem afetar os processos do Looker.

Tabelas persistentes no Modo de Desenvolvimento

O Looker tem alguns comportamentos especiais para gerenciar tabelas persistentes no modo de desenvolvimento.

Observação :esses comportamentos se aplicam a qualquer tipo de tabela persistente, que inclui tabelas de agregação e tabelas derivadas persistentes (TDPs).

Se você consultar uma tabela persistida no Modo de Desenvolvimento sem alterar a definição, o Looker consultará a versão de produção dessa tabela. Se você fizer uma alteração na definição da tabela que afete os dados na tabela ou a forma como a tabela é consultada, uma nova versão de desenvolvimento da tabela será criada na próxima vez que você consultar a tabela no Modo de Desenvolvimento. Com essa tabela de desenvolvimento, é possível testar alterações sem incomodar os usuários finais.

O que leva o Looker a criar uma tabela de desenvolvimento

Quando possível, o Looker usa a tabela de produção atual para responder a consultas, esteja você no Modo de Desenvolvimento ou não. Mas há alguns casos em que o Looker não pode usar a tabela de produção para consultas no Modo de Desenvolvimento:

• Se a tabela persistente tem um parâmetro que restringe o conjunto de dados para trabalhar mais rapidamente no Modo de Desenvolvimento
• Se você fez alterações na definição da sua tabela persistente que afetam os dados dela

O Looker vai criar uma tabela de desenvolvimento se você estiver no Modo de Desenvolvimento e consultar uma tabela derivada baseada em SQL que é definida usando uma cláusula WHERE condicional com instruções if prod e if dev.

Observação: esse não é o caso das tabelas nativas derivadas com o parâmetro dev_filters. Para tabelas derivadas nativas com dev_filters, o Looker tem a lógica de usar a tabela de produção para responder a consultas no Modo de Desenvolvimento, a menos que você mude a definição da tabela e a consulte no Modo de Desenvolvimento.

No caso de tabelas mantidas sem um parâmetro para restringir o conjunto de dados no Modo de Desenvolvimento, o Looker usa a versão de produção da tabela para responder a consultas no Modo de Desenvolvimento, a menos que você mude a definição da tabela e depois consulte a tabela no Modo de Desenvolvimento. Isso vale para qualquer mudança na tabela que afete os dados na tabela ou a forma como a tabela é consultada.

Aqui estão alguns exemplos dos tipos de alterações que solicitarão que o Looker crie uma versão de desenvolvimento de uma tabela persistente (o Looker criará a tabela somente se você a consultar depois de fazer essas alterações):

• Alterar a consulta em que a tabela persistente é baseada, como modificar os parâmetros explore_source, sql, query, sql_create ou create_process na própria tabela persistente ou em qualquer tabela obrigatória (no caso de tabelas derivadas em cascata)
• Mudar a estratégia de persistência da tabela, como modificar o parâmetro datagroup_trigger, sql_trigger_value, interval_trigger ou persist_for
• Alterar o nome do view de uma tabela derivada
• Mudar a increment_key ou a increment_offset de uma TDP incremental
• Alterar o connection usado pelo modelo associado

O Looker não vai criar uma tabela de desenvolvimento para mudanças que não modifiquem os dados da tabela nem afetem a forma como o Looker consulta a tabela. O parâmetro publish_as_db_view é um bom exemplo: no Modo de Desenvolvimento, se você mudar apenas a configuração publish_as_db_view de uma tabela derivada, o Looker não precisará recriar a tabela derivada, portanto, não vai criar uma tabela de desenvolvimento.

Por quanto tempo o Looker mantém as tabelas de desenvolvimento

Independentemente da estratégia de persistência real da tabela, o Looker trata tabelas de desenvolvimento persistente como se elas tivessem uma estratégia de persistência de persist_for: "24 hours". O Looker faz isso para garantir que as tabelas de desenvolvimento não sejam mantidas por mais de um dia, já que um desenvolvedor do Looker pode consultar muitas iterações de uma tabela durante o desenvolvimento e cada vez que uma nova tabela de desenvolvimento é criada. Para evitar que as tabelas de desenvolvimento sobrecarreguem o banco de dados, o Looker aplica a estratégia persist_for: "24 hours" para garantir que as tabelas sejam limpas do banco de dados com frequência.

Caso contrário, o Looker cria tabelas derivadas persistentes (TDPs) e tabelas de agregação no Modo de Desenvolvimento da mesma forma que cria tabelas persistentes no Modo de produção.

Se uma tabela de desenvolvimento for mantida no banco de dados quando você implantar alterações em uma TDP ou em uma tabela de agregação, o Looker geralmente poderá usar a tabela de desenvolvimento como a tabela de produção para que os usuários não precisem esperar a criação da tabela quando a consultarem.

Quando você implanta as alterações, a tabela ainda pode precisar ser recriada para ser consultada na produção, dependendo da situação:

• Caso já tenham se passado mais de 24 horas desde que você consultou a tabela no Modo de Desenvolvimento, a versão de desenvolvimento da tabela será marcada como expirada e não será usada para consultas. É possível verificar se há TDPs não criadas usando o ambiente de desenvolvimento integrado do Looker ou a guia Desenvolvimento da página Tabelas derivadas persistentes. Se você tem TDPs não criadas, pode consultá-las no Modo de Desenvolvimento antes de fazer as alterações, para que a tabela de desenvolvimento esteja disponível para ser usada na produção.
• Se uma tabela persistente tiver o parâmetro dev_filters (para tabelas derivadas nativas) ou a cláusula WHERE condicional que usa as instruções if prod e if dev (para tabelas derivadas baseadas em SQL), a tabela de desenvolvimento não poderá ser usada como a versão de produção, porque a versão de desenvolvimento tem um conjunto de dados abreviado. Nesse caso, depois de concluir o desenvolvimento da tabela e antes de implantar as mudanças, comente o parâmetro dev_filters ou a cláusula condicional WHERE e consulte a tabela no Modo de Desenvolvimento. Depois disso, o Looker vai criar uma versão completa da tabela que poderá ser usada na produção quando você implantar as mudanças.

Caso contrário, se você implantar as mudanças quando não houver uma tabela de desenvolvimento válida que possa ser usada como a tabela de produção, o Looker a recriará na próxima vez que a tabela for consultada no Modo de Produção (para tabelas persistentes que usam a estratégia persist_for) ou na próxima vez que o regerador for executado (para tabelas persistentes que usam datagroup_trigger, interval_trigger ou sql_trigger_value).

Como verificar TDPs não criadas no Modo de Desenvolvimento

Se uma tabela de desenvolvimento for mantida no banco de dados quando você implanta alterações em uma tabela derivada persistente (TDP) ou em uma tabela de agregação, o Looker geralmente pode usar a tabela de desenvolvimento como a tabela de produção para que os usuários não precisem esperar a criação da tabela durante a consulta. Para mais detalhes, consulte as seções Por quanto tempo o Looker persiste nas tabelas de desenvolvimento e O que leva o Looker a criar uma tabela de desenvolvimento nesta página.

Portanto, é ideal que todas as TDPs sejam criadas durante a implantação na produção para que as tabelas possam ser usadas imediatamente como as versões de produção.

É possível verificar se há TDPs não criadas no seu projeto no painel Integridade do projeto. Clique no ícone Project Health no ambiente de desenvolvimento integrado do Looker para abrir o painel Project Health. Em seguida, clique no botão Validate TDP Status.

Se houver TDPs não criadas, o painel Integridade do projeto as listará:

Se você tiver permissão do see_pdts, clique no botão Acessar o gerenciamento de TDPs. O Looker vai abrir a guia Desenvolvimento da página Tabelas derivadas persistentes e filtrar os resultados para seu projeto específico do LookML. A partir daí, você pode ver quais TDPs de desenvolvimento são criadas ou não e acessar outras informações de solução de problemas. Consulte a página de documentação Configurações do administrador: tabelas derivadas persistentes para mais informações.

Depois de identificar uma TDP não criada no projeto, é possível criar uma versão de desenvolvimento para ela. Basta abrir um Explore que consulta a tabela e usar a opção Recriar tabelas derivadas e executar no menu "Explorar". Consulte a seção Como recriar manualmente tabelas persistentes para uma consulta nesta página.

Observação :se uma tabela persistente for uma tabela derivada baseada em SQL definida usando uma cláusula WHERE condicional com instruções if prod e if dev, não será possível usar a versão de desenvolvimento da tabela para produção, já que a versão de desenvolvimento da tabela tem um conjunto de dados abreviado. Consulte a seção Por quanto tempo o Looker persiste nas tabelas de desenvolvimento nesta página para mais informações. No caso de tabelas derivadas nativas com o parâmetro dev_filters, o Looker usa a tabela de produção para responder a consultas no Modo de Desenvolvimento, a menos que você mude a definição da tabela e faça a consulta no Modo de Desenvolvimento. Consulte a seção O que solicita que o Looker crie uma tabela de desenvolvimento nesta página de documentação.

Compartilhamento e limpeza de tabelas

Em qualquer instância do Looker, o Looker vai compartilhar tabelas mantidas entre os usuários se elas tiverem a mesma definição e a mesma configuração de método de persistência. Além disso, se a definição de uma tabela deixar de existir, o Looker a marcará como expirada.

Isso traz vários benefícios:

• Se você não fez nenhuma alteração em uma tabela no Modo de Desenvolvimento, suas consultas usarão as tabelas de produção existentes. Esse é o caso, a menos que a tabela seja uma tabela derivada baseada em SQL e definida usando uma cláusula WHERE condicional com instruções if prod e if dev. Se a tabela for definida com uma cláusula condicional WHERE, o Looker criará uma tabela de desenvolvimento se você a consultar no Modo de Desenvolvimento. Para tabelas derivadas nativas com o parâmetro dev_filters, o Looker tem a lógica de usar a tabela de produção para responder a consultas no Modo de Desenvolvimento, a menos que você mude a definição da tabela e a consulte no Modo de Desenvolvimento.
• Se dois desenvolvedores fizerem a mesma alteração em uma tabela no Modo de Desenvolvimento, eles compartilharão a mesma tabela de desenvolvimento.
• Depois que você enviar as alterações do Modo de Desenvolvimento para o Modo de Produção, a definição de produção antiga não existirá mais. Por isso, a tabela de produção antiga será marcada como expirada e será descartada.
• Se você decidir descartar suas mudanças no Modo de Desenvolvimento, essa definição de tabela não existirá mais. Por isso, as tabelas de desenvolvimento desnecessárias serão marcadas como expiradas e serão descartadas.

Trabalho mais rápido no Modo de Desenvolvimento

Há situações em que a tabela derivada persistente (TDP) que você está criando leva muito tempo para ser gerada, o que pode ser demorado se você estiver testando muitas mudanças no Modo de Desenvolvimento. Nesses casos, é possível solicitar que o Looker crie versões menores de uma tabela derivada quando você estiver no Modo de Desenvolvimento.

Para tabelas derivadas nativas, é possível usar o subparâmetro dev_filters de explore_source para especificar filtros que são aplicados apenas a versões de desenvolvimento da tabela derivada:

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

Este exemplo inclui um parâmetro dev_filters, que filtra os dados para os últimos 90 dias, e um parâmetro filters, que filtra as informações para os últimos 2 anos e para o Aeroporto de Yucca Valley.

O parâmetro dev_filters age em conjunto com o parâmetro filters para que todos os filtros sejam aplicados à versão de desenvolvimento da tabela. Se dev_filters e filters especificarem filtros para a mesma coluna, dev_filters terá precedência para a versão de desenvolvimento da tabela. Neste exemplo, a versão de desenvolvimento da tabela vai filtrar os dados dos últimos 90 dias para o Aeroporto de Yucca Valley.

Para tabelas derivadas baseadas em SQL, o Looker aceita uma cláusula WHERE condicional com diferentes opções para versões de produção (if prod) e desenvolvimento (if dev) da tabela:

view: my_view {
  derived_table: {
    sql:
      SELECT
        columns
      FROM
        my_table
      WHERE
        -- if prod -- date > '2000-01-01'
        -- if dev -- date > '2020-01-01'
      ;;
  }
}

Neste exemplo, a consulta incluirá todos os dados de 2000 em diante no Modo de Produção, mas apenas os dados de 2020 em diante no Modo de Desenvolvimento. O uso estratégico desse recurso para limitar seu conjunto de resultados e aumentar a velocidade da consulta facilita a validação das mudanças no Modo de Desenvolvimento.

Observação :se uma tabela persistente tiver o parâmetro dev_filters ou a cláusula WHERE condicional, a tabela de desenvolvimento não poderá ser usada como a versão de produção, porque a versão de desenvolvimento tem um conjunto de dados abreviado. Nesse caso, depois de concluir o desenvolvimento da tabela e antes de implantar as mudanças, comente o parâmetro dev_filters ou a cláusula condicional WHERE e consulte a tabela no Modo de Desenvolvimento. Depois disso, o Looker vai criar uma versão completa da tabela que poderá ser usada na produção quando você implantar as mudanças. Consulte a seção Por quanto tempo o Looker persiste tabelas de desenvolvimento nesta página para mais detalhes sobre como usar tabelas de desenvolvimento na produção.

Como o Looker cria TDPs

Depois que uma tabela derivada persistente (TDP) for definida e for executada pela primeira vez ou acionada pelo regenerador para ser recriada de acordo com a estratégia de persistência, o Looker vai seguir estas etapas:

1. Use o SQL da tabela derivada para criar uma instrução CREATE TABLE AS SELECT (ou CTAS) e executá-la. Por exemplo, para recriar uma TDP chamada customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Emita as instruções para criar os índices quando a tabela for criada.
3. Renomeie a tabela de LC$.. ("Looker Create") para LR$.. ("Looker Read") para indicar que ela está pronta para uso
4. Descarte qualquer versão antiga da tabela que não esteja mais em uso

Há algumas implicações importantes:

• O SQL que forma a tabela derivada precisa ser válido dentro de uma instrução CTAS.
• Os aliases de coluna no conjunto de resultados da instrução SELECT precisam ser nomes de coluna válidos.
• Os nomes usados ao especificar a distribuição, as chaves de classificação e os índices precisam ser os nomes das colunas listados na definição SQL da tabela derivada, não os nomes de campos definidos no LookML.

O regenerador do Looker

O regenerador do Looker verifica o status e inicia recriações em busca de tabelas mantidas pelo acionador. Uma tabela persistente em acionador é uma tabela derivada persistente (TDP) ou uma tabela agregada que usa um acionador como estratégia de persistência:

• Para tabelas que usam sql_trigger_value, o gatilho é uma consulta especificada no parâmetro sql_trigger_value da tabela. O regenerador do Looker aciona a recriação da tabela quando o resultado da verificação mais recente da consulta do acionador é diferente do resultado da verificação anterior. Por exemplo, se a tabela derivada for mantida com a consulta SQL SELECT CURDATE(), o regenerador do Looker vai recriar a tabela na próxima vez que verificar o acionador após a mudança de data.
• Para tabelas que usam interval_trigger, o gatilho é uma duração de tempo especificada no parâmetro interval_trigger da tabela. O regerador do Looker aciona a recriação da tabela quando o tempo especificado passa.
• Para tabelas que usam datagroup_trigger, o acionador pode ser uma consulta especificada no parâmetro sql_trigger do grupo de dados associado ou um tempo de duração especificado no parâmetro interval_trigger do grupo de dados.

O regenerador do Looker também inicia recriações para tabelas persistentes que usam o parâmetro persist_for, mas somente quando a tabela persist_for é uma cascata de dependência de uma tabela com acionador. Nesse caso, o regenerador do Looker iniciará a recriação de uma tabela persist_for, já que ela é necessária para recriar as outras tabelas na cascata. Caso contrário, o regenerador não vai monitorar tabelas persistidas que usam a estratégia persist_for.

O ciclo do regenerador do Looker começa em um intervalo regular definido pelo administrador do Looker na configuração Programação de manutenção de TDP e grupo de dados da conexão do banco de dados. O padrão é um intervalo de cinco minutos. No entanto, o regenerador do Looker não inicia um novo ciclo até concluir todas as verificações e recriações de TDP do último ciclo. Isso significa que, se você tiver builds de TDP de longa duração, o ciclo de regeneração do Looker talvez não seja executado com a frequência definida na configuração Programação de manutenção de TDP e grupo de dados. Outros fatores podem afetar o tempo necessário para recriar suas tabelas, conforme descrito na seção Considerações importantes para implementar tabelas mantidas nesta página.

Nos casos em que uma TDP não é criada, o regenerador pode tentar recriar a tabela no próximo ciclo:

• Se a configuração Repetir builds de TDP com falha estiver ativada na conexão do banco de dados, o regenerador do Looker vai tentar recriar a tabela durante o próximo ciclo, mesmo que a condição de gatilho da tabela não seja atendida.
• Se a configuração Repetir builds de TDP com falha estiver desativada, o regenerador do Looker não vai tentar recriar a tabela até que a condição de acionamento da TDP seja atendida.

Se um usuário solicitar dados da tabela persistida enquanto ela estiver sendo criada e os resultados da consulta não estiverem no cache, o Looker verificará se a tabela atual ainda é válida. A tabela anterior pode não ser válida se não for compatível com a nova versão da tabela, o que pode acontecer se a nova tabela tiver uma definição diferente, se usar uma conexão de banco de dados diferente ou se a nova tabela tiver sido criada com uma versão diferente do Looker. Se a tabela atual ainda for válida, o Looker retornará os dados dela até que a nova seja criada. Caso contrário, se a tabela atual não for válida, o Looker vai fornecer os resultados da consulta quando a nova tabela for recriada.

Considerações importantes para implementar tabelas mantidas

Considerando a utilidade das tabelas persistidas (TDPs e tabelas de agregação), é fácil acumular muitas delas na sua instância do Looker. É possível criar um cenário em que o regerador do Looker precisa criar muitas tabelas ao mesmo tempo. Especialmente com tabelas em cascata ou tabelas de longa duração, é possível criar um cenário em que as tabelas têm um longo atraso antes da recriação ou em que os usuários têm um atraso no recebimento dos resultados de consulta de uma tabela enquanto o banco de dados está trabalhando para gerá-la.

O regenerador do Looker verifica os acionadores de TDP para ver se ele precisa recriar as tabelas mantidas pelo acionador. O ciclo do regenerador é definido em um intervalo regular definido pelo administrador do Looker na configuração Programação de manutenção de TDP e grupo de dados da conexão do banco de dados. O padrão é um intervalo de cinco minutos.

Diversos fatores podem afetar o tempo necessário para recriar as tabelas:

• Seu administrador do Looker pode ter alterado o intervalo das verificações do acionador do regenerador usando a configuração Programação de manutenção de grupo de dados e TDP na conexão do banco de dados.
• O regenerador do Looker não inicia um novo ciclo até concluir todas as verificações e recriações de TDP do último ciclo. Portanto, se você tiver builds de TDP de longa duração, o ciclo de regeneração do Looker talvez não seja tão frequente quanto a configuração Programação de manutenção de TDP e grupo de dados.
• Por padrão, o regenerador pode iniciar a recriação de uma TDP ou tabela agregada por vez em uma conexão. Um administrador do Looker pode ajustar o número permitido de recriações simultâneas do regenerador usando o campo Número máximo de conexões do builder de TDP nas configurações de uma conexão.
• Todas as TDPs e tabelas de agregação acionadas pelo mesmo datagroup serão recriadas durante o mesmo processo de geração. Isso pode ser uma carga pesada se você tiver muitas tabelas usando o grupo de dados, seja diretamente ou como resultado de dependências em cascata.

Além das considerações anteriores, há algumas situações em que é necessário evitar a adição de persistência a uma tabela derivada:

• Quando as tabelas derivadas são extended — cada extensão de uma TDP cria uma nova cópia da tabela no seu banco de dados.
• Quando tabelas derivadas usam filtros com modelo ou parâmetros líquidos: a persistência não é compatível com tabelas derivadas que usam filtros com modelo ou parâmetros líquidos.
• Quando tabelas derivadas nativas são criadas com base em Explores que usam atributos de usuário com access_filters ou sql_always_where, cópias da tabela são criadas no banco de dados para cada possível valor de atributo do usuário especificado.
• Quando os dados mudam com frequência e o dialeto do seu banco de dados não oferece suporte a TDPs incrementais.
• Quando o custo e o tempo envolvidos na criação de TDPs são muito altos.

Dependendo do número e da complexidade das tabelas mantidas na conexão do Looker, a fila pode conter muitas tabelas desse tipo que precisam ser verificadas e recriadas a cada ciclo. Por isso, é importante ter esses fatores em mente ao implementar tabelas derivadas na instância do Looker.

Como gerenciar TDPs em grande escala com a API

Monitorar e gerenciar tabelas derivadas persistentes (TDPs) que são atualizadas em programações variadas se torna cada vez mais complexo à medida que você cria mais TDPs na instância. Use a integração do Apache Airflow do Looker para gerenciar suas programações de TDP com outros processos de ETL e ELT.

Monitoramento e solução de problemas de TDPs

Se você usar tabelas derivadas persistentes (TDPs), e especialmente TDPs em cascata, é útil ver o status delas. É possível usar a página de administrador das tabelas derivadas persistentes do Looker para ver o status das suas TDPs. Consulte a página de documentação Configurações do administrador: tabelas derivadas persistentes para mais informações.

Ao tentar resolver problemas de TDPs:

• Preste atenção especial à distinção entre tabelas de desenvolvimento e tabelas de produção ao investigar o log de eventos de TDP.
• Verifique se nenhuma mudança foi feita no esquema em que o Looker armazena tabelas derivadas persistentes. Se tiver sido feita mudanças, talvez seja necessário atualizar as configurações de Conexão na seção Administrador do Looker e, em seguida, reiniciar o Looker para restaurar a funcionalidade normal da TDP.
• Determine se há problemas com todas as TDPs ou apenas uma. Se houver um problema com um deles, é provável que seja causado por um erro do LookML ou do SQL.
• Determine se os problemas com a TDP correspondem aos horários em que ela está programada para ser recriada.
• Verifique se todas as consultas sql_trigger_value foram avaliadas e se retornam apenas uma linha e uma coluna. Para TDPs baseadas em SQL, você pode fazer isso executando-as no SQL Runner. Aplicar um LIMIT protege contra o excesso de consultas. Para saber mais sobre como usar o SQL Runner para depurar tabelas derivadas, consulte a postagem na Comunidade Como usar o sql runner para testar tabelas derivadas .
• Para TDPs baseadas em SQL, use o SQL Runner para verificar se o SQL da TDP é executado sem erros. Aplique um LIMIT no SQL Runner para manter os tempos de consulta razoáveis.
• Para tabelas derivadas baseadas em SQL, evite usar expressões de tabela comuns (CTEs, na sigla em inglês). O uso de CTEs com DTs cria instruções WITH aninhadas que podem fazer com que as TDPs falhem sem aviso. Em vez disso, use o SQL para que a CTE crie uma DT secundária e faça referência a ela do primeiro DT usando a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME}.
• Verifique se existem tabelas das quais a TDP do problema depende, sejam elas normais ou as próprias TDPs, e se elas podem ser consultadas.
• Verifique se as tabelas das quais a TDP depende não têm bloqueios compartilhados ou exclusivos. Para que o Looker crie uma TDP, ele precisa adquirir um bloqueio exclusivo na tabela para ser atualizado. Isso entrará em conflito com outros bloqueios compartilhados ou exclusivos atualmente na mesa. O Looker só vai poder atualizar a TDP depois que todos os outros bloqueios forem liberados. O mesmo vale para todos os bloqueios exclusivos na tabela de onde o Looker está criando uma TDP. Se houver um bloqueio exclusivo em uma tabela, o Looker não vai conseguir adquirir um bloqueio compartilhado para executar consultas até que o bloqueio exclusivo seja apagado.
• Use o botão Show Processes no SQL Runner. Se houver um grande número de processos ativos, isso poderá diminuir a velocidade das consultas.
• Monitore os comentários na consulta. Consulte a seção Comentários de consulta para TDPs nesta página.

Comentários de consulta para TDPs

Os administradores de bancos de dados podem diferenciar facilmente as consultas normais daquelas que geram tabelas derivadas persistentes (TDPs). O Looker adiciona comentários à instrução CREATE TABLE ... AS SELECT ... que inclui o modelo e a visualização do LookML da TDP, além de um identificador exclusivo (slug) para a instância do Looker. Se a TDP estiver sendo gerada em nome de um usuário no Modo de Desenvolvimento, os comentários indicarão o ID do usuário. Os comentários da geração de TDPs seguem este padrão:

-- Building `<view_name>` in dev mode for user `<user_id>` on instance `<instance_slug>`
CREATE TABLE `<table_name>` SELECT ...
-- finished `<view_name>` => `<table_name>`

O comentário de geração da TDP vai aparecer na guia SQL de uma Análise se o Looker tiver que gerar uma TDP para a consulta da Análise. O comentário será exibido na parte superior da instrução SQL.

Por fim, o comentário de geração da TDP aparece no campo Mensagem na guia Informações do pop-up Detalhes da consulta para cada consulta na página de administrador de Consultas.

Como recriar TDPs após uma falha

Quando uma tabela derivada persistente (TDP) falha, veja o que acontece quando essa TDP é consultada:

• O Looker vai usar os resultados no cache se a mesma consulta tiver sido executada anteriormente. Consulte a página da documentação Consultas de armazenamento em cache para uma explicação de como isso funciona.
• Se os resultados não estiverem no cache, o Looker extrai resultados da TDP no banco de dados caso haja uma versão válida da TDP.
• Se não houver uma TDP válida no banco de dados, o Looker tentará recriar a TDP.
• Se não for possível recriar a TDP, o Looker retornará um erro para uma consulta. O regenerador do Looker tentará recriar a TDP na próxima vez que ela for consultada ou na próxima vez que a estratégia de persistência acionar uma recriação.

A mesma lógica se aplica às TDPs em cascata, exceto nas TDPs em cascata:

• Uma falha na compilação para uma tabela impede a criação de TDPs na cadeia de dependências.
• Uma TDP dependente está essencialmente consultando a TDP de que ela depende. Portanto, a estratégia de persistência de uma tabela pode acionar recompilações das TDPs que vão subindo na cadeia.

Revisitando o exemplo anterior de tabelas em cascata, em que TABLE_D depende de TABLE_C, que depende de TABLE_B, que depende de TABLE_A:

Se TABLE_B tiver uma falha, todo o comportamento padrão (não em cascata) será aplicado a TABLE_B. Se TABLE_B for consultado, o Looker primeiro tentará usar o cache para retornar resultados, depois tentará usar uma versão anterior da tabela, se possível, depois tentará recriar a tabela e, por fim, retornará um erro se TABLE_B não puder ser recriado. O Looker vai tentar recriar TABLE_B novamente na próxima consulta da tabela ou quando a estratégia de persistência dela acionar uma recriação.

O mesmo se aplica aos dependentes de TABLE_B. Portanto, se TABLE_B não puder ser criado e houver uma consulta em TABLE_C:

• O Looker vai tentar usar o cache para a consulta em TABLE_C.
• Se os resultados não estiverem no cache, o Looker vai tentar extrair resultados de TABLE_C no banco de dados.
• Se não houver uma versão válida de TABLE_C, o Looker vai tentar recriar TABLE_C, o que cria uma consulta em TABLE_B.
• O Looker vai tentar recriar TABLE_B, o que vai falhar se o TABLE_B não tiver sido corrigido.
• Se não for possível recriar TABLE_B, TABLE_C não poderá ser recriado, então o Looker retornará um erro para a consulta em TABLE_C.
• O Looker tentará recriar a TABLE_C de acordo com a estratégia de persistência habitual ou na próxima vez que a TDP for consultada (o que inclui a próxima vez que o TABLE_D tentar criar, já que TABLE_D depende da TABLE_C).

Depois de resolver o problema com TABLE_B, a TABLE_B e cada uma das tabelas dependentes vão tentar ser recriadas de acordo com as estratégias de persistência delas ou na próxima vez em que forem consultadas, o que inclui a próxima vez que uma TDP dependente tentar ser recriada. Ou, se uma versão de desenvolvimento das TDPs em cascata tiver sido criada no Modo de Desenvolvimento, as versões de desenvolvimento poderão ser usadas como as novas TDPs de produção. Consulte a seção Tabelas mantidas no Modo de Desenvolvimento nesta página para saber como isso funciona. Também é possível usar uma Análise para executar uma consulta em TABLE_D e, em seguida, recriar manualmente as TDPs da consulta, o que forçará a recriação de todas as TDPs que subirão na cascata de dependência.

Como melhorar o desempenho da TDP

Quando você cria tabelas derivadas persistentes (TDPs), o desempenho pode ser uma preocupação. Especialmente quando a tabela é muito grande, a consulta dela pode ser lenta, assim como pode ser para qualquer tabela grande no seu banco de dados.

É possível melhorar o desempenho filtrando os dados ou controlando como os dados na TDP são classificados e indexados.

Adicionar filtros para limitar o conjunto de dados

Com conjuntos de dados particularmente grandes, ter muitas linhas atrasará as consultas em uma tabela derivada persistente (TDP). Se você geralmente consulta apenas dados recentes, considere adicionar um filtro à cláusula WHERE da TDP que limita a tabela a 90 dias ou menos de dados. Dessa forma, apenas dados relevantes serão adicionados à tabela sempre que ela for recriada, para que as consultas em execução sejam muito mais rápidas. Em seguida, você pode criar uma TDP maior e separada para análise histórica, permitindo consultas rápidas de dados recentes e a capacidade de consultar dados antigos.

Como usar indexes ou sortkeys e distribution

Quando você cria uma grande tabela derivada persistente (TDP), a indexação da tabela (para dialetos como MySQL ou Postgres) ou a adição de chaves de classificação e distribuição (no Redshift) pode ajudar no desempenho.

Geralmente, é melhor adicionar o parâmetro indexes aos campos de ID ou data.

Para o Redshift, geralmente é melhor adicionar o parâmetro sortkeys nos campos de ID ou data e o parâmetro distribution no campo usado para mesclagem.

Configurações recomendadas para melhorar a performance

As configurações a seguir controlam como os dados na tabela derivada persistente (TDP) são classificados e indexados. Essas configurações são opcionais, mas altamente recomendadas:

• Para Redshift e Aster, use o parâmetro distribution para especificar o nome da coluna cujo valor é usado para espalhar os dados em um cluster. Quando duas tabelas são unidas pela coluna especificada no parâmetro distribution, o banco de dados pode encontrar os dados de mesclagem no mesmo nó. Assim, a E/S entre nós é minimizada.
• Para o Redshift, defina o parâmetro distribution_style como all para instruir o banco de dados a manter uma cópia completa dos dados em cada nó. Isso é frequentemente usado para minimizar a E/S entre nós quando tabelas relativamente pequenas são unidas. Defina esse valor como even para instruir o banco de dados a distribuir os dados uniformemente pelo cluster sem usar uma coluna de distribuição. Só é possível especificar esse valor quando distribution não é definido.
• Para o Redshift, use o parâmetro sortkeys. Os valores especificam quais colunas da TDP são usadas para classificar os dados no disco, facilitando a pesquisa. No Redshift, é possível usar sortkeys ou indexes, mas não ambos.
• Na maioria dos bancos de dados, use o parâmetro indexes. Os valores especificam quais colunas da TDP são indexadas. No Redshift, os índices são usados para gerar chaves de classificação intercaladas.