Tabelas derivadas no Looker

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

Por exemplo, pode ter uma tabela de base de dados denominada orders com muitas colunas. Quer calcular algumas métricas agregadas ao nível do cliente, como o número de encomendas que cada cliente fez ou quando cada cliente fez a primeira encomenda. Usando uma tabela derivada nativa ou uma tabela derivada baseada em SQL, pode criar uma nova tabela de base de dados denominada customer_order_summary que inclua estas métricas.

Em seguida, pode trabalhar com a tabela derivada customer_order_summary como se fosse qualquer outra tabela na base de dados.

Para ver exemplos de utilização populares de tabelas derivadas, visite o artigo Looker cookbooks: Getting the most out of derived tables in Looker (Livros de receitas do Looker: tirar o máximo partido das tabelas derivadas no Looker).

Tabelas derivadas nativas e tabelas derivadas baseadas em SQL

Para criar uma tabela derivada no seu projeto do Looker, use o parâmetro derived_table num parâmetro view. No parâmetro derived_table, pode definir a consulta para a tabela derivada de uma das seguintes formas:

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

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

• A tabela derivada nativa define a consulta com LookML no parâmetro explore_source. Neste exemplo, a consulta baseia-se numa vista orders existente, que é definida num ficheiro separado que não é apresentado neste exemplo. A consulta explore_source na tabela derivada nativa importa os campos customer_id, first_order e total_amount do ficheiro de visualização orders.
• A tabela derivada baseada em SQL define a consulta através de SQL no parâmetro sql. Neste exemplo, a consulta SQL é uma consulta direta da tabela orders na base 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 ;;
  }
}

Ambas as versões criam uma vista denominada customer_order_summary baseada na tabela orders, com as colunas customer_id, first_order, e total_amount.

Além do parâmetro derived_table e dos respetivos subparâmetros, esta vista customer_order_summary funciona como qualquer outro ficheiro de visualização. Quer defina a consulta da tabela derivada com LookML ou com SQL, pode criar medidas e dimensões do LookML baseadas nas colunas da tabela derivada.

Depois de definir a tabela derivada, pode usá-la como qualquer outra tabela na base de dados.

Tabelas derivadas nativas

As tabelas derivadas nativas baseiam-se em consultas que define através de termos do LookML. Para criar uma tabela derivada nativa, usa o parâmetro explore_source no parâmetro derived_table de um parâmetro view. Cria as colunas da sua tabela derivada nativa referindo-se às dimensões ou medidas do LookML no seu modelo. Veja o ficheiro de visualização da 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 compreender à medida que modela os seus dados.

Consulte a página de documentação Criar tabelas derivadas nativas para ver detalhes sobre a criação de tabelas derivadas nativas.

Tabelas derivadas baseadas em SQL

Para criar uma tabela derivada baseada em SQL, define uma consulta em termos de SQL, criando colunas na tabela através de uma consulta SQL. Não pode fazer referência a dimensões e medidas do LookML numa tabela derivada baseada em SQL. Consulte o ficheiro de visualização da tabela derivada baseada em SQL no exemplo anterior.

Normalmente, define a consulta SQL através do parâmetro sql no 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 numa definição de tabela derivada.

Determinados casos extremos não permitem a utilização do parâmetro sql. Nestes casos, o Looker suporta os seguintes parâmetros para definir uma consulta SQL para tabelas derivadas persistentes (PDTs):

• create_process: quando usa o parâmetro sql para um PDT, em segundo plano, o Looker envolve a CREATE TABLE declaração de linguagem de definição de dados (LDD) do dialeto em torno da sua consulta para criar o PDT a partir da sua consulta SQL. Alguns dialetos não suportam uma declaração SQL CREATE TABLE num único passo. Para estes dialetos, não pode criar um PDT com o parâmetro sql. Em alternativa, pode usar o parâmetro create_process para criar um PDT em vários passos. Consulte a página de documentação do parâmetro create_process para ver informações e exemplos.
• sql_create: se o seu exemplo de utilização exigir comandos DDL personalizados e o seu dialeto suportar DDL (por exemplo, o BigQuery ML preditivo da Google), pode usar o parâmetro sql_create para criar um PDT em vez de usar o parâmetro sql. Consulte a página de documentação sql_create para ver informações e exemplos.

Quer esteja a usar o parâmetro sql, create_process ou sql_create, em todos estes casos, está a definir a tabela derivada com uma consulta SQL, pelo que todas são consideradas tabelas derivadas baseadas em SQL.

Quando define uma tabela derivada baseada em SQL, certifique-se de que atribui a cada coluna um alias simples através de AS. Isto deve-se ao facto de ter de fazer referência aos nomes das colunas do conjunto de resultados nas dimensões, como ${TABLE}.first_order. É por este motivo que o exemplo anterior usa MIN(DATE(time)) AS first_order em vez de simplesmente MIN(DATE(time)).

Tabelas derivadas temporárias e persistentes

Além da distinção entre tabelas derivadas nativas e tabelas derivadas baseadas em SQL, também existe uma distinção entre uma tabela derivada temporária, que não é escrita na base de dados, e uma tabela derivada persistente (PDT), que é escrita num esquema na sua base de dados.

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

Tabelas derivadas temporárias

As tabelas derivadas apresentadas anteriormente são exemplos de tabelas derivadas temporárias. São temporários porque não existe uma estratégia de persistência definida no parâmetro derived_table.

As tabelas derivadas temporárias não são escritas na base de dados. Quando um utilizador executa uma consulta de exploração 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, além dos campos pedidos, das junções e dos valores de filtro. Se a combinação tiver sido executada anteriormente e os resultados ainda forem válidos na cache, o Looker usa os resultados em cache. Consulte a página de documentação Colocar em cache as consultas para mais informações sobre a colocação em cache de consultas no Looker.

Caso contrário, se o Looker não puder usar resultados em cache, tem de executar uma nova consulta na sua base de dados sempre que um utilizador solicitar dados de uma tabela derivada temporária. Por este motivo, deve certificar-se de que as tabelas derivadas temporárias têm um bom desempenho e não exercem uma pressão excessiva na base de dados. Nos casos em que a consulta demora algum tempo a ser executada, um PDT é, muitas vezes, uma melhor opção.

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

