Como usar agregações (aggregations) no Power BI: passo a passo

Seu relatório em DirectQuery está lento e a culpa não é do Power BI#

Se você conectou um modelo em DirectQuery numa tabela fato com centenas de milhões de linhas e os visuais demoram cinco, dez, quinze segundos para responder, você chegou no lugar certo. As agregações (aggregations) Power BI existem exatamente para esse problema: elas colocam uma tabela de resumo pré-calculada na frente da tabela detalhada, e o motor decide sozinho, consulta a consulta, se responde do resumo em memória ou vai buscar o detalhe na fonte. Quando funciona, o usuário sente o relatório ficar instantâneo sem mudar nada na aparência.

O ponto que quase ninguém explica direito é que agregação não é um botão mágico. É uma técnica de modelagem que exige entender granularidade, relacionamentos e o comportamento do motor. Feita errada, você tem um modelo que não usa a agregação nunca, ou pior, que devolve números inconsistentes. Neste guia eu mostro quando usar, o passo a passo de configuração e os erros que mais vejo em campo. Sem enrolação.

Agregação serve para reduzir a cardinalidade da consulta, não para tudo#

Vale começar deixando claro onde essa técnica entra. Agregação é a resposta para um cenário específico: você precisa de dado detalhado disponível (o usuário eventualmente vai querer olhar linha a linha, ou fazer drill até a transação), mas 90% das análises acontecem num nível mais alto, como mês, produto e região. Nesse caso, manter tudo em DirectQuery pune quem só quer um total mensal, e importar bilhões de linhas não cabe na memória.

A agregação resolve isso mantendo o detalhe em DirectQuery e uma tabela resumida em Import, no modo In-Memory. O motor VertiPaq responde do resumo quando a pergunta cabe no nível dele, e só desce para a fonte quando alguém pede granularidade fina.

Quando NÃO usar agregação:

• Se o seu modelo inteiro cabe em Import sem estourar a capacidade, importe tudo. Import puro é mais rápido que qualquer agregação e muito mais simples de manter.
• Se você quase nunca precisa do detalhe, crie só a tabela resumida e pronto. Não há motivo para carregar a complexidade de agregação para nunca descer ao grão fino.
• Se o problema é uma medida DAX mal escrita ou um modelo floco de neve mal desenhado, agregação não conserta isso. Arrume a modelagem primeiro. Vale revisar as boas práticas de modelagem e DAX antes de partir para técnica avançada.

Cenário	Melhor abordagem
Modelo cabe em memória (até dezenas de milhões de linhas)	Import puro
Fato gigante, análise quase sempre agregada	Tabela resumida em Import, sem detalhe
Fato gigante, detalhe necessário às vezes	Agregação sobre DirectQuery
Necessidade de tempo real no detalhe	DirectQuery ou Direct Lake, avaliar agregação por cima

Se você trabalha em cima do Microsoft Fabric, vale entender como o Direct Lake muda esse jogo, porque em muitos casos ele reduz a necessidade de agregação manual.

Existem dois tipos de agregação e você precisa saber qual usar#

Antes do passo a passo, separe os dois modelos mentais, porque eles se configuram de formas diferentes.

O primeiro é a agregação baseada em relacionamento, também chamada de agregação por tabela dimensional. Você cria uma tabela de resumo (por exemplo, vendas por dia, produto e loja), relaciona ela com as mesmas dimensões que a fato detalhada usa, e o Power BI faz o roteamento automático. Esse é o formato mais poderoso, porque funciona para qualquer medida sobre aquelas dimensões, mesmo que você adicione dimensões novas depois.

O segundo é a agregação por GroupBy, configurada na janela de gerenciamento de agregações. Aqui você mapeia coluna a coluna: esta coluna da tabela de resumo corresponde a um GroupBy daquela coluna do detalhe, e esta outra é um Sum, Count, Min ou Max. É mais explícito e cobre casos onde não há dimensão física, mas é mais rígido.

Aspecto	Baseada em relacionamento	Por GroupBy (Manage aggregations)
Configuração	Relacionamentos + Manage aggregations	Manage aggregations, coluna a coluna
Flexibilidade	Alta, cobre novas medidas	Baixa, presa ao que foi mapeado
Funções suportadas	Sum, Count, Min, Max, Count table rows	Sum, Count, Min, Max, GroupBy
Melhor para	Modelos estrela clássicos	Resumos sem dimensão dedicada

Na prática de consultoria, a maioria dos casos bem modelados usa a agregação baseada em relacionamento apoiada por dimensões compartilhadas. É o caminho que recomendo por padrão.

Passo a passo para configurar agregação baseada em relacionamento#

Vou assumir um modelo estrela: uma fato Vendas em DirectQuery, com dimensões Calendario, Produto e Loja. O objetivo é acelerar consultas no nível de dia, produto e loja.

Passo 1: crie a tabela de agregação na fonte#

O ideal é que a tabela de resumo já venha pronta da fonte, materializada como view ou tabela física no banco. Escrever um GROUP BY no SQL Server ou na sua camada de dados é mais barato e mais controlável do que deixar o Power BI resumir. Se você tem uma boa camada de engenharia de dados, essa tabela deveria nascer no processo de ETL, não no relatório.

A tabela resumida deve conter as chaves das dimensões (data, produto, loja) e as colunas numéricas já somadas (valor, quantidade, custo). Guarde também uma contagem de linhas, porque medidas de contagem distinta e média precisam dela.

Passo 2: importe a tabela de agregação em modo Import#

Adicione essa tabela ao modelo em modo Import, não DirectQuery. É esse Import que coloca o resumo em memória e dá a velocidade. A fato detalhada Vendas continua em DirectQuery. Você acabou de criar um modelo composto, e se esse conceito for novo, o guia de modelo composto ajuda a fixar a ideia.

Passo 3: relacione a tabela de agregação com as dimensões#

Conecte a tabela de resumo às mesmas dimensões Calendario, Produto e Loja. As dimensões devem estar em modo Dual, que é o modo que permite à dimensão se comportar como Import quando conversa com a agregação e como DirectQuery quando conversa com a fato. Configurar as dimensões como Dual é o passo que mais gente esquece, e sem ele o roteamento não funciona.

Passo 4: abra Manage aggregations e mapeie as colunas#

Clique com o botão direito na tabela de agregação e escolha Manage aggregations. Para cada coluna numérica, defina o Summarization (Sum na coluna de valor, por exemplo) e aponte a Detail table e a Detail column correspondentes na fato. Para a contagem de linhas, use Count table rows apontando para Vendas.

Marque a opção que mantém a tabela de agregação oculta. O usuário nunca deve ver ou usar essa tabela diretamente. Ela é infraestrutura, não conteúdo.

Passo 5: valide o roteamento com o Performance Analyzer#

Aqui a maioria para cedo demais. Ligue o Performance Analyzer, interaja com os visuais e capture as consultas. Copie a consulta DAX, cole no DAX Studio e verifique no Server Timings se apareceu o evento de aggregation match. Se a consulta bateu na agregação, o tempo cai para milissegundos. Se ela foi para a fonte SQL mesmo pedindo só um total mensal, algo no mapeamento ou nos relacionamentos está errado. Testar isso não é opcional, é a única forma de saber se a agregação realmente está sendo usada.

Os erros que mais vejo travarem a agregação#

Depois de configurar dezenas de modelos assim, os problemas se repetem. Guarde esta lista.

Dimensão fora do modo Dual. É o campeão. A dimensão precisa estar Dual para servir aos dois lados. Se ficou como Import ou DirectQuery puro, o motor não consegue casar a consulta com a agregação e desce para a fonte toda vez.

Granularidade incompatível. Se a tabela de resumo está no nível de mês e o visual pede por dia, a agregação não bate, e o motor vai ao detalhe. Isso é esperado, mas muita gente configura a agregação num grão alto demais e depois estranha que ela quase nunca é usada. Escolha o grão da agregação olhando as consultas reais dos usuários.

Medida que não pode ser agregada. Contagem distinta (DISTINCTCOUNT) sobre uma coluna que não está na tabela de resumo não tem como ser respondida pela agregação. O motor precisa do detalhe. Se distinct count é central no seu relatório, inclua a dimensão certa no grão da agregação ou aceite que essas medidas vão à fonte.

Números que não fecham. Se a tabela de resumo foi construída com filtro diferente da fato (por exemplo, excluiu devoluções que a fato inclui), a agregação devolve um valor e o detalhe devolve outro. O usuário perde a confiança no relatório inteiro. A tabela de agregação tem que ser um resumo fiel da fato, mesmas regras, mesmos filtros. Isso é questão de qualidade e governança de dados, não de estética.

