Conhecimento agregado

Visão geral

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

Para tabelas muito grandes no banco de dados, os desenvolvedores do Looker podem criar tabelas agregadas de dados menores, agrupadas por várias combinações de atributos. As tabelas agregadas funcionam como tabelas de resumo ou de acúmulo que o Looker pode usar para consultas sempre que possível, em vez da tabela grande original. Quando implementado de forma estratégica, 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 que ocorreu no seu site. Com esse banco de dados, você pode criar uma tabela agregada com os totais de vendas diários. Se o site receber 1.000 pedidos por dia, a tabela de agregação diária vai representar cada dia com 999 linhas a menos do que a tabela original. Você pode criar outra tabela de agregação com totais de vendas mensais que serão ainda mais eficientes. Assim, se um usuário executar uma consulta para 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 de agregação anual, o Looker vai usar a próxima melhor opção, que é a tabela de agregação de vendas mensais neste exemplo.

O Looker responde às perguntas dos usuários com as tabelas de agregação menores 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 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, a 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 consciência agregada, o Looker consulta 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 uma granularidade maior do que as tabelas agregadas podem oferecer.

As tabelas agregadas 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 de análise para acessar a melhor tabela de agregação. Isso significa que seus exercícios são mantidos e as análises podem ser consolidadas. Com a consciência agregada, uma Análise detalhada pode usar automaticamente tabelas agregadas, mas ainda se aprofundar em dados granulares, se necessário.

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

Como 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 agregadas precisam ser persistindos no banco de dados para que possam ser acessadas para a consciência agregada. As tabelas agregadas são um tipo de tabela derivada persistente (TDP).

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

Confira 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, programe o LookML do zero ou acesse o LookML da análise detalhada ou do painel de controle. Consulte a página de documentação do parâmetro aggregate_table para saber as especificidades do parâmetro aggregate_table e dos subparâmetros.

Como projetar tabelas de agregação

Para que uma consulta do recurso Explorar use uma tabela de agregação, ela precisa fornecer dados precisos para a consulta. O Looker pode usar uma tabela de agregação para uma consulta de análise detalhada se todas as condições a seguir forem verdadeiras:

  • Os campos da consulta "Análise" 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 da Análise detalhada podem ser derivados dos períodos na tabela agregada (consulte a seção Fatores de período nesta página).
  • A consulta da Análise contém tipos de medida aceitos pela consciência agregada (consulte a seção Fatores do tipo de medida nesta página) ou tem uma tabela de agregação que é uma correspondência exata (consulte a seção Como criar tabelas de agregação que correspondem exatamente às consultas da Análise nesta página).
  • O fuso horário da consulta da Análise corresponde ao fuso usado pela tabela agregada. Consulte a seção Fatores do fuso horário nesta página.
  • Os filtros da consulta de análise detalhada fazem referência a 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 forneça dados precisos para uma consulta de Análise detalhada é criar uma tabela agregada que corresponda exatamente a uma consulta de Análise detalhada. Consulte a seção Como criar tabelas de agregação que correspondem exatamente às consultas da Análise detalhada nesta página para saber mais.

Fatores de campo

Para ser usada em uma consulta da 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 da Análise detalhada tiver uma dimensão ou métrica que não está em uma tabela agregada, o Looker não poderá usar a tabela agregada e vai usar a tabela de base.

Por exemplo, se uma consulta agrupar por dimensões A e B, agregar pela medida C e filtrar pela dimensão D, a tabela agregada precisará ter, no mínimo, A, B e D 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 da 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 grosseira podem ser derivados de granularidades mais finas.

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

Fatores de período

A lógica de reconhecimento agregado do Looker pode derivar um período de outro. Uma tabela agregada pode ser usada para uma consulta, desde que o período dela tenha uma granularidade menor (ou igual) à consulta da Análise detalhada. Por exemplo, uma tabela agregada com base em dados diários pode ser usada para uma consulta da Análise detalhada que exige outros períodos, como consultas de dados diários, mensais e anuais ou até mesmo dados de dia, mês e semana do ano. No entanto, uma tabela agregada anual não pode ser usada para uma consulta de Análise detalhada 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 a 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 de agregação pode ser usada para uma consulta com um filtro de período, desde que o período da tabela de agregação tenha uma granularidade mais fina (ou igual) ao filtro de período usado na consulta "Explorar". Por exemplo, uma tabela agregada que tenha uma dimensão de período diário pode ser usada para uma consulta na Análise detalhada que filtra por dia, semana ou mês.

Fatores do tipo de medição