Para que o Looker suporte tabelas derivadas no seu projeto do Looker, o dialeto da base de dados também tem de as suportar. A tabela seguinte mostra os dialetos que suportam tabelas derivadas na versão mais recente do Looker:

Tabelas derivadas persistentes

Uma tabela derivada persistente (PDT) é uma tabela derivada que é escrita num esquema temporário na sua base de dados e regenerada na programação que especifica 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, precisa do seguinte:

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

• Um esquema temporário na sua base de dados. Pode ser qualquer esquema na sua base de dados, mas recomendamos que crie um novo esquema que seja usado apenas para este fim. O administrador da base de dados tem de configurar o esquema com autorização de escrita para o utilizador da base de dados do Looker.

• Uma associação do Looker configurada com o botão Ativar PDTs ativado. Esta definição Ativar PDTs é normalmente configurada quando configura inicialmente a sua ligação ao Looker (consulte a página de documentação Dialetos do Looker para obter instruções para o dialeto da sua base de dados), mas também pode ativar as PDTs para a sua ligação após a configuração inicial.

Dialetos de base de dados suportados para PDTs

Para que o Looker suporte PDTs no seu projeto do Looker, o dialeto da base de dados também tem de os suportar.

Para suportar qualquer tipo de PDTs (com base em LookML ou SQL), o dialeto tem de suportar gravações na base de dados, entre outros requisitos. Existem algumas configurações de base de dados só de leitura que não permitem que a persistência funcione (mais frequentemente, bases de dados de réplicas de troca a quente do Postgres). Nestes casos, pode usar tabelas derivadas temporárias.

A tabela seguinte mostra os dialetos que suportam tabelas derivadas baseadas em SQL persistentes na versão mais recente do Looker:

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

Compilar PDTs de forma incremental

Uma PDT incremental é uma tabela derivada persistente que o Looker cria anexando dados atualizados à tabela em vez de a reconstruir na totalidade.

Se o seu dialeto suportar PDTs incrementais e a sua PDT usar uma estratégia de persistência baseada em acionadores (datagroup_trigger, sql_trigger_value ou interval_trigger), pode definir a PDT como uma PDT incremental.

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

Dialetos de base de dados suportados para PDTs incrementais

Para que o Looker suporte PDTs incrementais no seu projeto do Looker, o dialeto da base de dados também tem de os suportar. A tabela seguinte mostra os dialetos que suportam PDTs incrementais na versão mais recente do Looker:

Criar PDTs

Para transformar uma tabela derivada numa tabela derivada persistente (PDT), define uma estratégia de persistência para a tabela. Para otimizar o desempenho, também deve adicionar uma estratégia de otimização.

Estratégias de persistência

A persistência de uma tabela derivada pode ser gerida pelo Looker ou, para dialetos que suportam vistas materializadas, pela sua base de dados através de vistas materializadas.

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

• Parâmetros de persistência geridos pelo Looker:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• Parâmetros de persistência geridos pela base de dados:
  • materialized_view: yes

Com as estratégias de persistência baseadas em acionadores (datagroup_trigger, sql_trigger_value e interval_trigger), o Looker mantém o PDT na base de dados até que o PDT seja acionado para reconstrução. Quando a PDT é acionada, o Looker recompila a PDT para substituir a versão anterior. Isto significa que, com os PDTs baseados em acionadores, os utilizadores não têm de esperar que o PDT seja criado para receber respostas a consultas de exploração do PDT.

datagroup_trigger

Os grupos de dados são o método mais flexível de criar persistência. Se tiver definido um datagroup com sql_trigger ou interval_trigger, pode usar o parâmetro datagroup_trigger para iniciar a reconstrução das suas tabelas derivadas persistentes (PDTs).

O Looker mantém a PDT na base de dados até que o respetivo grupo de dados seja acionado. Quando o grupo de dados é acionado, o Looker recompila a PDT para substituir a versão anterior. Isto significa que, na maioria dos casos, os seus utilizadores não têm de esperar que o PDT seja criado. Se um utilizador pedir dados do PDT enquanto este está a ser criado e os resultados da consulta não estiverem na cache, o Looker devolve dados do PDT existente até que o novo PDT seja criado. Consulte o artigo Colocar consultas em cache para ver uma vista geral dos grupos de dados.

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

sql_trigger_value

O parâmetro sql_trigger_value aciona a regeneração de uma tabela derivada persistente (PDT) baseada numa declaração SQL que fornecer. Se o resultado da declaração SQL for diferente do valor anterior, a PDT é regenerada. Caso contrário, a PDT existente é mantida na base de dados. Isto significa que, na maioria dos casos, os seus utilizadores não têm de esperar que o PDT seja criado. Se um utilizador pedir dados do PDT enquanto este está a ser criado e os resultados da consulta não estiverem na cache, o Looker devolve dados do PDT existente até que o novo PDT seja criado.

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

interval_trigger

O parâmetro interval_trigger aciona a regeneração de uma tabela derivada persistente (PDT) com base num intervalo de tempo que indicar, como "24 hours" ou "60 minutes". Semelhante ao parâmetro sql_trigger, isto significa que, normalmente, o PDT é pré-criado quando os utilizadores o consultam. Se um utilizador pedir dados do PDT enquanto este está a ser criado e os resultados da consulta não estiverem na cache, o Looker devolve dados do PDT existente até que o novo PDT seja criado.

persist_for

Outra opção é usar o parâmetro persist_for para definir o período durante o qual a tabela derivada deve ser armazenada antes de ser marcada como expirada, para que deixe de ser usada para consultas e seja eliminada da base de dados.

Uma persist_fortabela derivada persistente (PDT) é criada quando um utilizador executa uma consulta pela primeira vez. Em seguida, o Looker mantém o PDT na base de dados durante o período especificado no parâmetro persist_for do PDT. Se um utilizador consultar a PDT dentro do período de persist_for, o Looker usa os resultados em cache, se possível, ou executa a consulta na PDT.

Após o tempo persist_for, o Looker limpa a PDT da sua base de dados e a PDT é reconstruída da próxima vez que um utilizador a consultar, o que significa que a consulta tem de aguardar a reconstruçã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 acionadores (PDTs que usam a estratégia de persistência datagroup_trigger, interval_trigger ou sql_trigger_value), o regenerador monitoriza e recompila a tabela persist_for para recompilar outras tabelas na cascata. Consulte a secção Como o Looker cria tabelas derivadas em cascata nesta página.

materialized_view: yes

As vistas materializadas permitem-lhe usar a funcionalidade da sua base de dados para persistir tabelas derivadas no seu projeto do Looker. Se o dialeto da sua base de dados suportar vistas materializadas e a sua associação do Looker estiver configurada com o botão Ativar PDTs ativado, pode criar uma vista materializada especificando materialized_view: yes para uma tabela derivada. As visualizações materializadas são suportadas para tabelas derivadas nativas e tabelas derivadas baseadas em SQL.

Semelhante a uma tabela derivada persistente (PDT), uma vista materializada é um resultado de consulta que é armazenado como uma tabela no esquema temporário da sua base de dados. A principal diferença entre um PDT e uma vista materializada reside na forma como as tabelas são atualizadas:

• Para PDTs, a estratégia de persistência é definida no Looker e a persistência é gerida pelo Looker.
• Para as vistas materializadas, a base de dados é responsável pela manutenção e atualização dos dados na tabela.

Por este motivo, a funcionalidade de visualização materializada requer conhecimentos avançados do seu dialeto e das respetivas funcionalidades. Na maioria dos casos, a base de dados atualiza a vista materializada sempre que deteta novos dados nas tabelas consultadas pela vista materializada. As vistas materializadas são ideais para cenários que requerem dados em tempo real.

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

Estratégias de otimização

Uma vez que as tabelas derivadas persistentes (PDTs) são armazenadas na sua base de dados, deve otimizar as PDTs através das seguintes estratégias, conforme suportado pelo seu dialeto:

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

Por exemplo, para adicionar persistência ao exemplo de tabela derivada, pode defini-lo para ser reconstruído quando o grupo de dados orders_datagroup for acionado e adicionar índices em customer_id e first_order, da seguinte forma:

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

Se não adicionar um índice (ou um equivalente para o seu dialeto), o Looker avisa que o deve fazer para melhorar o desempenho das consultas.

Exemplos de utilização de PDTs

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

Como prática recomendada geral, os programadores devem tentar modelar os 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 ter de criar um PDT. Certifique-se de que analisa os planos de execução de consultas lentas através da ferramenta Explain from SQL Runner.

Além de reduzir o tempo de consulta e a carga da base de dados em consultas realizadas com frequência, existem vários outros exemplos de utilização para PDTs, incluindo:

• Testar otimizações
• Pré-associação ou agregação de dados

Também pode usar um PDT para definir uma chave principal nos casos em que não existe uma forma razoável de identificar uma linha única numa tabela como chave principal.

Usar PDTs para testar otimizações

Pode usar PDTs para testar diferentes opções de indexação, distribuições e outras opções de otimização sem precisar de muito apoio técnico do seu DBA ou programadores de ETL.

Considere um caso em que tem uma tabela, mas quer testar diferentes índices. O LookML inicial da vista pode ter o seguinte aspeto:

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

Para testar estratégias de otimização, pode usar o parâmetro indexes para adicionar índices ao LookML da seguinte 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]
  }
}

Consultar a vista uma vez para gerar o PDT. Em seguida, execute as consultas de teste e compare os resultados. Se os resultados forem favoráveis, pode pedir ao DBA ou à equipa de ETL para adicionar os índices à tabela original.

Lembre-se de alterar novamente o código de visualização para remover o PDT.

Usar PDTs para pré-associar ou agregar dados

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

Por exemplo, suponhamos que quer criar uma consulta para clientes por coorte com base na data em que fizeram a primeira encomenda. Esta consulta pode ser dispendiosa para executar várias vezes sempre que os dados forem necessários em tempo real. No entanto, 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 tabelas derivadas persistentes (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 noutra tabela derivada, use esta sintaxe:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

Neste formato, SQL_TABLE_NAME é uma string literal. Por exemplo, pode fazer referência à tabela derivada clean_events com esta sintaxe:

`${clean_events.SQL_TABLE_NAME}`

Pode usar esta mesma sintaxe para se referir a uma vista do LookML. Mais uma vez, neste caso, SQL_TABLE_NAME é uma string literal.

No exemplo seguinte, a clean_events PDT é criada a partir da tabela events na base de dados. O clean_events PDT exclui linhas indesejadas da tabela da base de dados events. Em seguida, é apresentada uma segunda PDT. A PDT event_summary é um resumo da PDT clean_events. A tabela event_summary é regenerada sempre que são adicionadas novas linhas a clean_events.

A PDT event_summary e a PDT clean_events são PDTs em cascata, em que event_summary depende de clean_events (uma vez que event_summary é definida através da PDT clean_events). Este exemplo específico pode ser feito de forma mais eficiente num único 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 se refere a uma tabela derivada desta forma, é frequentemente útil criar um alias para a tabela através deste 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 têm nomes com códigos longos na sua base de dados. Em alguns casos (especialmente com cláusulas ON), é fácil esquecer que tem de usar a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME} para obter este nome longo. Um alias pode ajudar a evitar este 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 utilizador não estiverem na cache, o Looker cria todas as tabelas derivadas necessárias para a consulta. Se tiver um TABLE_D cuja definição contém uma referência a TABLE_C, então TABLE_D é dependente de TABLE_C. Isto significa que, se consultar TABLE_D e a consulta não estiver na cache do Looker, o Looker vai reconstruir TABLE_D. No entanto, primeiro, tem de recriar a app 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 na cache, o Looker cria todas as tabelas necessárias para a consulta. Assim, o Looker cria TABLE_A, depois TABLE_B e, por fim, TABLE_C:

Neste cenário, TABLE_A tem de terminar a geração antes de o Looker poder começar a gerar TABLE_B e TABLE_B tem de terminar a geração antes de o Looker poder começar a gerar TABLE_C. Quando TABLE_C terminar, o Looker apresenta os resultados da consulta. (Uma vez que o TABLE_D não é necessário para responder a esta consulta, o Looker não vai reconstruir o TABLE_D neste momento.)

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

