Agregar reconhecimento

Visão geral

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

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

Por exemplo, você pode ter uma tabela de dados em escala de petabytes com uma linha para cada pedido que ocorreu no seu site. A partir desse banco de dados, você pode criar uma tabela agregada com seus totais de vendas diárias. Se o site recebe mil pedidos por dia, sua tabela agregada diária representa cada dia com 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 executar uma consulta de vendas diárias ou semanais, o Looker vai usar a tabela 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, que é a tabela agregada de vendas mensais neste exemplo.

O Looker responde às perguntas dos 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 de agregação 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 consulta da tabela do banco de dados original (orders_database). No entanto, se os usuários costumam fazer esse tipo de consulta com frequência, você pode criar uma tabela de agregação 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 agregada com base nas vendas diárias (sales_daily_aggregate_table).

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

As tabelas de agregação não precisam ser mescladas ou adicionadas a uma Análise separada. Em vez disso, o Looker ajusta dinamicamente a cláusula FROM da consulta da Análise para acessar a melhor tabela agregada para a consulta. Isso significa que as detalhações são mantidas, e as Análises podem ser consolidadas. Com o reconhecimento agregado, uma Análise pode aproveitar automaticamente as tabelas de agregação, mas ainda se aprofundar nos dados granulares, se necessário.

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

Como adicionar tabelas de agregação ao seu projeto

Os desenvolvedores do Looker podem criar tabelas de agregação 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 mantidas no banco de dados para que possam ser acessadas para o reconhecimento agregado. 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 do LookML.

Este é um exemplo de explore com uma tabela de agregação no 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 acesse o LookML da tabela de agregação em uma Análise ou em um dashboard. Consulte a página de documentação do parâmetro aggregate_table para ver as especificidades do parâmetro aggregate_table e os subparâmetros.

Como projetar tabelas de agregação

Para que uma consulta de Análise use uma tabela agregada, ela precisa fornecer dados precisos para essa consulta. O Looker poderá usar uma tabela de agregação para uma consulta da Análise se todas as condições a seguir forem verdadeiras:

  • Os campos da consulta "Explorar" são um subconjunto dos campos da tabela de agregação. Consulte a seção Fatores de campo nesta página. Ou, para períodos, os 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 "Análise" contém tipos de medição compatíveis com o reconhecimento agregado (consulte a seção Medir os fatores de tipo nesta página), ou essa consulta tem uma tabela agregada que é uma correspondência exata. Confira a seção Como criar tabelas de agregação que correspondem exatamente a consultas da Análise nesta página.
  • O fuso horário da consulta "Explorar" corresponde ao usado pela tabela de agregação. Consulte a seção Fatores de fuso horário nesta página.
  • Os filtros da consulta "Explorar" referenciam campos que estão disponíveis como dimensões na tabela de agregação, ou cada um dos filtros da consulta "Explorar" corresponde a um filtro na tabela de agregação (consulte a seção Filtrar fatores nesta página).

Uma forma de garantir que uma tabela de agregação possa fornecer dados precisos para uma consulta de Análise é criar uma tabela de agregação que corresponda exatamente a uma consulta de Análise. Consulte a seção Como criar tabelas de agregação que correspondem exatamente a consultas em "Analisar" nesta página para mais detalhes.

Fatores de campo

Para ser usada em uma consulta de Análise, uma tabela agregada precisa ter todas as dimensões e medidas necessárias, incluindo os campos usados para filtros nessa consulta. Se uma consulta da Análise tiver uma dimensão ou medida que não esteja em uma tabela de agregação, o Looker não poderá usar a tabela de agregação, e sim a tabela base.

Por exemplo, se uma consulta é agrupada por dimensões A e B, agregada por medida C e filtra pela dimensão D, a tabela de agregação precisa ter, no mínimo, A, B e D como dimensões e C como medida.

A tabela de agregação também pode ter outros campos, mas ela precisa ter pelo menos os campos de consulta "Análise" 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 aproximada podem ser derivados de períodos de granularidade mais fina.

