Tabelas derivadas no Looker

No Looker, uma tabela derivada é uma consulta cujos resultados são usados ​​como se a consulta fosse uma tabela real no banco de dados.

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

Você poderá então trabalhar com a tabela derivada customer_order_summary como se fosse qualquer outra tabela no banco de dados.

Para casos de uso populares de tabelas derivadas, visite Looker cookbooks: Getting the most out of derived tables in Looker.

Tabelas derivadas nativas e tabelas derivadas baseadas em SQL

Para criar uma tabela derivada em seu projeto Looker, use oderived_table parâmetro sob umvisualizar parâmetro. Dentro do parâmetro derived_table, você pode definir a consulta para a tabela derivada de duas maneiras:

• Para uma tabela derivada nativa , você define a tabela derivada com uma consulta baseada em LookML.
• Para umTabela derivada baseada em SQL Você define a tabela derivada com uma consulta SQL.

Por exemplo, os seguintes arquivos de visualização mostram como você pode 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 da 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 existente, que é definida em um arquivo separado que 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 à tabela orders no banco de dados.

Versão nativa derivada da tabela

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 de 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 ;;
  }
}

Ambas as 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 doderived_table parâmetro e seus subparâmetros, istocustomer_order_summary A visualização funciona exatamente como qualquer outra.ver arquivo . Quer você defina a consulta da tabela derivada com LookML ou com SQL, você pode criar medidas e dimensões LookML com base nas colunas da tabela derivada.

Depois de definir sua 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 LookML. Para criar uma tabela derivada nativa, você usa oexplore_source parâmetro dentro doderived_table parâmetro de umvisualizar parâmetro. Você cria as colunas da sua tabela derivada nativa fazendo referência às dimensões ou medidas LookML em seu modelo. Veja o arquivo de visualização em tabela derivado nativo no exemplo anterior .

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

Consulte a página de documentação Criando tabelas derivadas nativas para obter 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 SQL, criando colunas na tabela usando uma consulta SQL. Não é possível referenciar dimensões e medidas LookML em uma tabela derivada baseada em SQL. Veja o arquivo de visualização em tabela derivada baseado em SQL no exemplo anterior .

Normalmente, você define a consulta SQL usando osql parâmetro dentro doderived_table parâmetro de umvisualizar parâmetro.

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.

Certos casos extremos não permitirão o uso do parâmetro sql. Nesses casos, o Looker suporta os seguintes parâmetros para definir uma consulta SQL para tabelas derivadas persistentes (PDTs):

• create_process: Quando você usa osql parâmetro para um PDT, em segundo plano o Looker encapsula o dialetoCREATE TABLE Declaração da Linguagem de Definição de Dados (DDL) em torno da sua consulta para criar o PDT a partir da sua consulta SQL. Alguns dialetos não suportam uma instrução SQL CREATE TABLE em uma única etapa. Para esses dialetos, você não pode criar um PDT com o parâmetro sql. Em vez disso, você pode usar o parâmetro create_process para criar uma PDT em várias etapas. Veja ocreate_process Página de documentação de parâmetros para informações e exemplos.
• sql_create: se o caso de uso exigir comandos DDL personalizados e seu dialeto for compatível com DDL (por exemplo, o BigQuery ML preditivo do Google), use o parâmetro sql_create para criar uma PDT em vez do parâmetro sql. Consulte a página de documentação do sql_create para informações e exemplos.

Se você estiver usando o parâmetro sql, create_process ou sql_create, em todos esses casos, você estará definindo a tabela derivada com uma consulta SQL. Portanto, todas elas são consideradas tabelas derivadas baseadas em SQL.

Ao definir uma tabela derivada baseada em SQL, use AS para dar a cada coluna um alias limpo. Isso porque você precisa referenciar os nomes das colunas do conjunto de resultados nas dimensões, como ${TABLE}.first_order. É por isso que o exemplo anterior usa MIN(DATE(time)) AS first_order em vez de apenas MIN(DATE(time)).

Observação: para ser usada como um PDT incremental, uma tabela derivada baseada em SQL precisa ser definida usando o parâmetro sql. As tabelas derivadas baseadas em SQL 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 baseadas em SQL, também há uma distinção entre uma tabela derivada temporária, que não é gravada no banco de dados, e uma tabela derivada persistente (PDT, na sigla em inglês), que é gravada em um esquema no banco de dados.

As tabelas derivadas nativas e 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á uma 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 de Análise que envolve uma ou mais tabelas derivadas, o Looker cria uma consulta SQL usando uma combinação específica do dialeto do SQL para as tabelas derivadas mais os campos, junções 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 usar os resultados armazenados em cache. Consulte a página de documentação Armazenamento de consultas em cache para mais informações sobre o armazenamento em cache de consultas no Looker.

Caso contrário, se o Looker não puder usar os resultados armazenados em cache, ele vai precisar executar uma nova consulta no banco de dados toda vez 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 sobrecarregam o banco de dados. Nos casos em que a consulta leva algum tempo para ser executada, um PDT costuma ser uma opção melhor.

Dialetos de banco de dados suportados para tabelas derivadas temporárias

Para que o Looker suporte tabelas derivadas em seu projeto Looker, o dialeto do seu banco de dados também deve suportá-las. A tabela a seguir mostra quais dialetos suportam tabelas derivadas na versão mais recente do Looker:

Clique aqui para mostrar a tabela.

Dialeto	Compatível?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Tabelas derivadas persistentes

Uma tabela derivada persistente (PDT) é uma tabela derivada que é gravada em um esquema temporário no seu banco de dados e regenerada de acordo com a programação que você especificar.estratégia de persistência .

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

Requisitos para PDTs

Para usar tabelas derivadas persistentes (PDTs) em seu projeto Looker, você precisa do seguinte:

• Um dialeto de banco de dados que suporta PDTs. Consulte a seção Dialetos de banco de dados suportados para PDTs mais adiante nesta página para obter as listas de dialetos que suportam tabelas derivadas persistentes baseadas em SQL e tabelas derivadas nativas persistentes.

• Um esquema temporário no seu banco de dados. Pode ser qualquer esquema em seu banco de dados, mas recomendamos criar um novo esquema que será usado exclusivamente para essa finalidade. O administrador do banco de dados deve configurar o esquema com permissão de gravação para o usuário do banco de dados Looker.

  Aviso: Se você tiver várias instâncias do Looker, como uma instância de produção e uma instância de QA, certifique-se de definir esquemas temporários diferentes para cada instância para evitar conflitos de gerenciamento de PDT.

• Uma conexão Looker que está configurada com a opção Habilitar PDTs ativada. Esta configuração Habilitar PDTs geralmente é configurada quando você configura inicialmente sua conexão com o Looker (consulte a página de documentação Dialetos do Looker para obter instruções para o dialeto do seu banco de dados), mas você também pode habilitar PDTs para sua conexão após a configuração inicial.

Dialetos de banco de dados suportados para PDTs

Para que o Looker suporte PDTs em seu projeto Looker, o dialeto do seu banco de dados também deve suportá-los.

Para suportar qualquer tipo de PDT (baseado em LookML ou baseado em SQL), o dialeto deve suportar gravações no banco de dados, entre outros requisitos. Existem algumas configurações de banco de dados somente leitura que não permitem o funcionamento da persistência (mais comumente bancos de dados de réplica hot-swap do Postgres). Nesses casos, você pode usar tabelas derivadas temporárias em vez disso.

A tabela a seguir mostra os dialetos que suportam persistência.Tabelas derivadas baseadas em SQL na versão mais recente do Looker:

Clique aqui para mostrar a tabela.

Dialeto	Compatível?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Para suportar tabelas derivadas nativas persistentes (que possuem consultas baseadas em LookML), o dialeto também deve suportar uma função DDL CREATE TABLE. Segue abaixo uma lista dos dialetos que suportam tabelas derivadas nativas (baseadas em LookML) persistentes na versão mais recente do Looker:

Clique aqui para mostrar a tabela.

Dialeto	Compatível?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Nota: PDTs não são suportados para conexões Snowflake que usam OAuth.

Construindo PDTs incrementalmente

Uma PDT incremental é uma tabela derivada persistente que o Looker constrói adicionando novos dados à tabela em vez de reconstruí-la por completo.

Se o seuO dialeto suporta PDTs incrementais, e seu PDT usa uma estratégia de persistência baseada em gatilhos (datagroup_trigger, sql_trigger_value, ouinterval_trigger ), você podeDefina o PDT como um PDT incremental. .

Observação: PDTs incrementais não são suportados para PDTs que usam opersist_for estratégia de persistência.

Consulte a página de documentação Incremental PDTs para obter mais informações.

Dialetos de banco de dados suportados para PDTs incrementais

Para que o Looker suporte PDTs incrementais em seu projeto Looker, o dialeto do seu banco de dados também deve suportá-los. A tabela a seguir mostra quais dialetos suportam PDTs incrementais na versão mais recente do Looker:

Clique aqui para mostrar a tabela.

Dialeto	Compatível?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Criando PDTs

Para transformar uma tabela derivada em uma tabela derivada persistente (PDT), você define umaestratégia de persistência para a mesa. Para otimizar o desempenho, 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 que suportam 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 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 gatilhos (datagroup_trigger, sql_trigger_value e interval_trigger), o Looker mantém a PDT no banco de dados até que ela seja acionada para reconstrução. Quando a PDT é acionada, o Looker a recria para substituir a versão anterior. Isso significa que, com as PDTs baseadas em acionadores, os usuários não precisam esperar que a PDT seja criada para receber respostas às consultas do recurso Detalhar.

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

datagroup_trigger

Os grupos de dados são o método mais flexível de criar persistência. Se você definiu um grupo de dados com sql_trigger ou interval_trigger, use o parâmetro datagroup_trigger para iniciar a recriação das tabelas derivadas permanentes (PDTs).

O Looker mantém a PDT no banco de dados até que o grupo de dados seja acionado. Quando o grupo de dados é acionado, o Looker recria a PDT para substituir a versão anterior. Isso significa que, na maioria dos casos, os usuários não precisam esperar que a PDT seja criada. Se um usuário solicitar dados da TDP enquanto ela estiver sendo criada e os resultados da consulta não estiverem no cache, o Looker vai retornar dados da TDP atual até que a nova seja criada. Consulte Consultas de cache para uma visão geral dos datagroups.

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

sql_trigger_value

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

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

interval_trigger

Ointerval_trigger O parâmetro aciona a regeneração de uma tabela derivada persistente (PDT) com base em um intervalo de tempo que você fornece, como por exemplo:"24 hours" ou"60 minutes". Semelhante ao parâmetro sql_trigger, isso significa que normalmente a PDT será pré-construída quando seus usuários a consultarem. Se um usuário solicitar dados da PDT enquanto ela estiver sendo construída, e os resultados da consulta não estiverem no cache, o Looker retornará os dados da PDT existente até que a nova PDT seja construída.

persist_for

Outra opção é usar opersist_for Parâmetro para definir o período de tempo em que a tabela derivada deve ser armazenada antes de ser marcada como expirada, de forma que deixe de ser usada para consultas e seja removida do banco de dados.

Uma tabela derivada persistente (PDT) persist_for é criada quando um usuário executa uma consulta nela pela primeira vez. O Looker mantém o PDT no banco de dados pelo período de tempo especificado no parâmetro persist_for do PDT. Se um usuário consultar o PDT dentro do tempo persist_for, o Looker usa os resultados em cache, se possível, ou executa a consulta no PDT.

Após o tempo persist_for, o Looker limpa o PDT do seu banco de dados, e o PDT será reconstruído na próxima vez que um usuário o consultar, o que significa que a consulta precisará esperar pela reconstrução.

Os PDTs que usam persist_for não são reconstruídos automaticamente pelo Looker regenerator, exceto no caso de uma dependência cascade de PDTs. Quando umpersist_for A tabela faz parte de uma cascata de dependências com PDTs baseadas em gatilhos (PDTs que usam odatagroup_trigger, interval_trigger, ousql_trigger_value estratégia de persistência), o regenerador irá monitorar e reconstruir opersist_for tabela para reconstruir outras tabelas na cascata. Veja a seção Como o Looker constrói tabelas derivadas em cascata nesta página.

materialized_view: yes

Nota: A funcionalidade de visualização materializada é um recurso avançado. Dependendo do seu dialeto, uma visão materializada pode consumir muitos recursos, por isso é importante que você entenda a implementação de visões materializadas no seu dialeto. Consulte a documentação do seu dialeto para obter informações sobre o comportamento do dialeto e a frequência com que ele atualiza os dados das visualizações materializadas.

As visualizações materializadas permitem que você utilize a funcionalidade do seu banco de dados para persistir tabelas derivadas no seu projeto Looker. Se o dialeto do seu banco de dados suporta visualizações materializadas e sua conexão Looker estiver configurada com a opção Habilitar PDTs ativada, você pode criar uma visualização materializada especificando materialized_view: yes para uma tabela derivada. As visualizações materializadas são suportadas tanto para tabelas derivadas nativas quanto para tabelas derivadas baseadas em SQL.

Semelhante a umtabela derivada persistente (PDT) Uma visão materializada é o resultado de uma consulta que é armazenado como uma tabela no esquema temporário do seu banco de dados. A principal diferença entre uma PDT e uma visão materializada reside na forma como as tabelas são atualizadas:

• Para PDTs, a estratégia de persistência é definida no Looker, e a persistência é gerenciada pelo Looker.
• No caso de visões materializadas, o banco de dados é responsável por manter e atualizar os dados na tabela.

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

Veja omaterialized_view Consulte a página de documentação de parâmetros para obter informações sobre suporte a dialetos, requisitos e considerações importantes.

Estratégias de otimização

