tabela_agregada

Uso

cada e em conta do usuário

Hierarquia Arquivo de modelo explore aggregate_table

Valor padrão Nenhuma Aceita Um nome para a tabela agregada, o subparâmetro query para definir a tabela e o subparâmetro materialization para definir a estratégia de persistência da tabela Regras especiais O table_name precisa ser único em um determinado explore No subparâmetro materialization, você precisa especificar uma estratégia de persistência para a tabela agregada.

Definição

O parâmetro aggregate_table é usado para criar tabelas de agregação que minimizam o número de consultas necessárias para as tabelas grandes no banco de dados.

O Looker usa a lógica de reconhecimento agregado para encontrar a menor tabela agregada mais eficiente disponível no seu banco de dados para executar uma consulta, mantendo a correção. Consulte a página de documentação Reconhecimento agregado para uma visão geral e estratégias para criar tabelas de agregação.

Para tabelas muito grandes no seu banco de dados, você pode criar tabelas de dados agregados menores, agrupadas por várias combinações de atributos. As tabelas de agregação atuam como visualizações completas ou tabelas de resumo que o Looker pode usar para consultas sempre que possível, em vez da tabela grande original.

Para que as tabelas agregadas sejam acessíveis por meio do reconhecimento agregado, é necessário manter essas tabelas no seu banco de dados. A estratégia de persistência é especificada no parâmetro materialization da tabela agregada. Além disso, como as tabelas de agregação são um tipo de tabela derivada persistente (PDT, na sigla em inglês), elas têm os mesmos requisitos de conexão de banco de dados e dialeto que as PDTs. Consulte a página de documentação Tabelas derivadas no Looker para mais detalhes.

Depois de criar as tabelas de agregação, você pode executar consultas em "Explorar" para ver quais tabelas de agregação o Looker usa. Para mais informações, consulte a seção Como determinar qual tabela agregada é usada em uma consulta na página de documentação Reconhecimento agregado.

Consulte a seção Solução de problemas na página de documentação Reconhecimento agregado para ver os motivos mais comuns de uso de tabelas agregadas.

Como definir uma tabela agregada no LookML

Em vez de criar o LookML do zero, você pode usar um Explore ou um painel para criar um LookML da tabela agregada. Para mais detalhes, consulte as seções Como conseguir uma tabela agregada LookML de um recurso Explorar e Como conseguir uma tabela agregada LookML de um painel nesta página.

Cada parâmetro aggregate_table precisa ter um nome exclusivo em um determinado explore.

O parâmetro aggregate_table tem os subparâmetros query e materialization.

query

O parâmetro query define a consulta da tabela agregada, incluindo quais dimensões e medidas usar. O parâmetro query inclui os seguintes subparâmetros:

Esta seção se refere ao parâmetro query que faz parte de um aggregate_table.

O query também pode ser usado como parte de um explore, conforme descrito na página de documentação do parâmetro query.

Nome do parâmetro	Descrição	Exemplo
dimensions	Uma lista separada por vírgulas das dimensões da seção "Explorar" que será incluída na sua tabela agregada. O campo dimensions usa este formato: dimensions: [dimension1, dimension2, ...] Cada dimensão nessa lista precisa ser definida como um dimension no arquivo de visualização do recurso Explorar da consulta. Se você quiser incluir um campo definido como filter na consulta "Explorar", adicione-o à lista filters na consulta da tabela agregada.	dimensions:   [orders.created_month, orders.country]
measures	Uma lista separada por vírgulas das medidas de "Explorar" a ser incluída na sua tabela agregada. O campo measures usa este formato: measures: [measure1, measure2, ...] Para informações sobre os tipos de medidas com suporte para o reconhecimento agregado, consulte a seção Fatores de tipo de medição na página de documentação Reconhecimento agregado.	measures:   [orders.count]
filters	Se quiser, adicione um filtro a um query. Os filtros são adicionados à cláusula WHERE do SQL que gera a tabela agregada. O campo filters usa este formato: filters: [field1: "value1", field2: "value2", ...] Para mais informações sobre como os filtros podem impedir o uso da tabela agregada, consulte a seção Fatores de filtro na página de documentação Reconhecimento agregado.	filters: [orders.country: "United States", orders.state: "California"]
sorts	Como opção, especifica campos e direção de classificação (crescente ou decrescente) para a query. O campo sorts usa este formato: sorts: [field1: asc|desc, field2: asc|desc, ...]	[orders.country: asc, orders.state: desc]
timezone	Define o fuso horário da query. Se um fuso horário não for especificado, a tabela agregada não executará nenhuma conversão de fuso horário e usará o fuso horário do banco de dados. Para mais informações sobre como definir o fuso horário para que sua tabela agregada seja usada como uma origem de consulta, consulte a seção Fatores de fuso horário na página de documentação Reconhecimento agregado. O ambiente de desenvolvimento integrado sugere automaticamente o valor do fuso horário quando você digita o parâmetro timezone. O ambiente de desenvolvimento integrado também exibe a lista de valores de fuso horário compatíveis no painel Ajuda rápida.	timezone: America/Los_Angeles