Para que uma consulta do recurso Explorar use uma tabela de agregação, as medidas na tabela de agregação precisam fornecer dados precisos para a consulta.

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

Se uma consulta de Análise detalhada usar outro tipo de medida, o Looker vai usar a tabela original, não a agregada, para retornar os resultados. A única exceção é se a consulta da Análise for uma correspondência exata de uma consulta de tabela agregada, conforme descrito na seção Criar tabelas agregadas que correspondam exatamente às consultas da Análise.

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

Medidas com tipos compatíveis

A consciência agregada pode ser usada para consultas do recurso "Explorar" que usam métricas com estes tipos:

Para usar uma tabela de agregação em uma consulta de análise detalhada, o Looker precisa operar nas medidas da tabela de agregação e fornecer dados precisos na consulta. Por exemplo, uma medida com type: sum pode ser usada para agregar a consciência, porque é possível somar várias somas: uma tabela agregada de somas semanais pode ser somada para obter 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 exato.

No caso de medidas com type: average, a consciência agregada é aceita porque o Looker usa dados de soma e contagem para derivar com precisão os valores médios das tabelas agregadas.

Medidas definidas com expressões SQL

A consciência agregada 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 medida também são aceitos:

A consciência agrega é compatível com medidas 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} ;;
}

A consciência agregada também é compatível com medidas em que os cálculos são definidos no parâmetro sql, como esta:

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

E o conhecimento agregado é compatível com medidas em que as operações MIN, MAX e COUNT são definidas no parâmetro sql, como esta:

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 medidas, a consciência agregada aceita 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 agregado 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 fazer referência a objetos do 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 teria suporte em 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 medida 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 à dimensão, como esta:


 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, não é possível usar a consciência agregada com contagens distintas, 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 três semanas de intervalo. Se você tentar aplicar uma tabela de agregação semanal para receber uma contagem mensal de usuários distintos no seu site, esse usuário será contado duas vezes na consulta mensal de contagem distinta e os dados serão incorretos.

Uma solução alternativa é criar uma tabela agregada que corresponda exatamente a uma consulta da Análise detalhada, conforme descrito na seção Como criar tabelas agregadas que correspondam exatamente às consultas da Análise detalhada desta página. Quando a consulta da Análise detalhada e uma consulta de tabela agregada são iguais, as medidas de contagem distintas fornecem dados precisos, para que possam ser usadas para a consciência agregada.

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

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 é possível usar dados aproximados para a medida, para que ela possa ser calculada aproximadamente com base nas 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 distinta 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 para converter fusos horários, de modo que os usuários recebam resultados de 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 usuários estiverem no mesmo fuso horário, defina um único fuso horário para que todas as consultas sejam convertidas do fuso do banco de dados para o fuso 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.

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

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

As tabelas agregadas usam o fuso horário do banco de dados se nenhum valor de timezone for especificado. A conexão do banco de dados também vai usar o fuso horário do banco de dados se uma 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 sua 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. Nesse caso, a conexão do banco de dados vai usar o fuso horário dele.

Se qualquer uma delas for verdadeira, você poderá omitir o parâmetro timezone para suas 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, você vai precisar corresponder o valor timezone da tabela agregada ao valor do fuso horário de consulta.
  • Se a conexão do banco de dados usa 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 a tabela agregada ficar inutilizável. Por exemplo, digamos que você crie uma tabela agregada para a contagem de pedidos diários e que a tabela agregada filtre apenas os pedidos de óculos de sol da Austrália. Se um usuário executar uma consulta de análise detalhada para conferir a contagem diária de pedidos de óculos de sol em todo o mundo, 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 forma muito restrita para ser usada pela consulta "Explorar".

Além disso, preste atenção aos filtros que os desenvolvedores do Looker podem ter criado na Análise, 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 da Análise detalhada. Os usuários podem mudar o valor do filtro padrão da consulta, mas não podem remover o filtro totalmente.
  • 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 em "Explorar".

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 da 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 de agregação que será usada nessa Análise, ela 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, e esse mesmo campo é incluído como uma dimensão na tabela agregada:

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 recurso Análise detalhada. 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 os filtros especificados de uma consulta do Google Analytics for Search Console para a subconsulta da tabela derivada nativa. No caso da consciência agregada, se a consulta do Google Analytics for Web 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 os mesmos valores de filtro na consulta do Google Analytics for Web e na tabela agregada.

Criar tabelas de agregação que correspondem exatamente às consultas do recurso Análise detalhada

Uma maneira 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 à consulta de análise. Se a consulta da Análise detalhada 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 da Análise detalhada. Se uma tabela de agregação for uma correspondência exata de uma consulta do recurso Explorar, o Looker poderá usar tabelas de agregação que incluem qualquer tipo de medida.

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

