Summitview Studio

Power BI Lento: as 6 Causas Reais (e Como Resolver)

Power BI lento quase sempre é problema de modelo de dados, não de máquina, licença ou volume. A causa mais comum é uma tabela única e larga importada direto do sistema de origem, que obriga o motor a varrer muito mais dado do que precisa a cada visual da página.

Antes de comprar capacidade Premium para acelerar um relatório, vale saber: mais capacidade em cima de um modelo ruim compra um modelo ruim um pouco mais rápido. As seis causas, na ordem em que costumam ser a verdadeira.

1. Tabelão único em vez de star schema

Importar um extrato desnormalizado parece eficiente — está tudo num lugar só. Só que o motor VertiPaq foi feito para star schema: tabela fato estreita cercada de dimensões pequenas. Com um tabelão, a compressão desaba e todo filtro varre o conjunto inteiro. Remodelar em fatos e dimensões costuma reduzir o tamanho do modelo em 70% a 90% — e a velocidade vem junto.

2. Colunas de alta cardinalidade que ninguém usa

O VertiPaq comprime encontrando repetição. Coluna com valores únicos — GUID de transação, timestamp completo, campo de observação livre — praticamente não comprime e incha o modelo. Só quebrar datetime em uma coluna de data e outra de hora já derruba o tamanho, porque data se repete e hora exata nunca.

3. Medidas DAX que iteram linha a linha

Medida com FILTER sobre a tabela inteira, ou SUMX aninhado sobre fato sem filtro, força avaliação linha a linha em vez do caminho rápido do motor. Filtrar na coluna em vez da tabela, e deixar agregação simples ser simples, costuma resolver o gargalo sem mudar um número sequer na tela.

4. Relacionamento bidirecional e excesso de joins

Cross-filter bidirecional é confortável e caro: obriga o motor a resolver caminhos ambíguos de filtro em toda consulta. O padrão deve ser direção única, tratando as exceções com DAX explícito.

5. Transformação pesada no Power Query

Merge, join e coluna customizada no Power Query rodam a cada atualização. Esse trabalho pertence à origem — em SQL, numa view ou no warehouse — onde roda uma vez e fica consultável. É a diferença entre atualizar em noventa segundos e estourar o tempo às 3 da manhã, te entregando dado velho pela manhã.

6. Página entulhada de visuais

Cada visual dispara a própria consulta. Vinte e cinco visuais numa página são vinte e cinco consultas concorrendo pela mesma capacidade. Relatório que parece lento mesmo com modelo limpo muitas vezes só está superlotado — e quebrar uma página em três resolve numa tarde.

A ordem certa de atacar

  1. Abra o Analisador de Desempenho no Power BI Desktop e grave a página lenta. Ele mostra se o tempo está na consulta DAX, na renderização ou em outro lugar — e impede que você otimize a coisa errada.
  2. Meça tamanho do modelo e cardinalidade das colunas (DAX Studio, VertiPaq Analyzer). Remova o que ninguém usa.
  3. Arrume o schema antes de mexer em DAX. Star schema faz muito problema de "medida lenta" desaparecer sozinho.
  4. Empurre transformação para antes do Power Query.
  5. Só então pense em capacidade.

O padrão incômodo: na maioria dos resgates, o relatório lento é sintoma e o problema real é que ninguém é dono do modelo. Consertar um relatório compra um mês. Consertar o modelo encerra a categoria de reclamação.

Perguntas frequentes

Migrar para o Power BI Premium resolve a lentidão?

Às vezes, e raramente o bastante para ser a primeira medida. O Premium aumenta limites de capacidade e frequência de atualização, mas não corrige tabelão, coluna de alta cardinalidade nem DAX linha a linha. Arrume o modelo primeiro — muita equipe descobre que não precisa mais do upgrade que ia comprar.

Qual o limite de tamanho para o modo Importação?

Não existe um número de linhas mágico, porque a compressão depende da cardinalidade, não do volume. Star schema bem modelado com centenas de milhões de linhas estreitas pode ir bem, enquanto um tabelão de poucos milhões engasga. Acompanhe o tamanho do modelo em memória, não a contagem de linhas.

DirectQuery deixa o relatório mais rápido?

Em geral, não. O DirectQuery existe para dado atual e para volume que não cabe importado; normalmente deixa mais lento, porque cada visual vira consulta ao vivo na origem. Use quando você realmente precisa do dado do momento, não como solução de desempenho.

Quanto tempo leva para resolver um relatório lento?

Um relatório com causa clara costuma ser questão de dias. Reestruturar o modelo por baixo, para o workspace inteiro ficar rápido, normalmente leva algumas semanas — e é a versão que impede o problema de voltar.

Quer isso olhado direito?

A gente audita primeiro e diz com honestidade se compensa consertar ou refazer. Você fala com quem faria o trabalho.

Falar com a gente