Por causa dessas considerações de campo, uma tabela de agregação é específica para a Análise em que ela é definida. Uma tabela de agregação definida em uma Análise não será usada para consultas em outra Análise.

Fatores de prazo

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

O mesmo se aplica a subconjuntos de intervalos de tempo. Por exemplo, se você tiver uma tabela de agregação filtrada para os últimos três meses e um usuário consultar os dados com um filtro dos últimos dois meses, o Looker poderá usar a tabela de agregação 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 fina (ou igual) que o filtro de período usado na consulta de Análise. Por exemplo, uma tabela agregada que tem 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 de Análise use uma tabela de agregação, as medidas nessa tabela precisam ser capazes de fornecer dados precisos para essa consulta.

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

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

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

Medidas com tipos de medição compatíveis

O reconhecimento agregado pode ser usado em consultas de Análise que usam medições com estes tipos de medição:

Para usar uma tabela de agregação em uma consulta da Análise, o Looker precisa operar nas medidas da tabela de agregação para fornecer dados precisos nessa consulta. Por exemplo, uma medida com type: sum pode ser usada para reconhecimento agregado 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 medição 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 medições com type: average, o reconhecimento agregado é aceito 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 medições definidas com expressões no parâmetro sql. Quando definidas com expressões SQL, os seguintes tipos de medidas também são compatíveis:

O reconhecimento agregado é compatível com medições definidas como combinações de outras medidas, como neste 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 medições 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) ;;
}

Além disso, o reconhecimento agregado é compatível com medições 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 medições, 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 medições definidas usando o formato ${TABLE}.column_name, que indica uma coluna em uma tabela. Consulte a página de documentação Como incorporar o SQL e se referir a objetos do LookML para uma visão geral do uso de referências no LookML.

Por exemplo, uma medida definida com o parâmetro sql não seria aceita em uma tabela de agregação, porque 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 de agregação, crie uma dimensão definida com o formato ${TABLE}.column_name e uma medição que faça referência à dimensão, 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 sua tabela de agregação.

Medidas que aproximam contagens distintas

Em geral, contagens distintas não são compatíveis com o reconhecimento agregado porque não é possível obter dados precisos ao 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 três semanas de diferença. Se você tentar aplicar uma tabela agregada semanal para receber uma contagem mensal de usuários distintos no seu site, eles vão ser contados duas vezes na consulta de contagem diferente mensal, e os dados vão estar incorretos.

Uma solução para isso é criar uma tabela de agregação que corresponda exatamente a uma consulta da Análise, conforme descrito na seção Como criar tabelas de agregação que correspondem exatamente a consultas de Análise nesta página. Quando a consulta "Explorar" e uma consulta de tabela agregada são iguais, medidas de contagem distintas fornecem dados precisos que podem ser usados para gerar reconhecimento agregado.

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

O algoritmo HyperLogLog tem aproximadamente 2% de erro. O parâmetro allow_approximate_optimization: yes exige que os desenvolvedores do Looker confirmem que não há problema em usar dados aproximados para a medição, assim ela poderá ser calculada aproximadamente com base nas tabelas de agregação.

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 diferentes usando o HyperLogLog.

Fatores de fuso horário

Em muitos casos, os administradores de bancos de dados usam o UTC como fuso horário. No entanto, muitos usuários podem não estar no fuso horário UTC. O Looker tem várias opções de conversão de fusos horários para que os usuários recebam os resultados da consulta no próprio 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, defina um único fuso horário de consulta para que todas as consultas sejam convertidas do fuso horário do banco de dados para o 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.

Para mais informações sobre essas opções, consulte a página de documentação Como usar configurações de fuso horário.

Esses conceitos são importantes para a compreensão do conhecimento agregado porque, para que uma tabela agregada seja usada em uma consulta com dimensões de data ou filtros de data, o fuso horário da tabela de agregação deve corresponder à configuração de fuso horário usada para a consulta original.

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

  • Seu banco de dados não oferece suporte a fusos horários.
  • O fuso horário da consulta da conexão do banco de dados está definido como o fuso horário do banco de dados.
  • Sua conexão de banco de dados não tem um fuso horário de consulta nem fuso horário específico 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, omita o parâmetro timezone das suas tabelas de agregação.

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

  • Se a conexão do banco de dados usar um único fuso horário de consulta, será preciso corresponder o valor timezone da tabela agregada ao valor do fuso horário da 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 sua tabela de agregação. Os filtros em uma tabela de agregação podem restringir os resultados ao ponto em que a tabela de agregação não pode ser utilizada. Por exemplo, digamos que você crie uma tabela de agregação para as contagens de pedidos diários, e a tabela agregada filtre apenas para pedidos de óculos de sol provenientes da Austrália. Se um usuário executar uma consulta da Análise para conferir a contagem diária de pedidos de óculos de sol no mundo todo, o Looker não vai poder usar a tabela agregada, já que ela só tem dados da Austrália. A tabela de agregação filtra os dados muito restritos para serem usados pela consulta "Análise".

Além disso, considere os filtros que seus desenvolvedores do Looker podem ter integrado à sua Análise, como:

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

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

Por exemplo, esta é uma Análise com um filtro de acesso baseado no campo orders.region:

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

Para criar uma tabela de agregação que seria usada para esta Análise, ela precisa incluir o campo no qual se baseia o filtro de acesso. No próximo exemplo, o filtro de acesso é baseado no campo orders.region, e esse mesmo campo 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 da Análise. 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 às consultas da Análise que usam uma tabela derivada nativa configurada com bind_filters. O parâmetro bind_filters transmite filtros especificados de uma consulta de Análise para a subconsulta de tabela derivada nativa. No caso do reconhecimento agregado, se a consulta "Explorar" exigir uma tabela derivada nativa que use bind_filters, essa consulta só poderá usar uma tabela de agregação se todos os campos usados no parâmetro bind_filters da tabela derivada nativa tiverem exatamente os mesmos valores de filtro tanto na consulta "Explorar quanto na tabela agregada".

Como criar tabelas de agregação que correspondem exatamente a consultas de Análise

Uma forma de garantir que uma tabela de agregação possa ser usada para uma consulta de Análise é criar uma tabela de agregação que corresponda exatamente a essa consulta. Se a consulta "Análise" e a tabela de agregação usarem as mesmas medidas, dimensões, filtros, fusos horários e outros parâmetros, por definição, os resultados da tabela agregada serão aplicados a ela. Se uma tabela de agregação for uma correspondência exata de uma consulta da Análise, o Looker poderá usar tabelas de agregação que incluem qualquer tipo de medição.

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

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 para saber qual tabela de agregação será usada em uma consulta. Os comentários da guia SQL também são mostrados no Modo de Desenvolvimento para que os desenvolvedores possam testar novas tabelas de agregação antes de enviar as novas tabelas para produção.

Por exemplo, com base no exemplo de tabela de agregação mensal mostrado anteriormente, você pode acessar "Explorar" e executar uma consulta para os totais anuais de vendas. Depois, clique na guia SQL para conferir os detalhes da consulta que o Looker criou. No Modo de Desenvolvimento, o Looker mostra comentários para indicar a tabela de agregação usada na consulta.

Nos seguintes comentários na guia SQL, podemos notar 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 possíveis comentários na guia SQL e sugestões de como resolvê-los.

Estimativas de economia em computação para reconhecimento agregado

Se a conexão do banco de dados oferecer suporte a estimativas de custo e se for possível usar uma tabela agregada para uma consulta, a janela Explorar vai mostrar as economias de computação ao usar a tabela de agregação, em vez de consultar o banco de dados diretamente. As economias de reconhecimento agregadas são mostradas ao lado do botão Executar em uma Análise antes da execução da consulta.

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