materialization

O parâmetro materialization especifica a estratégia de persistência para sua tabela agregada, bem como outras opções de distribuição, particionamento, índices e clustering que podem ser compatíveis com seu dialeto SQL.

Para ter acesso à percepção agregada, a tabela agregada precisa persistir no banco de dados. Uma tabela agregada precisa ter uma das seguintes estratégias de persistência:

• datagroup_trigger
• sql_trigger_value
• persist_for (não recomendado)

Outras opções de materialization podem ser aceitas na tabela agregada, dependendo do dialeto SQL:

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

Por fim, para criar uma tabela agregada incremental, use os seguintes subparâmetros materialization:

• increment_key
• increment_offset

datagroup_trigger

Use o parâmetro datagroup_trigger para acionar a nova geração da tabela agregada com base em um grupo de dados atual definido no arquivo de modelo:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: order_datagroup
    }
    query: {
      ...
    }
  }
  ...
}

sql_trigger_value

Use o parâmetro sql_trigger_value para acionar a nova geração da tabela agregada com base em uma instrução SQL fornecida. Se o resultado da instrução SQL for diferente do valor anterior, a tabela será gerada novamente. Esta instrução sql_trigger_value acionará a nova geração quando a data mudar:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      sql_trigger_value: SELECT CURDATE() ;;
    }
    query: {
      ...
    }
  }
  ...
}

persist_for

O parâmetro persist_for também é compatível com tabelas de agregação. No entanto, a estratégia persist_for pode não proporcionar o melhor desempenho para reconhecimento agregado. Isso ocorre porque, quando um usuário executa uma consulta que depende de uma tabela persist_for, o Looker verifica a idade da tabela em relação à configuração persist_for. Se a tabela for mais antiga que a configuração persist_for, ela será gerada novamente antes da execução da consulta. Se a idade for menor que a configuração de persist_for, a tabela existente será usada. Portanto, a menos que um usuário execute uma consulta no tempo persist_for, a tabela agregada precisa ser recriada antes de ser usada para o reconhecimento agregado.

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      persist_for: "90 minutes"
    }
    query: {
      ...
    }
  }
  ...
}

A menos que você entenda as limitações e tenha um caso de uso específico para a implementação de persist_for, é melhor usar datagroup_trigger ou sql_trigger_value como uma estratégia de persistência para tabelas de agregação.

cluster_keys

O parâmetro cluster_keys permite adicionar uma coluna em cluster a tabelas particionadas no BigQuery ou no Snowflake. O clustering classifica os dados em uma partição com base nos valores das colunas em cluster e as organiza em blocos de armazenamento com o tamanho ideal.

No BigQuery, o clustering é compatível com tabelas agregadas que também são particionadas usando o parâmetro partition_keys.

Consulte a página de documentação do parâmetro cluster_keys para mais informações.

distribution

O parâmetro distribution permite especificar a coluna de uma tabela agregada em que uma chave de distribuição será aplicada. distribution funciona apenas com bancos de dados Redshift e Aster. Para outros dialetos SQL (como MySQL e Postgres), use indexes.

Consulte a página de documentação do parâmetro distribution para mais informações.

distribution_style

O parâmetro distribution_style permite especificar como a consulta de uma tabela agregada é distribuída nos nós em um banco de dados do Redshift:

• distribution_style: all indica que todas as linhas são totalmente copiadas para cada nó.
• distribution_style: even especifica a distribuição uniforme, de modo que as linhas são distribuídas para nós diferentes em ordem aleatória.

