Reconhecimento agregado

Para ver um guia sobre a implementação do reconhecimento agregado, consulte também nossa página de tutorial sobre reconhecimento agregado.

Informações gerais

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

Para tabelas muito grandes no banco de dados, os desenvolvedores do Looker podem criar tabelas de dados menores e 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 de usar a tabela grande original. Quando implementado estrategicamente, o reconhecimento agregado pode acelerar a consulta média por ordem de grandeza.

Por exemplo, você pode ter uma tabela de dados em escala de petabytes com uma linha para cada pedido que ocorreu no seu website. A partir desse banco de dados, você pode criar uma tabela agregada com os totais diários de vendas. Se o site recebe mil pedidos por dia, a tabela de agregação diária representa 999 linhas a menos do que a tabela original. Você pode criar outra tabela agregada com totais de vendas mensais que serão ainda mais eficientes. Agora, se um usuário fizer uma consulta de vendas diárias ou semanais, a Looker usará a tabela de vendas totais diárias. Se um usuário executar uma consulta sobre vendas anuais e você não tiver uma tabela de agregação anual, o Looker usará a próxima melhor opção, que é a tabela de vendas mensais neste exemplo.

O Looker responde às perguntas dos seus usuários com as menores tabelas de agregação 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. Por isso, o Looker recebe os resultados da tabela original do banco de dados (orders_database). No entanto, se seus usuários fazem esse tipo de consulta com frequência, é fácil 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 próxima melhor opção, 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 consultará a menor tabela de agregação possível para responder às perguntas dos usuários. A tabela original seria usada apenas para consultas que exigem granularidade maior do que as tabelas agregadas podem fornecer.

As tabelas agregadas não precisam ser mescladas ou adicionadas a uma exploração separada. Em vez disso, o Looker ajusta dinamicamente a cláusula FROM da consulta "Explorar" para acessar a melhor tabela agregada. Isso significa que seus tempos de interação são mantidos, e a guia "Explorar" pode ser consolidada. Com o reconhecimento agregado, uma exploração pode aproveitar automaticamente as tabelas agregadas, mas ainda assim analisar os dados granulares se necessário.

Também é possível aproveitar as tabelas agregadas para melhorar drasticamente o desempenho dos painéis, especialmente para blocos que consultam grandes conjuntos de dados. Veja mais detalhes na seção Como conseguir uma tabela de agregação do LookML de um painel na página de documentação do parâmetro aggregate_table.

Como adicionar tabelas de agregação ao projeto

Para serem acessíveis para o conhecimento agregado, as tabelas de agregação precisam ser mantidas no seu banco de dados. Como as tabelas de agregação são um tipo de tabela derivada permanente (PDT, na sigla em inglês), elas têm os mesmos requisitos que as tabelas de agregação. Consulte a página de documentação Tabelas derivadas no Looker para mais detalhes.

Os desenvolvedores do Looker podem criar tabelas de agregação estratégicas que minimizarão o número de consultas necessárias nas tabelas grandes de um banco de dados. As tabelas de agregação precisam manter o banco de dados para que possam ser acessadas. Portanto, as tabelas agregadas são um tipo de tabela derivada permanente (PDT, na sigla em inglês).

Uma tabela agregada é definida usando o parâmetro aggregate_table em um parâmetro explore no projeto LookML.

Veja um exemplo de explore com uma tabela agregada 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 agregada, você pode gravar o LookML do zero ou fazer isso em um painel Explorar ou em um painel. Consulte a página de documentação do parâmetro aggregate_table para ver detalhes específicos do parâmetro aggregate_table e dos subparâmetros dele.

Como projetar tabelas de agregação

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

• Os campos da consulta "Explorar" são um subconjunto dos campos da tabela agregada. Consulte a seção Fatores de campo nesta página. Ou então, os períodos da consulta "Explorar" podem ser derivados dos períodos na tabela de agregação. Consulte a seção Fatores de período nesta página.
• A consulta "Explorar" contém tipos de medidas compatíveis com o reconhecimento agregado (consulte a seção Medir os tipos de tipo nesta página) ou a consulta "Explorar" tem uma tabela de agregação que tem correspondência exata. Consulte a seção Como criar tabelas agregadas que correspondem exatamente às consultas "Explorar".
• O fuso horário da consulta "Explorar" corresponde ao fuso horário usado pela tabela de agregação. Consulte a seção Fatores de fuso horário nesta página.
• Os campos de referência dos filtros da consulta "Explorar" estão disponíveis como dimensões na tabela agregada, ou os filtros da consulta "Explorar" correspondem 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 "Explorar" é simplesmente criar uma tabela agregada que corresponda exatamente a uma consulta "Explorar". Consulte a seção Como criar tabelas agregadas que correspondem exatamente a "Explorar consultas" nesta página para mais detalhes.

