Em projetos de Power BI e Microsoft Fabric, é comum o cliente perceber lentidão, falhas de atualização ou alto consumo de capacidade e concluir rapidamente que precisa aumentar o SKU.
Mas, em muitos casos, o problema não está apenas na capacidade contratada. O problema está no modelo semântico.
Recentemente, em uma análise técnica realizada pela nossa equipe, encontramos um cenário bastante comum em ambientes corporativos: um modelo Power BI com uma tabela fato contendo aproximadamente 17 milhões de registros e cerca de 90 colunas. Durante o refresh, o modelo falhava por limite de memória.
A mensagem de erro indicava que a operação foi cancelada porque não havia memória suficiente para concluir o processamento. O modelo consumiu mais memória do que o limite disponível para aquela operação.
Aumentar a capacidade pode até resolver temporariamente, mas não elimina a causa raiz.
O que acontece durante o refresh do Power BI
Durante a atualização de um modelo semântico, o Power BI pode precisar manter uma cópia do modelo em memória para permitir que consultas continuem funcionando enquanto o refresh acontece. A própria Microsoft informa que, em um refresh completo, pode ser necessário até o dobro da memória usada pelo modelo. Por isso, modelos grandes ou mal otimizados podem falhar mesmo quando parecem “não tão grandes” olhando apenas o tamanho do arquivo.
Isso significa que o tamanho do PBIX ou do modelo publicado não conta a história inteira. O que pesa de verdade é a combinação de:
- volume de linhas;
- quantidade de colunas;
- cardinalidade dos campos;
- tipo dos dados;
- complexidade das transformações;
- medidas DAX;
- relacionamentos;
- quantidade de visuais;
- forma como o refresh foi configurado.
O erro mais comum: trazer dado demais para dentro do modelo
Um modelo com 17 milhões de linhas pode funcionar bem no Power BI, desde que seja bem modelado. O problema começa quando a tabela fato traz muitas colunas desnecessárias, campos de texto longos, dados históricos sem uso, colunas calculadas pesadas e granularidade maior do que a necessária.
No caso analisado, a principal tabela do modelo tinha aproximadamente 17,3 milhões de linhas e 90 colunas. Esse é um forte sinal de oportunidade de otimização. A primeira pergunta deveria ser:
Todas essas 90 colunas são realmente usadas nos relatórios, filtros, relacionamentos ou medidas?
Na maioria dos casos, a resposta é não.
1. Reduzir o volume importado
O primeiro passo é reduzir a quantidade de dados carregados no modelo. Algumas ações simples:
- limitar o histórico para os últimos meses ou anos realmente necessários;
- remover tabelas que não são usadas;
- remover colunas que não aparecem nos relatórios;
- evitar carregar campos de observação, descrição longa, GUIDs e textos de alta cardinalidade sem necessidade;
- criar tabelas agregadas para análises resumidas.
A Microsoft recomenda técnicas de redução de dados em modelos Import, incluindo o carregamento de dados agregados quando o nível de detalhe completo não é necessário. Isso pode reduzir bastante o tamanho do modelo e melhorar a performance.
2. Melhorar a modelagem: fato e dimensão
Modelos muito “achatados”, com uma tabela gigante contendo tudo, tendem a consumir mais memória e dificultar a performance. O ideal é trabalhar com um modelo em estrela, separando tabelas fato e tabelas dimensão. A Microsoft reforça que o esquema estrela é altamente relevante para modelos semânticos Power BI otimizados: dimensões são usadas para filtro e agrupamento, enquanto fatos são usadas para sumarização.
Na prática, isso significa separar, por exemplo: Fato Vendas, Dimensão Produto, Dimensão Cliente, Dimensão Loja, Dimensão Calendário e Dimensão Vendedor. Esse desenho reduz repetição de informações e deixa o modelo mais eficiente.
3. Ajustar tipos de dados e cardinalidade
Nem toda coluna pesa igual. Colunas de texto com muitos valores únicos — códigos longos, identificadores, notas fiscais, descrições, e-mails, documentos e chaves compostas — podem aumentar muito o tamanho do modelo. Algumas boas práticas:
- trocar texto por inteiro quando possível;
- remover casas decimais desnecessárias;
- separar data e hora quando a hora não for necessária;
- evitar colunas de data/hora com granularidade em segundos;
- remover identificadores que não são usados para análise;
- transformar campos categóricos em dimensões.
Esse tipo de ajuste costuma gerar ganho grande sem alterar a regra de negócio.
4. Desligar o Auto Date/Time
O recurso Auto Date/Time do Power BI cria tabelas ocultas de calendário automaticamente — uma para cada coluna de data do modelo. Em modelos maiores, isso aumenta o consumo de memória sem necessidade. O ideal é usar uma dimensão calendário própria, controlada e enxuta. Entenda por que desligar o Auto Date/Time e como fazer isso em poucos cliques.
5. Configurar atualização incremental
Quando o modelo possui muitos dados históricos, o refresh completo geralmente é um dos maiores vilões de consumo. A atualização incremental permite atualizar somente os dados novos ou alterados, evitando reprocessar toda a base a cada execução. Menos dados atualizados reduzem o consumo de memória e de recursos tanto no Power BI quanto na fonte.
Para funcionar bem, é importante validar a criação correta dos parâmetros RangeStart e RangeEnd, o filtro aplicado na coluna de data certa, o query folding funcionando e uma política de retenção bem definida. A atualização incremental não corrige um modelo ruim sozinha, mas reduz muito o impacto do refresh.
6. Revisar relatórios e visuais
Cada visual em uma página do Power BI executa consultas contra o modelo semântico. O Analisador de Desempenho permite ver o tempo de cada visual, copiar a consulta DAX e identificar onde está o gargalo.
Problemas comuns: muitas tabelas e matrizes na mesma página; visuais sem filtro trazendo milhares de linhas; segmentadores com alta cardinalidade; muitas medidas complexas na mesma página; custom visuals pesados; páginas iniciais carregando dados demais. Uma recomendação prática é criar uma página inicial mais leve, com poucos indicadores, e deixar análises detalhadas para páginas específicas.
7. Monitorar o consumo de capacidade
No Microsoft Fabric, não basta olhar se o relatório abre ou se o refresh conclui. É necessário acompanhar o consumo de capacidade. O Microsoft Fabric Capacity Metrics App permite analisar consumo de CU, operações, itens, workloads e sinais de throttling — que ocorre quando as operações consomem mais CUs do que a SKU permite, degradando a experiência do usuário.
Na prática, o monitoramento deve responder: qual modelo mais consome CU; qual refresh mais pesa; qual workspace gera mais carga; qual horário concentra picos; quais operações são interativas e quais são em segundo plano; se existe throttling; e se o problema é relatório, refresh, dataflow, notebook ou pipeline. Combinar isso com a gestão automática de capacidade ainda reduz custo ligando e desligando a capacidade sob demanda.
Plano recomendado de otimização
Para um cenário como esse, nossa recomendação seria seguir esta ordem:
| Etapa | Ação | Objetivo |
|---|---|---|
| 1 | Remover colunas não usadas | Reduzir memória |
| 2 | Filtrar histórico desnecessário | Reduzir volume |
| 3 | Ajustar tipos de dados | Reduzir tamanho do modelo |
| 4 | Revisar modelo estrela | Melhorar consultas |
| 5 | Remover colunas calculadas pesadas | Reduzir processamento |
| 6 | Configurar atualização incremental | Reduzir custo de atualização |
| 7 | Revisar visuais e DAX | Melhorar experiência do usuário |
| 8 | Reagendar refresh | Evitar concorrência com usuários |
| 9 | Monitorar CU no Fabric Metrics App | Identificar vilões reais |
| 10 | Só depois avaliar aumento de SKU | Evitar custo desnecessário |
Conclusão
Aumentar a capacidade pode ser necessário em alguns cenários, mas não deve ser a primeira resposta. Antes de contratar mais recurso, é importante analisar o modelo semântico, o processo de atualização, os visuais, as medidas DAX e o consumo real da capacidade.
No caso analisado, o problema não era apenas o volume de linhas. O conjunto de fatores — tabela fato grande, muitas colunas, refresh pesado e consumo de memória acima do limite — indicava uma necessidade clara de otimização.
A melhor estratégia é simples: otimizar primeiro, escalar depois. Isso reduz custo, melhora a experiência dos usuários e evita pagar por uma capacidade maior para compensar problemas de modelagem.
Perguntas frequentes
Pode resolver temporariamente, porque libera mais memória para a operação. Mas se a causa raiz é um modelo mal otimizado — colunas demais, alta cardinalidade, histórico sem uso — o custo sobe e o problema tende a voltar. O recomendado é otimizar o modelo primeiro e só depois avaliar o aumento de SKU.
Porque, em um refresh completo, o Power BI pode precisar de até o dobro da memória usada pelo modelo para manter uma cópia ativa enquanto processa. Somado a colunas de alta cardinalidade e transformações pesadas, o pico de memória ultrapassa o limite da operação mesmo com um arquivo aparentemente modesto.
Remover colunas não usadas, reduzir a cardinalidade dos campos (trocar texto por inteiro, remover identificadores), filtrar histórico desnecessário, adotar um esquema estrela e desligar o Auto Date/Time costumam trazer os maiores ganhos sem alterar a regra de negócio.
Pelo Microsoft Fabric Capacity Metrics App, que mostra o consumo de CU por item e operação, separa operações interativas de segundo plano e sinaliza throttling. Ele responde qual modelo, refresh ou workspace mais pesa na capacidade.