Como determinar qual tabela de agregação é 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 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 agregadas e ver como o Looker as usa antes de enviar novas tabelas para produção.

Por exemplo, com base na tabela de agregação mensal mostrada anteriormente, você pode acessar a seção "Explorar" e executar uma consulta para os 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 de agregação usada na consulta.

Com base nos comentários a seguir 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 conferir possíveis comentários que podem aparecer na guia SQL e sugestões de como resolvê-los.

Estimativas de economia de computação para a consciência agregada

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

Antes de executar a consulta, se você quiser saber qual tabela de agregação será usada, 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.

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

A economia de consciência agregada é 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 mescla novos dados às suas tabelas de agregação

Para tabelas de agregação com filtros de tempo, o Looker pode combinar dados novos na tabela de agregação. Você pode ter uma tabela agregada que inclui dados dos últimos três dias, mas que foi 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 de análise detalhada 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, em seguida, une esses resultados aos resultados na tabela agregada.

O Looker pode unir dados novos com os 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 essa tabela agregada foi criada ontem, o Looker vai recuperar os dados mais recentes que ainda não estão incluídos na tabela agregada e vai unir os resultados novos com os da tabela agregada. Isso significa que seus usuários vão receber os dados mais recentes e, ao mesmo tempo, otimizar a performance usando a consciência agregada.

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

As tabelas agregadas precisam ser mantidas

Para que a tabela de agregação seja acessível para a consciência de agregação, ela precisa ser persistindo 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 (TDP, na sigla em inglês), elas têm os mesmos requisitos que as TDPs. 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 oferecer suporte a eles. O Looker cria PDTs incrementais anexando dados novos à tabela, em vez de recriar a tabela por completo. 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 de documentação PDTs incrementais para mais informações sobre PDTs incrementais. Consulte a página de documentação do parâmetro increment_key para conferir um exemplo de tabela agregada 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.

Essa opção só fica disponível depois que a consulta do recurso "Explorar" é carregada.

A opção Recriar tabelas derivadas e executar recria todas as tabelas derivadas referenciadas na consulta, bem como as tabelas derivadas dependentes das tabelas na consulta. Isso inclui tabelas agregadas, 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 vai aguardar a reconstruçã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 Como determinar qual tabela de agregação é usada para uma consulta, se você estiver no Modo de desenvolvimento, será possível executar consultas no recurso Análise e clicar na guia SQL para conferir comentários sobre a tabela de agregação usada para a consulta, se houver.

A guia SQL também inclui comentários sobre por que as tabelas de agregação não foram usadas para uma consulta, se esse 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 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 que a tabela de agregação fosse usada.

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

Motivo para não usar a tabela de agregação Explicação e possíveis etapas
Não há esse campo na seção "Explorar". Há um erro de tipo de validação do LookML. Isso provavelmente ocorre porque a tabela de agregação não foi definida corretamente ou houve um erro de digitação no LookML para a tabela de agregação. Um possível culpado é um nome de campo incorreto ou algo semelhante.

Para resolver esse problema, verifique se as dimensões e as métricas na tabela de agregação 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 agregada não inclui os seguintes campos na consulta. Para ser usada em uma consulta da 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 da Análise detalhada tiver uma dimensão ou métrica que não está em uma tabela agregada, o Looker não poderá usar a tabela agregada 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 granularidades mais finas.

Para resolver isso, verifique se os campos da consulta do recurso "Explorar" estão incluídos na definição da tabela agregada.
A consulta continha os filtros a seguir, que não foram incluídos como campos nem correspondiam exatamente aos filtros na tabela de agregação. Os filtros na consulta de análise detalhada impedem que o Looker use a tabela de agregação.

Para resolver esse problema, siga um destes procedimentos:
  • Adicione o mesmo filtro à tabela agregada.
  • Adicione o campo usado pelo filtro à tabela agregada.
  • Remova os filtros da consulta "Explorar".
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 agrupadas: A consulta contém um ou mais tipos de métrica que não são compatíveis com a consciência agregada, como contagem distinta, mediana ou percentil.

Para resolver esse problema, verifique o tipo de cada medida na consulta e verifique se ela é um dos tipos de medida aceitos. Além disso, se a Análise detalhada tiver mesclagens, verifique se as medidas não são convertidas em medidas distintas (agrupamentos simétricos) por meio de mesclagens em leque. Consulte a seção Aggregates simétricos para Análises com mesclagens nesta página para ver uma explicação.
Uma tabela agregada diferente era mais adequada para a otimização. Havia várias tabelas de agregação viáveis para a consulta, e o Looker encontrou uma tabela de agregação mais otimizada 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, 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 de agregação para a consulta.