Para distribuir a consulta com base nos valores exclusivos de uma coluna (chaves de distribuição) específica, use o parâmetro distribution.

Consulte a página de documentação do parâmetro distribution_style para mais informações.

indexes

O parâmetro indexes permite aplicar índices às colunas de uma tabela agregada.

Consulte a página de documentação do parâmetro indexes para mais informações.

partition_keys

O parâmetro partition_keys define uma matriz de colunas pela qual a tabela agregada será particionada. partition_keys oferece suporte a dialetos de banco de dados que podem particionar colunas. Quando é executada uma consulta filtrada em uma coluna particionada, o banco de dados verifica apenas as partições que incluem os dados filtrados, em vez de verificar toda a tabela. partition_keys é compatível apenas com dialetos Presto e BigQuery.

Consulte a página de documentação do parâmetro partition_keys para mais informações.

sortkeys

Com o parâmetro sortkeys, é possível especificar uma ou mais colunas de uma tabela agregada para aplicar uma chave de classificação normal.

Consulte a página de documentação do parâmetro sortkeys para mais informações.

increment_key

É possível criar PDTs incrementais no seu projeto, se o dialeto for compatível. Uma PDT incremental é uma tabela derivada persistente (PDT, na sigla em inglês) criada pelo Looker anexando novos dados à tabela, em vez de recriar a tabela inteira. Consulte a página de documentação de PDTs incrementais para mais informações.

As tabelas agregadas são um tipo de PDT que podem ser criadas de maneira incremental com a adição do parâmetro increment_key. O parâmetro increment_key especifica o incremento de tempo em que os dados novos devem ser consultados e anexados à tabela de agregação.

Consulte a página de documentação do parâmetro increment_key para mais informações.

increment_offset

O parâmetro increment_offset define o número de períodos anteriores (com granularidade da chave incremental) que serão recriados ao anexar dados à tabela agregada. O parâmetro increment_offset é opcional para PDTs incrementais e tabelas agregadas.

Consulte a página de documentação do parâmetro increment_offset para mais informações.

Como conseguir um LookML da tabela agregada em um Explore

Como um atalho, os desenvolvedores do Looker podem usar uma consulta "Explorar" para criar uma tabela agregada e copiar o LookML no projeto LookML:

1. Em "Explorar", selecione todos os campos e filtros que você quer incluir na tabela agregada.
2. Clique em Executar para ver os resultados.
3. Selecione Instalar LookML no menu de engrenagem "Explorar". Essa opção está disponível somente para desenvolvedores do Looker.
4. Clique na guia Tabela agregada.
5. O Looker oferece o LookML para um refinamento do Explore que adicionará a tabela agregada ao Explore. Copie o LookML e cole-o no arquivo de modelo associado, que é indicado no comentário acima do refinamento Explorar. Se o recurso Explorar for definido em um Arquivo separado do Explorar, e não em um arquivo de modelo, você poderá adicionar o refinamento a esse arquivo. Qualquer um dos locais funcionará.

O Looker dá um nome à tabela agregada com base nas dimensões em "Explorar". O Looker usará o mesmo nome para a tabela agregada sempre que fornecer a tabela agregada LookML para o recurso Explorar. Tenha cuidado com outros refinamentos que podem ter sido adicionados anteriormente. Se você ou outro desenvolvedor já tiver recebido a tabela agregada LookML de uma análise, o Looker dará o mesmo nome para a tabela agregada. Se uma exploração tiver vários refinamentos, cada um com tabelas de mesmo nome, um refinamento vai substituir os outros, conforme descrito na seção Refinamentos aplicados em ordem, na página de documentação Refinamentos do LookML.

Se você precisar modificar a tabela agregada LookML, poderá fazer isso com os parâmetros descritos na seção Como definir uma tabela agregada no LookML nesta página. É possível renomear a tabela agregada sem alterar a aplicabilidade dela para a consulta "Explorar" original. No entanto, qualquer outra alteração na tabela agregada pode afetar a capacidade do Looker de usar a tabela agregada na consulta "Explorar". Consulte a seção Como criar tabelas agregadas da página de documentação Reconhecimento agregado para ver dicas sobre como otimizar suas tabelas de agregação e garantir que elas sejam usadas no reconhecimento.

Como conseguir um LookML da tabela agregada em um painel

