Trabalhar a performance do Power BI começa por uma medição, nunca por um palpite. Um relatório que leva doze segundos para abrir pode estar lento por causa de uma única medida mal escrita, porque a página carrega vinte visuais, ou porque o modelo varre centenas de milhões de linhas a cada clique. Cada causa pede uma correção diferente, e errar o diagnóstico custa uma sprint inteira em qualquer projeto de business intelligence.
A documentação de otimização da Microsoft separa o problema em camadas: a fonte de dados, o modelo semântico, as visualizações e o ambiente. No Brasil, boa parte dos times pula direto para a última e aumenta a capacidade porque o dashboard parece arrastado. A conta sobe, o gargalo continua no mesmo lugar, e o trimestre seguinte vira uma conversa sobre custos de licenciamento do Power BI e do Microsoft Fabric em vez de engenharia.
Três movimentos resolvem a maior parte da lentidão antes de alguém mexer em SKU:
- Medir com o Performance Analyzer para descobrir qual camada realmente consome os milissegundos.
- Reescrever as medidas que forçam o motor a trabalhar linha por linha.
- Adicionar agregações quando o volume de dados é a restrição de verdade.
A sequência vale em Import, DirectQuery ou Direct Lake, dentro de qualquer arquitetura de dados.
Performance Analyzer: medir antes de mexer na performance do Power BI
O Performance Analyzer fica na faixa Otimizar do Power BI Desktop e no menu Exibir quando o relatório é editado no serviço. Selecione Iniciar gravação e use o relatório como um usuário usaria: abra a página, mova um filtro, faça um drill down. Cada interação ganha uma seção própria no painel, com o nome da ação que a disparou, então o gesto de que o time reclama para de ser mistério, seja no Desktop ou em capacidade do Fabric.
Capture uma linha de base antes de mudar qualquer coisa
A técnica que separa otimização de adivinhação é uma linha de base comparável. Grave a página uma vez a frio, logo depois de abrir o arquivo, e use atualizar visuais nas rodadas seguintes, porque a primeira execução e uma reexecução aquecida não medem a mesma coisa. O DAX Studio oferece uma opção de limpar cache no comando de execução justamente por isso. Mude uma coisa, regrave a mesma interação e compare com a gravação salva: o resultado é evidência, não impressão, o mesmo hábito que mantém uma camada de métricas confiável.
Leia a divisão antes de mexer em uma medida
Cada visual registra sua duração por categoria, e essa divisão decide qual camada você corrige. Um visual dominado por tempo de consulta DAX é problema de modelo, um dominado por exibição visual é problema de renderização, e um dominado por Outro costuma ser problema de design de página. Ordene por duração, trate os dois ou três piores casos e ignore o resto, já que eles mal movem o total de uma camada de relatórios.
| Categoria | O que o número significa | Onde costuma estar a correção |
|---|---|---|
| Consulta DAX | Tempo entre o visual enviar a consulta e o modelo devolver o resultado | Lógica da medida, design do modelo, agregações |
| Consulta direta | Tempo que a fonte externa levou para responder, em tabelas DirectQuery | Índices na origem, particionamento, tabelas de agregação |
| Exibição visual | Tempo para desenhar o visual, incluindo buscar imagens web ou geocodificar | Tipo de visual, quantidade de pontos, visuais customizados |
| Outro | Preparar consultas, esperar outros visuais, processamento em segundo plano | Número de visuais na página, design da página |
| Parâmetros avaliados | Tempo avaliando parâmetros de campo dentro do visual, em versão prévia | Uso de parâmetros de campo |
Um detalhe da documentação economiza muito esforço perdido. A maior parte das operações de canvas e de visual roda em sequência numa única thread de interface, então as durações incluem o tempo em fila enquanto outras operações terminam. Um visual com 3.000 ms em Outro pode estar perfeitamente saudável e apenas esperando a vez. Cortar a quantidade de visuais da página, portanto, costuma render mais que micro-otimizar um deles, o que transforma design de dashboard em decisão de performance, e não só de estética.
Isole o visual antes de reescrever nada
Como as durações incluem tempo de fila, uma captura no nível da página infla o que carregou por último. Selecione analisar este visual no canto de um visual específico para cronometrar só ele, o que tira o ruído de enfileiramento e mostra se o elemento lento é a matriz, o mapa ou o cartão que ninguém olha. O botão exportar salva a gravação em JSON, então a comparação antes e depois prova o ganho em vez de assumi-lo, como em qualquer prática séria de engenharia de dados.
Tire a consulta de dentro do visual
Copiar consulta entrega o DAX exato que o visual mandou para o modelo, e em tabelas DirectQuery inclui também o SQL ou KQL traduzido. Executar na visualização de consulta DAX roda esse código dentro do Power BI Desktop, o que permite inspecionar a lógica e a grade de resultado. Dali, ferramentas como o DAX Studio quebram a execução em tempo de formula engine e de storage engine, o sinal mais útil de toda a otimização de DAX. O storage engine lê colunas comprimidas em bloco e escala bem, enquanto o formula engine trabalha linha por linha, então medidas que empurram o trabalho para baixo continuam rápidas conforme o dado cresce sobre um data lakehouse.
Otimização de DAX: padrões que empurram o trabalho para o storage engine
A consulta DAX do visual é verbosa de propósito, então o foco são as medidas que ela chama, porque é ali que mora o custo evitável. Toda vez que um cálculo obriga o motor a iterar sobre uma coluna de alta cardinalidade, você paga por linha. E pagar por linha sobre 200 milhões de registros transforma o dashboard em pausa para o café do time de dados.
| Padrão que trava a consulta | O que fazer no lugar | Por que ajuda |
|---|---|---|
| A mesma expressão repetida dentro da medida | Atribuir a uma variável com VAR e reusar a variável | A expressão é avaliada uma vez, não a cada referência |
| Divisão com IF manual para proteger do zero | Usar DIVIDE com o resultado alternativo | Remove um desvio que o motor avalia linha por linha |
| FILTER sobre a tabela fato inteira dentro do CALCULATE | Filtrar a coluna específica, ou usar KEEPFILTERS para preservar contexto | Filtro de coluna custa muito menos que materializar tabela |
| Iteradores como SUMX sobre colunas de alta cardinalidade | Pré-agregar na origem ou numa granularidade mais grossa | Reduz o número de linhas que o formula engine toca |
| Colunas calculadas criadas no modelo | Calcular no Power Query ou na origem, antes | Melhor compressão, modelo menor, menos memória por refresh |
| Chaves de texto e colunas datetime em tabelas grandes | Usar chaves inteiras e colunas de data quando possível | Cardinalidade menor comprime melhor no motor colunar |
Decisões de modelagem pesam tanto quanto a sintaxe da medida. Um star schema limpo, com relacionamentos de direção única, dá caminhos previsíveis ao motor, enquanto filtros bidirecionais e relações muitos-para-muitos criam relações limitadas que bloqueiam várias otimizações, o acerto de agregação entre elas. Governar a definição das métricas em um só lugar, como faz uma camada semântica bem modelada, também evita que lógica duplicada multiplique o custo de consulta por vários relatórios.
O design do relatório fecha essa camada. A orientação da Microsoft recomenda os filtros mais restritivos possíveis e, para tabelas grandes, um filtro Top N com teto generoso, algo como 10.000 linhas, já que o usuário raramente rola além de algumas dezenas. Visuais customizados também pedem teste individual, porque um visual mal otimizado degrada a página inteira, então componentes compartilhados merecem a mesma disciplina de revisão aplicada a modelos de dados usados por vários times.
Agregações: quando o modelo carrega mais dado do que a pergunta precisa
Quando a tabela fato é realmente grande, nenhuma reescrita de medida salva o relatório, e as agregações passam a ser a resposta estrutural. O padrão é direto: mantenha a tabela de detalhe em DirectQuery, adicione uma tabela de agregação oculta em modo Import numa granularidade mais grossa, e deixe o Power BI redirecionar as consultas para a tabela menor quando a granularidade pedida estiver coberta. Uma fato de um bilhão de linhas passa a ser respondida por alguns milhões de linhas pré-agregadas, o mesmo instinto do particionamento em arquiteturas modernas.
Algumas regras decidem se a agregação é de fato acertada. A tabela de detalhe precisa estar em DirectQuery, agregações em cadeia sobre três tabelas ou mais não são permitidas, e acertos por relacionamento exigem relações regulares, o que significa colocar as dimensões compartilhadas em modo Dual. Em modelos big data desnormalizados, sem relacionamentos, as entradas GroupBy na caixa de diálogo Gerenciar agregações se tornam obrigatórias. A segurança em nível de linha adiciona uma condição: a expressão precisa filtrar detalhe e agregação do mesmo jeito, senão aquela função para de se beneficiar, um detalhe de governança de dados que se repete em ambientes analíticos maduros.
Até DISTINCTCOUNT consegue acertar uma agregação quando uma entrada GroupBy preserva a distinção da chave, e a documentação situa esse limite em torno de 2 a 5 milhões de valores distintos antes de a performance sofrer de novo. Para confirmar o acerto em vez de confiar no cronômetro, o SQL Profiler expõe o evento estendido Query Processing\Aggregate Table Rewrite Query, a mesma disciplina de verificação usada ao validar uma migração para o Fabric.
As agregações automáticas oferecem o caminho de menor esforço em Premium por capacidade, Premium por usuário e Power BI Embedded. O Power BI guarda sete dias de log de consultas, treina no primeiro refresh agendado do dia ou da semana, e mantém o cache com machine learning, com uma barra deslizante para o percentual de consultas respondidas da memória. O treino tem limite de 60 minutos, até 48 atualizações por dia mantêm o cache fresco, e colunas calculadas nunca entram na conta. As duas abordagens convivem no mesmo modelo, o que serve bem a operações que rodam mais de uma ferramenta de BI em paralelo.
| Critério | Agregações definidas pelo usuário | Agregações automáticas |
|---|---|---|
| Configuração | Caixa Gerenciar agregações, tabela por tabela | Habilitada nas configurações do modelo, com agendamento |
| Conhecimento exigido | Experiência em modelagem e tuning de consulta | Dono do modelo, com pouco tuning |
| Licenciamento | Disponível onde há modelos compostos | Premium por capacidade, Premium por usuário, Embedded |
| Adaptação | Estática até alguém alterar | Retreinada a partir do log de consultas |
| Controle | Total, incluindo precedência entre tabelas | Uma barra deslizante de cobertura |
| Onde roda | Desktop e serviço | Somente no serviço do Power BI |
Ganhar performance no Power BI recompensa método mais que heroísmo: meça com o Performance Analyzer, corrija as medidas e o modelo, e recorra às agregações quando o volume for a restrição real. A BIX Tecnologia trabalha com múltiplas plataformas de dados, nuvem e BI, e a combinação certa muda conforme a expectativa de atualização, o modelo de licenciamento e a maturidade do time que opera os relatórios todo dia, o que também define o ROI do projeto de BI.
Se sua empresa está lidando com relatórios lentos e precisa de otimização de performance no Power BI baseada em evidência, nossos especialistas podem ajudar a diagnosticar o gargalo e desenhar a arquitetura certa para o seu contexto. Fale com a nossa equipe e avance na maturidade dos seus dados. ⬇️
FAQ: perguntas frequentes
O que é otimização de performance no Power BI? Otimização de performance no Power BI é a prática de medir onde o tempo de carregamento do relatório é gasto e corrigir a camada específica responsável por ele. Na prática, combina diagnóstico com o Performance Analyzer, otimização de DAX e de modelo, e tabelas de agregação para fatos grandes, em vez de aumentar capacidade e esperar que o problema desapareça.
Como usar o Performance Analyzer para achar um visual lento? Abra a faixa Otimizar no Power BI Desktop, selecione Performance Analyzer, clique em Iniciar gravação e interaja com o relatório como um usuário faria. Cada visual registra a duração dividida em consulta DAX, consulta direta, exibição visual, Outro e parâmetros avaliados, o que mostra se o custo está na consulta ou na renderização.
Por que minha medida DAX é lenta mesmo com poucas linhas na tela? Porque o resultado exibido e o dado varrido são coisas diferentes. Iteradores sobre colunas de alta cardinalidade, FILTER sobre tabelas fato inteiras e expressões repetidas empurram trabalho para o formula engine, que processa linha por linha. Reescrever com variáveis, DIVIDE e filtros em nível de coluna move o trabalho para o storage engine, que lê colunas comprimidas em bloco.
Quando usar agregações no Power BI? Use agregações quando a tabela de detalhe é grande o suficiente para que as idas e voltas do DirectQuery dominem o tempo de carga e o modo Import consuma memória demais. Uma tabela de agregação oculta em Import, com granularidade mais grossa, responde a maioria das consultas, enquanto a tabela de detalhe em DirectQuery cobre o resto. Configure as dimensões compartilhadas como Dual para que os acertos por relacionamento funcionem.
Qual a diferença entre agregações definidas pelo usuário e automáticas? Agregações definidas pelo usuário são configuradas na caixa Gerenciar agregações e ficam estáticas até alguém alterar, o que dá controle total, inclusive de precedência. Agregações automáticas exigem Premium por capacidade, Premium por usuário ou Power BI Embedded, e usam machine learning sobre sete dias de log de consultas para manter o cache sem modelagem manual.