Fatores de campo

Para ser usada em uma consulta "Explorar", uma tabela agregada precisa ter todas as dimensões e medidas necessárias para ela, incluindo os campos usados nos filtros da consulta em "Explorar". Se uma consulta de exploração contém uma dimensão ou medida que não está em uma tabela de agregação, o Looker não pode usar a tabela de agregação e usará a tabela de base.

Por exemplo, se uma consulta agrupa pelas dimensões A e B, agrega pela medida C e filtra na dimensão D, a tabela de agregação precisa ter A, B e D minimamente como dimensões e C como medida.

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

Devido a essas considerações de campo, uma tabela agregada é específica para a exploração em que é definida. Uma tabela agregada definida em uma exploração não será usada para consultas em uma exploração diferente.

Fatores de prazo

A lógica de reconhecimento agregado do Looker consegue derivar um período de outro. Uma tabela agregada pode ser usada para uma consulta, desde que o período da tabela agregada tenha uma granularidade mais (ou igual) que a da consulta "Explorar". Por exemplo, uma tabela agregada com base em dados diários pode ser usada para uma consulta "Explorar" que precise de outros períodos, como consultas de dados diários, mensais e anuais ou até dados do dia do mês, dia do ano e semana do ano. No entanto, não é possível usar uma tabela de agregação anual para uma consulta de exploração que exige dados por hora, já que os dados da tabela agregada não têm granularidade suficiente para a consulta em "Explorar".

O mesmo se aplica aos subconjuntos de períodos. 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 (ou igual) que o filtro de período usado na consulta "Explorar". Por exemplo, uma tabela agregada com uma dimensão de período diário pode ser usada para uma consulta "Explorar" que filtra por dia, semana ou mês.

Medir os fatores de tipo

Para que uma consulta "Explorar" use uma tabela agregada, as medidas nela precisam ser capazes de fornecer dados precisos.

Por isso, somente determinados tipos de medidas são permitidos, conforme descrito nas seções a seguir:

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

Se uma consulta "Explorar" usar qualquer outro tipo de medida, a Looker usará a tabela original, não a tabela agregada, para retornar resultados. A única exceção é se a consulta "Explorar" for uma correspondência exata de uma consulta de tabela agregada, conforme descrito na seção Como criar tabelas agregadas que correspondem exatamente às consultas "Explorar".

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

Medidas com tipos de medidas compatíveis

O reconhecimento agregado pode ser usado em consultas "Explorar" que usam medidas com estes tipos de medição:

• ponderada
• count
• min
• max
• média

Se uma ferramenta Explorar mesclar várias tabelas de banco de dados, o Looker poderá renderizar medidas dos tipos 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, conforme descrito na seção Agregações simétricas para explorações com mesclagens nesta página.

Para usar uma tabela agregada em uma consulta "Explorar", o Looker precisa operar nas medidas da tabela agregada para fornecer dados precisos. Por exemplo, uma medida com type: sum pode ser usada para aumentar o reconhecimento agregado, porque você pode somar várias somas: uma tabela agregada de somas semanais pode ser adicionada para ver uma soma mensal precisa. Da mesma forma, uma medida com type: max pode ser usada porque uma tabela agregada de valores máximos diários pode ser usada para encontrar o máximo semanal preciso.

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

Medidas definidas com expressões SQL

O reconhecimento agregado também pode ser usado com medidas definidas com expressões no parâmetro sql. Quando definidos com expressões SQL, os seguintes tipos de medidas também são compatíveis:

• number
• date
• string
• sim

O reconhecimento agregado é 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} ;;
}

O reconhecimento agregado 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) ;;
}

O reconhecimento agregado é compatível com 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})
}

O reconhecimento agregado é compatível apenas com operações MIN(), MAX() e COUNT(). Se você quiser usar uma medida média ou de soma na tabela agregada, crie uma medida type: average ou type: sum compatíveis com o reconhecimento agregado.

