Tabelas derivadas no Looker

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

Por exemplo, você pode ter uma tabela de banco de dados chamada orders que tem muitas colunas. Você quer calcular algumas métricas agregadas no nível do cliente, como quantos pedidos foram feitos por cliente ou quando ele fez o 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 inclua essas métricas.

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

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. No parâmetro derived_table, é possível definir a consulta para a tabela derivada de uma destas duas maneiras:

Por exemplo, os arquivos de visualização a seguir 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 é possível criar tabelas derivadas equivalentes usando LookML ou SQL para definir a consulta para a tabela derivada:

  • A tabela derivada nativa define a consulta com LookML no parâmetro explore_source. Neste exemplo, a consulta é baseada em uma visualização orders existente, que é definida em um arquivo separado que não é mostrado neste exemplo. A consulta explore_source na tabela derivada nativa contém os campos customer_id, first_order e total_amount do arquivo de visualização orders.
  • A tabela derivada baseada em SQL define a consulta usando SQL no parâmetro sql. Neste exemplo, a consulta SQL é uma consulta direta da tabela orders no banco de dados.
Versão de tabela derivada nativa 
view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}
Versão 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 do parâmetro derived_table e dos subparâmetros, essa visualização customer_order_summary funciona como qualquer outro arquivo de visualização. Ao definir a consulta da tabela derivada com o LookML ou com o SQL, você pode criar dimensões e dimensões do LookML baseadas nas colunas da tabela derivada.

Depois de definir a tabela derivada, use-a como qualquer outra tabela no banco de dados.

Tabelas nativas nativas

As tabelas derivadas nativas têm como base as consultas que você define usando termos do LookML. Para criar uma tabela derivada nativa, use o parâmetro explore_source dentro do parâmetro derived_table de um parâmetro 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 tabelas derivadas baseadas em SQL, as tabelas derivadas nativas são muito mais fáceis de ler e entender conforme você modela seus dados.

Consulte a página da 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 referenciar dimensões e medidas do LookML em uma tabela derivada baseada em SQL. Consulte o arquivo de visualização em tabela derivada baseado em SQL no exemplo anterior.

Geralmente, você define a consulta SQL usando o parâmetro sql dentro do parâmetro derived_table de um parâmetro 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 é compatível com os seguintes parâmetros para definir uma consulta SQL para PDTs (tabelas derivadas derivadas) permanentes:

  • create_process: quando você usa o parâmetro sql para uma PDT, o plano de fundo do Looker encapsula a CREATE TABLE declaração de linguagem de definição de dados (DDL, na sigla em inglês) da consulta para criar a PDT a partir da 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 TDP 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 o dialeto for compatível com DDL (por exemplo, o BigQuery ML preditivo do Google), será possível usar o parâmetro sql_create para criar um PDT em vez de usar o sql. Consulte a página da documentação do sql_create para ver informações e exemplos.

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

Ao definir uma tabela derivada baseada em SQL, atribua um alias limpo a cada coluna usando AS. Isso ocorre porque você precisará fazer referência aos nomes das colunas do conjunto de resultados nas suas 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 (PDTs)

