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 de agregação, 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, é preciso especificar uma estratégia de persistência para a tabela de agregação.

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 seu banco de dados.

O Looker usa a lógica de reconhecimento agregado para encontrar a menor e mais eficiente tabela de agregação disponível no seu banco de dados para executar uma consulta, mantendo a correção. Consulte a página de documentação Reconhecimento de agregados 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 de agregação menores de dados, agrupados por várias combinações de atributos. As tabelas de agregação atuam como resumos ou tabelas de resumo que o Looker pode usar em consultas sempre que possível, em vez da tabela grande original.

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

Depois de criar as tabelas de agregação, você pode executar consultas na Análise para ver quais tabelas de agregação o Looker usa. Para mais informações, consulte a seção Como determinar qual tabela de agregação é 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 agregados para ver os motivos comuns de as tabelas de agregação não serem usadas.

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 dashboard para criar o LookML da tabela de agregação. Para mais detalhes, consulte as seções Como acessar o LookML da tabela de agregação em uma Análise e Como acessar o LookML da tabela de agregação 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 de agregação, 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 que serão incluídas na tabela de agregação. 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 Explorar, 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 medições da Análise que serão incluídas na tabela de agregação. O campo measures usa este formato: measures: [measure1, measure2, ...] Para informações sobre os tipos de medição compatíveis com o reconhecimento de agregados, consulte a seção Fatores de tipo de medição na página de documentação Reconhecimento de agregados.	measures:   [orders.count]
filters	Opcionalmente, adiciona um filtro a um query. 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 tabela de agregação, consulte a seção Fatores de filtro na página de documentação Reconhecimento de agregação.	filters: [orders.country: "United States", orders.state: "California"]
sorts	Opcionalmente, especifica os campos e a 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 para query. Se um fuso horário não for especificado, a tabela de agregação não vai realizar nenhuma conversão de fuso horário e vai usar o fuso horário do banco de dados. Para saber como definir o fuso horário para que a tabela de agregação 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. O ambiente de desenvolvimento integrado 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 para sua tabela de agregação, bem como outras opções de distribuição, particionamento, índices e clustering que podem ser compatíveis com seu dialeto SQL.

Para que possa ser acessada pelo reconhecimento de agregados, a tabela de agregação precisa ser persistida no banco de dados. O parâmetro materialization da tabela de agregação 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 de agregação, 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 de materialization:

• increment_key
• increment_offset

datagroup_trigger

Use o parâmetro datagroup_trigger para acionar a regeneração da tabela de agregação com base em um datagroup 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 de agregação 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 de agregação. No entanto, a estratégia persist_for pode não oferecer a melhor performance para o 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 persist_for, a tabela atual será usada. Portanto, a menos que um usuário execute uma consulta dentro do tempo persist_for, a tabela de agregação 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 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 organiza as colunas em blocos de armazenamento de tamanho ideal.

Observação: no BigQuery, o clustering é compatível com tabelas de agregação 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 de agregação em que uma chave de distribuição será aplicada. O distribution funciona apenas com os 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 de agregação é distribuída entre os 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 uma distribuição uniforme, de modo que as linhas sejam distribuídas para nós diferentes de maneira round-robin.

Observação: para distribuir a consulta com base em valores exclusivos em uma coluna específica (chaves de distribuição), 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 de agregação.

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 de agregação será particionada. O partition_keys é compatível com dialetos de banco de dados que podem particionar colunas. Quando uma consulta é executada e filtrada em uma coluna particionada, o banco de dados verifica apenas as partições que incluem os dados filtrados, em vez de verificar a tabela inteira. partition_keys só é compatível com os dialetos Presto e BigQuery.

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

publish_as_db_view

O parâmetro publish_as_db_view permite sinalizar uma tabela de agregação para consulta fora do Looker. Para tabelas de agregação com publish_as_db_view definido como yes, o Looker cria uma visualização de banco de dados estável no banco de dados para a tabela de agregação. 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 do parâmetro publish_as_db_view para mais informações.

sortkeys

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

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

increment_key

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

As tabelas de agregação 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 em que os dados novos devem ser consultados e adicionados ao final da 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 (na granularidade da chave de incremento) que serão recriados ao anexar dados à tabela de agregação. O parâmetro increment_offset é opcional para TDPs incrementais e tabelas de agregação.

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

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

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

1. Na Análise, selecione todos os campos e filtros que você quer incluir na tabela de agregação.
2. Clique em Executar para conferir os resultados.
3. Selecione Get LookML no menu de engrenagem da Análise. 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 vai adicionar a tabela de agregação à Análise. Copie o LookML e cole-o no arquivo de modelo associado, que é indicado no comentário que precede o refinamento da Análise. Se a Análise estiver definida em um arquivo de Análise separado, e não em um arquivo de modelo, você poderá adicionar o refinamento ao arquivo da Análise, em vez do arquivo de modelo. Qualquer um dos locais vai funcionar.

Observação: o Looker dá um nome à tabela de agregação com base nas dimensões da Análise. O Looker vai usar o mesmo nome para a tabela de agregação sempre que fornecer o LookML da tabela de agregação para a Análise. Preste atenção a outros refinamentos na mesma Análise que podem ter sido adicionados anteriormente. Se você ou outro desenvolvedor já tiver acessado o LookML da tabela de agregação em uma Análise, o Looker vai dar o mesmo nome para a tabela de agregação. Se uma Análise tiver vários refinamentos, cada um com tabelas de agregação de 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 o LookML da tabela de agregação, use os parâmetros descritos na seção Como definir uma tabela de agregação no LookML nesta página. É possível renomear a tabela de agregação sem mudar a aplicabilidade dela à consulta original da Análise. No entanto, qualquer outra alteração na tabela de agregação pode afetar a capacidade do Looker de usar a tabela de agregação para a consulta da Análise. Consulte a seção Como projetar tabelas de agregação da página de documentação Reconhecimento de agregados para conferir dicas sobre como otimizar suas tabelas de agregação para garantir que elas sejam usadas para reconhecimento de agregados.

Como acessar o LookML de uma tabela de agregação em um dashboard

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

A criação de tabelas de agregação pode melhorar drasticamente o desempenho de um painel, especialmente para blocos que consultam conjuntos de dados enormes.

Se você tiver a permissão develop, poderá acessar o LookML para criar tabelas de agregação para um dashboard. Para isso, abra o dashboard, selecione Acessar LookML no menu de três pontos do dashboard e escolha a guia Tabelas de agregação:

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

Copie e cole cada refinamento de Análise no arquivo de modelo associado, que é indicado no comentário que precede o refinamento de Análise. Se a Análise estiver definida em um arquivo de Análise separado, e não em um arquivo de modelo, você poderá adicionar o refinamento ao arquivo de Análise em vez do arquivo de modelo. Qualquer um dos locais vai funcionar.

Observação: o Looker dá a cada tabela de agregação um nome baseado nas dimensões da consulta do bloco. O Looker vai usar o mesmo nome para a tabela de agregação sempre que fornecer o LookML da tabela de agregação para a consulta de bloco. Considere outros refinamentos na Análise do bloco que podem ter sido adicionados anteriormente. Se você ou outro desenvolvedor já tiver recebido o LookML da tabela de agregação da consulta do bloco do painel, o Looker vai dar o mesmo nome à tabela de agregação. Se uma Análise tiver vários refinamentos, cada um com tabelas de agregação de 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 dashboard for aplicado a um bloco, o Looker vai adicionar a dimensão do filtro à tabela de agregação do bloco para que ela possa ser usada no bloco. Isso ocorre porque as tabelas de agregação só podem ser usadas para uma consulta se os campos de referência dos filtros da consulta estiverem disponíveis como dimensões na tabela de agregação. Consulte a página de documentação Aggregate awareness para mais informações.

Se você precisar modificar o LookML da tabela de agregação, use os parâmetros descritos na seção Como definir uma tabela de agregação no LookML nesta página. É possível renomear a tabela de agregação sem mudar a aplicabilidade dela ao bloco original do painel, mas qualquer outra mudança na tabela de agregação pode afetar a capacidade do Looker de usá-la no painel. Consulte a seção Como projetar tabelas de agregação da página de documentação Reconhecimento de agregados para conferir dicas sobre como otimizar suas tabelas de agregação para garantir que elas sejam usadas para reconhecimento de agregados.

Exemplo

O exemplo a seguir cria uma tabela de agregação monthly_orders para a Análise event. A tabela de agregação cria uma contagem mensal de pedidos. O Looker vai usar a tabela de agregação 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 datagroup orders_datagroup. Além disso, a tabela de agregação é definida com publish_as_db_view: yes, o que significa que o Looker vai criar uma visualização estável no banco de dados para a tabela de agregação.

A definição da tabela de agregação é 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 projetar tabelas de agregação da página de documentação Reconhecimento de agregação para conferir dicas sobre como criar tabelas de agregação de forma estratégica:

• Fatores de período
• Fatores de fuso horário
• Filtros
• Fatores de campo
• Fatores do tipo de medição

Suporte de dialeto para reconhecimento de agregados

A capacidade de usar o reconhecimento de agregação depende do dialeto do banco de dados que sua conexão do Looker está usando. Na versão mais recente do Looker, os seguintes dialetos são compatíveis com o reconhecimento de agregados:

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.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
ClickHouse 26+
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+
Dremio 26+ with Arrow Flight SQL
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
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
MongoSQL
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