Medidas que se referem aos campos do LookML

Quando expressões sql são usadas em medidas, o reconhecimento agregado é compatível com os seguintes tipos de referências de campo:

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

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

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

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

Se você quiser incluir essa medida em uma tabela agregada, crie uma dimensão definida com o formato ${TABLE}.column_name e uma medida que faça referência a ela, desta forma:

 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 medida wholesale_value na tabela agregada.

Medidas que aproximam contagens distintas

Em geral, contagens diferentes não são compatíveis com o reconhecimento agregado, pois você não conseguirá dados precisos se tentar agregar contagens distintas. Por exemplo, se você estiver contando os usuários diferentes em um site, pode haver um usuário que acessou o site duas vezes, com três semanas de intervalo. Se você tentar aplicar uma tabela de agregação semanal para conseguir uma contagem mensal de usuários diferentes no seu site, esse usuário será contado duas vezes na sua consulta de contagem mensal, e os dados ficarão incorretos.

Uma solução alternativa é criar uma tabela agregada que corresponda exatamente a uma consulta "Explorar", conforme descrito na seção Como criar tabelas agregadas que correspondem exatamente a "Consultas de pesquisa" nesta página. Quando a consulta "Explorar" e uma consulta de tabela agregada são as mesmas, dados de contagem diferentes fornecem dados precisos, de modo que podem ser usados para o reconhecimento agregado.

Outra opção é usar aproximações para contagens distintas. Para dialetos compatíveis com esboços do HyperLogLog, o Looker pode aproveitar o algoritmo do HyperLogLog para aproximar contagens distintas para tabelas agregadas.

Sabe-se que o algoritmo HyperLogLog tem um erro de cerca de 2%. O parâmetro allow_approximate_optimization: yes exige que os desenvolvedores do Looker reconheçam que não há problema em usar dados aproximados para a medida. Assim, ela pode ser calculada aproximadamente a partir das tabelas de agregação.

Consulte a página de documentação do parâmetro allow_approximate_optimization para mais informações e para ver a lista de dialetos compatíveis com a contagem distinta usando HyperLogLog.

Fatores de fuso horário

Em muitos casos, os administradores de banco de dados usam UTC como fuso horário para bancos de dados. No entanto, é possível que muitos usuários não estejam no fuso horário UTC. O Looker tem várias opções para converter fusos horários para que os usuários recebam os resultados da consulta no próprio fuso horário:

• 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 seus usuários estiverem no mesmo fuso horário, você poderá definir um único fuso horário 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, onde 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 Como usar configurações de fuso horário para mais informações sobre essas opções.

Esses conceitos são importantes para entender o reconhecimento agregado, pois, para uma tabela agregada ser usada em uma consulta com dimensões ou filtros de data, o fuso horário da tabela agregada precisa corresponder à configuração de fuso horário usada para a consulta original.

As tabelas agregadas 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 qualquer uma 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 do banco de dados está definido para 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 específico nem fusos horários específicos do usuário. Se esse for o caso, sua conexão de banco de dados usará o fuso horário do banco de dados.

Se algum deles for verdadeiro, você poderá omitir o parâmetro timezone das tabelas de agregação.

Caso contrário, o fuso horário da tabela agregada deve ser definido para corresponder às possíveis consultas, de modo que a tabela agregada tenha mais chances de ser usada:

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

O Looker não poderá usar uma tabela agregada para uma consulta "Explorar" se o fuso horário dela não corresponder ao fuso na consulta. Se a conexão do seu banco de dados tiver fusos horários específicos do usuário, isso significa que você precisa de uma tabela de agregação separada para cada fuso horário do usuário.

Filtrar fatores

Tenha cuidado ao incluir filtros em sua tabela de agregação. Os filtros em uma tabela agregada podem restringir os resultados ao ponto em que a tabela não pode ser usada. Por exemplo, digamos que você crie uma tabela agregada para contagens diárias de pedidos e os filtros da tabela agregada apenas para pedidos de óculos escuros provenientes da Austrália. Se um usuário executar uma consulta "Explorar" para ver a contagem diária de óculos de sol no mundo todo, o Looker não poderá usar a tabela agregada para essa consulta, já que ela tem apenas os dados da Austrália. A tabela de agregação filtra os dados de maneira muito restrita para serem usados pela consulta "Explorar".

Além disso, considere os filtros que os desenvolvedores do Looker podem ter integrado ao seu Explorar, como:

• access_filters: aplica restrições de dados específicas do usuário.
• always_filter: exige que os usuários incluam um determinado conjunto de filtros em uma consulta de exploração. Os usuários podem alterar o valor de filtro padrão da consulta, mas não podem remover o filtro por completo.
• conditionally_filter: define um conjunto de filtros padrão que os usuários podem modificar se aplicarem pelo menos um filtro de uma segunda lista que também esteja definido em "Explorar".

Esses tipos de filtro são baseados em campos específicos. Se a opção Explorar tiver esses filtros, você precisará incluir os campos dela no parâmetro dimensions do aggregate_table.

Por exemplo, veja uma exploração 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 para essa exploração, a tabela de agregação precisa incluir o campo em que o filtro de acesso se baseia. No próximo exemplo, o filtro de acesso é baseado no campo orders.region, que está 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 agregada inclui a dimensão orders.region, o Looker pode filtrar dinamicamente os dados na tabela agregada para corresponder ao filtro da consulta "Explorar". Portanto, o Looker ainda pode usar a tabela agregada para as consultas da ferramenta, mesmo que ela tenha um filtro de acesso.

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

Criar tabelas agregadas que correspondam exatamente às consultas "Explorar"

Uma maneira de garantir que uma tabela agregada possa ser usada para uma consulta "Explorar" é simplesmente criar uma tabela agregada que corresponda exatamente à consulta "Explorar". Se a consulta "Explorar" e a tabela agregada usarem as mesmas medidas, dimensões, filtros, fusos horários e outros parâmetros, os resultados da tabela agregada serão aplicados à consulta "Explorar". Se uma tabela agregada corresponder exatamente a uma consulta "Explorar", o Looker poderá usar tabelas agregadas que incluem qualquer tipo de medida.

É possível criar uma tabela agregada a partir de uma exploração usando a opção Conseguir LookML no menu de roda dentada de uma exploração. Você também pode criar correspondências exatas para todos os blocos em um painel usando a opção Receber LookML no menu de roda dentada de um painel.

Como determinar qual tabela de agregação é usada em uma consulta

Os usuários com permissões see_sql podem usar os comentários na guia SQL de uma exploração para ver qual tabela de agregação será usada para uma consulta. Os comentários da guia SQL também são exibidos no Modo de desenvolvimento, para que os desenvolvedores possam testar novas tabelas de agregação para ver como o Looker as utiliza antes de enviá-las para produção.

Por exemplo, com base no exemplo de tabela de agregação mensal mostrada anteriormente, você pode acessar "Explorar" e fazer uma consulta de totais de vendas anuais. Depois, clique na guia SQL para ver os detalhes da consulta que o Looker criou. Se você estiver no modo de desenvolvimento, o Looker mostrará comentários para indicar a tabela de agregação usada para a consulta.

A partir dos comentários na guia SQL, podemos ver que o Looker está usando a tabela de agregação sales_monthly para essa consulta e informações sobre por que outras tabelas de agregação não foram usadas para a consulta:

-- 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 os possíveis comentários na guia SQL e sugestões sobre como resolvê-los.

Estimativas de economia de computação para reconhecimento agregado

Se sua conexão do banco de dados for compatível com as estimativas de custo e se uma tabela agregada puder ser usada para uma consulta, a janela "Explorar" mostrará a economia de uso da tabela agregada em vez de consultar o banco de dados diretamente. A economia de reconhecimento agregada é mostrada à esquerda do botão Executar em uma exploração antes da execução da consulta:

Antes de executar a consulta, se você quiser ver qual tabela de agregação será usada para a consulta, clique na guia SQL, conforme descrito na seção Como determinar qual tabela de agregação será usada para uma consulta nesta página de documentação.

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

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

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

Para tabelas agregadas com filtros de tempo, o Looker pode unir dados atualizados à sua tabela agregada. 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 inclui as informações de hoje. Por isso, ela não é usada em uma consulta "Explorar" com as informações diárias mais recentes.

No entanto, o Looker ainda poderá usar os dados nessa tabela agregada para a consulta, já que ele executará uma consulta nos dados mais recentes e fará a união desses resultados na tabela de agregação.

O Looker pode unir dados atualizados aos dados da sua tabela agregada nas seguintes circunstâncias:

• A tabela agregada tem um filtro de tempo.
• A tabela agregada inclui uma dimensão com base no mesmo campo de tempo do filtro de tempo.

Por exemplo, a tabela de agregação a seguir tem uma dimensão com base no campo orders.created_date e um filtro de tempo ("3 days") com base 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 a tabela agregada foi criada ontem, o Looker vai recuperar os dados mais recentes que ainda não foram incluídos na tabela agregada e unir os resultados atualizados com os da tabela agregada. Isso significa que os usuários receberão os dados mais recentes e otimizarão o desempenho usando o reconhecimento agregado.

Se você estiver no modo de desenvolvimento, clique na guia SQL de uma exploração para ver a tabela agregada que a Looker usou para a consulta e a instrução UNION que a Looker usou para trazer dados mais recentes que não foram incluídas na tabela de agregação.

Atualmente, se a ferramenta não puder mesclar dados atualizados com a tabela agregada, os dados existentes dela serão usados.

As tabelas de agregação precisam ser mantidas

Para ser acessível para o conhecimento agregado, sua tabela agregada precisa ser mantida no seu 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 permanente (PDT, na sigla em inglês), elas têm os mesmos requisitos que as tabelas de agregação. Consulte a página de documentação Tabelas derivadas no Looker para mais detalhes.

Você poderá criar PDTs incrementais no seu projeto se o dialeto for compatível. O Looker cria PDTs incrementais anexando dados novos à tabela, em vez de recriar a tabela inteira. Como as tabelas de agregação são um tipo de PDT, você também pode criar tabelas de agregação incrementais. Consulte a página da 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 tabela de agregação incremental.

Um usuário com permissão develop pode modificar 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 o botão Explorar ações e selecione Recriar tabelas derivadas e executar no menu Explorar ações.

Aguarde essa consulta carregar para que essa opção esteja disponível.

A opção Recriar tabelas derivadas e executar recria todas as tabelas derivadas referenciadas na consulta, bem como quaisquer tabelas derivadas que dependam das tabelas na consulta. Isso inclui tabelas agregadas, que são um tipo de tabela derivada permanente.

Para o usuário que inicia a opção Recriar tabelas derivadas e executar, a consulta aguardará a recompilação das tabelas antes de carregar os resultados. As consultas de outros usuários continuarão usando as tabelas existentes. Depois que as tabelas persistentes forem recriadas, todos os usuários usarão as tabelas recriadas.

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

Solução de problemas

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

A guia SQL também inclui comentários sobre o motivo das tabelas agregadas não terem sido usadas para uma consulta, se for o caso. Para tabelas de agregação que não são usadas, o comentário começará com:

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

Por exemplo, veja um comentário que explica por que a tabela de agregação sales_daily definida em order_items "Explorar" não foi usada para 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 alguns outros possíveis motivos para que uma tabela agregada não possa ser usada, além de etapas que você pode seguir para aumentar a usabilidade da tabela agregada.