Para resolver isso, verifique se o parâmetro primary_key da visualização e o parâmetro cancel_grouping_fields da seção "Explorar" estão configurados corretamente.
A tabela de agregação 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, remova o filtro da tabela agregada. Consulte a seção Fatores de filtro nesta página para mais detalhes.
Um campo é definido como somente filtro na consulta "Análise", mas é listado no parâmetro dimensions da tabela de agregação. O parâmetro dimensions da tabela agregada lista um campo definido apenas como filter na consulta de análise detalhada.

Para resolver isso, remova o campo da lista dimensions da tabela agregada. Se esse campo for necessário para a tabela de agregação, adicione-o à lista filters na consulta da tabela de agregação.
O otimizador não consegue determinar por que a tabela de agregação não foi usada. Este comentário é reservado para casos extremos. Se você encontrar isso em uma consulta de Análise detalhada usada com frequência, crie uma tabela agregada que corresponda exatamente à consulta. É possível acessar facilmente o LookML da tabela de agregação em uma Análise, conforme descrito na página de parâmetro aggregate_table.

Considerações

Agregados simétricos para análises com mesclas

É importante observar que, em uma análise 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. 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 de práticas recomendadas sobre agregados simétricos para uma explicação sobre esse recurso do Looker.

A funcionalidade de agregações simétricas evita erros de cálculo, mas também pode impedir que as tabelas de agregação sejam usadas em determinados casos.

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

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

Se você descobrir que sua tabela agregada não está sendo usada por esse motivo, crie uma tabela agregada para corresponder exatamente a uma consulta da Análise detalhada para usar esses tipos de métrica em uma Análise detalhada com mesclagens. Consulte a seção Como criar tabelas agregadas que correspondem exatamente às consultas da Análise detalhada nesta página para mais informações.

Além disso, se você tiver um dialeto SQL compatível com esboços do HyperLogLog, adicione o parâmetro allow_approximate_optimization: yes à medida. Quando uma métrica de contagem é definida com allow_approximate_optimization: yes, o Looker pode usar a métrica para a consciência agregada, mesmo que ela seja renderizada como uma contagem distinta.

Consulte a página de documentação do parâmetro allow_approximate_optimization para conferir detalhes e uma lista de dialetos do SQL com suporte a esboços HyperLogLog.

Suporte a dialetos para consciência agregada

A capacidade de usar a consciência agregada 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 à consciência agregada:

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

Suporte a dialetos para criar tabelas de agregação de forma incremental

Para que o Looker ofereça suporte a tabelas de agregação incremental no projeto, o dialeto do banco de dados também precisa oferecer suporte a 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?
Actian Avalanche
Não
Amazon Athena
Não
MySQL do Amazon Aurora
Não
Amazon Redshift
Sim
Apache Druid
Não
Apache Druid 0.13 ou mais recente
Não
Apache Druid 0.18+
Não
Apache Hive 2.3 ou mais recente
Não
Apache Hive 3.1.2 ou mais recente
Não
Apache Spark 3 ou mais recente
Não
ClickHouse
Não
Cloudera Impala 3.1 ou mais recente
Não
Cloudera Impala 3.1+ com driver nativo
Não
Cloudera Impala com driver nativo
Não
DataVirtuality
Não
Databricks
Sim
Denodo 7
Não
Denodo 8
Não
Dremio
Não
Dremio 11 ou mais recente
Não
Exasol
Não
Firebolt
Não
SQL legado do Google BigQuery
Não
SQL padrão do Google BigQuery
Sim
PostgreSQL do Google Cloud
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
Banco de dados SQL do Microsoft Azure
Não
Microsoft Azure Synapse Analytics
Sim
Microsoft SQL Server 2008 ou mais recente
Não
Microsoft SQL Server 2012 ou mais recente
Não
Microsoft SQL Server 2016
Não
Microsoft SQL Server 2017 ou mais recente
Não
MongoBI
Não
MySQL
Sim
MySQL 8.0.12+
Sim
Oracle
Não
Oracle ADWC
Não
PostgreSQL 9.5 ou mais recente
Sim
PostgreSQL anterior à versão 9.5
Sim
PrestoDB
Não
PrestoSQL
Não
SAP HANA 2+
Não
SingleStore
Não
SingleStore 7+
Não
Snowflake
Sim
Teradata
Não
Trino
Não
Vetor
Não
Vertica
Sim