Otimização de Capacidade no Power BI e Fabric: como reduzir consumo de CUs sem escalar hardware
Sobre o que é
Uma live técnica sobre como monitorar, identificar gargalos e otimizar o consumo de capacidade no Power BI e Microsoft Fabric. Aborda desde os “vilões” que drenam CUs até boas práticas de arquitetura de dados, atualização incremental, DAX eficiente e o recurso de Mirroring.
💡 Principais Insights
Pro → Capacidade: mudança total de paradigma
O licenciamento Pro é taxa fixa por usuário. Já o modelo de capacidade (Fabric/Premium) oferece mais recursos, mas introduz limites de processamento medidos em Compute Units (CUs). Isso exige uma mentalidade completamente nova: monitorar, otimizar e ser intencional com cada operação que consome recurso.
Atualização Incremental é prioridade máxima
Atualizar o modelo inteiro de uma vez consome uma quantidade massiva de recursos. A Atualização Incremental processa apenas dados novos ou alterados — e deve ser tratada como a primeira otimização a implementar em qualquer ambiente de capacidade.
RLS mal feito é o vilão silencioso
Um RLS com regras complexas que cruzam várias tabelas é executado a cada interação do usuário, gerando picos significativos de CPU. É um vilão silencioso porque não aparece como problema óbvio — mas degrada a capacidade constantemente. Mantenha o RLS o mais simples possível.
Mirroring: replicação sem consumir CUs
O recurso de Mirroring replica dados de bancos em tempo real para o OneLake sem consumir capacidade de processamento — você paga apenas pelo armazenamento. Já suporta Azure SQL, Snowflake e CosmosDB. Para AWS S3, use Shortcuts. Ainda não disponível para bancos on-premise ou AWS RDS.
Nunca filtre milhões de linhas no Power BI
A regra de ouro: faça o pré-filtro no banco de dados de origem ou no Power Query. Trazer milhões de linhas brutas para filtrar no Power BI drena capacidade de forma desnecessária. A filtragem eficiente na origem é mandatória.
💬 Frases que Marcaram
📖 Resumo Detalhado
A Mudança de Paradigma: Pro vs. Capacidade
A transição do licenciamento Pro para o modelo de capacidades (Fabric e Premium) representa uma mudança fundamental na forma como as equipes trabalham com Power BI. O modelo Pro é simples: taxa fixa por usuário, sem preocupação com consumo de recursos. Já o modelo de capacidade oferece muito mais poder, mas introduz limites de processamento medidos em Compute Units (CUs). Isso significa que cada operação — cada refresh, cada clique no relatório, cada exportação — consome parte de um recurso finito. As equipes precisam adotar novas abordagens de monitoramento e otimização.
Monitoramento com Fabric Capacity Metrics
Um dos principais desafios é que a Microsoft não disponibiliza uma API em tempo real para monitorar a capacidade. A solução recomendada é o aplicativo Fabric Capacity Metrics, que tem um atraso de cerca de cinco minutos mas fornece indicadores visuais cruciais.
No gráfico do aplicativo, os picos vermelhos representam operações interativas (cliques de usuários nos relatórios), enquanto as áreas azuis indicam operações em background (atualizações de dados). Existem também linhas de aviso: a linha vermelha indica que o consumo aumentou mais de 50% nos últimos 7 dias, e a linha amarela sinaliza aumento entre 30% e 50% no mesmo período.
Os “Vilões” do Consumo de Capacidade
Foram identificados diversos fatores que drenam a capacidade rapidamente:
⚠ Atualização ineficiente de dados
Atualizar o modelo inteiro de uma vez consome recursos massivos. Solução: implementar Atualização Incremental, que processa apenas dados novos ou alterados.
⚠ Colunas calculadas em DAX
Consomem muita memória e processamento. Solução: evitar sempre que possível e priorizar a criação de medidas.
⚠ Falta de integridade referencial
Quando a tabela dimensão não tem um ID correspondente na tabela fato, o Power BI cria uma linha “em branco” virtual — isso altera a lógica do motor de cálculo e aumenta substancialmente o consumo de recursos.
⚠ DAX ineficiente
Repetir a mesma fórmula em vez de usar variáveis (VAR) obriga o motor a recalcular múltiplas vezes. Usar FILTER numa tabela inteira em vez de FILTER(VALUES(Coluna)) também é um erro comum e custoso.
⚠ RLS complexo (vilão silencioso)
Regras que cruzam várias tabelas são executadas a cada interação do usuário, gerando picos de CPU constantes. Solução: manter o RLS o mais simples possível.
⚠ Exportação massiva para Excel
Usuários exportando grandes volumes geram consultas pesadas em background, podendo até derrubar a capacidade inteira.
Boas Práticas de Arquitetura
Filtragem na origem: A regra de ouro é nunca trazer milhões de linhas para filtrar no Power BI. O pré-filtro deve ser feito no banco de dados ou no Power Query, reduzindo drasticamente o consumo.
Cuidado ao pausar a capacidade: O Fabric usa um sistema de smoothing que empresta processamento futuro. Ao pausar a capacidade quando ela está em overage, a Microsoft cobra imediatamente o tempo futuro emprestado. Pausar e reiniciar gera custos.
Relatórios paginados: Conectar relatórios paginados ao mesmo dataset consome a capacidade principal. A melhor alternativa é conectar diretamente ao banco de dados de origem.
Escolha da Ferramenta de Ingestão
A escolha da ferramenta certa impacta diretamente na performance e no custo:
| Ferramenta | Complexidade | Performance | Melhor Uso |
|---|---|---|---|
| Dataflow Gen2 | Baixa (low-code) | Moderada | Pequenos/médios volumes, prototipagem |
| Data Factory | Média | Boa | Orquestração complexa de fluxos |
| Spark (Notebooks) | Alta (requer código) | Excelente | Grandes volumes, melhor custo-benefício |
Arquitetura Medallion no OneLake
A estrutura recomendada dentro do OneLake é a arquitetura Medallion, que divide os dados em três camadas:
● Bronze: dados brutos, como chegam da origem
● Silver: dados limpos e transformados
● Gold: dados prontos para análise e consumo nos relatórios
Mirroring: Replicação Sem Consumir CUs
O Mirroring é um dos recursos mais poderosos do Fabric: ele replica dados de bancos em tempo real para o OneLake sem consumir capacidade de processamento — você paga apenas pelo armazenamento. É um diferencial crucial para quem quer manter dados atualizados sem estourar CUs.
Atualmente suporta Azure SQL, Snowflake e CosmosDB. Ainda não está disponível para bancos on-premise ou AWS RDS. Para dados no AWS S3, a recomendação é usar Shortcuts (Atalhos).
🎯 Pra quem é essa live?
Profissionais que trabalham com Power BI em ambientes de capacidade (Fabric ou Premium) e precisam otimizar custos. Analistas e engenheiros de dados que querem entender os vilões do consumo de CUs. Líderes técnicos decidindo entre Dataflow, Pipeline e Spark. E qualquer pessoa avaliando a migração de Pro para capacidade.
✅ Takeaways Rápidos
✅ Implemente Atualização Incremental como prioridade máxima
✅ Otimize DAX: use VAR e evite FILTER em tabela inteira
✅ Mantenha o RLS simples — é o vilão silencioso
✅ Filtre dados na origem, nunca milhões de linhas no Power BI
✅ Explore o Mirroring para replicar dados sem gastar CUs
✅ Escolha a ferramenta de ingestão certa pro volume de dados
✅ Otimize antes de escalar — não jogue dinheiro no problema
Resumo por Power Tuning · powertuning.com.br