Motivo para não usar a tabela agregada	Explicação e possíveis etapas
Este campo não existe em "Explorar".	Há um erro de tipo de validação do LookML. Provavelmente isso ocorre porque a tabela agregada não foi definida corretamente ou houve um erro de digitação no LookML na sua tabela agregada. Um culpado é um nome de campo incorreto ou algo parecido. Para resolver isso, verifique se as dimensões e medidas na tabela agregada correspondem aos nomes dos campos em "Explorar". Consulte a página de documentação do parâmetro aggregate_table para mais informações sobre como definir uma tabela agregada.
A tabela agregada não inclui os seguintes campos na consulta.	Para ser usada em uma consulta "Explorar", uma tabela agregada precisa ter todas as dimensões e medidas necessárias para ela, incluindo os campos usados nos filtros da consulta em "Explorar". Se uma consulta de exploração contém uma dimensão ou medida que não está em uma tabela de agregação, o Looker não pode usar a tabela de agregação e 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 os períodos de granularidade mais granulares podem ser derivados de granularidades mais refinadas. Para resolver isso, verifique se os campos da consulta "Explorar" estão incluídos na definição da tabela agregada.
A consulta contém os seguintes filtros que não foram incluídos como campos nem tiveram correspondência exata por filtros na tabela de agregação.	Os filtros na consulta "Explorar" impedem que o Looker use a tabela de agregação. Para resolver isso, você tem as seguintes opções: Adicione o mesmo filtro à tabela agregada. Adicione o campo que o filtro usa à tabela agregada. Remova os filtros da consulta "Explorar". Veja mais detalhes na seção Filtrar fatores desta página.
A consulta contém as seguintes medidas que não podem ser agrupadas.	A consulta contém um ou mais tipos de medidas que não são compatíveis com o reconhecimento agregado, como contagem distinta, mediana ou percentil. Para resolver isso, verifique o tipo de cada medida na consulta e veja se ela é de um dos tipos de medida compatíveis. Além disso, se o recurso Explorar tiver mesclagens, verifique se suas medidas não foram convertidas em medidas diferentes (agregações simétricas) usando as junções fan-out. Consulte a seção Agregações simétricas para explorar com mesclagens nesta página para ver uma explicação.
Uma tabela de agregação diferente é a melhor opção para otimização.	Havia várias tabelas de agregação viáveis para a consulta, e o Looker encontrou uma tabela de agregação mais ideal para usar. Não é necessário fazer nada neste caso.
O Looker não fez nenhum agrupamento (devido a um parâmetro primary_key ou cancel_grouping_fields) e, portanto, a consulta não pode ser consolidada.	A consulta faz referência a uma dimensão que impede que ela tenha uma cláusula GROUP BY. Portanto, o Looker não pode usar nenhuma tabela agregada para a consulta. Para resolver isso, verifique se os parâmetros primary_key da vista e cancel_grouping_fields estão configurados corretamente.
A tabela agregada continha filtros que não estavam na consulta.	A tabela agregada tem um filtro que não é de tempo e está fora da consulta. Para resolver isso, remova o filtro da tabela agregada. Consulte a seção Fatores de filtro nesta página para mais detalhes.
Um campo é definido como somente de filtro na consulta "Explorar", mas é listado no parâmetro dimensions da tabela de agregação.	O parâmetro dimensions da tabela agregada lista um campo definido somente como um campo filter na consulta "Explorar". Para resolver isso, remova o campo da lista dimensions da tabela agregada. Se este campo for necessário para a tabela agregada, adicione-o à lista filters na consulta da tabela agregada.
O otimizador não pode determinar por que a tabela agregada não foi usada.	Este comentário é reservado para casos específicos. Se você vir isso para uma consulta "Explorar" usada com frequência, crie uma tabela agregada que corresponda exatamente à consulta "Explorar". É possível ver facilmente a tabela agregada LookML em um Explorar, conforme descrito na página de parâmetros aggregate_table.

Informações importantes

Agregações simétricas para o recurso Explorar com mesclagens

É importante observar que, em uma exploração que mescla 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 erros de cálculo de fanout para mesclagens e faz parte da funcionalidade de agregações simétricas do Looker. Consulte a página Práticas recomendadas sobre agregados simétricos para uma explicação sobre esse recurso do Looker.

A funcionalidade de agregação simétrica impede erros de cálculo, mas também pode impedir que suas tabelas de agregação sejam usadas em certos casos. Por isso, é importante entendê-los.

Para os tipos de medição compatíveis com o reconhecimento agregado, 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 mesclagem de muitos para um ou um para muitos.
• A medida é de uma visualização de uma mesclagem de muitos para muitos.

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

Se você descobrir que a tabela agregada não está sendo usada por esse motivo, crie uma tabela desse tipo para corresponder exatamente a uma consulta "Explorar" e use esses tipos de medida em uma exploração com mesclagens. Consulte a seção Como criar tabelas agregadas que correspondem exatamente a "Explorar consultas" nesta página para mais informações.

Além disso, se você tiver um dialeto SQL compatível com esboços do HyperLogLog, poderá adicionar o parâmetro allow_approximate_optimization: yes à medida. Quando uma medida de contagem é definida com allow_approximate_optimization: yes, o Looker pode usá-la para aumentar o reconhecimento agregado, mesmo que ela seja renderizada como uma contagem distinta.

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

Suporte do Dialeto para reconhecimento agregado

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

O SQL legado do Google BigQuery é compatível com o reconhecimento agregado, mas não é compatível com a união de dados novos com os dados da tabela agregada.

Compatibilidade com dialetos para criar tabelas de agregação de forma incremental

Para que o Looker seja compatível com tabelas de agregação 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 tabelas agregadas e como criar PDTs de maneira incremental na versão mais recente do Looker: