aggregate_table

Uso

explore: explore_name {
  aggregate_table: table_name {

    query:  {
      dimensions: [dimension1, dimension2, ... ]
      measures: [measure1, measure2, ... ]
      sorts: [field1: asc, field2: desc, ... ]
      filters: [field1: "value1", field2: "value2", ... ]
      timezone: timezone
    }

    materialization:  {
      ...
    }
  }

  ...

}

Hierarquia Arquivo de modelo explore aggregate_table

Valor padrão Nenhum 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 exclusivo em um determinado explore No subparâmetro materialization, especifique uma estratégia de persistência para a tabela agregada.

Definição

O parâmetro aggregate_table é usado para criar tabelas agregadas 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 e mais eficiente tabela agregada disponível no seu banco de dados para executar uma consulta, mantendo a correção. Consulte a página de documentação Reconhecimento de agregação para uma visão geral e estratégias de criação de tabelas de agregação.

Para tabelas muito grandes no seu banco de dados, é possível criar tabelas agregadas menores de dados, agrupados por várias combinações de atributos. As tabelas agregadas atuam como resumos ou tabelas de resumo que o Looker pode usar para consultas sempre que possível, em vez da tabela grande original.

Observação: para serem acessíveis ao reconhecimento de agregados, as tabelas agregadas precisam ser persistidas no banco de dados. A estratégia de persistência é especificada no parâmetro materialization da tabela agregada. Além disso, como as tabelas agregadas são um tipo de tabela derivada persistente (TDP), elas têm os mesmos requisitos de conexão e dialeto de banco de dados que as TDPs. Consulte a página de documentação Tabelas derivadas no Looker para mais detalhes.

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

Consulte a seção Solução de problemas na página de documentação Reconhecimento de agregação para saber os motivos comuns de não uso das tabelas de agregação.

Como definir uma tabela de agregação no LookML

Observação: em vez de criar o LookML do zero, use uma Análise ou um painel para criar o LookML da tabela de agregação. Para mais detalhes, consulte as seções Como acessar a tabela de agregação do LookML em uma Análise e Como acessar a tabela de agregação do LookML em 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 para a tabela agregada, incluindo quais dimensões e métricas usar. O parâmetro query inclui os seguintes subparâmetros:

Observação:esta seção se refere ao parâmetro query, que faz parte de um aggregate_table.

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 Análise detalhada que serão incluídas 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 da Análise da consulta. Se você quiser incluir um campo definido como filter na consulta do recurso Detalhar, adicione-o à lista filters na consulta da tabela de agregação.	dimensions:   [orders.created_month, orders.country]
measures	Uma lista separada por vírgulas das medidas da análise detalhada que serão incluídas na tabela agregada. O campo measures usa este formato: measures: [measure1, measure2, ...] Para informações sobre os tipos de métricas compatíveis com a percepção de agregação, consulte a seção Fatores do tipo de métrica na página de documentação Percepção de agregação.	measures:   [orders.count]
filters	Adiciona um filtro a um query, se quiser. Os filtros são adicionados à cláusula WHERE do SQL que gera a tabela de agregação. O campo filters usa este formato: filters: [field1: "value1", field2: "value2", ...] Para saber como os filtros podem impedir o uso da sua tabela agregada, consulte a seção Fatores de filtro na página de documentação Conscientização de agregação.	filters: [orders.country: "United States", orders.state: "California"]
sorts	Especifica campos e direção de classificação (crescente ou decrescente) para o 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 do query. Se um fuso horário não for especificado, a tabela agregada não fará nenhuma conversão de fuso horário e usará o fuso horário do banco de dados. Para informações sobre como definir o fuso horário para que sua tabela agregada seja usada como uma fonte de consulta, consulte a seção Fatores de fuso horário na página de documentação Reconhecimento de agregação. O ambiente de desenvolvimento integrado sugere automaticamente o valor do fuso horário quando você digita o parâmetro timezone no ambiente. O IDE também mostra a lista de valores de fuso horário compatíveis no painel de Ajuda rápida.	timezone: America/Los_Angeles

materialization

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

Para ser acessível ao reconhecimento de agregados, a tabela agregada precisa ser persistida no banco de dados. O parâmetro materialization da sua tabela agregada precisa ter um dos seguintes subparâmetros para especificar a estratégia de persistência:

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

Além disso, os seguintes subparâmetros materialization podem ser compatíveis com sua tabela agregada, dependendo do dialeto SQL:

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

Para criar uma tabela de agregação incremental, use os seguintes subparâmetros materialization:

• increment_key
• increment_offset

datagroup_trigger