Como as tabelas derivadas persistentes (PDTs) são armazenadas em seu banco de dados, você deve otimizar suas PDTs usando as seguintes estratégias, conforme suportado pelo seu dialeto:

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

Por exemplo, para adicionar persistência à tabela derivada example, você pode configurá-la para ser reconstruída quando o grupo de dados orders_datagroup for acionado e adicionar índices em customer_id e first_order, assim:

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 o seu dialeto), o Looker irá avisá-lo de que você deve fazê-lo para melhorar o desempenho das consultas.

Casos de uso para PDTs

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

Como prática recomendada geral, os desenvolvedores devem tentar modelar os dados sem usar PDTs (Teorias de Decisão de Probabilidade) 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 PDT (Tabela de Dados Probabilística). Certifique-se de analisar os planos de execução de consultas lentas usando a ferramenta Explain do 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 PDTs, incluindo:

• Testando otimizações
• Pré-junção ou agregação de dados

Você também podeUse uma PDT para definir uma chave primária. nos casos em que não existe uma forma razoável de identificar uma linha única numa tabela como chave primária.

Utilizando PDTs para testar otimizações

Você pode usar PDTs para testar diferentes opções de indexação, distribuição e outras otimizações sem precisar de muito suporte do seu DBA ou dos desenvolvedores de ETL.

Considere um caso em que você tem uma tabela, mas deseja testar diferentes índices. O seu LookML inicial para a visualização pode ter a seguinte aparência:

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

Para testar estratégias de otimização, você pode usar oindexes parâmetro 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 única vez para gerar a PDT. Em seguida, execute suas consultas de teste e compare os resultados. Se os resultados forem favoráveis, você pode solicitar ao seu DBA ou equipe de ETL que adicione os índices à tabela original.

Não se esqueça de mudar o código da vista para remover a PDT.

Usar TDPs para pré-unir ou agregar dados

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

Por exemplo, suponha que você queira criar uma consulta para 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 são necessários em tempo real. No entanto, é possível calcular a consulta apenas uma vez e reutilizar os resultados com uma PDT:

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 referenciar uma tabela derivada na definição de outra, criando uma cadeia de tabelas derivadas em cascata ou tabelas derivadas permanentes (PDTs) em cascata, 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 reconstruídas automaticamente pelo regenerador do Looker e como podem ser reconstruídas manualmente pelos usuários. Há também outras considerações importantes para implementar tabelas persistentes. Todos esses tópicos são abordados mais adiante nesta página.

Sintaxe para referenciar uma tabela derivada

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

`${derived_table_or_view_name.SQL_TABLE_NAME}`

Nesse formato, SQL_TABLE_NAME é uma string literal. Por exemplo, é possível referenciar a tabela derivada clean_events com esta sintaxe:

`${clean_events.SQL_TABLE_NAME}`

Você pode usar essa mesma sintaxe para se referir a uma visualização do LookML. Nesse caso, SQL_TABLE_NAME é uma string literal.

Observação: a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME} não é compatível com o parâmetro sql_trigger de um datagroup. Portanto, não é possível usar uma tabela derivada para acionar um datagroup. No entanto, é 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 PDTs.

No exemplo a seguir, a PDT clean_events é criada com base na tabela events no banco de dados. A PDT clean_events exclui linhas indesejadas da tabela de banco de dados events. Em seguida, uma segunda TDP é mostrada. A TDP event_summary é um resumo da TDP clean_events. A tabela event_summary é regenerada sempre que novas linhas são adicionadas a clean_events.

A PDT event_summary e a PDT clean_events são PDTs em cascata, onde event_summary depende de clean_events (já que event_summary é definida usando a PDT clean_events). Este exemplo específico poderia ser feito de forma mais eficiente em uma única PDT, 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 necessário, ao se referir a uma tabela derivada dessa maneira, costuma ser ú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, os PDTs são nomeados com códigos longos em seu banco de dados. Em alguns casos (especialmente com cláusulas ON) é possível esquecer que você precisa usar a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME} para recuperar esse nome longo. Um pseudônimo pode ajudar a evitar esse tipo de erro.

Como o Looker constrói tabelas derivadas em cascata

No caso de tabelas derivadas em cascata temporary, se os resultados da consulta de um usuário não estiverem no cache, o Looker criará todas as tabelas derivadas necessárias para a consulta. Se você tem um TABLE_D cuja definição contém uma referência a TABLE_C, então TABLE_D é dependente de TABLE_C. Isso significa que se você consultar TABLE_D e a consulta não estiver no cache do Looker, o Looker reconstruirá TABLE_D. Mas primeiro, ele deve reconstruir TABLE_C.

Considere um cenário com tabelas derivadas temporárias em cascata, onde TABLE_D é dependente de TABLE_C, que é dependente de TABLE_B, que é dependente de TABLE_A. Se o Looker não tiver resultados válidos para uma consulta em TABLE_C no cache, o Looker criará todas as tabelas necessárias para a consulta. Assim, o Looker irá construir TABLE_A, e depois TABLE_B, e depois TABLE_C:

Neste cenário, TABLE_A deve terminar de gerar antes que o Looker possa começar a gerar TABLE_B, e TABLE_B deve terminar de gerar antes que o Looker possa começar a gerar TABLE_C. Quando TABLE_C terminar, o Looker fornecerá os resultados da consulta. (Como TABLE_D não é necessário para responder a esta consulta, o Looker não irá reconstruir TABLE_D neste momento.)

Veja odatagroup Página de documentação de parâmetros para um exemplo de cenário de PDTs em cascata que usam o mesmo grupo de dados.

A mesma lógica básica se aplica às PDTs: o Looker criará qualquer tabela necessária para responder a uma consulta, em toda a cadeia de dependências. Mas, com as PDTs, muitas vezes as tabelas já existem e não precisam ser reconstruídas. Com consultas padrão de usuários em PDTs em cascata, o Looker recria os PDTs na cascata somente se não houver uma versão válida dos PDTs no banco de dados. Se você quiser forçar uma reconstrução para todos os PDTs em cascata, você pode reconstruir manualmente as tabelas para uma consulta por meio de um Explore.

Um ponto lógico importante a entender é que, no caso de uma cascata PDT, uma PDT dependente está essencialmente consultando a PDT da qual depende. Isso é especialmente significativo para as PDTs que utilizam opersist_for estratégia. Normalmente, as PDTs persist_for são construídas quando um usuário as consulta, permanecem no banco de dados até que seu intervalo persist_for termine e, em seguida, não são reconstruídas até que sejam consultadas novamente por um usuário. No entanto, se umpersist_for A PDT faz parte de uma cascata com PDTs baseadas em gatilho (PDTs que usam odatagroup_trigger ,interval_trigger , ousql_trigger_value estratégia de persistência), apersist_for Essencialmente, a PDT é consultada sempre que suas PDTs dependentes são reconstruídas. Assim, neste caso, o PDT persist_for será reconstruído de acordo com o cronograma de seus PDTs dependentes. Isso significa que persist_for PDTs podem ser afetados pela estratégia de persistência de seus dependentes.