Esquecer de atualizar a agregação junto com o detalhe. O detalhe em DirectQuery é sempre atual, mas a agregação em Import só atualiza no refresh. Se o refresh da agregação atrasa, você mostra um total resumido de ontem ao lado de um detalhe de hoje. Alinhe as janelas de atualização.

Boas práticas de quem faz isso em produção#

Algumas recomendações que separam um modelo que funciona no laboratório de um que aguenta produção.

• Comece pela pergunta, não pela tabela. Levante quais consultas os usuários realmente rodam e agregue no grão dessas perguntas. Agregação genérica no grão errado é esforço desperdiçado.
• Materialize a agregação na fonte. Deixe o banco ou o pipeline de dados montar o resumo. O Power BI é bom em consultar, não em ser o motor de ETL do seu resumo.
• Documente o que a agregação cobre. Deixe registrado quais medidas e quais dimensões são aceleradas. Quando alguém adicionar uma dimensão nova, essa pessoa precisa saber se a agregação some ou não.
• Monitore o hit rate. Use o Performance Analyzer e o DAX Studio periodicamente para confirmar que as consultas continuam batendo na agregação depois de mudanças no relatório.
• Considere Direct Lake antes de sofrer. Se você está no Fabric, avalie Direct Lake e uma boa arquitetura de dados antes de investir horas em agregação manual. Em muitos cenários novos ele entrega a velocidade sem a complexidade.

Agregação bem feita é invisível: o usuário só percebe que o relatório ficou rápido. Mal feita, ela vira uma fonte silenciosa de números errados. A diferença está no cuidado com granularidade, relacionamentos e validação.

Perguntas frequentes#

Agregação funciona só com DirectQuery?

O caso clássico é acelerar DirectQuery, sim, porque é onde a lentidão dói. Mas a técnica também aparece em modelos compostos que misturam Import e DirectQuery. Em Import puro ela não faz sentido, porque o modelo inteiro já está em memória e mais rápido do que qualquer resumo adicionaria.

Preciso escrever DAX diferente para usar agregação?

Não. A grande vantagem é que suas medidas continuam iguais. O roteamento é automático e transparente. O usuário e o autor do relatório escrevem e leem exatamente as mesmas medidas, e o motor decide nos bastidores se responde do resumo ou do detalhe.

Como sei se a agregação está sendo usada de verdade?

Use o Performance Analyzer no Power BI Desktop para capturar a consulta e o DAX Studio para inspecionar o Server Timings. Procure pelo evento de aggregation match. Se ele aparece, a agregação foi usada. Se a consulta vai para o SQL mesmo pedindo dado agregado, revise o modo Dual das dimensões e o mapeamento das colunas.

Qual granularidade escolher para a tabela de agregação?

Escolha o grão mais fino que ainda cobre a maioria das análises com um volume de linhas gerenciável. Se as pessoas analisam por dia, produto e loja, agregue nesse nível. Grão alto demais reduz o uso da agregação, grão baixo demais aproxima o tamanho da própria fato e perde o ganho.

Agregação atrapalha o drill-through até o detalhe?

Não, esse é justamente o desenho ideal. As consultas de alto nível respondem da agregação em milissegundos, e quando o usuário faz drill até a transação, o motor desce para o detalhe em DirectQuery. O usuário tem velocidade no dia a dia e detalhe disponível quando precisa.

Posso ter mais de uma tabela de agregação no mesmo modelo?

Pode, e em modelos grandes é comum ter agregações em grãos diferentes, por exemplo uma por mês e outra por dia. O motor escolhe a agregação mais adequada para cada consulta. Só cuide da complexidade: cada agregação extra é mais uma peça para manter, documentar e manter consistente com a fato.

Fechando#

Agregação é uma das técnicas mais eficazes para domar DirectQuery em modelos grandes, mas ela recompensa o rigor. Modele o grão pela pergunta real, coloque as dimensões em Dual, materialize o resumo na fonte e valide o roteamento antes de publicar. Feito assim, o relatório fica rápido sem sacrificar o detalhe, e ninguém precisa saber que existe uma tabela escondida fazendo o trabalho pesado.

Se você tem um ambiente Power BI penando com performance ou está desenhando uma arquitetura em Fabric e quer acertar de primeira, fale com a gente. A Fynx já entregou mais de 2.000 soluções Microsoft e resolve esse tipo de problema em campo todos os dias.