<\/p>\n
<\/p>\n
Alison Pezzott<\/a><\/strong> \u00a0e\u00a0 Rafael Mendon\u00e7a<\/a><\/strong> \u00a0\u00b7\u00a0 Abril 2026<\/p>\n <\/p>\n Apresentadores<\/p>\n Alison Pezzott<\/strong> \u00a0\u00b7\u00a0 LinkedIn \u2197<\/a><\/p>\n Rafael Mendon\u00e7a<\/strong> \u00a0\u00b7\u00a0 LinkedIn \u2197<\/a><\/p>\n<\/div>\n<\/div>\n <\/p>\n Sobre o que \u00e9<\/p>\n Uma live t\u00e9cnica sobre como monitorar, identificar gargalos e otimizar o consumo de capacidade no Power BI e Microsoft Fabric. Aborda desde os “vil\u00f5es” que drenam CUs at\u00e9 boas pr\u00e1ticas de arquitetura de dados, atualiza\u00e7\u00e3o incremental, DAX eficiente e o recurso de Mirroring.<\/p>\n<\/div>\n <\/p>\n O licenciamento Pro \u00e9 taxa fixa por usu\u00e1rio. J\u00e1 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\u00e7\u00e3o que consome recurso.<\/p>\n<\/div>\n Atualizar o modelo inteiro de uma vez consome uma quantidade massiva de recursos. A Atualiza\u00e7\u00e3o Incremental processa apenas dados novos ou alterados \u2014 e deve ser tratada como a primeira otimiza\u00e7\u00e3o a implementar em qualquer ambiente de capacidade.<\/p>\n<\/div>\n Um RLS com regras complexas que cruzam v\u00e1rias tabelas \u00e9 executado a cada intera\u00e7\u00e3o do usu\u00e1rio, gerando picos significativos de CPU. \u00c9 um vil\u00e3o silencioso porque n\u00e3o aparece como problema \u00f3bvio \u2014 mas degrada a capacidade constantemente. Mantenha o RLS o mais simples poss\u00edvel.<\/p>\n<\/div>\n O recurso de Mirroring replica dados de bancos em tempo real para o OneLake sem consumir capacidade de processamento \u2014 voc\u00ea paga apenas pelo armazenamento. J\u00e1 suporta Azure SQL, Snowflake e CosmosDB. Para AWS S3, use Shortcuts. Ainda n\u00e3o dispon\u00edvel para bancos on-premise ou AWS RDS.<\/p>\n<\/div>\n A regra de ouro: fa\u00e7a o pr\u00e9-filtro no banco de dados de origem ou no Power Query. Trazer milh\u00f5es de linhas brutas para filtrar no Power BI drena capacidade de forma desnecess\u00e1ria. A filtragem eficiente na origem \u00e9 mandat\u00f3ria.<\/p>\n<\/div>\n<\/div>\n <\/p>\n <\/p>\n <\/p>\n A transi\u00e7\u00e3o do licenciamento Pro para o modelo de capacidades (Fabric e Premium) representa uma mudan\u00e7a fundamental na forma como as equipes trabalham com Power BI. O modelo Pro \u00e9 simples: taxa fixa por usu\u00e1rio, sem preocupa\u00e7\u00e3o com consumo de recursos. J\u00e1 o modelo de capacidade oferece muito mais poder, mas introduz limites de processamento medidos em Compute Units (CUs). Isso significa que cada opera\u00e7\u00e3o \u2014 cada refresh, cada clique no relat\u00f3rio, cada exporta\u00e7\u00e3o \u2014 consome parte de um recurso finito. As equipes precisam adotar novas abordagens de monitoramento e otimiza\u00e7\u00e3o.<\/p>\n <\/p>\n Um dos principais desafios \u00e9 que a Microsoft n\u00e3o disponibiliza uma API em tempo real para monitorar a capacidade. A solu\u00e7\u00e3o recomendada \u00e9 o aplicativo Fabric Capacity Metrics, que tem um atraso de cerca de cinco minutos mas fornece indicadores visuais cruciais.<\/p>\n No gr\u00e1fico do aplicativo, os picos vermelhos<\/strong> representam opera\u00e7\u00f5es interativas (cliques de usu\u00e1rios nos relat\u00f3rios), enquanto as \u00e1reas azuis<\/strong> indicam opera\u00e7\u00f5es em background (atualiza\u00e7\u00f5es de dados). Existem tamb\u00e9m linhas de aviso: a linha vermelha<\/strong> indica que o consumo aumentou mais de 50% nos \u00faltimos 7 dias, e a linha amarela<\/strong> sinaliza aumento entre 30% e 50% no mesmo per\u00edodo.<\/p>\n <\/p>\n Foram identificados diversos fatores que drenam a capacidade rapidamente:<\/p>\n \u26a0 Atualiza\u00e7\u00e3o ineficiente de dados<\/strong><\/p>\n Atualizar o modelo inteiro de uma vez consome recursos massivos. Solu\u00e7\u00e3o:<\/strong> implementar Atualiza\u00e7\u00e3o Incremental, que processa apenas dados novos ou alterados.<\/p>\n<\/div>\n \u26a0 Colunas calculadas em DAX<\/strong><\/p>\n Consomem muita mem\u00f3ria e processamento. Solu\u00e7\u00e3o:<\/strong> evitar sempre que poss\u00edvel e priorizar a cria\u00e7\u00e3o de medidas.<\/p>\n<\/div>\n \u26a0 Falta de integridade referencial<\/strong><\/p>\n Quando a tabela dimens\u00e3o n\u00e3o tem um ID correspondente na tabela fato, o Power BI cria uma linha “em branco” virtual \u2014 isso altera a l\u00f3gica do motor de c\u00e1lculo e aumenta substancialmente o consumo de recursos.<\/p>\n<\/div>\n \u26a0 DAX ineficiente<\/strong><\/p>\n Repetir a mesma f\u00f3rmula em vez de usar vari\u00e1veis (VAR) obriga o motor a recalcular m\u00faltiplas vezes. Usar FILTER numa tabela inteira em vez de FILTER(VALUES(Coluna)) tamb\u00e9m \u00e9 um erro comum e custoso.<\/p>\n<\/div>\n \u26a0 RLS complexo (vil\u00e3o silencioso)<\/strong><\/p>\n Regras que cruzam v\u00e1rias tabelas s\u00e3o executadas a cada intera\u00e7\u00e3o do usu\u00e1rio, gerando picos de CPU constantes. Solu\u00e7\u00e3o:<\/strong> manter o RLS o mais simples poss\u00edvel.<\/p>\n<\/div>\n \u26a0 Exporta\u00e7\u00e3o massiva para Excel<\/strong><\/p>\n Usu\u00e1rios exportando grandes volumes geram consultas pesadas em background, podendo at\u00e9 derrubar a capacidade inteira.<\/p>\n<\/div>\n <\/p>\n Filtragem na origem:<\/strong> A regra de ouro \u00e9 nunca trazer milh\u00f5es de linhas para filtrar no Power BI. O pr\u00e9-filtro deve ser feito no banco de dados ou no Power Query, reduzindo drasticamente o consumo.<\/p>\n Cuidado ao pausar a capacidade:<\/strong> O Fabric usa um sistema de smoothing que empresta processamento futuro. Ao pausar a capacidade quando ela est\u00e1 em overage, a Microsoft cobra imediatamente o tempo futuro emprestado. Pausar e reiniciar gera custos.<\/p>\n Relat\u00f3rios paginados:<\/strong> Conectar relat\u00f3rios paginados ao mesmo dataset consome a capacidade principal. A melhor alternativa \u00e9 conectar diretamente ao banco de dados de origem.<\/p>\n <\/p>\n A escolha da ferramenta certa impacta diretamente na performance e no custo:<\/p>\n\ud83d\udca1 Principais Insights<\/h2>\n
Pro \u2192 Capacidade: mudan\u00e7a total de paradigma<\/h3>\n
Atualiza\u00e7\u00e3o Incremental \u00e9 prioridade m\u00e1xima<\/h3>\n
RLS mal feito \u00e9 o vil\u00e3o silencioso<\/h3>\n
Mirroring: replica\u00e7\u00e3o sem consumir CUs<\/h3>\n
Nunca filtre milh\u00f5es de linhas no Power BI<\/h3>\n
\ud83d\udcac Frases que Marcaram<\/h2>\n
\ud83d\udcd6 Resumo Detalhado<\/h2>\n
A Mudan\u00e7a de Paradigma: Pro vs. Capacidade<\/h3>\n
Monitoramento com Fabric Capacity Metrics<\/h3>\n
Os “Vil\u00f5es” do Consumo de Capacidade<\/h3>\n
Boas Pr\u00e1ticas de Arquitetura<\/h3>\n
Escolha da Ferramenta de Ingest\u00e3o<\/h3>\n