Use o parâmetro datagroup_trigger para acionar a regeneração da tabela agregada com base em um grupo de dados 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 regeneração da tabela agregada com base em uma instrução SQL fornecida por você. Se o resultado da instrução SQL for diferente do valor anterior, a tabela será gerada novamente. Esta instrução sql_trigger_value vai acionar a regeneraçã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 agregadas. No entanto, a estratégia persist_for pode não oferecer a melhor performance para o reconhecimento agregado. Isso acontece 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á regenerada antes da execução da consulta. Se a idade for menor que a configuração persist_for, a tabela atual será usada. Portanto, a menos que um usuário execute uma consulta dentro do período de persist_for, a tabela agregada precisa ser recriada antes de ser usada para reconhecimento de agregação.

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 do persist_for, é melhor usar datagroup_trigger ou sql_trigger_value como uma estratégia de persistência para tabelas agregadas.

cluster_keys

O parâmetro cluster_keys permite adicionar uma coluna de 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 organiza essas colunas em blocos de armazenamento com o tamanho ideal.

Observação: 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 de parâmetros do cluster_keys para mais informações.

distribution

O parâmetro distribution permite especificar a coluna de uma tabela de agregação 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 de parâmetros do distribution para mais informações.

distribution_style

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

• distribution_style: all indica que todas as linhas foram totalmente copiadas para cada nó.
• distribution_style: even especifica uma distribuição uniforme, para que as linhas sejam distribuídas para diferentes nós de maneira rotativa.

Observação: para distribuir a consulta com base em valores únicos em uma coluna específica (chaves de distribuição), use o parâmetro distribution.

Consulte a página de documentação de parâmetros do 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 de parâmetros do indexes para mais informações.

partition_keys

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

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

publish_as_db_view

O parâmetro publish_as_db_view permite sinalizar uma tabela agregada para consulta fora do Looker. Para tabelas agregadas com publish_as_db_view definido como yes, o Looker cria uma visualização estável do banco de dados para a tabela agregada. A visualização estável do banco de dados é criada no próprio banco de dados para que possa ser consultada fora do Looker.

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

sortkeys

O parâmetro sortkeys permite especificar uma ou mais colunas de uma tabela agregada em que uma chave de classificação regular será aplicada.

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

increment_key

É possível criar PDTs incrementais no seu projeto se o dialeto for compatível com elas. Uma TDP incremental é uma tabela derivada persistente (TDP) que o Looker cria adicionando dados novos à tabela, em vez de recriá-la por completo. Consulte a página de documentação TDPs incrementais para mais informações.

As tabelas agregadas são um tipo de TDP e podem ser criadas de forma incremental adicionando o parâmetro increment_key. O parâmetro increment_key especifica o incremento de tempo para o qual os dados atualizados devem ser consultados e anexados à tabela agregada.

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

increment_offset

O parâmetro increment_offset define o número de períodos anteriores (na granularidade da chave de incremento) 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 de parâmetros do increment_offset para mais informações.

Como acessar a tabela de agregação do LookML em uma Análise

Como um atalho, os desenvolvedores do Looker podem usar uma consulta de Análise para criar uma tabela agregada e copiar o LookML para o projeto do LookML:

1. Na análise detalhada, selecione todos os campos e filtros que você quer incluir na tabela de agregação.
2. Clique em Executar para ver os resultados.
3. Selecione Get LookML no menu de engrenagem da análise detalhada. Essa opção está disponível apenas para desenvolvedores do Looker.
4. Clique na guia Tabela de agregação.
5. O Looker fornece o LookML para um refinamento de Análise que adiciona a tabela agregada à Análise. Copie o LookML e cole no arquivo de modelo associado, indicado no comentário que precede o refinamento do recurso "Explorar". Se a Análise for definida em um arquivo separado, e não em um arquivo de modelo, adicione o refinamento ao arquivo da Análise em vez do arquivo de modelo. Qualquer um dos locais funciona.

Observação: o Looker atribui um nome à tabela agregada com base nas dimensões da Análise. O Looker vai usar o mesmo nome para a tabela agregada sempre que fornecer o LookML da tabela agregada para a Análise. Preste atenção a outros refinamentos da mesma análise que podem ter sido adicionados anteriormente. Se você ou outro desenvolvedor já tiver recebido a tabela de agregação do LookML de uma Análise, o Looker vai dar o mesmo nome para a tabela de agregação. Se uma análise detalhada tiver vários refinamentos, cada um com tabelas agregadas do mesmo nome, um refinamento vai substituir os outros, conforme descrito na seção Os refinamentos são aplicados em ordem da página de documentação Refinamentos do LookML.

Se você precisar modificar a LookML da tabela agregada, use os parâmetros descritos na seção Definir uma tabela agregada em LookML desta página. Você pode renomear a tabela agregada sem mudar a aplicabilidade dela à consulta original do recurso "Explorar". No entanto, outras mudanças na tabela agregada podem afetar a capacidade do Looker de usar a tabela agregada para a consulta da Análise. Consulte a seção Como criar tabelas agregadas na página de documentação Reconhecimento de agregados para dicas sobre como otimizar suas tabelas agregadas e garantir que elas sejam usadas para o reconhecimento de agregados.

Como acessar a tabela de agregação do LookML em um painel

Outra opção para desenvolvedores do Looker é acessar a tabela de agregação do LookML para todos os blocos em um painel e copiar o LookML para o projeto.

Criar tabelas de agregação pode melhorar muito a performance de um painel, especialmente para blocos que consultam conjuntos de dados enormes.

Se você tiver a permissão develop, poderá abrir um painel, selecionar Receber LookML no menu de três pontos e escolher a guia Tabelas de agregação para criar tabelas de agregação para um painel:

Para cada bloco que ainda não está otimizado com reconhecimento de agregação, o Looker fornece a LookML para um refinamento do Explore que adiciona a tabela de agregação a ele. Se o painel incluir vários blocos da mesma Análise, o Looker vai colocar todas as tabelas agregadas em um único refinamento de Análise. Para reduzir o número de tabelas agregadas geradas, o Looker determina se uma tabela agregada gerada pode ser usada em mais de um bloco e, se for o caso, descarta as tabelas agregadas redundantes que podem ser usadas em menos blocos.

Copie e cole cada refinamento do recurso Detalhar em um arquivo de modelo associado, indicado no comentário antes do refinamento. Se a Análise for definida em um arquivo separado, e não em um arquivo de modelo, adicione o refinamento ao arquivo da Análise em vez do arquivo de modelo. Qualquer um dos locais funciona.

Observação: o Looker dá a cada tabela agregada um nome com base nas dimensões da consulta do bloco. O Looker vai usar o mesmo nome para a tabela agregada sempre que fornecer a consulta de bloco do LookML da tabela agregada. Considere outros refinamentos na opção "Explorar" do bloco que podem ter sido adicionados anteriormente. Se você ou outro desenvolvedor já tiver recebido a LookML da tabela de agregação da consulta do bloco do painel, o Looker vai dar o mesmo nome para a tabela de agregação. Se uma análise detalhada tiver vários refinamentos, cada um com tabelas agregadas do mesmo nome, um refinamento vai substituir os outros, conforme descrito na seção Os refinamentos são aplicados em ordem da página de documentação Refinamentos do LookML.

Se um filtro de painel for aplicado a um bloco, o Looker vai adicionar a dimensão do filtro à tabela agregada do bloco para que ela possa ser usada. Isso acontece porque as tabelas agregadas só podem ser usadas em uma consulta se os filtros dela fizerem referência a campos disponíveis como dimensões na tabela agregada. Consulte a página de documentação Aggregate awareness para mais informações.

Se você precisar modificar a LookML da tabela agregada, use os parâmetros descritos na seção Definir uma tabela agregada em LookML desta página. Você pode renomear a tabela agregada sem mudar a aplicabilidade dela ao bloco original do painel, mas outras mudanças podem afetar a capacidade do Looker de usar a tabela agregada no painel. Consulte a seção Como criar tabelas agregadas na página de documentação Reconhecimento de agregados para dicas sobre como otimizar suas tabelas agregadas e garantir que elas sejam usadas para o reconhecimento de agregados.

Exemplo

O exemplo a seguir cria uma tabela agregada monthly_orders para a análise detalhada event. A tabela agregada cria uma contagem mensal de pedidos. O Looker vai usar a tabela agregada para consultas de contagem de pedidos que podem aproveitar a granularidade mensal, como consultas de contagem de pedidos anuais, trimestrais e mensais.

A tabela de agregação é configurada com persistência usando o orders_datagroup datagroup. Além disso, a tabela agregada é definida com publish_as_db_view: yes, o que significa que o Looker vai criar uma visualização estável do banco de dados para a tabela agregada.

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

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

Informações importantes

Consulte a seção Como criar tabelas agregadas na página de documentação Reconhecimento de agregação para dicas sobre como criar tabelas agregadas de forma estratégica:

• Fatores de período
• Fatores de fuso horário
• Fatores de filtro
• Fatores de campo
• Fatores do tipo de medida

Compatibilidade com dialetos para reconhecimento agregado

A capacidade de usar o reconhecimento de agregação 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 de agregação:

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