Após a execução da consulta, a janela "Explorar" mostrará qual tabela de agregação foi usada para responder à consulta ao lado do botão Executar.

A economia de reconhecimento agregada é mostrada para conexões de banco de dados que estão 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 tabelas de agregação

Para tabelas de agregação com filtros de tempo, o Looker pode unir dados novos na sua tabela de agregação. Você pode ter uma tabela agregada que inclui dados dos últimos três dias, mas ela pode ter sido criada ontem. A tabela de agregação não teria as informações de hoje, então não é possível usá-la em uma consulta "Explorar" nas informações diárias mais recentes.

No entanto, o Looker ainda pode usar os dados daquela tabela agregada para a consulta porque o Looker vai executar uma consulta nos dados mais recentes e unir esses resultados nos resultados na tabela de agregação.

O Looker pode unir dados novos com os da sua tabela de agregação nas seguintes circunstâncias:

  • A tabela de agregação tem um filtro de tempo.
  • A tabela de agregação inclui uma dimensão com base no mesmo campo de tempo que o filtro de tempo.

Por exemplo, a tabela agregada a seguir tem uma dimensão baseada 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 essa tabela agregada tiver sido criada ontem, o Looker vai recuperar os dados mais recentes que ainda não foram incluídos na tabela de agregação e unir os novos resultados com os da tabela de agregação. Isso significa que seus usuários vão receber os dados mais recentes e, ao mesmo tempo, otimizar a performance usando o reconhecimento agregado.

Se você estiver no Modo de Desenvolvimento, clique na guia SQL de uma Análise para conferir a tabela de agregação que o Looker usou para a consulta e a instrução UNION que o Looker usou para inserir dados mais recentes que não foram incluídos na tabela de agregação.

As tabelas de agregação precisam ser mantidas

Para ser acessível para o reconhecimento agregado, a tabela agregada precisa persistir 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 persistente (PDT), elas têm os mesmos requisitos que as PDTs. Para mais detalhes, consulte a página de documentação Tabelas derivadas no Looker.

É possível criar PDTs incrementais no seu projeto se o dialeto for compatível com elas. O Looker cria TDPs incrementais anexando dados novos à tabela, em vez de recriá-la totalmente. Como as tabelas de agregação são um tipo de PDT, você também pode criar tabelas de agregação incrementais. Para mais informações sobre TDPs incrementais, consulte a página de documentação sobre TDPs incrementais. 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 a permissão develop pode substituir as configurações de persistência e recriar todas as tabelas de agregação 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 "Análise" 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 quaisquer tabelas derivadas que dependam das tabelas na consulta. Isso inclui tabelas de agregação, que são um tipo de tabela derivada persistente.

Para o usuário que iniciar a opção Recriar tabelas derivadas e executar, a consulta esperará que as tabelas sejam recriadas antes de carregar os resultados. As consultas de outros usuários ainda vão usar as tabelas atuais. Após a reconstrução das tabelas persistentes, todos os usuários vão usar essas tabelas.

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 Como determinar qual tabela de agregação é usada para uma consulta, se você estiver no Modo de Desenvolvimento, poderá executar consultas em "Análise" e clicar na guia SQL para conferir comentários sobre a tabela de agregação usada na consulta, se houver.

A guia SQL também inclui comentários sobre o motivo pelo qual as tabelas de agregação não foram usadas para uma consulta, se esse for o caso. Em 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, aqui está um comentário sobre por que a tabela de agregação sales_daily definida na Análise order_items 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 algumas outras possíveis razões pelas quais uma tabela de agregação não pode ser usada, junto com etapas que você pode seguir para aumentar a usabilidade da tabela de agregação.

Motivo para não usar a tabela de agregação Explicação e possíveis etapas
Esse campo não existe em "Explorar". Há um erro de tipo de validação do LookML. Isso pode acontecer principalmente porque a tabela de agregação não foi definida corretamente ou houve um erro de digitação no LookML para sua tabela de agregação. Um provável culpado é um nome de campo incorreto ou algo semelhante.