Outra opção para os desenvolvedores do Looker é buscar a tabela agregada LookML para todos os blocos em um painel e, em seguida, copiar o LookML no projeto LookML.

A criação de tabelas agregadas pode melhorar significativamente o desempenho de um painel, especialmente para blocos que consultam grandes conjuntos de dados.

Se você tiver a permissão develop, poderá acessar o LookML para criar tabelas agregadas de um painel abrindo o painel, selecionando Get LookML no menu de três pontos e escolhendo a guia Aggregate Tables:

Para cada bloco que ainda não foi otimizado com o reconhecimento agregado, o Looker oferece o LookML para um exploração do Explore que adicionará a tabela agregada ao recurso Explorar. Se o painel incluir vários blocos do mesmo recurso "Explorar", o Looker colocará todas as tabelas agregadas em um único refinamento. Para reduzir o número de tabelas de agregação geradas, o Looker determina se uma tabela agregada pode ser usada para mais de um bloco e, em caso afirmativo, descarta qualquer tabela de agregação redundante que possa ser usada para menos blocos.

Copie e cole cada refinamento no campo de modelo associado, conforme indicado no comentário acima do refinamento. Se o recurso "Explorar" for definido em um arquivo separado do Explorar, e não em um arquivo de modelo, você poderá adicionar o refinamento a esse arquivo, em vez de ao arquivo de modelo. Qualquer um dos locais funcionará.

Lembre-se de que o Looker atribui um nome a cada tabela agregada com base nas dimensões na consulta do bloco. O Looker usará o mesmo nome para a tabela agregada sempre que fornecer a tabela agregada LookML para uma consulta de blocos. Portanto, tenha cuidado com outros refinamentos no recurso Explorar do bloco, que podem ter sido adicionados anteriormente. Se você ou outro desenvolvedor já tiver recebido a tabela agregada LookML na consulta do bloco do painel, o Looker terá o mesmo nome para a tabela agregada. Se uma exploração tiver vários refinamentos, cada um com tabelas de mesmo nome, um refinamento vai substituir os outros, conforme descrito na seção Refinamentos aplicados em ordem, na página de documentação Refinamentos do LookML.

Se houver um filtro de painel aplicado a um bloco, o Looker adicionará a dimensão do filtro à tabela agregada para que ela possa ser usada para o bloco. Isso ocorre porque as tabelas de agregação podem ser usadas para uma consulta somente se os campos de referência de filtros da consulta estiverem disponíveis como dimensões na tabela de agregação. Consulte a página de documentação Reconhecimento agregado para informações.

Se você precisar modificar a tabela agregada LookML, poderá fazer isso com os parâmetros descritos na seção Como definir uma tabela agregada no LookML nesta página. É possível renomear a tabela agregada sem alterar a aplicabilidade dela ao bloco original do painel, mas qualquer outra alteração na tabela agregada pode afetar a capacidade do Looker de usar a tabela agregada no painel. Consulte a seção Como criar tabelas agregadas da página de documentação Reconhecimento agregado para ver dicas sobre como otimizar suas tabelas de agregação e garantir que elas sejam usadas no reconhecimento.

Exemplo

O exemplo a seguir cria uma tabela agregada monthly_orders para a exploração event. A tabela agregada cria uma contagem mensal de pedidos. O Looker usará a tabela agregada para consultas de contagem de pedidos que podem aproveitar a granularidade mensal, como consultas de contagens de pedidos anuais, trimestrais e mensais.

A tabela agregada é configurada com persistência usando o orders_datagroupdatagroup.

A definição da tabela agregada é semelhante a esta:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_month]
      measures: [orders.count]
      filters: [orders.created_date: "1 year", orders.status: "fulfilled"]
      timezone: America/Los_Angeles
    }
  }
}

Considerações

Consulte a seção Como criar tabelas agregadas da página de documentação Reconhecimento agregado para ver dicas sobre como criar estratégias para essas tabelas:

• Fatores temporais
• Fatores de fuso horário
• Filtrar fatores
• Fatores de campo
• Medir os tipos de fator

Disparar o suporte para aumentar o reconhecimento

A capacidade de usar o reconhecimento agregado depende do dialeto do banco de dados usado pela conexão do Looker. Na versão mais recente do Looker, os seguintes dialetos são compatíveis com o reconhecimento agregado: