Tabelas derivadas no Looker

No Looker, uma tabela derivada é uma consulta cujos resultados são usados como se ela 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 tabela de banco de dados chamada customer_order_summary que inclui essas métricas.

Depois, é possível trabalhar com a tabela derivada customer_order_summary como se fosse qualquer outra tabela no banco de dados.

Para conferir 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 baseadas em SQL

Para criar uma tabela derivada no seu projeto do Looker, use o parâmetro derived_table em um parâmetro view. Dentro do parâmetro derived_table, é possível 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 uma tabela derivada baseada 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 de uma tabela derivada customer_order_summary. As duas versões da LookML mostram como criar tabelas derivadas equivalentes usando LookML ou SQL para definir a consulta da tabela derivada:

• A tabela derivada nativa define a consulta com a LookML no parâmetro explore_source. Neste exemplo, a consulta é baseada em uma visualização orders existente, que é definida em um arquivo separado não mostrado aqui. 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.

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

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 com base na tabela orders, com as colunas customer_id, first_order, e total_amount.

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

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

Tabelas derivadas nativas

As tabelas derivadas nativas são baseadas em consultas definidas 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 view. Para criar as colunas da sua tabela derivada nativa, consulte as dimensões ou medidas do LookML no seu modelo. Consulte o arquivo de visualização em tabela derivada nativa 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 ao modelar seus dados.

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

Tabelas derivadas baseadas em SQL

Para criar uma tabela derivada baseada em SQL, defina uma consulta em termos de SQL, criando colunas na tabela usando uma consulta SQL. Não é possível se referir a dimensões e medidas do LookML em uma tabela derivada baseada em SQL. Consulte o arquivo de visualização em tabela derivada baseada em SQL no exemplo anterior.

Normalmente, você define a consulta SQL usando o parâmetro sql dentro do parâmetro derived_table de um parâmetro view.

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 oferece suporte aos seguintes parâmetros para definir uma consulta SQL para tabelas derivadas persistentes (PDTs):

• create_process: quando você usa o parâmetro sql para uma PDT, o Looker envolve a instrução de linguagem de definição de dados (DDL) CREATE TABLE do dialeto em segundo plano na sua consulta para criar a PDT com 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 PDT com o parâmetro sql. Em vez disso, use o parâmetro create_process para criar uma PDT em várias etapas. Consulte a página de 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 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 de usar o 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, a tabela derivada será definida com uma consulta SQL. Portanto, todas 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)).

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), que é gravada em um esquema no banco de dados.

As tabelas derivadas nativas e as 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 do recurso Detalhar 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 precisará executar uma nova consulta no 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 sobrecarregam o 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 banco de dados também precisa oferecer. A tabela a seguir mostra quais dialetos são compatíveis com tabelas derivadas na versão mais recente do Looker:

Tabelas derivadas persistentes

Uma tabela derivada persistente (PDT) é uma tabela derivada gravada em um esquema temporário no seu banco de dados e regenerada na programação especificada com uma 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) no seu projeto do Looker, você precisa do seguinte:

• Um dialeto de banco de dados compatível com PDTs. Consulte a seção Dialetos de banco de dados compatíveis com PDTs mais adiante nesta página para ver as listas de dialetos que oferecem suporte a tabelas derivadas persistentes com base em SQL e tabelas derivadas nativas persistentes.

• Um esquema temporário no seu banco de dados. Pode ser qualquer esquema no seu banco de dados, mas recomendamos criar um novo esquema que será usado apenas para essa finalidade. 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 do Looker configurada com a opção Ativar TDPs ativada. A configuração Ativar TDPs geralmente é configurada quando você cria a conexão do Looker (consulte a página de documentação Dialetos do Looker para instruções sobre o dialeto do seu banco de dados), mas 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 PDTs

Para que o Looker ofereça suporte a PDTs no seu projeto do Looker, o dialeto do banco de dados também precisa oferecer.

Para oferecer suporte a qualquer tipo de PDT (com base em LookML ou SQL), o dialeto precisa ser compatível com gravações no banco de dados, entre outros requisitos. Há algumas configurações de banco de dados somente leitura que não permitem que a persistência funcione (mais comumente bancos de dados de réplica de troca a quente do Postgres). Nesses casos, use tabelas derivadas temporárias.

A tabela a seguir mostra os dialetos que oferecem suporte a tabelas derivadas persistentes com base em SQL na versão mais recente do Looker:

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

Criação incremental de TDPs

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

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

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

Dialetos de banco de dados compatíveis com PDTs incrementais

Para que o Looker seja compatível com PDTs incrementais no seu projeto do Looker, o dialeto do banco de dados também precisa ser compatível. A tabela a seguir mostra quais dialetos são compatíveis com PDTs incrementais na versão mais recente do Looker:

Como criar TDPs

Para transformar uma tabela derivada em uma tabela derivada persistente (TDP), defina uma estratégia de persistência para ela. Para otimizar o desempenho, adicione também 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 oferecem suporte a visualizações materializadas, pelo banco de dados usando visualizações materializadas.

Para tornar uma tabela derivada permanente, 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 acionadores (datagroup_trigger, sql_trigger_value e interval_trigger), o Looker mantém a PDT no banco de dados até que ela seja acionada para recriação. Quando o PDT é acionado, o Looker o 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.

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 PDT enquanto ela estiver sendo criada e os resultados da consulta não estiverem no cache, o Looker vai retornar dados da PDT atual até que a nova seja criada. Consulte Consultas de cache para uma visão geral dos grupos de dados.

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 PDT enquanto ela estiver sendo criada e os resultados da consulta não estiverem no cache, o Looker vai retornar dados da PDT 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

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

persist_for

Outra opção é usar o parâmetro persist_for para definir o período em que a tabela derivada deve ser armazenada antes de ser marcada como expirada. Assim, ela não será mais usada para consultas e será removida do banco de dados.

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

Depois do tempo persist_for, o Looker limpa a PDT do banco de dados, e ela é recriada na próxima vez que um usuário a consulta. Isso significa que a consulta precisa aguardar a recriação.

As PDTs que usam persist_for não são reconstruídas automaticamente pelo regenerador do Looker, exceto no caso de uma cascata de dependências de PDTs. Quando uma tabela persist_for faz parte de uma cascata de dependências com PDTs baseadas em gatilho (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

Com as visualizações materializadas, é possível usar a funcionalidade do banco de dados para manter tabelas derivadas no projeto do Looker. Se o dialeto do seu banco de dados aceitar visualizações materializadas e sua conexão do Looker estiver configurada com a opção Ativar TDPs ativada, você poderá 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 (PDT), uma visualização materializada é um resultado de consulta armazenado como uma tabela no esquema inicial do banco de dados. A principal diferença entre uma PDT e uma visualização materializada é a 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.
• Para visualizações materializadas, o banco de dados é responsável por manter e atualizar os dados na tabela.

Por isso, a funcionalidade de visualização materializada exige conhecimento avançado do seu dialeto e dos recursos dele. Na maioria dos casos, o banco de dados atualiza a visualização materializada sempre que detecta novos dados nas tabelas consultadas por ela. 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 permanentes (PDTs) são armazenadas no banco de dados, otimize-as usando as seguintes estratégias, conforme compatibilidade com seu dialeto:

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

Por exemplo, para adicionar persistência ao exemplo de tabela derivada, defina a reconstrução quando o grupo de dados orders_datagroup for acionado e adicione í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 seu dialeto), o Looker vai avisar que é preciso fazer isso para melhorar o desempenho da consulta.

Casos de uso para PDTs

As tabelas derivadas permanentes (PDTs, na sigla em inglês) são úteis porque podem melhorar a performance de uma consulta ao manter os resultados dela 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 mudar o tipo de dados de uma coluna pode resolver um problema sem a necessidade de criar um PDT. Analise os planos de execução de consultas lentas usando a ferramenta "Explicar do SQL Runner".

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

• Otimizações de teste
• Pré-junção ou agregação de dados

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

Como usar PDTs para testar otimizações

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

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

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

Para testar estratégias de otimização, use o parâmetro indexes para adicionar índices à 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 as consultas de teste e compare os resultados. Se os resultados forem favoráveis, peça ao DBA ou à equipe de ETL para adicionar os índices à tabela original.

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

Usar PDTs para pré-junção ou agregação de dados

Pode ser útil fazer pré-junção ou pré-agregação de 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.

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, você pode 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.

No exemplo a seguir, a PDT clean_events é criada com base na tabela events no banco de dados. O PDT clean_events omite linhas indesejadas da tabela de banco de dados events. Em seguida, um segundo PDT é mostrado. O PDT event_summary é um resumo do PDT clean_events. A tabela event_summary é regenerada sempre que novas linhas são adicionadas a clean_events.

As PDTs event_summary e clean_events são PDTs em cascata, em que event_summary depende de clean_events (já que event_summary é definida usando a PDT clean_events). Este exemplo específico poderia ser feito de maneira 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, quando você se refere a uma tabela derivada dessa maneira, geralmente é útil criar um alias para ela usando este formato:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

O exemplo anterior faz o seguinte:

${clean_events.SQL_TABLE_NAME} AS clean_events

É útil usar um alias porque, nos bastidores, as PDTs são nomeadas com códigos longos no 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 cuja definição contenha uma referência a TABLE_C, então TABLE_D será dependente 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 TABLE_D. Mas primeiro, ele precisa recriar o TABLE_C.

Considere um cenário com 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. Assim, o Looker vai criar TABLE_A, depois TABLE_B e, por fim, TABLE_C:

Nesse cenário, TABLE_A precisa terminar de gerar antes que o Looker possa começar a gerar TABLE_B, e TABLE_B precisa terminar de gerar antes que o Looker possa começar a gerar TABLE_C. Quando TABLE_C terminar, o Looker vai 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 PDTs em cascata que usam o mesmo grupo de dados.

A mesma lógica básica se aplica aos PDTs: o Looker vai criar qualquer tabela necessária para responder a uma consulta, até o final da cadeia de dependências. Mas com PDTs, geralmente as tabelas já existem e não precisam ser recriadas. Com consultas de usuário padrão em PDTs em cascata, o Looker recria as PDTs na cascata somente se não houver uma versão válida delas no banco de dados. Se quiser forçar uma recriação em cascata de todas as TDPs, recrie manualmente as tabelas de uma consulta em uma análise detalhada.

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

Reconstruir manualmente tabelas permanentes para uma consulta

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

Essa opção só aparece para usuários com permissão develop e depois que a consulta do recurso Detalhar é carregada.

A opção Recriar tabelas derivadas e executar recria todas as tabelas permanentes (todas as PDTs e tabelas agregadas) necessárias para responder à consulta, independente da estratégia de persistência. Isso inclui todas as tabelas agregadas e PDTs na consulta atual, bem como todas as tabelas agregadas e PDTs 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 as PDTs 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 PDTs incrementais para ver alguns exemplos de cenários que mostram como os PDTs incrementais são criados, dependendo da configuração.

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

Observações 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 vão usar as tabelas atuais. Depois que as tabelas persistentes forem recriadas, todos os usuários vão usar as tabelas recriadas. Embora esse processo seja projetado para evitar a interrupção das consultas de outros usuários enquanto as tabelas são recriadas, eles ainda podem ser afetados pela carga adicional no banco de dados. Se você estiver em uma situação em que acionar uma recriação durante o horário comercial pode sobrecarregar seu banco de dados de forma inaceitável, talvez seja necessário comunicar aos usuários que eles nunca devem recriar determinados PDTs ou tabelas agregadas durante esse período.

• Se um usuário estiver no Modo de Desenvolvimento e a análise detalhada for baseada em uma tabela de desenvolvimento, a operação Recriar e executar tabelas derivadas vai recriar a tabela de desenvolvimento, não a de produção, para a análise detalhada. Mas se a análise detalhada 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 persistentes no modo de desenvolvimento para informações sobre tabelas de desenvolvimento e de produção.

• Para instâncias hospedadas pelo Looker, se a tabela derivada levar mais de uma hora para ser recriada, ela não será recriada com êxito, 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 de 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 permanentes no modo de desenvolvimento.

Se você consultar uma tabela persistente no modo de desenvolvimento sem fazer mudanças na definição dela, o Looker vai consultar a versão de produção dessa tabela. Se você fizer uma mudança na definição da tabela que afete os dados nela ou a forma como ela é consultada, uma nova versão de desenvolvimento será criada na próxima vez que você consultar a tabela no modo de desenvolvimento. Com uma tabela de desenvolvimento, é possível testar mudanças sem incomodar os usuários.

O que faz o Looker criar uma tabela de desenvolvimento

Sempre que possível, o Looker usa a tabela de produção atual para responder às consultas, esteja você no modo de desenvolvimento ou não. No entanto, 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 tiver um parâmetro que restringe o conjunto de dados para trabalhar mais rápido no modo de desenvolvimento
• Se você fez mudanças na definição da 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 definida usando uma cláusula condicional WHERE com instruções if prod e if dev.

Para tabelas persistentes que não têm 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 ou a forma como ela é consultada.

Confira alguns exemplos de tipos de mudanças que fazem o Looker criar uma versão de desenvolvimento de uma tabela persistente. O Looker só cria a tabela se você fizer uma consulta depois de fazer essas mudanças:

• Mudar a consulta em que a tabela persistente se baseia, como modificar o parâmetro explore_source, sql, query, sql_create ou create_process na própria tabela persistente ou em qualquer tabela necessá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 da tabela
• Mudar o nome do view de uma tabela derivada
• Mudar o increment_key ou increment_offset de uma TDP incremental
• Mudar o connection usado pelo modelo associado

Para mudanças que não modificam os dados da tabela nem afetam a maneira como o Looker consulta a tabela, o Looker não cria uma tabela de desenvolvimento. 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 e, portanto, não vai criar uma tabela de desenvolvimento.

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

Independente da estratégia de persistência real da tabela, o Looker trata as tabelas persistentes de desenvolvimento como se 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 desordenem o banco de dados, o Looker aplica a estratégia persist_for: "24 hours" para garantir que as tabelas sejam limpas com frequência do banco de dados.

Caso contrário, o Looker vai criar tabelas derivadas persistentes (PDTs) e 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 ao implantar mudanças em uma PDT ou tabela agregada, o Looker poderá usar a tabela de desenvolvimento como a de produção. Assim, os usuários não precisam esperar que a tabela seja criada ao consultá-la.

Ao implantar as mudanças, talvez seja necessário recriar a tabela para que ela possa 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 dela será marcada como expirada e não será usada para consultas. É possível verificar PDTs não criadas usando o IDE do Looker ou a guia Desenvolvimento da página Tabelas derivadas permanentes. Se você tiver PDTs não criadas, poderá consultá-las no modo de desenvolvimento antes de fazer as mudanças para que a tabela de desenvolvimento fique disponível para uso na produção.
• Se uma tabela persistente tiver o parâmetro dev_filters (para tabelas derivadas nativas) ou a cláusula condicional WHERE 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, já que a versão de desenvolvimento tem um conjunto de dados abreviado. Se for esse o caso, depois de terminar de desenvolver a 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. O Looker vai criar uma versão completa da tabela que pode ser usada para 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 vai recriar a tabela na próxima vez que ela for consultada no modo de produção (para tabelas persistentes que usam a estratégia persist_for) ou na próxima vez que o regenerador for executado (para tabelas persistentes que usam datagroup_trigger, interval_trigger ou sql_trigger_value).

Verificar TDPs não criadas no Modo de Desenvolvimento

Se uma tabela de desenvolvimento for mantida no banco de dados ao implantar mudanças em uma tabela derivada permanente (PDT) ou em uma tabela de agregação, o Looker 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 ao consultá-la. Consulte as seções Por quanto tempo o Looker mantém as tabelas de desenvolvimento e O que faz o Looker criar uma tabela de desenvolvimento nesta página para mais detalhes.

Portanto, é ideal que todas as PDTs sejam criadas quando você implanta na produção para que as tabelas possam ser usadas imediatamente como as versões de produção.

Para verificar se há PDTs não criadas no seu projeto, acesse o painel Integridade do projeto. Clique no ícone Integridade do projeto no IDE do Looker para abrir o painel Integridade do projeto. Em seguida, clique no botão Validar status da TDP.

Se houver TDPs não criadas, o painel Integridade do projeto vai listá-las:

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

Depois de identificar uma TDP não criada no projeto, você pode criar uma versão de desenvolvimento dela abrindo uma análise detalhada que consulta a tabela e usando a opção Recriar e executar tabelas derivadas no menu "Analisar detalhadamente". Consulte a seção Reconstruir manualmente tabelas permanentes para uma consulta nesta página.

Compartilhamento e limpeza de tabelas

Em qualquer instância do Looker, o Looker compartilha tabelas persistentes entre 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 vai marcá-la como expirada.

Isso traz vários benefícios:

• Se você não fez nenhuma mudança em uma tabela no Modo de Desenvolvimento, suas consultas vão usar as tabelas de produção atuais. A menos que sua tabela seja uma tabela derivada baseada em SQL definida usando uma cláusula condicional WHERE com instruções if prod e if dev. Se a tabela for definida com uma cláusula condicional WHERE, o Looker vai criar uma tabela de desenvolvimento se você consultar a tabela no Modo de desenvolvimento. Para tabelas derivadas nativas com o parâmetro dev_filters, o Looker tem a lógica para usar a tabela de produção e 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 mudança em uma tabela no modo de desenvolvimento, eles vão compartilhar a mesma tabela de desenvolvimento.
• Depois que você envia as mudanças do modo de desenvolvimento para o modo de produção, a definição de produção antiga não existe mais. Por isso, a tabela de produção antiga é marcada como expirada e será descartada.
• Se você decidir descartar as mudanças do Modo de Desenvolvimento, essa definição de tabela não vai mais existir. Assim, as tabelas de desenvolvimento desnecessárias serão marcadas como expiradas e serão excluídas.

Trabalhar mais rápido no Modo de Desenvolvimento

Há situações em que a tabela derivada permanente (PDT) 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, você pode pedir ao Looker para criar versões menores de uma tabela derivada no modo de desenvolvimento.

Para tabelas derivadas nativas, use o subparâmetro dev_filters de explore_source para especificar filtros que são aplicados apenas à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 dos últimos 90 dias e um parâmetro filters que filtra os dados dos últimos dois anos e do 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 dev_filters e filters especificarem filtros para a mesma coluna, dev_filters terá precedência na 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 oferece suporte a uma cláusula condicional WHERE 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 vai 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. Usar esse recurso de forma estratégica para limitar o conjunto de resultados e aumentar a velocidade da consulta pode facilitar muito a validação das mudanças no modo de desenvolvimento.

Como o Looker cria TDPs

Depois que uma tabela derivada permanente (PDT) é definida e executada pela primeira vez ou acionada pelo regenerador para reconstrução de acordo com a estratégia de persistência, o Looker passa pelas seguintes etapas:

1. Use o SQL da tabela derivada para criar e executar uma instrução CREATE TABLE AS SELECT (ou CTAS). Por exemplo, para recriar uma PDT 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"), indicando que ela está pronta para uso.
4. Remova qualquer versão mais antiga da tabela que não deva mais ser usada.

Há algumas implicações importantes:

• O SQL que forma a tabela derivada precisa ser válido em 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 distribuição, chaves de classificação e índices precisam ser os nomes das colunas listados na definição SQL da tabela derivada, não os nomes dos campos definidos na LookML.

O regenerador do Looker

O regenerador do Looker verifica o status e inicia recriações para tabelas persistentes por gatilho. Uma tabela com gatilho permanente é uma tabela derivada persistente (PDT) ou uma tabela de agregação que usa um gatilho 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 uma recriação da tabela quando o resultado da verificação da consulta de gatilho mais recente é diferente do resultado da verificação anterior. Por exemplo, se a tabela derivada for persistida com a consulta SQL SELECT CURDATE(), o regenerador do Looker vai recriar a tabela na próxima vez que ele verificar o gatilho após a mudança de data.
• Para tabelas que usam interval_trigger, o gatilho é uma duração especificada no parâmetro interval_trigger da tabela. O regenerador do Looker aciona uma recriação da tabela quando o tempo especificado passa.
• Para tabelas que usam datagroup_trigger, o gatilho pode ser uma consulta especificada no parâmetro sql_trigger do grupo de dados associado ou uma duração especificada no parâmetro interval_trigger do grupo de dados.

O regenerador do Looker também inicia reconstruçõ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 persistente acionada. Nesse caso, o regenerador do Looker vai iniciar reconstruções para uma tabela persist_for, já que ela é necessária para reconstruir as outras tabelas em cascata. Caso contrário, o regenerador não monitora tabelas persistentes que usam a estratégia persist_for.