Além da distinção entre as tabelas derivadas nativas e as 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 permanente (PDT, na sigla em inglês) (que é gravada em um esquema no seu 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 "Explorar" que envolve uma ou mais tabelas derivadas, o Looker constrói uma consulta SQL usando uma combinação específica de dialeto do SQL para as tabelas derivadas, além dos campos, junções e valores de filtro solicitados. Se a combinação já tiver sido executada antes e os resultados ainda forem válidos, o Looker usará os resultados armazenados em cache. Consulte a página de documentação Consultas de armazenamento 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 um bom desempenho e não sobrecarregam seu banco de dados. Nos casos em que a consulta demora um pouco 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 seja compatível com tabelas derivadas no projeto do Looker, o dialeto do banco de dados também precisa ser compatível com elas. A tabela a seguir mostra quais dialetos são compatíveis com tabelas derivadas na versão mais recente do Looker:

Tabelas derivadas permanentes (PDTs, na sigla em inglês)

Uma tabela derivada permanente (PDT, na sigla em inglês) é uma tabela derivada gravada em um esquema de rascunho no banco de dados e regenerada na programação que você especificar com uma estratégia de persistência.

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

Requisitos para TDPs

Para usar 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 nesta página para ver as listas de dialetos compatíveis com tabelas derivadas baseadas em SQL permanentes e tabelas derivadas nativas permanentes.
  • Um esquema de rascunho no seu banco de dados. Isso pode ser qualquer esquema no banco de dados, mas recomendamos a criação de 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. Isso geralmente é configurado quando você configura inicialmente a conexão do Looker (consulte a página de documentação Dialetos do Looker para ver instruções sobre seu dialeto do banco de dados), mas também é possível ativar PDTs para sua conexão após a configuração inicial.

Dialetos de banco de dados compatíveis com PDTs

Para que o Looker seja compatível com PDTs no projeto do Looker, o dialeto do banco de dados também precisa ser compatível.

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

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

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

Como criar PDTs de modo incremental

Uma PDT incremental é uma tabela derivada persistente (PDT, na sigla em inglês) que o Looker cria anexando novos dados à tabela em vez de recriá-la por completo.

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

Consulte a página de documentação de 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 projeto do Looker, o dialeto do banco de dados também precisa ser compatível com eles. A tabela a seguir mostra quais dialetos são compatíveis com PDTs incrementais na versão mais recente do Looker:

Como criar tabelas derivadas permanentes (PDTs, na sigla em inglês)

Para transformar uma tabela derivada em uma tabela derivada permanente (PDT, na sigla em inglês), defina uma estratégia de persistência para a tabela. 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, no caso de dialetos compatíveis com visualizações materializadas, pelo banco de dados usando visualizações materializadas.

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

Com estratégias de persistência baseadas em acionadores (datagroup_trigger, sql_trigger_value e interval_trigger), o Looker mantém a TDP no banco de dados até que a PDT seja acionada para a recriação. Quando a TDP é acionada, a Looker a recria para substituir a versão anterior. Isso significa que, com as PDTs baseadas em acionadores, os usuários não precisarão esperar para que a TDP seja criada a fim de receber respostas para as consultas Explorar da PDT.

datagroup_trigger

Grupos de dados são o método mais flexível para criar persistência. Se você tiver definido um grupo de dados com sql_trigger ou interval_trigger, poderá usar o parâmetro datagroup_trigger para iniciar a recriação dos seus PDTs.

O Looker mantém a TDP no banco de dados até que o grupo de dados seja acionado. Quando o grupo de dados é acionado, o Looker recria a TDP para substituir a versão anterior. Isso significa que, na maioria dos casos, os usuários não precisarão aguardar a criação do PDT. Se um usuário solicitar dados da PDT enquanto ela está sendo criada e os resultados da consulta não estiverem no cache, o Looker retornará dados da PDT atual até a criação da nova PDT. Consulte Consultas de armazenamento em 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 PDT com base em uma instrução SQL fornecida. Se o resultado da instrução SQL for diferente do valor anterior, o PDT será gerado novamente. Caso contrário, a TDP existente será mantida no banco de dados. Isso significa que, na maioria dos casos, os usuários não precisarão aguardar a criação do PDT. Se um usuário solicitar dados da PDT enquanto ela está sendo criada e os resultados da consulta não estiverem no cache, o Looker retornará dados da PDT atual até a criação da nova PDT.

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 TDP com base em um intervalo de tempo fornecido por você, como "24 hours" ou "60 minutes". Semelhante ao parâmetro sql_trigger, isso significa que geralmente a PDT será pré-criada quando os usuários a consultarem. Se um usuário solicitar dados da PDT enquanto ela está sendo criada e os resultados da consulta não estiverem no cache, o Looker retornará dados da PDT atual até a criação da nova PDT.

persist_for

No entanto, outra opção é usar o parâmetro persist_for para definir por quanto tempo a tabela derivada 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 TDP persist_for é 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 TDP dentro do tempo persist_for, o Looker usará os resultados em cache, se possível, ou executará a consulta na PDT.

Após persist_for, o Looker limpa a TDP do banco de dados, e ela é recriada na próxima vez que o usuário fizer uma consulta. Isso significa que a consulta precisa aguardar a recriação.

As PDTs que usam persist_for não são recriadas automaticamente pelo regenerador da Looker, exceto no caso de uma cascata de dependências. Quando uma tabela persist_for faz parte de uma cascata de dependência com PDTs baseados em gatilho (PDTs que usam a estratégia de persistência datagroup_trigger, interval_trigger ou sql_trigger_value), o regenerador vai monitorar e recriar 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

As visualizações materializadas permitem aproveitar a funcionalidade do banco de dados para manter as tabelas derivadas no projeto do Looker. Se o dialeto do seu banco de dados for compatível com visualizações materializadas e sua conexão do Looker estiver configurada com a opção Ativar PDTs 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, na sigla em inglês), uma visualização materializada é um resultado de consulta armazenado como uma tabela no esquema de rascunho do banco de dados. A principal diferença entre uma TDP e uma visualização materializada é a forma como as tabelas são atualizadas:

  • Para PDTs, a estratégia de persistência é definida no Looker, que é gerenciada pelo Looker.
  • Para visualizaçõ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 dos recursos dele. Na maioria dos casos, o banco de dados atualizará a visualização materializada sempre que detectar novos dados nas tabelas consultadas pela visualização materializada. As visualizações materializadas são ideais para cenários que exigem dados em tempo real.

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

Estratégias de otimização

Como as TDPs são armazenadas no banco de dados, é preciso otimizá-las usando as seguintes estratégias compatíveis com seu dialeto:

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

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

Se você não adicionar um índice (ou um equivalente no seu dialeto), o Looker avisará que isso precisa ser feito para melhorar o desempenho da consulta.

Casos de uso de TDPs

As TDPs são úteis porque podem melhorar o desempenho de uma consulta mantendo os resultados em uma tabela.

Como prática recomendada geral, os desenvolvedores devem tentar modelar dados sem usar PDTs 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 um PDT. Analise os planos de execução de consultas lentas usando a ferramenta de explicação 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 TDPs, incluindo:

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

Como usar TDPs para testar otimizações

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

Considere um caso em que você tem uma tabela, mas quer testar diferentes índices. 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 o parâmetro indexes para adicionar índices ao LookML desta forma:

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

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

Altere o código de visualização novamente para remover o PDT.

Como usar PDTs para pré-agrupar ou agregar dados

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

Por exemplo, suponha que você queira gerar relatórios de clientes por coorte com base em quando eles fizeram o primeiro pedido. Pode ser dispendioso executar essa consulta várias vezes sempre que os dados forem necessários em tempo real. No entanto, você pode calcular a consulta apenas uma vez e, em seguida, reutilizar os resultados com um 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 fazer referência a uma tabela derivada na definição de outra, criando uma cadeia de tabelas derivadas em cascata ou 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 tabela derivada, use esta sintaxe:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

Nesse formato, SQL_TABLE_NAME é uma string literal. Por exemplo, você pode fazer referência à 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. Novamente, nesse caso, o SQL_TABLE_NAME é uma string literal.

No próximo exemplo, a TDP clean_events é criada a partir da tabela events no banco de dados. O PDT clean_events exclui linhas indesejadas da tabela do banco de dados events. Em seguida, uma segunda PDT é mostrada. A PDT event_summary é um resumo da PDT clean_events. A tabela event_summary é regenerada sempre que novas linhas são adicionadas a clean_events.

O PDT event_summary e o PDT clean_events estão em cascata, em que event_summary depende de clean_events (já que event_summary é definido usando o PDT clean_events). Esse exemplo específico pode ser feito de forma mais eficiente em um único PDT, mas é útil para demonstrar as 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 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 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 no seu banco de dados. Em alguns casos (especialmente com cláusulas ON), é fácil esquecer que você precisa usar a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME} para recuperar esse nome longo. Um alias pode ajudar a evitar esse tipo de erro.

Como o Looker cria tabelas derivadas em cascata

No caso de cascata de tabelas derivadas temporárias, 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 de 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, a ferramenta recriará TABLE_D. Mas, primeiro, ele precisa recriar TABLE_C.

Agora vamos analisar um cenário em cascata de tabelas derivadas temporárias 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. Então, o Looker criará TABLE_A, depois TABLE_B e TABLE_C:

Nesse cenário, a TABLE_A precisa terminar de gerar antes que o Looker possa começar a gerar TABLE_B e assim por diante, até que TABLE_C seja concluído e o Looker possa fornecer os resultados da consulta. Como TABLE_D não é necessário para responder a essa consulta, o Looker não 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 a PDTs: o Looker criará qualquer tabela necessária para responder a uma consulta, até a cadeia de dependências. Mas com as TDPs, muitas vezes as tabelas já existem e não precisam ser recriadas. Com consultas de usuários padrão em PDTs em cascata, o Looker só recria as PDTs em cascata se não houver uma versão válida delas no banco de dados. Se você quiser forçar uma recriação de todos os TDPs em cascata, é possível reconstruir manualmente as tabelas para uma consulta em uma exploração.

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

Como recriar manualmente tabelas permanentes para uma consulta

Os usuários podem selecionar a opção Recriar tabelas derivadas e executar no menu "Explorar" para modificar as configurações de persistência e recriar todas as PDTs e tabelas de agregação necessárias para a consulta atual em "Explorar":

Clique no botão "Explorar ações" para abrir o menu "Explorar" e selecionar "Recriar tabelas derivadas" e "Executar".

Essa opção só é visível para usuários com permissão develop e depois que a consulta "Explorar" é carregada.

A opção Recriar tabelas derivadas e executar recria todas as tabelas persistentes (todas as PDTs e tabelas agregadas) necessárias para responder à consulta, independentemente da estratégia de persistência. Isso inclui quaisquer tabelas de agregação e PDTs na consulta atual, além de quaisquer tabelas de agregação e PDT referenciados pela tabela de consulta e PDT na consulta atual.

No caso de PDTs incrementais, a opção Recriar tabelas derivadas e gerar aciona a criação de um novo incremento. Com 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 elas são criadas, dependendo da configuração.

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

Se table_c depende de table_b, e table_b depende de table_a, então reconstruir table_c primeiro recria a tabela_a, depois a table_b e, por fim, a table_c.

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

  • Para o usuário que inicia a operação Recriar tabelas derivadas e executar, a consulta aguardará a recompilação das tabelas antes de carregar os resultados. As consultas de outros usuários continuarão usando as tabelas existentes. Depois que as tabelas persistentes forem recriadas, todos os usuários usarão as tabelas recriadas. Embora esse processo seja projetado para evitar a interrupção de consultas de outros usuários enquanto as tabelas são recriadas, esses usuários ainda podem ser afetados pela carga adicional em seu banco de dados. Se você estiver em uma situação em que o acionamento de uma recriação durante o horário comercial possa sobrecarregar seu banco de dados, talvez seja necessário comunicar aos usuários que eles nunca devem recriar algumas TDPs ou tabelas agregadas durante esse horário.

  • Se um usuário estiver no Modo de desenvolvimento e a exploração for baseada em uma tabela de desenvolvimento, a operação Reconstruir tabelas derivadas e execução recriará a tabela de desenvolvimento, e não a de produção, para a exploração. No entanto, se o Explorar no modo de desenvolvimento estiver usando a versão de produção de uma tabela derivada, a tabela de produção será recriada. Para mais informações sobre tabelas de desenvolvimento e de produção, consulte Tabelas persistentes no modo de desenvolvimento.

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

Tabelas persistentes no modo de desenvolvimento

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

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

O que solicita que o Looker crie uma tabela de desenvolvimento

Quando possível, o Looker usa a tabela de produção atual para responder a consultas, independentemente de você estar ou não no modo de desenvolvimento. No entanto, há alguns casos em que o Looker não pode usar a tabela de produção para consultas no modo de desenvolvimento:

O Looker 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 WHERE condicional 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ê altere a definição da tabela e depois consulte a tabela no modo de desenvolvimento. Isso se aplica a todas as alterações na tabela que afetam os dados ou à forma como a tabela é consultada.

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

Para alterações que não modifiquem os dados da tabela ou afetem a forma como a Looker consulta a tabela, a Looker não criará uma tabela de desenvolvimento. O parâmetro publish_as_db_view é um bom exemplo: no modo de desenvolvimento, se você alterar apenas a configuração publish_as_db_view para uma tabela derivada, o Looker não precisará recriar a tabela derivada, por isso, não criará uma tabela de desenvolvimento.

Por quanto tempo o Looker persiste em tabelas de desenvolvimento

Seja qual for a estratégia real de persistência da tabela, o Looker trata as tabelas persistentes de desenvolvimento como se elas tivessem uma estratégia de persistência de persist_for: "24 hours". O Looker faz isso para garantir que as tabelas de desenvolvimento não permaneçam por mais de um dia, porque um desenvolvedor do Looker pode consultar muitas iterações de uma tabela durante o desenvolvimento e sempre que uma nova tabela de desenvolvimento é criada. Para evitar que as tabelas de desenvolvimento bagunçam o banco de dados, o Looker aplica a estratégia persist_for: "24 hours" para garantir que elas sejam limpas com frequência.

Caso contrário, o Looker criará 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 mantida no seu banco de dados quando você implantar alterações em uma PDT ou em uma tabela agregada, o Looker poderá usá-la como a tabela de produção para que os usuários não precisem esperar pela criação quando consultarem a tabela.

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

  • Se já tiverem se passado mais de 24 horas desde que você consultou a tabela no modo de desenvolvimento, a versão de desenvolvimento da tabela estará marcada como expirada e não será usada para consultas. É possível verificar PDTs não criadas usando o ambiente de desenvolvimento integrado do Looker ou a guia Desenvolvimento da página Tabelas derivadas persistentes. Se você tiver PDTs não compilados, poderá consultá-los no modo de desenvolvimento antes de fazer as alterações para que a tabela de desenvolvimento esteja disponível para uso na produção.
  • Se uma tabela persistida tiver o parâmetro dev_filters (para tabelas derivadas nativas) ou a cláusula WHERE condicional que está usando 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 esse for o caso, depois de concluir o desenvolvimento da tabela e antes de implantar as alterações, será possível comentar o parâmetro dev_filters ou a cláusula condicional WHERE e consultar a tabela no modo de desenvolvimento. O Looker criará uma versão completa da tabela, que poderá ser usada na produção quando você implantar as alterações.