A mesma lógica básica aplica-se às PDTs: o Looker cria qualquer tabela necessária para responder a uma consulta, até ao fim da cadeia de dependências. No entanto, com as PDTs, é frequente que as tabelas já existam e não precisem de ser recriadas. Com consultas de utilizadores padrão em PDTs em cascata, o Looker recompila os PDTs na cascata apenas se não existir uma versão válida dos PDTs na base de dados. Se quiser forçar uma recompilação para todas as PDTs numa cascata, pode recompilar manualmente as tabelas para uma consulta através de uma exploração.

Um ponto lógico importante a compreender é que, no caso de uma cascata de PDTs, uma PDT dependente está essencialmente a consultar a PDT da qual depende. Isto é significativo, especialmente para os PDTs que usam a estratégia persist_for. Normalmente, as persist_for PDTs são criadas quando um utilizador consulta as mesmas, permanecem na base de dados até o respetivo intervalo persist_for terminar e, em seguida, não são recriadas até serem consultadas novamente por um utilizador. No entanto, se uma PDT persist_for fizer parte de uma cascata com PDTs baseadas em acionadores (PDTs que usam a estratégia de persistência datagroup_trigger, interval_trigger ou sql_trigger_value), a PDT persist_for é essencialmente consultada sempre que as respetivas PDTs dependentes são reconstruídas. Assim, neste caso, a PDT persist_for é recompilada de acordo com o horário das respetivas PDTs dependentes. Isto significa que persist_foras PDTs podem ser afetadas pela estratégia de persistência das respetivas dependentes.

Reconstruir manualmente tabelas persistentes para uma consulta

Os utilizadores podem selecionar a opção Recompilar tabelas derivadas e executar no menu de um Explore para substituir as definições de persistência e recompilar todas as tabelas derivadas persistentes (PDTs) e as tabelas de agregação necessárias para a consulta atual no Explore:

Esta opção só é visível para utilizadores com a autorização develop e apenas depois de a consulta Explorar ter sido carregada.

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

No caso de PDTs incrementais, a opção Recompilar tabelas derivadas e executar aciona a compilação de um novo incremento. Com os 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 existir. Consulte a página de documentação PDTs incrementais para ver alguns exemplos de cenários que mostram como as PDTs incrementais são criadas, consoante a respetiva configuração.

No caso de PDTs em cascata, isto significa reconstruir todas as tabelas derivadas na cascata, começando pela parte superior. Este é o mesmo comportamento que quando consulta uma tabela numa cascata de tabelas derivadas temporárias:

Tenha em atenção o seguinte acerca da recompilação manual de tabelas derivadas:

• Para o utilizador que inicia a operação Recompilar tabelas derivadas e executar, a consulta aguarda a recompilação das tabelas antes de carregar os resultados. As consultas de outros utilizadores continuam a usar as tabelas existentes. Assim que as tabelas persistentes forem reconstruídas, todos os utilizadores vão usar as tabelas reconstruídas. Embora este processo seja concebido para evitar a interrupção das consultas de outros utilizadores enquanto as tabelas estão a ser reconstruídas, esses utilizadores podem continuar a ser afetados pela carga adicional na sua base de dados. Se estiver numa situação em que o acionamento de uma recompilação durante o horário de funcionamento possa exercer uma pressão inaceitável na sua base de dados, pode ter de comunicar aos seus utilizadores que nunca devem recompilar determinados PDTs ou tabelas agregadas durante esse horário.

• Se um utilizador estiver no modo de programação e a exploração se basear numa tabela de programação, a operação Recompilar tabelas derivadas e executar recompila a tabela de programação, e não a tabela de produção, para a exploração. No entanto, se o Explore no modo de programação estiver a usar a versão de produção de uma tabela derivada, a tabela de produção é recompilada. Consulte o artigo Tabelas persistentes no modo de programação para ver informações sobre tabelas de desenvolvimento e tabelas de produção.

• Para instâncias alojadas no Looker, se a tabela derivada demorar mais de uma hora a ser recompilada, a tabela não é recompilada com êxito e a sessão do navegador excede o limite de tempo. Consulte a secção Tempos limite de consulta e colocação em fila na página de documentação Definições de administração – Consultas para ver mais informações sobre os tempos limite que podem afetar os processos do Looker.

Tabelas persistentes no modo de programação

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

Se consultar uma tabela persistente no modo de programação sem fazer alterações à respetiva definição, o Looker consulta a versão de produção dessa tabela. Se fizer uma alteração à definição da tabela que afete os dados na tabela ou a forma como a tabela é consultada, é criada uma nova versão de desenvolvimento da tabela da próxima vez que consultar a tabela no modo de desenvolvimento. Ter uma tabela de desenvolvimento deste tipo permite-lhe testar alterações sem perturbar os utilizadores.

O que leva o Looker a criar uma tabela de programação

Sempre que possível, o Looker usa a tabela de produção existente para responder a consultas, quer esteja ou não no modo de programação. No entanto, existem determinados casos em que o Looker não pode usar a tabela de produção para consultas no modo de programação:

• Se a sua tabela persistente tiver um parâmetro que restrinja o respetivo conjunto de dados para funcionar mais rapidamente no modo de desenvolvimento
• Se fez alterações à definição da sua tabela persistente que afetam os dados na tabela

O Looker cria uma tabela de desenvolvimento se estiver no modo de desenvolvimento e consultar uma tabela derivada baseada em SQL definida através de uma cláusula condicional WHERE com declaraçõ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 programação, o Looker usa a versão de produção da tabela para responder a consultas no modo de programação, a menos que altere a definição da tabela e depois consulte a tabela no modo de programação. Isto aplica-se a quaisquer alterações à tabela que afetem os dados na tabela ou a forma como a tabela é consultada.

Seguem-se alguns exemplos dos tipos de alterações que pedem ao Looker para criar uma versão de desenvolvimento de uma tabela persistente (o Looker cria a tabela apenas se consultar posteriormente a tabela depois de fazer estas alterações):

• Alterar a consulta na qual 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)
• Alterar 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
• Alterar o nome do view de uma tabela derivada
• Alterar o increment_key ou o increment_offset de um PDT incremental
• Alterar o connection usado pelo modelo associado