O ciclo do regenerador do Looker começa em um intervalo regular configurado pelo administrador do Looker na configuração Programação de manutenção da conexão de 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 reconstruções de PDT do último ciclo. Isso significa que, se você tiver builds de PDT de longa duração, o ciclo do regenerador do Looker poderá não ser executado com a frequência definida na configuração Programação de manutenção. Outros fatores podem afetar o tempo necessário para recriar as tabelas, conforme descrito na seção Considerações importantes para implementar tabelas persistentes 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 Tentar novamente builds de TDP com falha estiver ativada na conexão de banco de dados, o regenerador do Looker vai tentar recriar a tabela durante o próximo ciclo, mesmo que a condição de acionamento dela 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 persistente enquanto ela estiver sendo criada e os resultados da consulta não estiverem no cache, o Looker vai 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, o que pode acontecer se a nova tabela tiver uma definição diferente, usar uma conexão de banco de dados diferente ou ter sido criada com uma versão diferente do Looker. Se a tabela atual ainda for válida, o Looker vai retornar dados dela até que a nova seja criada. Caso contrário, se a tabela atual não for válida, o Looker vai fornecer resultados de consulta assim que a nova tabela for recriada.

Considerações importantes para implementar tabelas persistentes

Considerando a utilidade das tabelas persistentes (PDTs e tabelas agregadas), é fácil acumular muitas delas na sua instância do Looker. É possível criar um cenário em que o regenerador do Looker precisa criar muitas tabelas ao mesmo tempo. Principalmente com tabelas em cascata ou de longa duração, é possível criar um cenário em que as tabelas têm um longo atraso antes da reconstrução ou em que os usuários sofrem um atraso ao receber os resultados da consulta de uma tabela enquanto o banco de dados trabalha para gerar a tabela.

O regenerador do Looker verifica os gatilhos de TDP para saber se precisa recriar tabelas persistidas por gatilho. O ciclo do regenerador é definido em um intervalo regular configurado pelo administrador do Looker na configuração Programação de manutenção da conexão com o banco de dados. O padrão é um intervalo de cinco minutos.

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

• O administrador do Looker pode ter mudado o intervalo das verificações de acionamento do regenerador usando a configuração Programação de manutenção na conexão do banco de dados.
• O regenerador do Looker não inicia um novo ciclo até concluir todas as verificações e reconstruções de TDP do ciclo anterior. Portanto, se você tiver builds de PDT de longa duração, o ciclo do regenerador do Looker poderá não ser tão frequente quanto a configuração Programação de manutenção.
• Por padrão, o regenerador pode iniciar a reconstruçã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 criador de TDPs nas configurações de uma conexão.
• Todas as PDTs e tabelas agregadas acionadas pelo mesmo datagroup serão recriadas durante o mesmo processo de regeneração. Isso pode ser uma carga pesada se você tiver muitas tabelas usando o grupo de dados, diretamente ou como resultado de dependências em cascata.

Além das considerações anteriores, há também algumas situações em que você deve evitar adicionar persistência a uma tabela derivada:

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

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

Gerenciar TDPs em grande escala pela API

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

Monitoramento e solução de problemas de PDTs

Se você usa tabelas derivadas persistentes (PDTs), principalmente PDTs em cascata, é útil conferir o status delas. Use a página de administrador Tabelas derivadas permanentes do Looker para conferir o status das suas PDTs. Consulte a página de documentação Configurações de administrador - tabelas derivadas permanentes para mais informações.

Ao tentar resolver problemas de TDPs:

• Preste atenção especial à distinção entre tabelas de desenvolvimento e de produção ao investigar o registro de eventos da PDT.
• Verifique se não houve mudanças no esquema temporário em que o Looker armazena as PDTs. Se houver mudanças, talvez seja necessário atualizar as configurações de conexão na seção Administrador do Looker e reiniciar o Looker para restaurar a funcionalidade normal de PDT.
• Determine se há problemas com todas as TDPs ou apenas uma. Se houver um problema com um deles, a causa provavelmente será um erro de LookML ou 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 são avaliadas corretamente e retornam apenas uma linha e uma coluna. Para PDTs baseadas em SQL, execute-as no SQL Runner. (Aplicar um LIMIT protege contra consultas excessivas.) Para mais informações sobre como usar o SQL Runner para depurar tabelas derivadas, consulte a postagem da comunidade Como usar 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. 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). Usar 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 a fim de criar uma DT secundária e faça referência a ela na primeira DT usando a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME}.
• Verifique se todas as tabelas de que a TDP com problema depende (tabelas normais ou TDPs) existem e podem ser consultadas.
• Verifique se as tabelas de que a PDT com problema depende não têm bloqueios compartilhados ou exclusivos. Para que o Looker crie uma PDT, ele precisa adquirir um bloqueio exclusivo na tabela que precisa ser atualizada. Isso vai entrar em conflito com outros bloqueios compartilhados ou exclusivos que estão na tabela. O Looker não poderá atualizar a PDT até que todos os outros bloqueios sejam removidos. O mesmo vale para bloqueios exclusivos na tabela de que o Looker está criando 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 liberado.
• Use o botão Mostrar processos no SQL Runner. Se houver um grande número de processos ativos, isso poderá diminuir os tempos de consulta.
• Monitore os comentários na consulta. Consulte a seção Comentários de consulta para PDTs nesta página.

Consultar comentários para TDPs

Os administradores de banco de dados podem diferenciar facilmente as consultas normais daquelas que geram tabelas derivadas permanentes (PDTs, na sigla em inglês). O Looker adiciona comentários à instrução CREATE TABLE ... AS SELECT ... que inclui o modelo e a visualização da 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 precisar 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 da 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 houver uma versão válida dela.
• Se não houver uma TDP válida no banco de dados, o Looker vai tentar recriar a TDP.
• 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 PDTs 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.
• Uma TDP dependente consulta a TDP em que se baseia. Assim, a estratégia de persistência de uma tabela pode acionar recompilações das TDPs acima na cadeia.

Retomando 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:

1. Se TABLE_B for consultado, o Looker primeiro tentará usar o cache para retornar resultados.
2. Se essa tentativa falhar, o Looker tentará usar uma versão anterior da tabela, se possível.
3. Se essa tentativa também falhar, o Looker tentará recriar a tabela.
4. Por fim, se TABLE_B não puder ser recriado, o Looker vai retornar um erro.

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

O mesmo vale para os dependentes de TABLE_B. Portanto, se TABLE_B não puder ser criado e houver uma consulta em TABLE_C, a seguinte sequência vai ocorrer:

1. O Looker vai tentar usar o cache para a consulta em TABLE_C.
2. Se os resultados não estiverem no cache, o Looker vai tentar extrair resultados de TABLE_C no banco de dados.
3. 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.
4. O Looker vai tentar recriar TABLE_B, o que vai falhar se TABLE_B não tiver sido corrigido.
5. Se TABLE_B não puder ser recriado, TABLE_C também não poderá, e o Looker vai retornar um erro para a consulta em TABLE_C.
6. O Looker vai tentar reconstruir TABLE_C de acordo com a estratégia de persistência normal ou na próxima vez que a PDT for consultada (incluindo a próxima vez que TABLE_D tentar criar, já que TABLE_D depende de TABLE_C).

Depois de resolver o problema com TABLE_B, TABLE_B e cada uma das tabelas dependentes tentarão ser reconstruídas de acordo com as 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 das TDPs em cascata foi criada no Modo de desenvolvimento, essas versões poderão ser usadas como as novas TDPs de produção. Consulte a seção Tabelas persistentes no modo de desenvolvimento nesta página para saber como isso funciona. Ou você pode usar uma análise detalhada para executar uma consulta em TABLE_D e recriar manualmente as PDTs da consulta, o que vai forçar uma recriação de todas as PDTs na cascata de dependência.

Como melhorar a performance da TDP

Ao 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 qualquer tabela grande no banco de dados.

Para melhorar a performance, filtre os dados ou controle como os dados na PDT são classificados e indexados.

Adicionar filtros para limitar o conjunto de dados

Com conjuntos de dados muito grandes, ter muitas linhas vai diminuir a velocidade das consultas em uma tabela derivada permanente (PDT). Se você costuma consultar apenas dados recentes, adicione um filtro à cláusula WHERE da PDT que limite a tabela a 90 dias ou menos de dados. Assim, apenas os dados relevantes serão adicionados à tabela a cada reconstrução, e a execução de consultas será muito mais rápida. Em seguida, crie uma PDT separada e maior 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

Ao criar uma 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 o parâmetro indexes em campos de ID ou data.

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

Configurações recomendadas para melhorar a performance

As configurações a seguir controlam como os dados na tabela derivada permanente (PDT) são classificados e indexados. Estas 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 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 a E/S entre nós.
• 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 é usado com frequência 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 de maneira uniforme pelo cluster sem usar uma coluna de distribuição. Esse valor só pode ser especificado quando distribution não é 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.