Caso contrário, se você implantar as alterações quando não houver uma tabela de desenvolvimento válida que possa ser usada como a de produção, o Looker a recriará na próxima vez em que a tabela for consultada no modo de produção (para tabelas persistidas 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 PDTs não criadas no modo de desenvolvimento

Se uma tabela de desenvolvimento for mantida no seu banco de dados quando você implantar alterações em uma PDT ou em uma tabela agregada, o Looker poderá usá-la como a tabela de produção para que os usuários não precisem esperar pela criação quando consultarem a tabela. Consulte as seções Por quanto tempo o Looker mantém tabelas de desenvolvimento e O que solicita ao Looker para criar uma tabela de desenvolvimento nesta página para mais detalhes.

Portanto, o ideal é que todos os PDTs sejam criados durante a implantação na produção. Assim, as tabelas poderão ser usadas imediatamente como versões de produção.

Verifique se há PDTs não criados no 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 Validate PDT Status.


Se houver PDTs não criados, eles serão listados pelo painel Integridade do projeto:

O painel "Integridade do projeto" mostra uma lista de PDTs não criados para o projeto e um botão "Ir para Gerenciamento de PDT".

Se você tiver a permissão see_pdts, clique no botão Go to PDT Management. O Looker abrirá a guia Desenvolvimento da página Persistent Derived Tables e filtrará os resultados para seu projeto específico do LookML. A partir daí, você pode ver quais TDPs de desenvolvimento são compilados e não criados e 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 um PDT não criado no projeto, você pode criar uma versão de desenvolvimento abrindo uma guia "Explorar" que consulta a tabela e usando a opção Recriar tabelas derivadas e executar no menu "Explorar". Consulte a seção Como recriar 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 os usuários se elas tiverem a mesma definição e 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 alterações em uma tabela no modo de desenvolvimento, as consultas usarão as tabelas de produção existentes. Esse é o caso, a menos que sua tabela seja uma tabela derivada baseada em SQL definida com uma cláusula WHERE condicional com instruções if prod e if dev. Se a tabela estiver definida com uma cláusula WHERE condicional, o Looker criará uma tabela de desenvolvimento se você a consultar no modo de desenvolvimento. Para tabelas derivadas nativas com o parâmetro dev_filters, o Looker tem a lógica de usar a tabela de produção para responder a consultas no modo de desenvolvimento, a menos que você 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 durante o Modo de desenvolvimento, eles compartilharão a mesma tabela de desenvolvimento.
  • Depois que você enviar as alterações do modo de desenvolvimento para o modo de produção, a definição de produção antiga não existirá mais e a tabela de produção antiga será marcada como expirada e será descartada.
  • Se você decidir descartar as alterações no Modo de desenvolvimento, a definição da tabela não existirá mais, portanto, as tabelas de desenvolvimento desnecessárias serão marcadas como expiradas e serão descartadas.

Como trabalhar mais rapidamente no modo de desenvolvimento

Existem situações em que a TDP que está criando leva muito tempo para ser gerada, o que poderá ser demorado, caso você esteja testando muitas mudanças no modo de desenvolvimento. Nesses casos, você pode solicitar que o Looker crie versões menores de uma tabela derivada quando estiver no modo de desenvolvimento.

Para tabelas derivadas nativas, é possível usar o subparâmetro dev_filters de explore_source para especificar filtros que são aplicados 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 dois 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 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.

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

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

Neste exemplo, a consulta incluirá todos os dados de 2000 em diante no modo de produção, mas apenas os dados de 2020 em diante no modo de desenvolvimento. O uso estratégico desse recurso para limitar o conjunto de resultados e aumentar a velocidade da consulta facilita a validação do modo de desenvolvimento.

Como o Looker cria TDPs

Depois que uma TDP é definida e executada pela primeira vez ou acionada pelo regenerador para reconstruir 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 um PDT chamado customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
  2. Emitir as instruções para criar os índices quando a tabela for criada
  3. Renomeie a tabela de LC$.. ("Looker Create") para LR$.. ("Looker Read") para indicar que a tabela está pronta para uso.
  4. Solte qualquer versão antiga da tabela que não esteja mais em uso

Há algumas implicações importantes:

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

Regenerador do Looker

O regenerador do Looker verifica o status e inicia a recriação de tabelas que não são acionadas pelo acionador. Uma tabela persistente do acionador é uma PDT ou uma tabela agregada que usa um acionador como uma 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 última verificação de consulta do acionador é diferente do resultado da verificação anterior. Por exemplo, se a tabela derivada persistir com a consulta SQL SELECT CURDATE(), o regenerador do Looker a recriará na próxima vez em que o regenerador verificar o acionador após a mudança da data.
  • Para tabelas que usam interval_trigger, o acionador é uma duração de tempo especificada no parâmetro interval_trigger da tabela. O regenerador do Looker aciona uma recriação da tabela após o período especificado.
  • Para tabelas que usam datagroup_trigger, o acionador pode ser uma consulta especificada no parâmetro sql_trigger do grupo de dados associado ou uma duração de tempo especificada no parâmetro interval_trigger do grupo de dados.

O regenerador do Looker também inicia recriações de 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 por gatilho. Nesse caso, o regenerador do Looker iniciará a criação de uma tabela persist_for, já que ela é necessária para recriar 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 do PDT e do grupo de dados na sua 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 as recriações de TDP do último ciclo. Isso significa que, se você tiver versões de TDP de longa duração, o ciclo de regeneração do Looker poderá não ser executado com a frequência definida na configuração Programação de manutenção de PDT e grupo de dados. Outros fatores podem afetar o tempo necessário para recriar as tabelas, conforme descrito na seção Considerações importantes sobre a implementação de tabelas persistentes nesta página.

Quando não é possível criar um PDT, o regenerador pode tentar recriar a tabela no próximo ciclo:

  • Se a configuração Nova tentativa de criação de TDPs estiver ativada na conexão do banco de dados, o regenerador do Looker tentará recriar a tabela durante o próximo ciclo, mesmo que a condição do acionador não seja atendida.
  • Se a configuração Repetir falhas de criação de TDP estiver desativada, o regenerador do Looker não tentará recriar a tabela até que a condição de acionamento da PDT seja atendida.

Se um usuário solicitar dados da tabela persistida enquanto ela estiver sendo criada e os resultados da consulta não estiverem no cache, o Looker verificará se a tabela ainda é válida. A tabela anterior pode não ser válida se não for compatível com a nova versão da tabela, o que pode acontecer se a nova tabela tiver uma definição diferente, se 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 atual ainda for válida, o Looker retornará dados da tabela atual até que a nova seja criada. Caso contrário, se a tabela atual não for válida, os resultados da consulta serão fornecidos pelo Looker 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. Especialmente com as tabelas em cascata, ou tabelas de longa duração, é possível criar um cenário em que as tabelas tenham um longo atraso antes da recriação ou em que os usuários enfrentam um atraso no recebimento de resultados de consulta de uma tabela enquanto o banco de dados está trabalhando duro para gerá-la.

O regenerador do Looker verifica os acionadores de TDP para ver se ele recria tabelas permanentes. O ciclo do regenerador é definido em um intervalo regular definido pelo administrador do Looker na configuração Programação de manutenção do PDT e do grupo de dados na sua conexão de banco de dados (o padrão é um intervalo de cinco minutos).

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

  • Seu administrador do Looker pode ter alterado o intervalo das verificações do acionador do regenerador usando a configuração Programação de manutenção do PDT e do grupo de dados na sua conexão de banco de dados.
  • O regenerador do Looker não inicia um novo ciclo até concluir todas as verificações e as recriações de TDP do último ciclo. Portanto, se você tiver builds de TDP de longa duração, o ciclo de regeneração do Looker poderá não ser tão frequente quanto a configuração Programação de manutenção do PDT e do grupo de dados.
  • Por padrão, o regenerador pode iniciar a recriação de uma tabela PDT ou 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 do PDT nas configurações de uma conexão.
  • Todas as TDPs e tabelas agregadas acionadas pelo mesmo datagroup serão recriadas durante o mesmo processo de regeneração. Essa 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 é necessário evitar a adição de persistência a uma tabela derivada:

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

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

Como gerenciar TDPs em grande escala com API

O monitoramento e o gerenciamento de TDPs que são atualizados em programações variadas se tornam cada vez mais complexos à medida que você cria mais TDPs na instância. Use a integração do Apache Airflow do Looker para gerenciar suas programações de TDP e outros processos ETL e ELT.

Como monitorar e solucionar problemas em TDPs

Se você usar PDTs, e especialmente em cascata, é útil ver o status deles. Você pode usar a página de administração de tabelas derivadas permanentes do Looker para ver o status dos seus PDTs. Consulte a página de documentação Configurações do administrador: tabelas derivadas permanentes para mais informações.

Ao tentar resolver problemas de TDPs:

  • Preste atenção especial na distinção entre tabelas de desenvolvimento e tabelas de produção ao investigar o Log de eventos de TDP.
  • Verifique se nenhuma mudança foi feita no esquema de rascunho em que o Looker armazena tabelas derivadas persistentes. Se você fez alterações, talvez seja necessário atualizar as configurações de Connection na seção Admin do Looker e, possivelmente, reiniciar o Looker para restaurar a funcionalidade normal do PDT.
  • Determine se há problemas com todos os PDTs ou apenas um. Se houver um problema com um deles, é provável que seja causado por um erro de LookML ou SQL.
  • Determine se os problemas com a TDP correspondem aos horários em que ela está programada para recriar.
  • Verifique se todas as consultas sql_trigger_value foram avaliadas e retornam apenas uma linha e coluna. Para PDTs com base em SQL, você pode fazer isso no SQL Runner. A aplicação de um LIMIT protege contra consultas descontroladas. Para mais informações sobre como usar o SQL Runner para depurar tabelas derivadas, consulte a postagem Como usar o sql executor para testar tabelas derivadas (em inglês).
  • 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 usar expressões de tabela comuns (CTEs, na sigla em inglês). O uso de CTEs com DTs cria instruções WITH aninhadas que podem fazer com que PDTs falhem sem aviso prévio. Em vez disso, use o SQL da CTE para criar uma DT secundária e faça referência à DT da primeira usando a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME}.
  • Verifique se existem tabelas das quais o problema PDT depende, sejam elas tabelas normais ou PDTs, e elas podem ser consultadas.
  • Verifique se as tabelas de que o problema depende não têm bloqueios compartilhados ou exclusivos. Para que o Looker crie um PDT com sucesso, ele precisa adquirir um bloqueio exclusivo na tabela a ser atualizado. Isso entrará em conflito com outros bloqueios compartilhados ou exclusivos que estão atualmente na tabela. O Looker só vai poder atualizar a PDT depois que todos os outros bloqueios forem apagados. O mesmo vale para todos os bloqueios exclusivos na tabela que o Looker está criando. A partir daí, 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 Show Processes no SQL Runner. Se houver um grande número de processos ativos, o tempo de consulta poderá ficar mais lento.
  • Monitore os comentários na consulta. Consulte a seção Consultar comentários sobre PDTs nesta página.

Comentários de consulta para TDPs

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

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

Como recriar PDTs após uma falha

Quando uma TDP tem falha, veja o que acontece quando ela é consultada:

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

Com PDTs em cascata, a mesma lógica se aplica, exceto com PDTs em cascata:

  • Uma falha de compilação para uma tabela impede a criação de PDTs na cadeia de dependências.
  • Uma PDT dependente está essencialmente consultando a PDT da qual depende, de modo que a estratégia de persistência de uma tabela pode acionar a recriação das PDTs que estão subindo na cadeia.

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

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

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

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

Depois de resolver o problema com TABLE_B, o TABLE_B e cada uma das tabelas dependentes tentarão se recriar de acordo com as estratégias de persistência ou na próxima vez que forem consultados, o que inclui a próxima tentativa de recriação de um PDT dependente. Ou, se uma versão de desenvolvimento dos PDTs na cascata tiver sido criada no modo de desenvolvimento, as versões de desenvolvimento poderão ser usadas como os novos PDTs de produção. Consulte a seção Tabelas persistentes no modo de desenvolvimento desta página para saber como isso funciona. Ou você pode usar uma exploração para executar uma consulta em TABLE_D e recriar manualmente os PDTs da consulta, o que forçará uma recriação de todos os PDTs que estão subindo na cascata de dependências.

Como melhorar o desempenho do PDT

Quando você cria PDTs, o desempenho pode ser uma preocupação. Principalmente quando a tabela é muito grande, a consulta pode ser lenta, assim como em qualquer tabela grande no banco de dados.

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

Como adicionar filtros para limitar o conjunto de dados

Com conjuntos de dados particularmente grandes, ter muitas linhas desacelera as consultas em um PDT. Se você geralmente consulta apenas dados recentes, adicione um filtro à cláusula WHERE da sua PDT que limite a tabela a 90 dias ou menos de dados. Dessa forma, apenas os dados relevantes serão adicionados à tabela sempre que ela for recriada, de modo que a execução de consultas será muito mais rápida. Em seguida, você pode criar um PDT separado e maior para análise histórica, permitindo consultas rápidas de dados recentes e a capacidade de consultar dados antigos.

Usando indexes ou sortkeys e distribution

Quando você cria um 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 nos campos de ID ou data.

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

As configurações a seguir controlam como os dados no 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 espalhar os dados em um cluster. Quando duas tabelas são mescladas pela coluna especificada no parâmetro distribution, o banco de dados pode encontrar os dados mesclados no mesmo nó para que a E/S entre nós seja minimizada.
  • Para o Redshift, defina o parâmetro distribution_style como all para instruir o banco de dados a manter uma cópia completa dos dados em cada nó. Isso geralmente é usado para minimizar a E/S entre nós quando tabelas fielmente pequenas são unidas. Defina esse valor como even para instruir o banco de dados a espalhar os dados de maneira uniforme pelo cluster sem usar uma coluna de distribuição. Este valor só pode ser especificado quando distribution não é especificado.
  • Para o Redshift, use o parâmetro sortkeys. Os valores especificam quais colunas da TDP são usadas para classificar os dados no disco para facilitar a pesquisa. No Redshift, é possível usar sortkeys ou indexes, mas não ambos. Exemplo:
* On most databases, use the [`indexes`](/reference/view-params/indexes) parameter. The values specify which columns of the PDT are indexed. (On Redshift, indexes are used to generate interleaved sort keys.)