Para alterações que não modificam os dados da tabela nem afetam a forma como o Looker consulta a tabela, o Looker não cria uma tabela de desenvolvimento. O parâmetro publish_as_db_view é um bom exemplo: no modo de programação, se alterar apenas a definição publish_as_db_view de uma tabela derivada, o Looker não precisa de recompilar a tabela derivada e, por isso, não cria uma tabela de programação.

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

Independentemente da estratégia de persistência real da tabela, o Looker trata as tabelas persistentes de desenvolvimento como se tivessem uma estratégia de persistência de persist_for: "24 hours". O Looker faz isto para garantir que as tabelas de desenvolvimento não são mantidas durante mais de um dia, uma vez que um programador 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 desordenem a base de dados, o Looker aplica a estratégia persist_for: "24 hours" para garantir que as tabelas são limpas frequentemente da base de dados.

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

Se uma tabela de desenvolvimento for mantida na sua base de dados quando implementa alterações numa PDT ou numa tabela agregada, o Looker pode, muitas vezes, usar a tabela de desenvolvimento como a tabela de produção para que os seus utilizadores não tenham de esperar que a tabela seja criada quando consultam a tabela.

Tenha em atenção que, quando implementa as alterações, a tabela pode ter de ser reconstruída para ser consultada em produção, consoante a situação:

• Se tiverem passado mais de 24 horas desde que consultou a tabela no modo de desenvolvimento, a versão de desenvolvimento da tabela é etiquetada como expirada e não é usada para consultas. Pode verificar se existem PDTs não criadas através do IDE do Looker ou do separador Desenvolvimento da página Tabelas derivadas persistentes. Se tiver PDTs não compilados, pode consultá-los no modo de programação imediatamente antes de fazer as alterações para que a tabela de desenvolvimento esteja disponível para utilização em produção.
• Se uma tabela persistente tiver o parâmetro dev_filters (para tabelas derivadas nativas) ou a cláusula conditional WHERE que usa as declarações if prod e if dev (para tabelas derivadas baseadas em SQL), não é possível usar a tabela de desenvolvimento como a versão de produção, uma vez que a versão de desenvolvimento tem um conjunto de dados abreviado. Se for este o caso, depois de terminar o desenvolvimento da tabela e antes de implementar as alterações, pode comentar o parâmetro dev_filters ou a cláusula condicional WHERE e, em seguida, consultar a tabela no modo de programação. Em seguida, o Looker cria uma versão completa da tabela que pode ser usada para produção quando implementar as alterações.

Caso contrário, se implementar as alterações quando não existir uma tabela de desenvolvimento válida que possa ser usada como tabela de produção, o Looker vai reconstruir a tabela na próxima vez que a tabela for consultada no modo de produção (para tabelas persistentes que usam a estratégia persist_for) ou na próxima vez que o regenerador for executado (para tabelas persistentes que usam datagroup_trigger, interval_trigger ou sql_trigger_value).

Verificar PDTs não compiladas no modo de programação

Se uma tabela de desenvolvimento for mantida na sua base de dados quando implementa alterações numa tabela derivada persistente (PDT) ou numa tabela agregada, o Looker pode, muitas vezes, usar a tabela de desenvolvimento como a tabela de produção para que os seus utilizadores não tenham de esperar que a tabela seja criada quando a consultam. Consulte as secções Durante quanto tempo o Looker mantém as tabelas de desenvolvimento e O que leva o Looker a criar uma tabela de desenvolvimento nesta página para ver mais detalhes.

Por conseguinte, é ideal que todos os PDTs sejam criados quando fizer a implementação para produção, para que as tabelas possam ser usadas imediatamente como as versões de produção.

Pode verificar se existem PDTs não criadas no seu projeto no painel Estado do projeto. Clique no ícone Estado do projeto no IDE do Looker para abrir o painel Estado do projeto. Em seguida, clique no botão Validar estado das PDTs.

Se existirem PDTs não compiladas, o painel Estado do projeto apresenta-as:

Se tiver autorização see_pdts, pode clicar no botão Aceder à gestão de PDTs. O Looker abre o separador Development da página Tabelas derivadas persistentes e filtra os resultados para o seu projeto LookML específico. A partir daí, pode ver que PDTs de desenvolvimento estão criados e não criados, bem como aceder a outras informações de resolução de problemas. Consulte a página de documentação Definições de administrador – Tabelas derivadas persistentes para mais informações.

Depois de identificar um PDT não compilado no seu projeto, pode compilar uma versão de desenvolvimento abrindo um Explore que consulte a tabela e, em seguida, usando a opção Recompilar tabelas derivadas e executar no menu Explorar. Consulte a secção Reconstruir manualmente tabelas persistentes para uma consulta nesta página.

Partilha e limpeza de tabelas

Em qualquer instância do Looker, o Looker partilha tabelas persistentes entre utilizadores se as tabelas tiverem a mesma definição e a mesma definição do método de persistência. Além disso, se a definição de uma tabela deixar de existir, o Looker marca a tabela como expirada.

Isto tem várias vantagens:

• Se não tiver feito alterações a uma tabela no modo de programação, as suas consultas usam as tabelas de produção existentes. Este é o caso, a menos que a sua tabela seja uma tabela derivada baseada em SQL definida através de uma cláusula condicional WHERE com declarações if prod e if dev. Se a tabela estiver definida com uma cláusula WHERE condicional, o Looker cria uma tabela de desenvolvimento se 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 para responder a consultas no modo de programação, a menos que altere a definição da tabela e, em seguida, consulte a tabela no modo de programação.)
• Se dois programadores fizerem a mesma alteração a uma tabela no modo de desenvolvimento, partilham a mesma tabela de desenvolvimento.
• Depois de enviar as alterações do modo de programação para o modo de produção, a definição de produção antiga deixa de existir. Por isso, a tabela de produção antiga é marcada como expirada e é eliminada.
• Se decidir rejeitar as alterações do modo de programação, a definição da tabela deixa de existir. Por isso, as tabelas de desenvolvimento desnecessárias são marcadas como expiradas e são eliminadas.

Trabalhar mais rapidamente no modo de programação

Existem situações em que a tabela derivada persistente (PDT) que está a criar demora muito tempo a ser gerada, o que pode ser demorado se estiver a testar muitas alterações no modo de programação. Para estes casos, pode pedir ao Looker para criar versões mais pequenas de uma tabela derivada quando estiver no modo de desenvolvimento.

Para tabelas derivadas nativas, pode usar o subparâmetro dev_filters de explore_source para especificar filtros que só são aplicados às versões de desenvolvimento da tabela derivada:

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

Este exemplo inclui um parâmetro dev_filters que filtra os dados para os últimos 90 dias e um parâmetro filters que filtra os dados para os últimos 2 anos e para o aeroporto de Yucca Valley.

O parâmetro dev_filters funciona 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 tem precedência para a versão de desenvolvimento da tabela. Neste exemplo, a versão de desenvolvimento da tabela filtra os dados dos últimos 90 dias para o aeroporto de Yucca Valley.

Para tabelas derivadas baseadas em SQL, o Looker suporta uma cláusula WHERE condicional com diferentes opções para as versões de produção (if prod) e de 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 inclui todos os dados de 2000 em diante quando está no modo de produção, mas apenas os dados de 2020 em diante quando está no modo de desenvolvimento. A utilização estratégica desta funcionalidade para limitar o conjunto de resultados e aumentar a velocidade das consultas pode facilitar muito a validação das alterações do modo de desenvolvimento.

Como o Looker cria PDTs

Depois de uma tabela derivada persistente (PDT) ser definida e executada pela primeira vez ou acionada pelo regenerador para reconstrução de acordo com a respetiva estratégia de persistência, o Looker segue os seguintes passos:

1. Use o SQL da tabela derivada para criar uma declaração CREATE TABLE AS SELECT (ou CTAS) e executá-la. Por exemplo, para recompilar uma PDT denominada customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Emita as declarações para criar os índices quando a tabela for criada
3. Mude o nome da tabela de LC$.. ("Looker Create") para LR$.. ("Looker Read") para indicar que a tabela está pronta a ser usada
4. Elimine qualquer versão mais antiga da tabela que já não deve estar em utilização

Existem algumas implicações importantes:

• O SQL que forma a tabela derivada tem de ser válido numa declaração CTAS.
• Os aliases das colunas no conjunto de resultados da instrução SELECT têm de ser nomes de colunas válidos.
• Os nomes usados quando especifica a distribuição, as chaves de ordenação e os índices têm de ser os nomes das colunas indicados na definição SQL da tabela derivada e não os nomes dos campos definidos no LookML.

O regenerador do Looker

O regenerador do Looker verifica o estado e inicia as reconstruções das tabelas persistentes acionadas. Uma tabela de acionador persistente é uma tabela derivada persistente (PDT) ou uma tabela agregada que usa um acionador como estratégia de persistência:

• Para tabelas que usam sql_trigger_value, o acionador é uma consulta especificada no parâmetro sql_trigger_value da tabela. O regenerador do Looker aciona uma recompilação da tabela quando o resultado da verificação da consulta do acionador mais recente é diferente do resultado da verificação da consulta do acionador anterior. Por exemplo, se a tabela derivada for persistida com a consulta SQL SELECT CURDATE(), o regenerador do Looker vai reconstruir a tabela na próxima vez que verificar o acionador após as alterações de data.
• Para tabelas que usam interval_trigger, o acionador é uma duração especificada no parâmetro interval_trigger da tabela. O regenerador do Looker aciona uma recompilação da tabela quando o tempo especificado tiver decorrido.
• Para tabelas que usam datagroup_trigger, o acionador pode ser uma consulta especificada no parâmetro sql_trigger do grupo de dados associado, ou o acionador pode ser 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 apenas quando a tabela persist_for é uma cascata de dependência de uma tabela persistente acionada. Neste caso, o regenerador do Looker inicia as reconstruções para uma tabela persist_for, uma vez que a tabela é necessária para reconstruir as outras tabelas na cascata. Caso contrário, o regenerador não monitoriza tabelas persistentes que usam a estratégia persist_for.

O ciclo do gerador do Looker começa a um intervalo regular configurado pelo administrador do Looker na definição Horário de manutenção na ligação da base de dados (o valor predefinido é 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 reconstruções de PDT do ciclo anterior. Isto significa que, se tiver compilações de PDT de execução prolongada, o ciclo do regenerador do Looker pode não ser executado com a frequência definida na definição Programação de manutenção. Outros fatores podem afetar o tempo necessário para reconstruir as tabelas, conforme descrito na secção Considerações importantes para implementar tabelas persistentes nesta página.

Nos casos em que uma PDT não é compilada, o regenerador pode tentar recompilar a tabela no ciclo do regenerador seguinte:

• Se a definição Tentar novamente compilações de PDT com falhas estiver ativada na ligação da base de dados, o regenerador do Looker tenta recompilar a tabela durante o ciclo do regenerador seguinte, mesmo que a condição de acionamento da tabela não seja cumprida.
• Se a definição Repetir compilações de PDTs falhadas estiver desativada, o regenerador do Looker não tenta recompilar a tabela até que a condição de acionamento da PDT seja cumprida.

Se um utilizador pedir dados da tabela persistente enquanto esta está a ser criada e os resultados da consulta não estiverem na cache, o Looker verifica se a tabela existente ainda é válida. (A tabela anterior pode não ser válida se não for compatível com a nova versão da tabela, o que pode acontecer se a nova tabela tiver uma definição diferente, usar uma ligação à base de dados diferente ou tiver sido criada com uma versão diferente do Looker.) Se a tabela existente ainda for válida, o Looker devolve dados da tabela existente até que a nova tabela seja criada. Caso contrário, se a tabela existente não for válida, o Looker fornece resultados da consulta assim que a nova tabela for reconstruída.

Considerações importantes para implementar tabelas persistentes

Tendo em conta 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 de criar muitas tabelas ao mesmo tempo. Especialmente com tabelas em cascata ou tabelas de execução prolongada, pode criar um cenário em que as tabelas têm um longo atraso antes de serem reconstruídas ou em que os utilizadores experimentam um atraso na obtenção dos resultados da consulta de uma tabela enquanto a base de dados está a trabalhar arduamente para gerar a tabela.

O regenerador do Looker verifica os acionadores de PDTs para ver se deve recompilar tabelas persistentes acionadas. O ciclo do regenerador é definido a um intervalo regular configurado pelo administrador do Looker na definição Horário de manutenção na ligação da base de dados (o valor predefinido é um intervalo de cinco minutos).

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

• O administrador do Looker pode ter alterado o intervalo das verificações do acionador do regenerador através da definição Horário de manutenção na ligação à base de dados.
• O regenerador do Looker não inicia um novo ciclo até concluir todas as verificações e reconstruções de PDT do ciclo anterior. Assim, se tiver compilações de PDT de execução prolongada, o ciclo do regenerador do Looker pode não ser tão frequente quanto a definição Maintenance Schedule.
• Por predefinição, o regenerador pode iniciar a recompilação de uma tabela PDT ou agregada de cada vez através de uma ligação. Um administrador do Looker pode ajustar o número permitido de recompilações simultâneas do gerador através do campo Número máximo de ligações do compilador de PDTs nas definições de uma ligação.
• Todas as PDTs e tabelas agregadas acionadas pelo mesmo datagroup são recompiladas durante o mesmo processo de regeneração. Isto pode ser uma carga pesada se tiver muitas tabelas a usar o grupo de dados, diretamente ou como resultado de dependências em cascata.

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

• Quando as tabelas derivadas são expandidas: cada expansão de uma PDT cria uma nova cópia da tabela na sua base de dados.
• Quando as tabelas derivadas usam filtros baseados em modelos ou parâmetros Liquid: a persistência não é suportada para tabelas derivadas que usam filtros baseados em modelos ou parâmetros Liquid.
• Quando as tabelas derivadas nativas são criadas a partir de explorações que usam atributos do utilizador com access_filters ou com sql_always_where, são criadas cópias da tabela na sua base de dados para cada valor de atributo do utilizador possível especificado.
• Quando os dados subjacentes mudam com frequência e o dialeto da base de dados não suporta PDTs incrementais.
• Quando o custo e o tempo envolvidos na criação de PDTs são demasiado elevados.

Consoante o número e a complexidade das tabelas persistentes na sua ligação do Looker, a fila pode conter muitas tabelas persistentes que precisam de ser verificadas e reconstruídas em cada ciclo. Por isso, é importante ter estes fatores em atenção quando implementar tabelas derivadas na sua instância do Looker.

Gerir PDTs em grande escala através da API

A monitorização e a gestão de tabelas derivadas persistentes (PDTs) que são atualizadas em horários variáveis tornam-se cada vez mais complexas à medida que cria mais PDTs na sua instância. Pondere usar a integração do Apache Airflow do Looker para gerir as suas agendas de PDT juntamente com os outros processos de ETL e ELT.

Monitorização e resolução de problemas de PDTs

Se usar tabelas derivadas persistentes (PDTs), e especialmente PDTs em cascata, é útil ver o estado das suas PDTs. Pode usar a página de administração das tabelas derivadas persistentes do Looker para ver o estado das suas PDTs. Consulte a página de documentação Definições de administrador – Tabelas derivadas persistentes para obter informações.

Ao tentar resolver problemas de PDTs:

• Preste especial atenção à distinção entre tabelas de desenvolvimento e tabelas de produção quando investigar o registo de eventos de PDT.
• Verifique se não foram feitas alterações ao esquema temporário onde o Looker armazena PDTs. Se tiverem sido feitas alterações, pode ter de atualizar as definições de Ligação na secção Administração do Looker e, em seguida, reiniciar o Looker para restaurar a funcionalidade normal de PDTs.
• Determine se existem problemas com todas as PDTs ou apenas com uma. Se houver um problema com um deles, é provável que o problema seja causado por um erro de LookML ou SQL.
• Determine se os problemas com a PDT correspondem às horas em que está agendada para recompilação.
• Certifique-se de que todas as consultas sql_trigger_value são avaliadas com êxito e que devolvem apenas uma linha e uma coluna. Para PDTs baseados em SQL, pode fazê-lo executando-os 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 publicação da comunidade Usar o SQL Runner para testar tabelas derivadas .
• Para PDTs baseados em SQL, use o SQL Runner para verificar se o SQL do PDT é executado sem erros. (Certifique-se de que aplica um LIMIT no SQL Runner para manter os tempos de consulta razoáveis.)
• Para tabelas derivadas baseadas em SQL, evite usar expressões de tabelas comuns (CTEs). A utilização de CTEs com DTs cria declarações WITH aninhadas que podem fazer com que os PDTs falhem sem aviso. Em alternativa, use o SQL para o CTE para criar uma DT secundária e faça referência a essa DT a partir da primeira DT usando a sintaxe ${derived_table_or_view_name.SQL_TABLE_NAME}.
• Verifique se existem tabelas das quais a PDT problemática depende, sejam tabelas normais ou PDTs, e se é possível consultá-las.
• Certifique-se de que as tabelas das quais a PDT com problemas depende não têm bloqueios partilhados nem exclusivos. Para criar um PDT com êxito, o Looker tem de adquirir um bloqueio exclusivo na tabela que precisa de ser atualizada. Isto entra em conflito com outros bloqueios partilhados ou exclusivos que estão atualmente na tabela. O Looker não pode atualizar a PDT até que todos os outros bloqueios tenham sido removidos. O mesmo se aplica a quaisquer bloqueios exclusivos na tabela a partir da qual o Looker está a criar uma PDT. Se existir um bloqueio exclusivo numa tabela, o Looker não consegue adquirir um bloqueio partilhado para executar consultas até que o bloqueio exclusivo seja removido.
• Use o botão Mostrar processos no executador de SQL. Se houver um grande número de processos ativos, isto pode tornar os tempos de consulta mais lentos.
• Monitorize os comentários na consulta. Consulte a secção Consultar comentários para PDTs nesta página.

Consultar comentários para PDTs

Os administradores da base de dados podem distinguir facilmente as consultas normais das que geram tabelas derivadas persistentes (PDTs). O Looker adiciona comentários à declaração CREATE TABLE ... AS SELECT ... que inclui o modelo LookML e a vista do PDT, além de um identificador exclusivo (slug) para a instância do Looker. Se o PDT estiver a ser gerado em nome de um utilizador no modo de desenvolvimento, os comentários indicam o ID do utilizador. Os comentários de geração de PDTs 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 aparece no separador SQL de uma análise detalhada se o Looker tiver de gerar um PDT para a consulta da análise detalhada. O comentário aparece na parte superior da declaração SQL.

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

Recompilar PDTs após uma falha

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

• O Looker usa os resultados na cache se a mesma consulta tiver sido executada anteriormente. (Consulte a página de documentação Colocar consultas em cache para ver uma explicação de como funciona.)
• Se os resultados não estiverem na cache, o Looker extrai os resultados da TDD na base de dados, se existir uma versão válida da TDD.
• Se não existir nenhuma PDT válida na base de dados, o Looker tenta recompilar a PDT.
• Se não for possível recompilar a PDT, o Looker devolve um erro para uma consulta. O regenerador do Looker tenta reconstruir o PDT na próxima vez que o PDT for consultado ou na próxima vez que a estratégia de persistência do PDT acionar uma reconstrução.

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

• Uma falha na compilação de uma tabela impede a compilação das PDTs na cadeia de dependências.
• Uma PDT dependente está essencialmente a consultar a PDT da qual depende, pelo que a estratégia de persistência de uma tabela pode acionar reconstruções das PDTs que sobem na hierarquia.

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

Se TABLE_B tiver uma falha, aplica-se todo o comportamento padrão (não em cascata) para TABLE_B:

1. Se TABLE_B for consultado, o Looker tenta primeiro usar a cache para devolver resultados.
2. Se esta tentativa falhar, o Looker tenta usar uma versão anterior da tabela, se possível.
3. Se esta tentativa também falhar, o Looker tenta reconstruir a tabela.
4. Por último, se não for possível reconstruir TABLE_B, o Looker devolve 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 se aplica aos dependentes de TABLE_B. Assim, se não for possível criar TABLE_B e existir uma consulta em TABLE_C, ocorre a seguinte sequência:

1. O Looker vai tentar usar a cache para a consulta em TABLE_C.
2. Se os resultados não estiverem na cache, o Looker tenta extrair resultados de TABLE_C na base de dados.
3. Se não existir uma versão válida de TABLE_C, o Looker tenta reconstruir TABLE_C, o que cria uma consulta em TABLE_B.
4. Em seguida, o Looker tenta reconstruir TABLE_B (o que falha se TABLE_B não tiver sido corrigido).
5. Se não for possível reconstruir TABLE_B, também não é possível reconstruir TABLE_C. Por isso, o Looker devolve um erro para a consulta em TABLE_C.
6. Em seguida, o Looker tenta reconstruir TABLE_C de acordo com a respetiva estratégia de persistência habitual ou na próxima vez que o PDT for consultado (o que inclui a próxima vez que TABLE_D tentar criar, uma vez que TABLE_D depende de TABLE_C).

Depois de resolver o problema com TABLE_B, o TABLE_B e cada uma das tabelas dependentes tentam ser reconstruídos de acordo com as respetivas estratégias de persistência ou na próxima vez que forem consultados (o que inclui a próxima vez que um PDT dependente tentar ser reconstruído). Em alternativa, se uma versão de desenvolvimento das PDTs na cascata tiver sido criada no modo de programação, as versões de desenvolvimento podem ser usadas como as novas PDTs de produção. (Consulte a secção Tabelas persistentes no modo de desenvolvimento nesta página para saber como funciona.) Em alternativa, pode usar uma exploração para executar uma consulta em TABLE_D e, em seguida, recompilar manualmente as PDTs para a consulta, o que força uma recompilação de todas as PDTs que sobem a cascata de dependências.

Melhorar o desempenho da PDT

Quando cria tabelas derivadas persistentes (PDTs), o desempenho pode ser uma preocupação. Especialmente quando a tabela é muito grande, a consulta da tabela pode ser lenta, tal como pode acontecer com qualquer tabela grande na sua base de dados.

Pode melhorar o desempenho filtrando os dados ou controlando a forma como os dados na PDT são ordenados e indexados.

Adicionar filtros para limitar o conjunto de dados

Com conjuntos de dados particularmente grandes, ter muitas linhas abranda as consultas de uma tabela derivada persistente (PDT). Se normalmente consulta apenas dados recentes, considere adicionar uma cláusula WHERE ao seu PDT que limite a tabela a 90 dias ou menos de dados. Desta forma, apenas os dados relevantes são adicionados à tabela sempre que esta é reconstruída, o que torna a execução de consultas muito mais rápida. Em seguida, pode criar um PDT separado e maior para a análise do histórico, o que permite consultas rápidas de dados recentes e a capacidade de consultar dados antigos.

Usar indexes ou sortkeys e distribution

Quando cria uma tabela derivada persistente (PDT) grande, a indexação da tabela (para dialetos como MySQL ou Postgres) ou a adição de chaves de ordenação e distribuição (para o Redshift) podem ajudar a melhorar o desempenho.

Normalmente, é melhor adicionar o parâmetro indexes em campos de ID ou data.

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

Definições recomendadas para melhorar o desempenho

As seguintes definições controlam a forma como os dados na tabela derivada persistente (PDT) são ordenados e indexados. Estas definições são opcionais, mas vivamente recomendadas:

• Para o Redshift e o Aster, use o parâmetro distribution para especificar o nome da coluna cujo valor é usado para distribuir os dados por um cluster. Quando duas tabelas são unidas pela coluna especificada no parâmetro distribution, a base de dados pode encontrar os dados de união no mesmo nó, pelo que a E/S entre nós é minimizada.
• Para o Redshift, defina o parâmetro distribution_style como all para indicar à base de dados que mantenha uma cópia completa dos dados em cada nó. Isto é frequentemente usado para minimizar a E/S entre nós quando são unidas tabelas relativamente pequenas. Defina este valor como even para indicar à base de dados que distribua os dados uniformemente pelo cluster sem usar uma coluna de distribuição. Este valor só pode ser especificado quando distribution não estiver especificado.
• Para o Redshift, use o parâmetro sortkeys. Os valores especificam as colunas da PDT que são usadas para ordenar os dados no disco para facilitar a pesquisa. No Redshift, pode usar sortkeys ou indexes, mas não ambos.
• Na maioria das bases de dados, use o parâmetro indexes. Os valores especificam que colunas da TPD são indexadas. (No Redshift, os índices são usados para gerar chaves de ordenação intercaladas.)