Para resolver isso, verifique se as dimensões e as medições na tabela de agregação 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 de agregação.
A tabela de agregação não inclui os seguintes campos na consulta. Para ser usada em uma consulta de Análise, uma tabela agregada precisa ter todas as dimensões e medidas necessárias, incluindo os campos usados para filtros nessa consulta. Se uma consulta da Análise tiver uma dimensão ou medida que não esteja em uma tabela de agregação, o Looker não poderá usar a tabela de agregação, e sim a tabela 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 aproximada podem ser derivados de períodos de granularidade mais fina.

Para resolver isso, verifique se os campos da consulta "Análise" 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 pelos filtros na tabela agregada. Os filtros na consulta "Análise" impedem que o Looker use a tabela de agregação.

Para resolver isso, siga um destes procedimentos:
  • Adicione o mesmo filtro à sua tabela de agregação.
  • Adicione o campo que o filtro usa à sua tabela de agregação.
  • Remova os filtros da consulta "Análise".
Consulte a seção Fatores de filtro 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 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 se ela é um dos tipos compatíveis. Além disso, se a Análise tiver mesclagens, confira se as medidas não são convertidas em medidas distintas (agregações simétricas) usando junções distribuídas. Consulte a seção Agregações simétricas para explorações com junções nesta página para ver uma explicação.
Uma tabela de agregação diferente era 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 no lugar. Nesse caso, não é preciso fazer nada.
Como o Looker não fez nenhum agrupamento (devido a um parâmetro primary_key ou cancel_grouping_fields), a consulta não pode ser agrupada. A consulta faz referência a uma dimensão que a impede de ter 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 visualização e cancel_grouping_fields da Análise 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 não está na consulta.

Para resolver isso, é possível remover o filtro da tabela de agregação. Consulte a seção Filtrar fatores nesta página para mais detalhes.
Um campo é definido como somente filtro na consulta da Análise, mas é listado no parâmetro dimensions da tabela de agregação. O parâmetro dimensions da tabela de agregação lista um campo que é definido apenas como um filter na consulta de Análise.

Para resolver isso, remova o campo da lista dimensions da tabela de agregação. Se esse campo for necessário para a tabela de agregação, 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 específicos. Caso isso aconteça em uma consulta da Análise muito usada, crie uma tabela de agregação que corresponda exatamente a essa consulta. Você pode acessar a tabela de agregação do LookML facilmente em uma Análise, conforme descrito na página de parâmetros aggregate_table.

Informações importantes

Agregados simétricos para análises com mesclagens

É importante observar que, em uma Análise que mescla várias tabelas de banco de dados, o Looker pode 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. Por exemplo, uma medida count é renderizada como um tipo de medida count_distinct. Isso serve para evitar erros de cálculo de fanout nas 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 saber mais sobre esse recurso do Looker.

A funcionalidade de agregações simétricas 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 isso.

Para os tipos de medição compatíveis com o reconhecimento agregado, isso se aplica a sum, count e average. O Looker renderizará esses tipos de medidas como DISTINCT se:

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

Se você acha que sua tabela de agregação não está sendo usada por esse motivo, crie uma tabela para corresponder exatamente a uma consulta da Análise e use esses tipos de medidas em uma Análise com mesclagens. Consulte a seção Como criar tabelas de agregação que correspondem exatamente a consultas em "Analisar" nesta página para mais informações.

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

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

Suporte a dialetos para reconhecimento agregado

A capacidade de usar o reconhecimento agregado depende do dialeto do banco de dados usado pela conexão do Looker. Na versão mais recente do Looker, os seguintes dialetos oferecem suporte ao reconhecimento agregado:

Dialeto Compatível?
Avalanche Actian
Sim
Amazon Athena
Sim
MySQL do Amazon Aurora
Sim
Amazon Redshift
Sim
Apache Druid
No
Apache Druid 0.13 ou superior
No
Apache Druid 0.18 ou superior
No
Apache Hive 2.3 ou superior
Sim
Apache Hive 3.1.2 ou posterior
Sim
Apache Spark 3 ou mais recente
Sim
ClickHouse
No
Cloudera Impala 3.1 ou superior
Sim
Cloudera Impala 3.1+ com driver nativo
Sim
Cloudera Impala com driver nativo
Sim
DataVirtuality
No
Databricks
Sim
Denodo 7
No
Denodo 8
No
Drêmio
No
Dremio 11 ou superior
No
Exasol
Sim
Bola de fogo
No
SQL legado do Google BigQuery
Sim
SQL padrão do Google BigQuery
Sim
PostgreSQL do Google Cloud
Sim
Google Cloud SQL
No
Google Spanner (em inglês)
No
Greenplum
Sim
HyperSQL
No
IBM Netezza
Sim
MariaDB
Sim
PostgreSQL do Microsoft Azure
Sim
Banco de dados SQL do Microsoft Azure
Sim
Análises do Microsoft Azure Synapse
Sim
Microsoft SQL Server 2008 ou superior
Sim
Microsoft SQL Server 2012 ou posterior
Sim
Microsoft SQL Server 2016
Sim
Microsoft SQL Server 2017 ou posterior
Sim
MongoBI
No
MySQL
Sim
MySQL 8.0.12 ou mais recente
Sim
Oracle
Sim
ADWC da Oracle
Sim
PostgreSQL 9.5 ou mais recente
Sim
PostgreSQL anterior à 9.5
Sim
PrestoDB
Sim
PrestoSQL
Sim
SAP HANA 2 ou posterior
Sim
SingleStore
Sim
SingleStore 7 ou superior
Sim
Snowflake
Sim
Teradata
Sim
Trino
Sim
Vetor
Sim
Vertica
Sim

Suporte a dialeto para criação incremental de tabelas de agregação

Para que o Looker ofereça suporte a tabelas de agregação incremental 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 oferecem suporte à criação incremental de PDTs na versão mais recente do Looker:

Dialeto Compatível?
Avalanche Actian
No
Amazon Athena
No
MySQL do Amazon Aurora
No
Amazon Redshift
Sim
Apache Druid
No
Apache Druid 0.13 ou superior
No
Apache Druid 0.18 ou superior
No
Apache Hive 2.3 ou superior
No
Apache Hive 3.1.2 ou posterior
No
Apache Spark 3 ou mais recente
No
ClickHouse
No
Cloudera Impala 3.1 ou superior
No
Cloudera Impala 3.1+ com driver nativo
No
Cloudera Impala com driver nativo
No
DataVirtuality
No
Databricks
Sim
Denodo 7
No
Denodo 8
No
Drêmio
No
Dremio 11 ou superior
No
Exasol
No
Bola de fogo
No
SQL legado do Google BigQuery
No
SQL padrão do Google BigQuery
Sim
PostgreSQL do Google Cloud
Sim
Google Cloud SQL
No
Google Spanner (em inglês)
No
Greenplum
Sim
HyperSQL
No
IBM Netezza
No
MariaDB
No
PostgreSQL do Microsoft Azure
Sim
Banco de dados SQL do Microsoft Azure
No
Análises do Microsoft Azure Synapse
Sim
Microsoft SQL Server 2008 ou superior
No
Microsoft SQL Server 2012 ou posterior
No
Microsoft SQL Server 2016
No
Microsoft SQL Server 2017 ou posterior
No
MongoBI
No
MySQL
Sim
MySQL 8.0.12 ou mais recente
Sim
Oracle
No
ADWC da Oracle
No
PostgreSQL 9.5 ou mais recente
Sim
PostgreSQL anterior à 9.5
Sim
PrestoDB
No
PrestoSQL
No
SAP HANA 2 ou posterior
No
SingleStore
No
SingleStore 7 ou superior
No
Snowflake
Sim
Teradata
No
Trino
No
Vetor
No
Vertica
Sim