Envie seu hack para o Looker Hackathon 2025 [Edição para o setor público] em breve! Ganhe um prêmio real de "Melhor hack" e mostre sua habilidade com dados. Confira as perguntas frequentes e as regras oficiais para mais informações.

Esta página foi traduzida pela API Cloud Translation.

Conhecimento agregado

Visão geral

O Looker usa a lógica de reconhecimento de agregação para encontrar a menor e mais eficiente tabela disponível no seu banco de dados e executar uma consulta, mantendo a precisão.

Para tabelas muito grandes no seu banco de dados, os desenvolvedores do Looker podem criar tabelas agregadas menores de dados, agrupadas por várias combinações de atributos. As tabelas agregadas funcionam como tabelas de resumo que o Looker pode usar para consultas sempre que possível, em vez da tabela grande original. Quando implementado estrategicamente, o reconhecimento agregado pode acelerar a consulta média em ordens de magnitude.

Por exemplo, você pode ter uma tabela de dados de petabyte com uma linha para cada pedido feito no seu site. Nesse banco de dados, você pode criar uma tabela agregada com os totais de vendas diárias. Se o site receber 1.000 pedidos por dia, a tabela agregada diária vai representar cada dia com 999 linhas a menos do que a tabela original. Você pode criar outra tabela agregada com os totais de vendas mensais, que será ainda mais eficiente. Agora, se um usuário executar uma consulta de vendas diárias ou semanais, o Looker vai usar a tabela de total de vendas diárias. Se um usuário executar uma consulta sobre vendas anuais e você não tiver uma tabela agregada anual, o Looker vai usar a melhor opção seguinte, que é a tabela agregada de vendas mensais neste exemplo.

O Looker responde às perguntas dos usuários com as menores tabelas agregadas sempre que possível. Exemplo:

Para uma consulta sobre o total de vendas mensais, o Looker usa a tabela agregada com base nas vendas mensais (sales_monthly_aggregate_table).
Para uma consulta sobre o total de cada venda em um dia, não há uma tabela agregada com essa granularidade. Portanto, o Looker recebe os resultados da consulta da tabela de banco de dados original (orders_database). No entanto, se os usuários executarem esse tipo de consulta com frequência, você poderá criar uma tabela agregada para ela.
Para uma consulta sobre vendas semanais, não há uma tabela de agregação semanal. Por isso, o Looker usa a melhor opção seguinte, que é a tabela de agregação com base nas vendas diárias (sales_daily_aggregate_table).

Usando a lógica de reconhecimento agregado, o Looker consulta a menor tabela agregada possível para responder às perguntas dos usuários. A tabela original seria usada apenas para consultas que exigem uma granularidade mais refinada do que as tabelas agregadas podem oferecer.

Não é necessário unir ou adicionar tabelas de agregação a uma análise detalhada separada. Em vez disso, o Looker ajusta dinamicamente a cláusula FROM da consulta do recurso "Explorar" para acessar a melhor tabela agregada para a consulta. Isso significa que os detalhamentos são mantidos e as análises detalhadas podem ser consolidadas. Com o reconhecimento de agregação, uma análise detalhada pode usar automaticamente tabelas agregadas, mas ainda analisar dados granulares, se necessário.

Você também pode usar tabelas de agregação para melhorar drasticamente a performance dos painéis, especialmente para blocos que consultam conjuntos de dados enormes. Para mais detalhes, consulte a seção Como extrair a LookML da tabela de agregação de um painel na página de documentação do parâmetro aggregate_table.

Adicionar tabelas de agregação ao projeto

Os desenvolvedores do Looker podem criar tabelas agregadas estratégicas que minimizam o número de consultas necessárias nas tabelas grandes de um banco de dados. As tabelas de agregação precisam ser persistidas no banco de dados para que possam ser acessadas pela percepção de agregação. Portanto, as tabelas de agregação são um tipo de tabela derivada persistente (PDT).

Uma tabela de agregação é definida usando o parâmetro aggregate_table em um parâmetro explore no projeto da LookML.

Confira um exemplo de explore com uma tabela de agregação em LookML:

explore: orders {
  label: "Sales Totals"
  join: order_items {
    sql_on: ${orders.id} = ${order_items.id} ;;
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [created_month]
      measures: [order_items.total_sales]
    }
  }
  # other explore parameters
}

Para criar uma tabela de agregação, escreva o LookML do zero ou use uma análise detalhada ou um painel. Consulte a página de documentação do parâmetro aggregate_table para saber mais sobre o parâmetro aggregate_table e os subparâmetros dele.

Como criar tabelas de agregação

Para que uma consulta do recurso "Explorar" use uma tabela agregada, ela precisa fornecer dados precisos para a consulta. O Looker pode usar uma tabela agregada para uma consulta do recurso "Explorar" se todas as condições a seguir forem verdadeiras:

Os campos da consulta do recurso Detalhar são um subconjunto dos campos da tabela agregada. Consulte a seção Fatores de campo nesta página. Ou, para períodos, os períodos da consulta de detalhamento podem ser derivados dos períodos na tabela agregada (consulte a seção Fatores de período nesta página).
A consulta do recurso Detalhar contém tipos de métricas compatíveis com o reconhecimento agregado (consulte a seção Fatores do tipo de métrica nesta página) ou tem uma tabela agregada que é uma correspondência exata (consulte a seção Como criar tabelas agregadas que correspondem exatamente às consultas do recurso Detalhar nesta página).
O fuso horário da consulta do recurso Detalhar corresponde ao fuso horário usado pela tabela agregada. Consulte a seção Fatores de fuso horário nesta página.
Os filtros da consulta de análise detalhada referenciam campos disponíveis como dimensões na tabela agregada, ou cada um dos filtros da consulta de análise detalhada corresponde a um filtro na tabela agregada. Consulte a seção Fatores de filtro nesta página.

Uma maneira de garantir que uma tabela agregada possa fornecer dados precisos para uma consulta do recurso Detalhar é criar uma tabela agregada que corresponda exatamente a uma consulta do recurso Detalhar. Consulte a seção Criar tabelas agregadas que correspondem exatamente às consultas do recurso Detalhar nesta página para mais detalhes.

Fatores de campo

Para ser usada em uma consulta do recurso Análise detalhada, uma tabela agregada precisa ter todas as dimensões e medidas necessárias para essa consulta, incluindo os campos usados para filtros. Se uma consulta do recurso "Analisar" contiver uma dimensão ou métrica que não está em uma tabela agregada, o Looker não poderá usar essa tabela e vai usar a tabela de base.

Por exemplo, se uma consulta agrupa pelas dimensões A e B, agrega pela métrica C e filtra pela dimensão D, a tabela agregada precisa ter, no mínimo, A, B e D como dimensões e C como uma métrica.

A tabela agregada também pode ter outros campos, mas precisa ter pelo menos os campos de consulta do recurso Detalhar para ser viável para otimização. A única exceção são as dimensões de período, já que períodos de granularidade mais grosseira podem ser derivados de períodos de granularidade mais refinada.

Devido a essas considerações de campo, uma tabela de agregação é específica do recurso "Explorar" em que ela é definida. Uma tabela agregada definida em uma análise detalhada não será usada para consultas em outra análise.

Fatores de período

A lógica de agregação do Looker consegue derivar um período de outro. Uma tabela de agregação pode ser usada em uma consulta desde que o período dela tenha uma granularidade mais refinada (ou igual) à da consulta de análise detalhada. Por exemplo, uma tabela agregada baseada em dados diários pode ser usada para uma consulta do recurso Detalhar que exige outros períodos, como consultas de dados diários, mensais e anuais, ou até mesmo dados de dia do mês, dia do ano e semana do ano. No entanto, uma tabela agregada anual não pode ser usada para uma consulta do recurso "Explorar" que exige dados por hora, já que os dados da tabela agregada não têm granularidade suficiente para a consulta.

O mesmo se aplica aos subconjuntos de período. Por exemplo, se você tiver uma tabela agregada filtrada para os últimos três meses e um usuário consultar os dados com um filtro para os últimos dois meses, o Looker poderá usar a tabela agregada para essa consulta.

Além disso, a mesma lógica se aplica a consultas com filtros de período: uma tabela agregada pode ser usada para uma consulta com um filtro de período, desde que o período da tabela agregada tenha uma granularidade mais refinada (ou igual) que o filtro de período usado na consulta do Explorar. Por exemplo, uma tabela de agregação com uma dimensão de período diário pode ser usada para uma consulta do recurso Detalhar que filtra por dia, semana ou mês.

Fatores do tipo de medição

Para que uma consulta do recurso "Explorar" use uma tabela agregada, as medidas nela precisam fornecer dados precisos para a consulta.

Por isso, apenas alguns tipos de métricas são compatíveis, conforme descrito nas seções a seguir:

Medidas com tipos compatíveis
Métricas definidas por expressões SQL
Medidas que não são definidas com ${TABLE}
Medidas que aproximam contagens distintas

Se uma consulta do recurso Detalhar usar qualquer outro tipo de métrica, o Looker vai usar a tabela original, não a agregada, para retornar os resultados. A única exceção é se a consulta do recurso "Explorar" for uma correspondência exata de uma consulta de tabela agregada, conforme descrito na seção Criar tabelas agregadas que correspondem exatamente às consultas do recurso "Explorar".

Caso contrário, o Looker vai usar a tabela original, não a agregada, para retornar resultados.

Medidas com tipos compatíveis

A percepção agregada pode ser usada em consultas detalhadas que usam medidas com estes tipos:

Para usar uma tabela agregada em uma consulta do recurso "Explorar", o Looker precisa operar nas medidas da tabela agregada para fornecer dados precisos na consulta. Por exemplo, uma métrica com type: sum pode ser usada para agregar informações porque é possível somar várias somas: uma tabela agregada de somas semanais pode ser adicionada para gerar uma soma mensal precisa. Da mesma forma, uma medida com type: max pode ser usada porque uma tabela agregada de máximos diários pode ser usada para encontrar o máximo semanal preciso.

No caso de medidas com type: average, a agregação de reconhecimento é compatível porque o Looker usa dados de soma e contagem para derivar valores médios com precisão de tabelas agregadas.

Métricas definidas com expressões SQL

A agregação de reconhecimento também pode ser usada com medidas definidas com expressões no parâmetro sql. Quando definidos com expressões SQL, os seguintes tipos de métricas também são aceitos:

A agregação de indicadores é compatível com medidas definidas como combinações de outras medidas, como este exemplo:

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

A otimização de agregação também é compatível com medidas em que os cálculos são definidos no parâmetro sql, como esta medida:

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

A compatibilidade com reconhecimento de agregação é oferecida para medidas em que as operações MIN, MAX e COUNT são definidas no parâmetro sql, como esta medida:

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

Medidas que se referem a campos do LookML

Quando as expressões sql são usadas em métricas, a agregação de dados é compatível com os seguintes tipos de referências de campo:

Referências usando o formato ${view_name.field_name}, que indica campos em outras visualizações
Referências usando o formato ${field_name}, que indica campos na mesma visualização

O reconhecimento de agregação não é compatível com medidas definidas usando o formato ${TABLE}.column_name, que indica uma coluna em uma tabela. Consulte a página de documentação Como incorporar SQL e se referir a objetos LookML para uma visão geral do uso de referências em LookML.

Por exemplo, uma métrica definida com esse parâmetro sql não seria compatível com uma tabela agregada, já que usa o formato ${TABLE}.column_name:

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

Se você quiser incluir essa métrica em uma tabela de agregação, crie uma dimensão definida com o formato ${TABLE}.column_name e uma métrica que faça referência a ela, assim:


 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

  measure: wholesale_value {
    type: number
    sql: (${total_sale_price} * 0.60) ;;
}

Agora você pode usar a métrica wholesale_value na sua tabela de agregação.

Medidas que aproximam contagens distintas

Em geral, as contagens distintas não são compatíveis com a percepção de agregação porque não é possível receber dados precisos se você tentar agregar contagens distintas. Por exemplo, se você estiver contando os usuários distintos em um site, pode haver um usuário que acessou o site duas vezes, com um intervalo de três semanas. Se você tentasse aplicar uma tabela de agregação semanal para receber uma contagem mensal de usuários distintos no seu site, esse usuário seria contado duas vezes na consulta mensal de contagem distinta, e os dados estariam incorretos.

Uma solução alternativa é criar uma tabela agregada que corresponda exatamente a uma consulta do recurso "Explorar", conforme descrito na seção Criar tabelas agregadas que correspondem exatamente a consultas do recurso "Explorar" desta página. Quando a consulta do recurso Explorar e uma consulta de tabela agregada são iguais, as medidas de contagem distinta fornecem dados precisos e podem ser usadas para o reconhecimento de agregação.

Outra opção é usar aproximações para contagens distintas. Para dialetos que aceitam sketches do HyperLogLog, o Looker pode usar o algoritmo HyperLogLog para aproximar contagens distintas de tabelas de agregação.

O algoritmo HyperLogLog tem um erro de cerca de 2%. O parâmetro allow_approximate_optimization: yes exige que os desenvolvedores do Looker confirmem que é possível usar dados aproximados para a métrica. Assim, ela pode ser calculada aproximadamente em tabelas agregadas.

Consulte a página de documentação do parâmetro allow_approximate_optimization para mais informações e a lista de dialetos que oferecem suporte à contagem de valores distintos usando HyperLogLog.

Fatores de fuso horário

Em muitos casos, os administradores de banco de dados usam o UTC como fuso horário para bancos de dados. No entanto, muitos usuários podem não estar no fuso horário UTC. O Looker tem várias opções para converter fusos horários e mostrar aos usuários os resultados da consulta no fuso horário deles:

Fuso horário da consulta, uma configuração que se aplica a todas as consultas na conexão do banco de dados. Se todos os usuários estiverem no mesmo fuso horário, você poderá definir um único fuso horário de consulta para que todas as consultas sejam convertidas do fuso horário do banco de dados para o fuso horário da consulta.
Fusos horários específicos do usuário, em que os usuários podem ser atribuídos e selecionar fusos horários individualmente. Nesse caso, as consultas são convertidas do fuso horário do banco de dados para o fuso horário do usuário individual.

Consulte a página de documentação Usar configurações de fuso horário para mais informações sobre essas opções.

Esses conceitos são importantes para entender a percepção de agregação porque, para que uma tabela agregada seja usada em uma consulta com dimensões ou filtros de data, o fuso horário na tabela agregada precisa corresponder à configuração de fuso horário usada na consulta original.

As tabelas de agregação usam o fuso horário do banco de dados se nenhum valor timezone for especificado. Sua conexão de banco de dados também usará o fuso horário do banco de dados se alguma das seguintes condições for verdadeira:

Seu banco de dados não é compatível com fusos horários.
O fuso horário da consulta da conexão de banco de dados está definido como o mesmo fuso horário do banco de dados.
Sua conexão de banco de dados não tem um fuso horário de consulta especificado nem fusos horários específicos do usuário. Se for esse o caso, a conexão do banco de dados usará o fuso horário dele.

Se alguma dessas opções for verdadeira, você poderá omitir o parâmetro timezone das tabelas agregadas.

Caso contrário, o fuso horário da tabela agregada precisa ser definido para corresponder a possíveis consultas, aumentando a probabilidade de uso da tabela agregada:

Se a conexão do banco de dados usar um único fuso horário de consulta, faça a correspondência entre o valor timezone da tabela agregada e o valor do fuso horário de consulta.
Se a conexão do banco de dados usar fusos horários específicos do usuário, crie tabelas agregadas idênticas, cada uma com um valor timezone diferente para corresponder aos possíveis fusos horários dos usuários.

Filtrar fatores

Tenha cuidado ao incluir filtros na tabela de agregação. Os filtros em uma tabela agregada podem restringir os resultados a ponto de torná-la inutilizável. Por exemplo, digamos que você crie uma tabela de agregação para contagens diárias de pedidos, e essa tabela filtre apenas os pedidos de óculos de sol da Austrália. Se um usuário executar uma consulta do recurso Explorar para contagens diárias de pedidos de óculos de sol no mundo todo, o Looker não poderá usar a tabela agregada para essa consulta, já que ela só tem os dados da Austrália. A tabela agregada filtra os dados de maneira muito restrita para serem usados pela consulta de análise detalhada.

Além disso, fique atento aos filtros que os desenvolvedores do Looker podem ter criado na sua Análise, como:

access_filters: aplica restrições de dados específicos do usuário.
always_filter: exige que os usuários incluam um determinado conjunto de filtros para uma consulta do recurso Detalhar. Os usuários podem mudar o valor padrão do filtro para a consulta, mas não podem remover o filtro completamente.
conditionally_filter: define um conjunto de filtros padrão que os usuários podem substituir se aplicarem pelo menos um filtro de uma segunda lista também definida na análise detalhada.

Esses tipos de filtro são baseados em campos específicos. Se a análise detalhada tiver esses filtros, inclua os campos deles no parâmetro dimensions do aggregate_table.

Por exemplo, confira uma análise detalhada com um filtro de acesso baseado no campo orders.region:

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

Para criar uma tabela agregada que seria usada nessa Análise, ela precisa incluir o campo em que o filtro de acesso se baseia. No exemplo a seguir, o filtro de acesso é baseado no campo orders.region, e esse mesmo campo é incluído como uma dimensão na tabela de agregação:

explore: orders {
  access_filter: {
    field: orders.region  # <-- orders.region field
    user_attribute: region
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_day, orders.region] # <-- orders.region field
      measures: [orders.total_sales]
      timezone: America/Los_Angeles
    }
  }
}

Como a consulta da tabela de agregação inclui a dimensão orders.region, o Looker pode filtrar dinamicamente os dados na tabela de agregação para corresponder ao filtro da consulta do Explorar. Portanto, o Looker ainda pode usar a tabela agregada para as consultas da análise, mesmo que ela tenha um filtro de acesso.

Isso também se aplica a consultas do recurso "Explorar" que usam uma tabela derivada nativa configurada com bind_filters. O parâmetro bind_filters transmite filtros especificados de uma consulta do recurso Detalhar para a subconsulta de tabela derivada nativa. No caso da agregação, se a consulta do Explorar exigir uma tabela derivada nativa que use bind_filters, ela só poderá usar uma tabela agregada se todos os campos usados no parâmetro bind_filters da tabela derivada nativa tiverem exatamente os mesmos valores de filtro na consulta do Explorar e na tabela agregada.

Como criar tabelas agregadas que correspondem exatamente às consultas do recurso Detalhar

Uma maneira de garantir que uma tabela agregada pode ser usada em uma consulta de análise é criar uma tabela agregada que corresponda exatamente à consulta de análise. Se a consulta do recurso Detalhar e a tabela agregada usarem as mesmas métricas, dimensões, filtros, fusos horários e outros parâmetros, os resultados da tabela agregada serão aplicados à consulta do recurso Detalhar. Se uma tabela agregada for uma correspondência exata de uma consulta do recurso Explorar, o Looker poderá usar tabelas agregadas que incluem qualquer tipo de métrica.

É possível criar uma tabela de agregação em uma análise detalhada usando a opção Acessar LookML no menu de engrenagem de uma Análise detalhada. Você também pode criar correspondências exatas para todos os blocos em um painel usando a opção Receber LookML no menu de engrenagem de um painel.

Como determinar qual tabela agregada é usada para uma consulta

Os usuários com permissões see_sql podem usar os comentários na guia SQL de uma análise detalhada para saber qual tabela agregada será usada em uma consulta. Os comentários da guia SQL também são mostrados no Modo de desenvolvimento. Assim, os desenvolvedores podem testar novas tabelas agregadas para ver como o Looker as usa antes de enviar novas tabelas para produção.

Por exemplo, com base na tabela de agregação mensal de exemplo mostrada anteriormente, acesse a análise detalhada e execute uma consulta para totais de vendas anuais. Em seguida, clique na guia SQL para conferir os detalhes da consulta criada pelo Looker. Se você estiver no modo de desenvolvimento, o Looker vai mostrar comentários para indicar a tabela agregada usada na consulta.

Nos comentários a seguir na guia SQL, podemos ver que o Looker está usando a tabela agregada sales_monthly para essa consulta, além de informações sobre por que outras tabelas agregadas não foram usadas:

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

Consulte a seção Solução de problemas nesta página para ver possíveis comentários na guia SQL e sugestões de como resolver os problemas.

Estimativas de economia de computação para percepção agregada

Se a conexão com o banco de dados oferecer suporte a estimativas de custo e se uma tabela agregada puder ser usada em uma consulta, a janela "Explorar" vai mostrar a economia de computação ao usar a tabela agregada em vez de consultar o banco de dados diretamente. A economia agregada de reconhecimento é mostrada ao lado do botão Executar em uma análise detalhada antes da execução da consulta.

Antes de executar a consulta, se quiser saber qual tabela agregada será usada, clique na guia SQL, conforme descrito na seção Determinar qual tabela agregada é usada para uma consulta desta página de documentação.

Depois que a consulta for executada, a janela "Explorar" vai mostrar qual tabela agregada foi usada para responder à consulta ao lado do botão Executar.

A economia agregada de conscientização é mostrada para conexões de banco de dados ativadas para estimativas de custo. Consulte a página de documentação Analisar dados no Looker para mais informações.

O Looker une novos dados às suas tabelas de agregação

Para tabelas de agregação com filtros de tempo, o Looker pode unir dados atualizados à sua tabela de agregação. Você pode ter uma tabela agregada com dados dos últimos três dias, mas ela pode ter sido criada ontem. A tabela agregada não teria as informações de hoje, então não seria possível usá-la para uma consulta do recurso Detalhar sobre as informações diárias mais recentes.

No entanto, o Looker ainda pode usar os dados dessa tabela agregada para a consulta, porque ele executa uma consulta nos dados mais recentes e une esses resultados aos resultados na tabela agregada.

O Looker pode unir dados atualizados com os da tabela agregada nas seguintes circunstâncias:

A tabela de agregação tem um filtro de período.
A tabela de agregação inclui uma dimensão com base no mesmo campo de tempo do filtro de tempo.

Por exemplo, a tabela agregada a seguir tem uma dimensão baseada no campo orders.created_date e um filtro de período ("3 days") baseado no mesmo campo:

aggregate_table: sales_last_3_days {
  query:  {
    dimensions: [orders.created_date]
    measures: [order_items.total_sales]
    filters: [orders.created_date: "3 days"]  # <-- time filter
    timezone: America/Los_Angeles
  }
  ...
}

Se essa tabela agregada foi criada ontem, o Looker vai extrair os dados mais recentes que ainda não estão incluídos nela e unir os resultados atualizados com os resultados da tabela agregada. Isso significa que seus usuários vão receber os dados mais recentes e otimizar o desempenho usando a percepção agregada.

Se você estiver no modo de desenvolvimento, clique na guia SQL de uma análise detalhada para conferir a tabela agregada usada pelo Looker na consulta e a instrução UNION usada para trazer dados mais recentes que não estavam incluídos na tabela agregada.

As tabelas de agregação precisam ser persistentes

Para ser acessível para reconhecimento de agregação, a tabela de agregação precisa ser persistida no banco de dados. A estratégia de persistência é especificada no parâmetro materialization da tabela agregada. Como as tabelas de agregação são um tipo de tabela derivada persistente (PDT), elas têm os mesmos requisitos das PDTs. Consulte a página de documentação Tabelas derivadas no Looker para mais detalhes.

É possível criar PDTs incrementais no seu projeto se o dialeto for compatível com elas. O Looker cria PDTs incrementais anexando dados novos à tabela, em vez de recriá-la por completo. Como as tabelas agregadas são um tipo de PDT, também é possível criar tabelas agregadas incrementais. Consulte a página de documentação PDTs incrementais para mais informações. Consulte a página de documentação do parâmetro increment_key para ver um exemplo de uma tabela de agregação incremental.

Um usuário com a permissão develop pode substituir as configurações de persistência e recriar todas as tabelas agregadas de uma consulta para receber os dados mais atualizados. Para recriar as tabelas de uma consulta, selecione a opção Recriar tabelas derivadas e executar no menu de engrenagem Abrir ações.

Aguarde o carregamento da consulta do recurso Detalhar para que essa opção fique disponível.

A opção Recriar tabelas derivadas e executar recria todas as tabelas derivadas referenciadas na consulta, bem como as tabelas derivadas de que as tabelas na consulta dependem. Isso inclui tabelas de agregação, que são um tipo de tabela derivada persistente.

Para o usuário que inicia a opção Recriar tabelas derivadas e executar, a consulta aguarda a recriação das tabelas antes de carregar os resultados. As consultas de outros usuários ainda vão usar as tabelas atuais. Depois que as tabelas persistentes forem recriadas, todos os usuários vão usar as tabelas recriadas.

Consulte a página de documentação Tabelas derivadas no Looker para mais detalhes sobre a opção Recriar tabelas derivadas e executar.

Solução de problemas

Conforme descrito na seção Determinar qual tabela agregada é usada para uma consulta, se você estiver no Modo de desenvolvimento, poderá executar consultas na Análise detalhada e clicar na guia SQL para ver comentários sobre a tabela agregada usada para a consulta, se houver.

A guia SQL também inclui comentários sobre por que as tabelas agregadas não foram usadas em uma consulta, se for o caso. Para tabelas agregadas que não são usadas, o comentário começa com:

Did not use [explore name]::[aggregate table name];

Por exemplo, confira um comentário sobre por que a tabela agregada sales_daily definida na análise detalhada order_items não foi usada em uma consulta:

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

Nesse caso, os filtros na consulta impediram o uso da tabela agregada.

A tabela a seguir mostra outros motivos possíveis para não usar uma tabela agregada, além das etapas que você pode seguir para aumentar a usabilidade dela.

Motivo para não usar a tabela de agregação	Explicação e possíveis etapas
Esse campo não existe na análise detalhada.	Há um erro de tipo de validação do LookML. Isso provavelmente aconteceu porque a tabela de agregação não foi definida corretamente ou porque houve um erro de digitação na LookML dela. Um possível culpado é um nome de campo incorreto ou algo parecido. Para resolver isso, verifique se as dimensões e métricas na tabela agregada correspondem aos nomes dos campos na análise detalhada. Consulte a página de documentação do parâmetro `aggregate_table` para mais informações sobre como definir uma tabela agregada.
A tabela de agregação não inclui os seguintes campos na consulta.	Para ser usada em uma consulta do recurso Análise detalhada, uma tabela agregada precisa ter todas as dimensões e medidas necessárias para essa consulta, incluindo os campos usados para filtros. Se uma consulta do recurso "Analisar" contiver uma dimensão ou métrica que não está em uma tabela agregada, o Looker não poderá usar essa tabela e vai usar a tabela de base. Consulte a seção Fatores de campo nesta página para mais detalhes. A única exceção são as dimensões de período, já que períodos de granularidade mais grosseira podem ser derivados de períodos de granularidade mais refinada. Para resolver isso, verifique se os campos da consulta de detalhamento estão incluídos na definição da tabela agregada.
A consulta continha os seguintes filtros que não foram incluídos como campos nem correspondidos exatamente por filtros na tabela de agregação.	Os filtros na consulta do recurso "Analisar" impedem que o Looker use a tabela de agregação. Para resolver isso, faça uma das seguintes ações: Adicione o mesmo filtro à sua tabela de agregação. Adicione à tabela de agregação o campo usado pelo filtro. Remova os filtros da consulta do recurso Detalhar. Consulte a seção Filtrar fatores nesta página para mais detalhes.
A consulta contém as seguintes medidas que não podem ser acumuladas.	A consulta contém um ou mais tipos de métricas que não são compatíveis com a otimização de agregação, como contagem distinta, mediana ou percentil. Para resolver isso, verifique o tipo de cada métrica na consulta e confira se é um dos tipos de métricas compatíveis. Além disso, se a análise detalhada tiver junções, verifique se as métricas não foram convertidas em métricas distintas (agregações simétricas) por junções ramificadas. Consulte a seção Agregações simétricas para análises detalhadas com junções nesta página para uma explicação.
Uma tabela agregada diferente era mais adequada para otimização.	Havia várias tabelas agregadas viáveis para a consulta, e o Looker encontrou uma tabela agregada mais adequada para usar. Não é necessário fazer nada nesse caso.
O Looker não fez nenhum agrupamento (devido a um parâmetro `primary_key` ou `cancel_grouping_fields`), e, portanto, não é possível resumir a consulta.	A consulta faz referência a uma dimensão que impede o uso de uma cláusula `GROUP BY`. Portanto, o Looker não pode usar nenhuma tabela agregada para a consulta. Para resolver isso, verifique se o parâmetro `primary_key` da visualização e o parâmetro `cancel_grouping_fields` da análise detalhada estão configurados corretamente.
A tabela de agregação continha filtros que não estavam na consulta.	A tabela de agregação tem um filtro que não é de tempo e não está na consulta. Para resolver isso, remova o filtro da tabela de agregação. Consulte a seção Filtrar fatores nesta página para mais detalhes.
Um campo é definido como somente para filtro na consulta do recurso Detalhar, mas é listado no parâmetro `dimensions` da tabela de agregação.	O parâmetro `dimensions` da tabela agregada lista um campo definido apenas como um campo `filter` na consulta do recurso Detalhar. Para resolver isso, remova o campo da lista `dimensions` da tabela de agregação. Se esse campo for necessário para a tabela agregada, adicione-o à lista `filters` na consulta da tabela agregada.
O otimizador não consegue determinar por que a tabela agregada não foi usada.	Este comentário é reservado para casos extremos. Se isso acontecer com uma consulta de análise detalhada usada com frequência, crie uma tabela agregada que corresponda exatamente à consulta. É possível acessar a tabela de agregação do LookML em uma análise detalhada, conforme descrito na página do parâmetro `aggregate_table`.

Informações importantes

Agregações simétricas para análises detalhadas com junções

É importante observar que, em uma análise detalhada que combina várias tabelas de banco de dados, o Looker pode renderizar medidas do tipo SUM, COUNT e AVERAGE como SUM DISTINCT, COUNT DISTINCT e AVERAGE DISTINCT, respectivamente. O Looker faz isso para evitar erros de cálculo de fanout. Por exemplo, uma medida count é renderizada como um tipo de medida count_distinct. Isso evita cálculos incorretos de fanout para junções e faz parte da funcionalidade de agregação simétrica do Looker. Consulte a página de práticas recomendadas sobre agregações simétricas para uma explicação desse recurso do Looker.

A funcionalidade de agregação simétrica evita erros de cálculo, mas também pode impedir que suas tabelas de agregação sejam usadas em determinados casos. Por isso, é importante entender.

Para os tipos de métricas compatíveis com o reconhecimento de agregação, isso se aplica a sum, count e average. O Looker vai renderizar esses tipos de medidas como DISTINCT se:

A medida é da visualização "um" de uma junção muitos para um ou um para muitos.
A medida é de qualquer visualização de uma junção muitos-para-muitos.

Consulte a página de documentação do parâmetro relationship para uma explicação sobre esses tipos de junções.

Se você descobrir que sua tabela agregada não está sendo usada por esse motivo, crie uma tabela agregada que corresponda exatamente a uma consulta do recurso Explorar para usar esses tipos de métricas em uma análise detalhada com junções. Consulte a seção Criar tabelas agregadas que correspondem exatamente às consultas do recurso Detalhar nesta página para mais informações.

Além disso, se você tiver um dialeto SQL que ofereça suporte a esboços HyperLogLog, adicione o parâmetro allow_approximate_optimization: yes à métrica. Quando uma medida de contagem é definida com allow_approximate_optimization: yes, o Looker pode usar a medida para reconhecimento de agregação, mesmo que ela seja renderizada como uma contagem distinta.

Consulte a página de documentação do parâmetro allow_approximate_optimization para mais detalhes e uma lista de quais dialetos SQL são compatíveis com esboços HyperLogLog.

Compatibilidade com dialetos para percepção agregada

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

Suporte a dialetos para criar tabelas agregadas de forma incremental

Para que o Looker seja compatível com tabelas agregadas incrementais no seu projeto do Looker, o dialeto do banco de dados também precisa ser compatível com elas. A tabela a seguir mostra quais dialetos são compatíveis com a criação incremental de PDTs na versão mais recente do Looker:

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