Ao configurar a persistência para estruturas PDT profundamente aninhadas (cadeias de PDTs em cascata com múltiplos níveis de dependências), certifique-se de que os períodos de retenção do cache e os intervalos do grupo de dados forneçam tempo suficiente para que toda a cascata seja construída. Períodos curtos de retenção de cache podem causar uma disputa que resulta em um erro 409 Conflict durante a atualização. Para obter mais informações e melhores práticas recomendadas, consulte a seção Solução de problemas de erros de conflito 409 em PDTs profundamente aninhados nesta página.

Reconstruindo manualmente tabelas persistentes para uma consulta

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

Esta opção só está visível para usuários comdevelop permissão, e somente depois que a consulta Explorar for carregada.

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

No caso de PDTs incrementais , a opção Recriar tabelas derivadas e executar aciona a criação de um novo incremento. Com PDTs incrementais, um incremento inclui o período de tempo especificado noincrement_key parâmetro, e também o número de períodos de tempo anteriores especificados noincrement_offset parâmetro, se houver. Consulte a página de documentação PDTs incrementais para ver alguns cenários de exemplo que mostram como os PDTs incrementais são construídos, dependendo de sua configuração.

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

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

• Para o usuário que inicia a operação Recriar tabelas derivadas e executar, a consulta aguardará a reconstrução das tabelas antes de carregar os resultados. As consultas de outros usuários ainda usarão as tabelas existentes. Assim que as tabelas persistentes forem reconstruídas, todos os usuários passarão a usar as tabelas reconstruídas. Embora esse processo seja projetado para evitar a interrupção das consultas de outros usuários enquanto as tabelas estão sendo reconstruídas, esses usuários ainda podem ser afetados pela carga adicional em seu banco de dados. Se você estiver em uma situação em que acionar uma reconstrução durante o horário comercial possa sobrecarregar seu banco de dados de forma inaceitável, talvez seja necessário comunicar aos seus usuários que eles nunca devem reconstruir determinadas PDTs ou tabelas agregadas durante esse período.

• Se um usuário estiver no Modo de Desenvolvimento e a Exploração 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 Exploração. Mas se a opção Explorar no Modo de Desenvolvimento estiver usando a versão de produção de uma tabela derivada, a tabela de produção será reconstruída. Consulte Tabelas persistentes no modo de desenvolvimento para obter informações sobre tabelas de desenvolvimento e tabelas de produção.

• Para instâncias hospedadas pelo Looker, se a tabela derivada demorar mais de uma hora para ser reconstruída, a reconstrução não será bem-sucedida e a sessão do navegador expirará. Consulte a seção Tempos limite de consulta e enfileiramento na página de documentação Configurações de administrador - Consultas para obter mais informações sobre tempos limite que podem afetar os processos do Looker.

Tabelas persistentes no modo de desenvolvimento

O Looker possui alguns comportamentos especiais para gerenciar tabelas persistidas no Modo de Desenvolvimento.

Nota: Esses comportamentos se aplicam a qualquer tipo de tabela persistida, incluindo tabelas agregadas bem como tabelas derivadas persistentes (PDTs).

Se você consultar uma tabela persistida no Modo de Desenvolvimento sem fazer qualquer alteração em sua definição, o Looker consultará a versão de produção dessa tabela. Se vocêfazer Se você fizer uma alteração na definição da tabela que afete os dados nela contidos 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. Ter uma tabela de desenvolvimento como essa permite testar alterações sem incomodar os usuários.

O que leva o Looker a criar uma tabela de desenvolvimento?

Sempre que possível, o Looker utiliza a tabela de produção existente para responder às consultas, independentemente de você estar ou não no Modo de Desenvolvimento. Mas existem certos casos em que o Looker não pode usar a tabela de produção para consultas no Modo de Desenvolvimento:

• Se a sua tabela persistida tiver um parâmetro que reduza o seu conjunto de dados para trabalhe mais rápido no Modo de Desenvolvimento
• Se você fez alterações na definição da sua tabela persistida que afetam os dados na tabela

O Looker criará uma tabela de desenvolvimento se você estiver no Modo de Desenvolvimento e fizer uma consulta.Tabela derivada baseada em SQL que é definido usando umcondicionalWHERE cláusula comif prod eif dev declarações .

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

Para tabelas persistidas que não possuem 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 às consultas no Modo de Desenvolvimento, a menos que você altere a definição da tabela e then consulte a tabela no Modo de Desenvolvimento. Isso se aplica a quaisquer alterações na tabela que afetem os dados nela contidos ou a forma como a tabela é consultada.

Aqui estão alguns exemplos dos tipos de alterações que farão com que o Looker crie uma versão de desenvolvimento de uma tabela persistente (o Looker criará a tabela somente se você consultá-la posteriormente, após fazer essas alterações):

• Alterar a consulta na qual a tabela persistente se baseia, como por exemplo, modificar oexplore_source, sql, query, sql_create, oucreate_process parâmetro na própria tabela persistente ou em qualquer tabela necessária (no caso detabelas derivadas em cascata )
• Alterar a estratégia de persistência da tabela, como modificar a própria tabela.datagroup_trigger, sql_trigger_value, interval_trigger, oupersist_for parâmetro
• Alterar o nome de uma tabela derivadaview
• Mudando oincrement_key ouincrement_offset de umPDT incremental
• Mudando oconnection que é usado pelo modelo associado

Para alterações que não modificam os dados da tabela nem afetam a forma como o Looker consulta a tabela, o Looker não criará uma tabela de desenvolvimento. Opublish_as_db_view O parâmetro é um bom exemplo: No Modo de Desenvolvimento, se você alterar apenas opublish_as_db_view Ao configurar uma tabela derivada, o Looker não precisa recriá-la e, portanto, não 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 as tabelas persistidas em desenvolvimento como se tivessem uma estratégia de persistência de de persist_for: "24 hours". O Looker faz isso para garantir que as tabelas de desenvolvimento não sejam persistidas por mais de um dia, já que um desenvolvedor do Looker pode consultar várias 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 (PDTs) e tabelas agregadas no Modo de Desenvolvimento da mesma forma que cria tabelas persistentes no Modo de Produção.

Se uma tabela de desenvolvimento for persistida em seu banco de dados ao implantar alterações em uma PDT ou em uma tabela agregada, o Looker geralmente pode usar a tabela de desenvolvimento como a tabela de produção, para que seus usuários não precisem esperar a tabela ser criada ao consultá-la.

Observe que, ao implantar suas alterações, a tabela ainda poderá precisar ser reconstruída para ser consultada em produção, dependendo da situação:

• Se já se passaram 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. Você pode verificar PDTs não construídas usando o Looker IDE ou usando a guia Desenvolvimento da página Tabelas Derivadas Persistentes. Se você tiver PDTs não compiladas, poderá consultá-las no Modo de Desenvolvimento imediatamente antes de fazer as alterações, para que a tabela de desenvolvimento esteja disponível para uso em produção.
• Se uma tabela persistida tiver odev_filters parâmetro (paratabelas derivadas nativas ) ou ocondicionalWHERE cláusula que está usando oif prod eif dev declarações (paraTabelas derivadas baseadas em SQL ), a tabela de desenvolvimento não pode ser usada como versão de produção, pois possui um conjunto de dados abreviado. Nesse caso, depois de terminar de desenvolver a tabela e antes de implantar as alterações, você pode comentar o parâmetro dev_filters ou a cláusula condicional WHERE e, em seguida, consultar a tabela no Modo de Desenvolvimento. Em seguida, o Looker criará uma versão completa da tabela que poderá ser usada em produção quando você implantar suas alterações.

Caso contrário, se você implantar suas alterações quando não houver uma tabela de desenvolvimento válida que possa ser usada como tabela de produção, o Looker reconstruirá a tabela na próxima vez que ela for consultada no Modo de Produção (para tabelas persistidas que usam o...).persist_for estratégia), ou na próxima vez que oregenerador executa (para tabelas persistidas que usamdatagroup_trigger, interval_trigger, ousql_trigger_value ).

Verificação de PDTs não compilados no Modo de Desenvolvimento

Se uma tabela de desenvolvimento for persistida em seu banco de dados ao implantar alterações em uma tabela derivada persistente (PDT) ou em uma tabela agregada, o Looker geralmente pode usar a tabela de desenvolvimento como a tabela de produção, para que seus usuários não precisem esperar a tabela ser criada ao consultá-la. Consulte as seções Por quanto tempo o Looker persiste as tabelas de desenvolvimento e O que leva o Looker a criar uma tabela de desenvolvimento nesta página para obter mais detalhes.

Portanto, o ideal é que todas as suas PDTs sejam criadas no momento da implantação em produção, para que as tabelas possam ser usadas imediatamente como versões de produção.

Você pode verificar se há PDTs não construídos em seu projeto no painel Saúde do Projeto. Clique no ícone Project Health no Looker IDE para abrir o painel Project Health. Em seguida, clique no botão Validar status PDT.

Se houver PDTs não construídos, o painel Project Health os listará:

Se você tiversee_pdts Para obter permissão, você pode clicar emAcesse o Gerenciamento de PDT botão. O Looker abrirá a guia Development da página Persistent Derived Tables e filtrará os resultados para o seu projeto LookML específico. A partir daí, você pode ver quais PDTs de desenvolvimento foram compilados e quais não foram, além de acessar outras informações para solução de problemas. Consulte a página de documentação Configurações de administrador - Tabelas derivadas persistentes para obter mais informações.

Depois de identificar uma PDT não construída em seu projeto, você pode construir uma versão de desenvolvimento dela abrindo um Explore que consulta a tabela e, em seguida, usando a opção Reconstruir tabelas derivadas e executar do menu Explore. Consulte a seção Reconstruindo manualmente tabelas persistentes para uma consulta nesta página.

Nota: Se uma tabela persistida for uma tabela derivada baseada em SQL que é definida usando uma cláusula condicional WHERE com instruções if prod e if dev, você não poderá 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 as tabelas de desenvolvimento nesta página para obter mais informações. Paratabelas derivadas nativas com odev_filters O Looker usa a tabela de produção para responder a consultas no Modo de Desenvolvimento, a menos que você altere a definição da tabela e, em seguida, consulte a tabela no Modo de Desenvolvimento (consulte oO que leva o Looker a criar uma tabela de desenvolvimento? (Seção nesta página de documentação).

Compartilhamento da mesa e limpeza

Em qualquer instância do Looker, o Looker compartilhará tabelas persistidas entre usuários se as tabelas 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 tiver feito nenhuma alteração em uma tabela no Modo de Desenvolvimento, suas consultas usarão as tabelas de produção existentes. Isso ocorre a menos que sua mesa seja umaTabela derivada baseada em SQL que é definido usando umcondicionalWHERE cláusula comif prod eif dev declarações. Se a tabela for definida com uma cláusula condicional WHERE, o Looker criará uma tabela de desenvolvimento se você consultar a tabela no Modo de Desenvolvimento. (Paratabelas derivadas nativas com odev_filters O Looker possui a lógica para usar a tabela de produção para responder a consultas no Modo de Desenvolvimento, a menos que você altere a definição da tabela e, em seguida, consulte a tabela no Modo de Desenvolvimento.
• Se dois desenvolvedores fizerem a mesma alteração em uma tabela enquanto estiverem no Modo de Desenvolvimento, eles compartilharão a mesma tabela de desenvolvimento.
• Assim que você enviar suas alterações do Modo de Desenvolvimento para o Modo de Produção, a antiga definição de produção deixará de existir, portanto, a antiga tabela de produção será marcada como expirada e será descartada.
• Se você decidir descartar as alterações feitas no Modo de Desenvolvimento, a definição dessa tabela deixará de existir, portanto, as tabelas de desenvolvimento desnecessárias serão marcadas como expiradas e serão excluídas.

Trabalhando mais rápido no Modo de Desenvolvimento

Existem situações em que a tabela derivada persistente (PDT) que você está criando demora muito tempo para ser gerada, o que pode ser demorado se você estiver testando muitas alterações no Modo de Desenvolvimento. Nesses casos, você pode instruir o Looker a criar versões menores de uma tabela derivada quando estiver no Modo de Desenvolvimento.

Paratabelas derivadas nativas, você pode usar odev_filters subparâmetro deexplore_source Para especificar filtros que se aplicam somente às 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 os dados para os últimos 2 anos e para o Aeroporto de Yucca Valley.

O parâmetro dev_filters atua em conjunto com o parâmetro filters para que todos os filtros sejam aplicados à versão de desenvolvimento da tabela. Se ambos 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 filtrará os dados dos últimos 90 dias para o Aeroporto de Yucca Valley.

ParaTabelas derivadas baseadas em SQL O Looker suporta uma condicional.WHERE cláusula com diferentes opções de produção (if prod ) e desenvolvimento (if dev ) versões 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 a partir de 2000 quando estiver em Modo de Produção, mas apenas os dados a partir de 2020 quando estiver em Modo de Desenvolvimento. Utilizar essa funcionalidade estrategicamente para limitar o conjunto de resultados e aumentar a velocidade de consulta pode facilitar bastante a validação das alterações no Modo de Desenvolvimento.

Nota: Se uma tabela persistida tiver o parâmetro dev_filters ou a cláusula condicional WHERE, a tabela de desenvolvimento não poderá ser usada como a versão de produção, uma vez que a versão de desenvolvimento tem um conjunto de dados abreviado. Nesse caso, depois de terminar de desenvolver a tabela e antes de implantar as alterações, você pode comentar o parâmetro dev_filters ou a cláusula condicional WHERE e, em seguida, consultar a tabela no Modo de Desenvolvimento. Em seguida, o Looker criará uma versão completa da tabela que poderá ser usada em produção quando você implantar suas alterações. Consulte a seção Por quanto tempo o Looker mantém as tabelas de desenvolvimento nesta página para obter mais detalhes sobre como usar tabelas de desenvolvimento em produção.

Como o Looker constrói PDTs

Após uma tabela derivada persistente (PDT) ter sido definida e ser executada pela primeira vez ou acionada pelo regenerator para reconstrução de acordo com sua estratégia de persistência, o Looker passará pelas seguintes etapas:

1. Utilize o SQL da tabela derivada para criar uma instrução CREATE TABLE AS SELECT (ou CTAS) e execute-a. Por exemplo, para reconstruir uma PDT chamada customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Execute as instruções para criar os índices quando a tabela for construída.
3. Renomeie a tabela de LC$.. ("Looker Create") para LR$.. ("Looker Read"), para indicar que a tabela está pronta para uso.
4. Remova qualquer versão antiga da tabela que não deva mais ser usada.

Há algumas implicações importantes:

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

O regenerador Looker

O regenerador do Looker verifica o status e inicia reconstruções para tabelas persistidas por gatilho. Uma tabela persistida por gatilho é uma tabela derivada persistente (PDT) ou uma tabela agregada que usa um gatilho como estratégia de persistência:

• Para tabelas que usamsql_trigger_value O gatilho é uma consulta especificada na tabela.sql_trigger_value parâmetro. O regenerador do Looker aciona uma reconstrução da tabela quando o resultado da última verificação da consulta de gatilho é diferente do resultado da verificação da consulta de gatilho anterior. Por exemplo, se sua tabela derivada for persistida com a consulta SQL SELECT CURDATE(), o regenerador do Looker reconstruirá a tabela na próxima vez que o regenerador verificar o gatilho após as alterações de data.
• Para tabelas que usaminterval_trigger O gatilho é uma duração de tempo especificada na tabela.interval_trigger parâmetro. O regenerador do Looker aciona uma reconstrução da tabela quando o tempo especificado tiver decorrido.
• Para tabelas que usamdatagroup_trigger O gatilho pode ser uma consulta especificada no grupo de dados associado.sql_trigger parâmetro, ou o gatilho pode ser uma duração de tempo especificada no grupo de dados.interval_trigger parâmetro.

O regenerador do Looker também inicia reconstruções para tabelas persistidas que usam opersist_for parâmetro, mas somente quando opersist_for A tabela é uma dependência.cascata de uma tabela persistida por gatilho. Neste caso, o regenerador do Looker iniciará reconstruções para uma tabela persist_for, já que a tabela é necessária para reconstruir as outras tabelas na cascata. Caso contrário, o regenerador não monitora tabelas persistidas que usam a estratégia persist_for.

Além disso, o regenerador Looker criamodelos analíticos Em seu banco de dados, se você definiu o modelo analítico usando oderived_analytic_model parâmetro. Os processos de regeneração do Looker derivam modelos analíticos semelhantes aos PDTs que são visualizações materializadas. Tanto as visualizações materializadas quanto os modelos analíticos derivados são criados apenas uma vez e não suportam gatilhos, como...gatilhos de grupo de dados, Gatilhos SQL, ougatilhos de intervalo . O regenerador do Looker recria modelos analíticos em seu banco de dados somente se a definição LookML deles for alterada ou se alguma das visualizações LookML das quais eles dependem for alterada.

O ciclo de regeneração do Looker começa em um intervalo regular configurado pelo administrador do Looker na configuração Agendamento de Manutenção da sua conexão com o banco de dados (o padrão é um intervalo de cinco minutos). No entanto, o regenerador Looker não inicia um novo ciclo até que tenha concluído todas as verificações e reconstruções do PDT do ciclo anterior. Isso significa que, se você tiver builds PDT de longa duração, o ciclo de regeneração do Looker pode não ser executado com a frequência definida na configuração Agendamento de Manutenção. Outros fatores podem afetar o tempo necessário para reconstruir suas tabelas, conforme descrito na seção Considerações importantes para a implementação de tabelas persistidas desta página.

Nos casos em que uma PDT não for construída, o regenerador poderá tentar reconstruir a tabela no próximo ciclo de regeneração:

• Se a configuração Retry Failed PDT Builds estiver habilitada na sua conexão de banco de dados, o regenerador do Looker tentará reconstruir a tabela durante o próximo ciclo de regeneração, mesmo que a condição de gatilho da tabela não seja atendida.
• Se a configuração Tentar novamente em caso de falha na construção do PDT estiver desativada, o regenerador do Looker não tentará reconstruir a tabela até que a condição de acionamento do PDT seja atendida.

Se um usuário solicitar dados da tabela persistida enquanto ela está sendo construída e os resultados da consulta não estiverem no cache, o Looker verifica se a tabela existente 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 ocorrer se a nova tabela tiver uma definição diferente, se a nova tabela 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 existente ainda for válida, o Looker retornará os dados da tabela existente até que a nova tabela seja criada. Caso contrário, se a tabela existente não for válida, o Looker fornecerá os resultados da consulta assim que a nova tabela for recriada.

Considerações importantes para a implementação de tabelas persistentes

Considerando a utilidade das tabelas persistentes (PDTs e tabelas agregadas ), é possível acumular muitas delas em sua instância do Looker. É possível criar um cenário em que oRegenerador Looker Precisa construir várias tabelas ao mesmo tempo. Especialmente comtabelas em cascata Em tabelas de longa duração, por exemplo, você pode criar um cenário onde as tabelas têm um longo atraso antes de serem reconstruídas, ou onde os usuários experimentam um atraso na obtenção de resultados de consultas de uma tabela enquanto o banco de dados está trabalhando arduamente para gerar a tabela.

O Looker regenerator verifica os gatilhos PDT para ver se deve reconstruir as tabelas persistidas por gatilho. O ciclo de regeneração é definido em um intervalo regular que é configurado pelo seu administrador do Looker na configuração Agendamento de Manutenção em sua conexão de banco de dados (o padrão é um intervalo de cinco minutos).

Diversos fatores podem afetar o tempo necessário para reconstruir suas tabelas:

• Seu administrador do Looker pode ter alterado o intervalo das verificações do gatilho do regenerador usando a configuração Agendamento de Manutenção em sua conexão de banco de dados.
• O regenerador Looker não inicia um novo ciclo até que tenha concluído todas as verificações e reconstruções de PDT do ciclo anterior. Portanto, se você tiver builds PDT de longa duração, o ciclo de regeneração do Looker pode não ser tão frequente quanto a configuração Agendamento de Manutenção.
• Por padrão, o regenerador pode iniciar a reconstrução de uma tabela PDT ou agregada por vez em uma conexão. Um administrador do Looker pode ajustar o número permitido de reconstruções simultâneas do regenerador usando o campo Número máximo de conexões do construtor PDT nas configurações de uma conexão.
• Todas as PDTs e tabelas agregadas acionadas pelo mesmodatagroup será reconstruído durante o mesmo processo de regeneração. Isso pode representar 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, existem também algumas situações em que você deve evitar adicionar persistência a uma tabela derivada:

• Quando as tabelas derivadas serão extended — Cada extensão de uma PDT criará uma nova cópia da tabela em seu banco de dados.
• Quando tabelas derivadas usam filtros com modelo ou parâmetros Liquid — A persistência não é suportada para tabelas derivadas que usam filtros com modelo ou parâmetros Liquid.
• Quandotabelas derivadas nativas são construídos a partir de Explores que usamatributos do usuário comaccess_filters, ou comsql_always_where — Serão criadas cópias da tabela em seu banco de dados para cada valor possível de atributo de usuário especificado.
• Quando os dados subjacentes mudam frequentemente e o dialeto do seu banco de dados não oferece suportePDTs incrementais.
• Quando o custo e o tempo envolvidos na criação de PDTs são muito altos.

Dependendo da quantidade e complexidade das tabelas persistidas na sua conexão com o Looker, a fila pode conter muitas tabelas que precisam ser verificadas e reconstruídas a cada ciclo. Portanto, é importante levar esses fatores em consideração ao implementar tabelas derivadas na sua instância do Looker.

Gerenciando PDTs em escala usando API

Monitorar e gerenciar tabelas derivadas persistentes (PDTs) que são atualizadas em intervalos variáveis ​​torna-se cada vez mais complexo à medida que você cria mais PDTs em sua instância. Considere usar a integração Looker Apache Airflow para gerenciar seus agendamentos PDT juntamente com seus outros processos ETL e ELT.

Monitoramento e resolução de problemas de PDTs

Se você usa tabelas derivadas persistentes (PDTs), e especialmente PDTs cascading, é útil ver o status de suas PDTs. Você pode usar a página de administração Looker Persistent Derived Tables para ver o status de suas PDTs. Você também pode verificar oÁrvore de solução de problemas do PDT para depuração passo a passo.

Ao tentar solucionar problemas de PDTs:

• Preste especial atenção à distinção entretabelas de desenvolvimento e tabelas de produção ao investigar oRegistro de eventos PDT.
• Verifique se a configuração Temp Database na sua conexão Looker corresponde ao seu esquema ou banco de dados temporário real. Se a configuração Temp Database na conexão não corresponder ao esquema temporário do seu banco de dados, atualize a configuração Temp Database para que o Looker possa armazenar tabelas derivadas persistentes no seu banco de dados.
• Determine se há problemas com todos os PDTs ou apenas com um deles. Se houver algum problema com um deles, é provável que a causa seja um erro de LookML ou SQL.
• Determine se os problemas com o PDT correspondem aos horários em que está programado para ser reconstruído.
• Certifique-se de que todossql_trigger_value As consultas são avaliadas com sucesso e retornam apenas uma linha e uma coluna. Para PDTs baseados em SQL, você pode fazer isso executando-os no SQL Runner. (A aplicação de um LIMIT protege contra consultas descontroladas.) Para obter mais informações sobre como usar o SQL Runner para depurar tabelas derivadas, consulte a postagem da comunidade Usando o SQL Runner para testar tabelas derivadas .
• Para PDTs baseadas em SQL, use o SQL Runner para verificar se o SQL da PDT é executado sem erros. (Certifique-se de aplicar um LIMIT no SQL Runner para manter os tempos de consulta razoáveis.)
• Para tabelas derivadas baseadas em SQL, evite usarexpressões de tabela comuns (CTEs). O uso de CTEs com DTs cria instruções WITH aninhadas que podem fazer com que as PDTs falhem sem aviso prévio. Em vez disso, use o SQL para sua CTE para criar uma DT secundária e referencie essa DT a partir da sua primeira DT usando o${derived_table_or_view_name.SQL_TABLE_NAME} sintaxe.
• Verifique se todas as tabelas das quais o PDT problemático depende — sejam tabelas normais ou os próprios PDTs — existem e podem ser consultadas.
• Certifique-se de que nenhuma tabela da qual o PDT problemático dependa possua bloqueios compartilhados ou exclusivos. Para que o Looker consiga construir uma PDT com sucesso, ele precisa adquirir um bloqueio exclusivo na tabela que precisa ser atualizada. Isso entrará em conflito com outros bloqueios compartilhados ou exclusivos que estejam sendo considerados. O Looker não poderá atualizar o PDT até que todos os outros bloqueios sejam liberados. O mesmo se aplica a quaisquer bloqueios exclusivos na tabela a partir da qual o Looker está construindo uma PDT; se houver um bloqueio exclusivo em uma tabela, o Looker não poderá adquirir um bloqueio compartilhado para executar consultas até que o bloqueio exclusivo seja removido.
• Use o botão Mostrar processos no SQL Runner. Se houver um grande número de processos ativos, isso poderá tornar os tempos de consulta mais lentos.
• Monitore os comentários na consulta. Consulte a seção Comentários de consulta para PDTs nesta página.

• Quando funções de data específicas do banco de dados (como current_date()) são usadas na consulta SQL de uma tabela derivada, há risco de incompatibilidade de fuso horário entre a sessão do Looker do usuário e o banco de dados subjacente. Como as funções de banco de dados são executadas diretamente no banco de dados e não passam pela conversão de fuso horário da consulta do Looker, essa discrepância pode causar resultados inesperados de filtro de data. Por exemplo, um filtro de data para "Ontem" pode ser avaliado como "Há dois dias" perto da meia-noite.

  Para resolver esse problema, verifique se o fuso horário está alinhado corretamente entre o banco de dados e a instância do Looker. Isso pode exigir coordenação com sua equipe de engenharia de dados.

• Se você encontrar um erro 409 Conflict durante uma atualização de TDP em estruturas de TDP profundamente aninhadas (cadeias de TDPs em cascata com vários níveis de dependências), consulte a seção Solução de problemas de erros de conflito 409 em TDPs profundamente aninhadas nesta página.

Consultar comentários para PDTs

Os administradores de banco de dados podem diferenciar consultas normais daquelas que geram tabelas derivadas permanentes (PDTs). O Looker adiciona comentários à instrução CREATE TABLE ... AS SELECT ... que inclui o modelo e a visualização do LookML da PDT, além de um identificador exclusivo (slug) para a instância do Looker. Se a PDT estiver sendo gerada em nome de um usuário no modo de desenvolvimento, os comentários vão indicar o ID dele. Os comentários de geração de PDT 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 de PDT vai aparecer na guia "SQL" de uma Análise se o Looker tiver que gerar uma PDT para a consulta da Análise. O comentário vai aparecer na parte de cima da instrução SQL.

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

Recriar TDPs após uma falha

Quando uma tabela derivada persistente (TDP) falha, acontece o seguinte quando ela é consultada:

• O Looker vai usar os resultados no cache se a mesma consulta já tiver sido executada. Consulte a página de documentação Consultas de cache para uma explicação de como isso funciona.
• Se os resultados não estiverem no cache, o Looker vai extrair os resultados da PDT no banco de dados, se uma versão válida da PDT existir.
• Se não houver uma PDT válida no banco de dados, o Looker vai tentar recriá-la.
• Se a TDP não puder ser recriada, o Looker vai retornar um erro para uma consulta. O regenerador do Looker vai tentar recriar a TDP na próxima vez que ela for consultada ou quando a estratégia de persistência dela acionar uma recriação.

Com as em cascata, a mesma lógica se aplica, mas:

• Uma falha na criação de uma tabela impede a criação das TDPs na cadeia de dependência.
• Um PDT dependente está essencialmente consultando o PDT do qual depende, então a estratégia de persistência de uma tabela pode desencadear reconstruções dos PDTs subindo na cadeia.

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

Se TABLE_B apresentar uma falha, todo o comportamento padrão (não em cascata) se aplica a TABLE_B:

1. Se TABLE_B for consultado, o Looker primeiro tenta usar o cache para retornar resultados.
2. Caso essa tentativa falhe, o Looker tentará usar uma versão anterior da tabela, se possível.
3. Se essa tentativa também falhar, o Looker tentará reconstruir a tabela.
4. Finalmente, se TABLE_B não puder ser reconstruído, o Looker retornará um erro.

O Looker tentará reconstruir TABLE_B novamente quando a tabela for consultada novamente ou quando a estratégia de persistência da tabela acionar uma reconstrução.

O mesmo também se aplica aos dependentes de TABLE_B. Portanto, se TABLE_B não puder ser construído e houver uma consulta em TABLE_C, a seguinte sequência ocorrerá:

1. O Looker tentará usar o cache para a consulta em TABLE_C.
2. Se os resultados não estiverem no cache, o Looker tentará obter os resultados de TABLE_C no banco de dados.
3. Se não houver uma versão válida de TABLE_C, o Looker tentará reconstruir TABLE_C, o que cria uma consulta em TABLE_B.
4. O Looker tentará então reconstruir TABLE_B (o que falhará se TABLE_B não tiver sido corrigido).
5. Se TABLE_B não puder ser reconstruído, então TABLE_C também não poderá ser reconstruído, portanto o Looker retornará um erro para a consulta em TABLE_C.
6. O Looker tentará então reconstruir TABLE_C de acordo com sua estratégia de persistência usual, ou na próxima vez que o PDT for consultado (o que inclui a próxima vez que TABLE_D tentar construir, já que TABLE_D depende de TABLE_C).

Assim que você resolver o problema com TABLE_B, então TABLE_B e cada uma das tabelas dependentes tentarão ser reconstruídas de acordo com suas estratégias de persistência, ou na próxima vez que forem consultadas (o que inclui a próxima vez que uma PDT dependente tentar ser reconstruída). Ou, se uma versão de desenvolvimento dos PDTs na cascata foi criada no Modo de Desenvolvimento, as versões de desenvolvimento podem ser usadas como os novos PDTs de produção. (Consulte a seção Tabelas persistidas no Modo de Desenvolvimento nesta página para saber como isso funciona.) Ou você pode usar um Explore para executar uma consulta em TABLE_D e então reconstruir manualmente os PDTs para a consulta, o que forçará uma reconstrução de todos os PDTs subindo na cascata de dependência.

Solução de problemas de erros de conflito 409 em PDTs profundamente aninhadas

Ao trabalhar com estruturas PDT profundamente aninhadas (cadeias de PDTs em cascata com múltiplos níveis de dependências), configurar períodos curtos de retenção de cache (por exemplo, 15 minutos) pode causar uma disputa que resulta em um erro 409 Conflict durante a atualização.

Essa disputa ocorre porque o cache para PDTs aninhadas de nível inferior pode expirar enquanto as PDTs de nível superior ainda estão em processo de construção. Quando essa situação ocorre, o Looker aciona uma nova solicitação de compilação duplicada para os PDTs de nível inferior enquanto o trabalho inicial ainda está sendo processado no data warehouse, o que resulta no conflito.

Para resolver ou evitar esse erro, siga as melhores práticas abaixo:

• Aumente o período de armazenamento do cache: Defina o período de armazenamento do cache (max_cache_age oupersist_for ) para que os PDTs levem pelo menos duas a três vezes o tempo máximo necessário para concluir a construção completa de todos os PDTs aninhados.
• Aumentar o intervalo de atualização do grupo de dados: Permitir tempo adequado para que as compilações PDT profundamente aninhadas terminem, o que reduz o risco de sobreposição de processos de compilação.

Melhorar o desempenho da PDT

Quando vocêCriar tabelas derivadas persistentes (PDTs) O desempenho pode ser uma preocupação. Principalmente quando a tabela é muito grande, a consulta pode ser lenta, assim como pode ser para qualquer tabela grande em seu banco de dados.

Você pode melhorar o desempenho filtrando os dados ou controlando como os dados no PDT são classificados e indexados.

Adicionando filtros para limitar o conjunto de dados

Em conjuntos de dados particularmente grandes, ter muitas linhas pode tornar as consultas em uma tabela derivada persistente (PDT) mais lentas. Se você costuma consultar apenas dados recentes, considere adicionar um filtro à cláusula WHERE da sua PDT que limite a tabela a dados de 90 dias ou menos. Dessa forma, apenas os dados relevantes serão adicionados à tabela a cada reconstrução, tornando a execução de consultas muito mais rápida. Em seguida, você pode criar uma PDT separada e maior para análise histórica, permitindo consultas rápidas a dados recentes e também a capacidade de consultar dados antigos.

Usando indexes ou sortkeys e distribution

Ao criar uma tabela derivada persistente (PDT) grande, indexar a tabela (para dialetos como MySQL ou Postgres) ou adicionar chaves de classificação e distribuição (para Redshift) pode ajudar no desempenho.

Geralmente é melhor adicionar oindexes parâmetro em campos de ID ou data.

Para o Redshift, geralmente é melhor adicionar osortkeys parâmetro em campos de ID ou data e odistribution parâmetro no campo que é usado para junção.

Configurações recomendadas para melhorar o desempenho.

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

• Para Redshift e Aster, use odistribution parâmetro para especificar o nome da coluna cujo valor é usado para distribuir 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 junção no mesmo nó, minimizando assim a E/S entre nós.
• Para o Redshift, defina odistribution_style parâmetro paraall Instruir o banco de dados a manter uma cópia completa dos dados em cada nó. Isso geralmente é usado para minimizar a E/S entre nós quando tabelas relativamente pequenas são unidas. Defina este valor como even para instruir o banco de dados a distribuir os dados uniformemente pelo cluster sem usar uma coluna de distribuição. Este valor só pode ser especificado quando distribution não for especificado.
• Para o Redshift, use o parâmetro sortkeys. Os valores especificam quais colunas da PDT são usadas para classificar os dados no disco e facilitar a pesquisa. No Redshift, você pode 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 PDT são indexadas. No Redshift, os índices são usados para gerar chaves de classificação intercaladas.