Otimização de desempenho do Power BI: DAX, modelos e consultas

Um relatório do Power BI que leva 15 segundos para carregar é um relatório que os usuários param de usar. O desempenho não é uma sutileza técnica – é a diferença entre a adoção do BI e o abandono do BI. Cada segundo de tempo de carregamento do relatório reduz o envolvimento do usuário de forma mensurável. A pesquisa mostra consistentemente que os painéis interativos (menos de 3 segundos de tempo de carregamento) recebem de 4 a 5 vezes mais visualizações do que os lentos (mais de 10 segundos), e os usuários que experimentam lentidão consistente revertem para processos manuais em 30 dias.

A boa notícia é que os problemas de desempenho do Power BI quase sempre podem ser resolvidos. Em nossa experiência na otimização de centenas de ambientes do Power BI, 90% dos problemas de desempenho são atribuídos a uma das cinco causas principais: medidas DAX ineficientes, modelos de dados superdimensionados, design de relacionamento insatisfatório, uso inadequado do DirectQuery ou capacidade insuficiente para a carga de trabalho. Este guia fornece uma abordagem sistemática para diagnosticar e resolver cada um desses problemas.

Se o seu ambiente do Power BI estiver enfrentando problemas de desempenho que sua equipe não consegue resolver internamente, nossos serviços de otimização de desempenho do Power BI fornecerão análise e correção práticas.

Principais conclusões

• O Performance Analyzer no Power BI Desktop identifica quais elementos visuais e consultas estão lentos --- sempre comece aqui antes de otimizar
• O DAX Studio revela se consultas lentas estão com gargalos no mecanismo de armazenamento (verificação de dados) ou no mecanismo de fórmula (cálculo) --- a correção difere drasticamente
• Os erros mais comuns de desempenho do DAX são aninhamento desnecessário de CALCULATE, uso de iteradores onde agregadores são suficientes e materialização de grandes tabelas intermediárias
• O tamanho do modelo afeta diretamente o desempenho: a remoção de colunas não utilizadas, a redução da cardinalidade e a otimização dos tipos de dados podem reduzir os modelos de 40 a 70%
• As tabelas de agregação fornecem melhorias de desempenho de consulta de 10 a 100 vezes para grandes conjuntos de dados, pré-computando dados de resumo
• O DirectQuery é 10 a 100 vezes mais lento que o modo de importação para relatórios interativos --- use-o somente quando os requisitos de atualização de dados realmente exigirem isso
• O benchmarking antes/depois com métricas documentadas é essencial para comprovar o impacto da otimização e prevenir regressões

---

Ferramentas e metodologia de diagnóstico

Analisador de Desempenho

O Performance Analyzer é a ferramenta de diagnóstico integrada do Power BI Desktop. Ele registra o tempo de execução de cada consulta gerada por cada elemento visual em uma página de relatório, dividindo o tempo em três componentes:

Como usar o Analisador de Desempenho:

1. Abra seu relatório no Power BI Desktop.
2. Vá para Exibir > Analisador de Desempenho.
3. Clique em “Iniciar gravação”.
4. Interaja com o relatório (altere filtros, navegue nas páginas, aplique segmentações de dados).
5. Clique em “Parar”.
6. Revise os resultados, classificados por duração total.

Interpretando resultados:

• Se o tempo de consulta DAX dominar, o problema está nas suas medidas ou modelo. Use o DAX Studio para análises mais profundas.
• Se o tempo de exibição visual predominar, o problema está na configuração visual (muitos pontos de dados, formatação condicional complexa ou visual personalizado com desempenho insatisfatório).
• Se o tempo "Outro" dominar, o problema será a infraestrutura (latência de rede para DirectQuery, gargalos de gateway ou limitação de capacidade).

A etapa crítica que a maioria das pessoas ignora: Copie a consulta DAX do Performance Analyzer (clique com o botão direito > "Copiar consulta") e cole-a no DAX Studio. O Performance Analyzer informa qual visual está lento. O DAX Studio explica por quê.

Estúdio DAX

O DAX Studio é uma ferramenta gratuita e de código aberto que fornece recursos de diagnóstico profundos para o mecanismo do Analysis Services subjacente ao Power BI. É a ferramenta mais importante em qualquer kit de ferramentas de engenheiro de desempenho do Power BI.

Principais capacidades do DAX Studio:

Temporizações do servidor: mostra o detalhamento entre o tempo de consulta do Storage Engine (SE) e do Formula Engine (FE).

• Consultas do Storage Engine (SE) são varreduras de dados executadas no armazenamento colunar (mecanismo VertiPaq). Eles são altamente paralelizados e rápidos. As consultas SE aparecem como instruções xmSQL no rastreamento.
• Operações do Formula Engine (FE) são cálculos de thread único realizados nos resultados de consultas SE. As operações FE são o principal gargalo na maioria das medidas lentas do DAX.

O objetivo da otimização é colocar o máximo de trabalho possível no Storage Engine e minimizar as operações do Formula Engine.

Planos de consulta: o DAX Studio pode exibir planos de consulta lógicos e físicos, mostrando exatamente como o mecanismo processa sua medida. Para usuários avançados, os planos de consulta revelam oportunidades de otimização invisíveis apenas nos dados de tempo.

VertiPaq Analyzer: verifica todo o modelo de dados e relata o tamanho da coluna, cardinalidade, tipo de codificação e tamanho do dicionário para cada coluna em cada tabela. É assim que você identifica colunas e tabelas superdimensionadas que estão inflando seu modelo.

Metodologia de Otimização Sistemática

1. Linha de base: registre os tempos de carregamento de cada página usando o Performance Analyzer. Tamanho do modelo do documento (Arquivo > Informações > Reduzir tamanho do arquivo > Analisar). Registre métricas de capacidade se estiver em Premium/Fabric.

2. Identificar: Classifique os resultados do Performance Analyzer por duração total. Concentre-se nos 5 visuais mais lentos – eles proporcionam o maior impacto quando otimizados.

3. Diagnóstico: Copie cada consulta lenta para o DAX Studio. Analise o tempo SE vs FE. Identifique padrões DAX específicos que causam gargalos de FE.

4. Otimizar: aplique correções direcionadas (abordadas em detalhes abaixo). Teste cada mudança individualmente para medir seu impacto.

5. Validar: Execute novamente o Performance Analyzer e compare com a linha de base. Documente a melhoria para cada otimização.

6. Monitorar: Configure o monitoramento contínuo do desempenho (métricas de capacidade, problemas relatados pelo usuário, verificações periódicas do Performance Analyzer) para evitar regressão.

---

Padrões e correções lentas do DAX

Padrão 1: CALCULATE Nesting desnecessário

O problema:

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

Instruções CALCULATE aninhadas não adicionam poder – elas adicionam confusão e, às vezes, sobrecarga de desempenho. Cada CALCULATE cria um novo contexto de filtro, e aninhá-los pode produzir resultados inesperados e forçar o Formula Engine a realizar transições de contexto redundantes.

A correção:

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

Combine argumentos de filtro em um único CALCULATE. Vários argumentos de filtro são aplicados simultaneamente (interseção). Isso produz o mesmo resultado com uma execução mais limpa.

Padrão 2: FILTER com ALL em vez de filtros diretos de coluna

O problema:

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

FILTER(ALL(Products), ...) força o mecanismo a materializar toda a tabela Products no Formula Engine e, em seguida, iterar em cada linha para aplicar o filtro. Para uma tabela com milhões de linhas, isso é extraordinariamente lento.

A correção:

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

Os filtros de coluna diretos em CALCULATE são resolvidos no mecanismo de armazenamento, que é muito mais rápido. Use FILTER somente quando precisar aplicar uma condição complexa que não pode ser expressa como uma simples comparação de colunas (por exemplo, filtrar um valor de medida ou uma condição envolvendo múltiplas colunas).

Regra geral: Se sua condição FILTER fizer referência a uma única coluna com uma comparação simples, substitua-a por um argumento de filtro direto CALCULATE. Reserve FILTER para condições genuinamente complexas.

Padrão 3: Iteradores onde agregadores são suficientes

O problema:

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SUMX itera em cada linha da tabela Sales, avaliando a expressão para cada linha no Formula Engine. Para uma tabela Sales com 10 milhões de linhas, isso significa 10 milhões de operações FE.

A correção:

Se o cálculo for uma simples multiplicação de duas colunas, calcule-o previamente como uma coluna calculada:

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

SUM opera no Storage Engine, que processa dados colunares em lotes altamente otimizados. A coluna calculada aumenta o tamanho do modelo, mas reduz drasticamente o tempo de consulta.

Quando manter SUMX: Use SUMX quando precisar de lógica condicional em nível de linha (por exemplo, SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount]))) ou ao iterar em uma tabela pequena (tabelas de dimensão com milhares, não milhões, de linhas).

Padrão 4: Grandes Tabelas Intermediárias

O problema:

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

SUMMARIZE cria uma tabela intermediária no Formula Engine. Se a combinação de Categoria e Mês produzir 10.000 linhas e [Cálculo Complexo] acionar consultas SE adicionais para cada linha, o resultado será mais de 10.000 consultas --- um padrão de desempenho catastrófico conhecido como "tempestades de consultas SE".

A correção:

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

Ao materializar o subtotal em ADDCOLUMNS (que usa a transição de contexto de forma eficiente), as referências subsequentes a @SubTotal não acionam consultas SE adicionais. As variáveis ​​(VAR) também garantem que a tabela seja avaliada apenas uma vez, mesmo se for referenciada diversas vezes.

Padrão 5: Impacto no desempenho da segurança em nível de linha

O problema:

RLS com expressões DAX complexas avalia cada consulta, adicionando sobrecarga que se compõe entre os recursos visuais. Uma regra RLS mal escrita pode duplicar ou triplicar o tempo de carregamento do relatório.

Destruidores comuns de desempenho de RLS:

• LOOKUPVALUE em filtros RLS (força a avaliação FE por linha)
• Operadores CONTAINS ou IN em tabelas grandes
• Regras RLS que fazem referência a medidas em vez de filtros de coluna simples
• RLS multi-mesa com problemas de direção de filtro cruzado

A correção:

• Use comparações simples de colunas: [TenantId] = USERNAME() ou [Region] IN VALUES(SecurityTable[Region])
• Mapeamentos de segurança pré-computados em uma tabela de dimensões dedicada com relacionamentos diretos
• Evite medidas em regras RLS --- use apenas filtros em nível de coluna
• Teste o desempenho do RLS com o DAX Studio comparando os tempos de consulta com e sem o RLS ativo

---

Redução do tamanho do modelo

Por que o tamanho do modelo é importante

O modo de importação do Power BI armazena dados em um formato colunar altamente compactado (mecanismo VertiPaq). O tamanho do modelo impacta diretamente:

• Consumo de memória: Todo o modelo deve caber na memória. No Premium/Fabric, modelos maiores consomem mais capacidade e podem desencadear limitação de pressão de memória.
• Duração da atualização: modelos maiores demoram mais para serem atualizados porque mais dados precisam ser processados, compactados e carregados.
• Desempenho de consulta: modelos maiores produzem varreduras maiores, o que aumenta o tempo de consulta mesmo para DAX bem otimizado.
• Tamanho do arquivo: arquivos PBIX com modelos grandes demoram para salvar, publicar e baixar.

Identificando contribuidores do tamanho do modelo

Use o VertiPaq Analyzer do DAX Studio (Avançado > Visualizar métricas) para identificar as maiores tabelas e colunas:

Técnicas de otimização

Remover colunas não utilizadas:

A otimização única de maior impacto. Cada coluna do seu modelo consome memória, seja ela usada ou não. Audite seu modelo e remova qualquer coluna não referenciada em uma regra visual, de medida, de relacionamento ou de RLS.

Impacto típico: redução de 20-40% no tamanho do modelo.

Reduza a cardinalidade da coluna de texto:

Colunas de texto com muitos valores exclusivos (descrições, endereços, notas) são mal compactadas. Se a coluna for necessária apenas para exibição (não para filtragem ou agrupamento), considere movê-la para uma tabela somente de detalhes ou truncar valores longos.

Para colunas usadas no agrupamento/filtragem, considere agrupar: em vez de 50.000 nomes de produtos exclusivos, agrupe em 500 categorias de produtos com uma tabela de pesquisa separada para detalhes de produtos individuais.

Otimize os tipos de dados:

• Use Inteiro em vez de Decimal quando os valores forem números inteiros (economiza 50% por coluna)
• Use Date em vez de DateTime quando o tempo não for necessário (reduz a cardinalidade)
• Evite armazenar valores numéricos como texto (o texto é compactado muito pior que os números)
• Use booleano em vez de texto para colunas sim/não ou verdadeiro/falso

Impacto típico: redução de 10-20% no tamanho do modelo.

Dividir tabelas grandes:

Uma tabela de fatos de 100 milhões de linhas pode ser dividida em dados ativos (ano atual, carregados a cada atualização) e dados históricos (anos anteriores, carregados com menos frequência ou armazenados como agregações). Isso reduz o tamanho do modelo e a duração da atualização.

Tabelas de agregação (abordadas em detalhes abaixo):

Para tabelas de fatos grandes, as tabelas de agregação fornecem a maior melhoria de desempenho ao pré-computar dados resumidos em granularidades comumente consultadas.

---

Tabelas de agregação

O que são tabelas de agregação

As tabelas de agregação são tabelas de resumo pré-calculadas que o Power BI consulta em vez de verificar a tabela de detalhes completa. Quando um usuário visualiza um gráfico que mostra a receita mensal por região, o Power BI consulta a tabela de agregação (que pode ter 120 linhas: 10 regiões x 12 meses) em vez da tabela de detalhes (que pode ter 50 milhões de linhas de transação).

O poder das tabelas de agregação é que elas são transparentes para relatar os consumidores. Os usuários interagem com os mesmos recursos visuais e medidas. O Power BI roteia automaticamente as consultas para a tabela de agregação quando a granularidade da consulta corresponde e passa para a tabela de detalhes para consultas detalhadas ou em nível de detalhe.

Projetando tabelas de agregação

Etapa 1: Identificar a granularidade da agregação.

Analise seus relatórios para determinar as granularidades de consulta mais comuns. Para um painel de vendas:

• A maioria das consultas visuais executivas no nível Mês + Região + Categoria do Produto
• Consulta visual do gerente no nível Semana + Loja + Produto
• Consulta de tabelas detalhadas em nível de transação individual

Projete uma ou duas tabelas de agregação nas granularidades mais comumente consultadas.

Etapa 2: Crie a tabela de agregação.

No Power Query, crie uma nova tabela que agrupe sua tabela de fatos na granularidade de agregação:

Etapa 3: Configurar mapeamentos de agregação.

No Power BI Desktop, selecione a tabela de agregação, vá para Propriedades > Gerenciar Agregações e mapeie cada coluna de agregação para sua coluna e função da tabela de detalhes correspondente:

Etapa 4: ocultar a tabela de agregação.

Os usuários não devem interagir diretamente com a tabela de agregação. Oculte-o da visualização do relatório. O Power BI o utiliza de forma automática e transparente.

Impacto no desempenho da agregação

Essas melhorias são aplicadas nas páginas do relatório. Uma página com 10 elementos visuais, cada um consultando a tabela de agregação em vez da tabela de detalhes, pode carregar em 1 segundo em vez de 30 segundos.

Manutenção da tabela de agregação

• Atualize as tabelas de agregação na mesma programação das tabelas de detalhes para manter a consistência
• Monitore as taxas de acerto da agregação usando o DAX Studio (os eventos de rastreamento mostram se as consultas atingiram a agregação ou falharam)
• Adicione novas tabelas de agregação à medida que você identifica padrões de consulta comuns adicionais
• Remover tabelas de agregação cuja taxa de acerto caia abaixo de 50% (consomem espaço sem benefício suficiente)

---

Otimização DirectQuery

Quando o DirectQuery é necessário

O DirectQuery consulta o banco de dados de origem em tempo real, em vez de importar dados para o mecanismo na memória do Power BI. É necessário quando:

• Os requisitos de atualização de dados exigem latência inferior a um minuto (negociação de ações, monitoramento de IoT, detecção de fraudes)
• O conjunto de dados excede os limites de tamanho do modelo do Power BI (10 GB no Premium P1, 25 GB no P2 etc.)
• A conformidade ou a segurança exigem que os dados nunca saiam do sistema de origem
• O banco de dados de origem já possui amplas visualizações materializadas e infraestrutura de agregação

Para todos os outros cenários, o modo Importação é fortemente preferido. O modo de importação é 10 a 100 vezes mais rápido para consultas interativas e oferece uma melhor experiência ao usuário.

Estratégias de desempenho do DirectQuery

Reduza o número de recursos visuais por página.

Cada visual no modo DirectQuery gera uma consulta separada no banco de dados de origem. Uma página com 20 elementos visuais gera 20 consultas simultâneas quando a página é carregada, além de consultas adicionais quando os filtros são alterados. Limite as páginas do DirectQuery a no máximo 8 a 10 elementos visuais.

Otimize o banco de dados de origem.

O Power BI envia consultas SQL (ou consultas nativas para fontes não SQL) para a origem. O desempenho do banco de dados de origem determina diretamente o desempenho do relatório. Certifique-se de:

• Existem índices em todas as colunas usadas em filtros, relacionamentos e medidas
• As estatísticas estão atualizadas nas tabelas consultadas
• O servidor de banco de dados possui CPU e memória suficientes para consultas analíticas simultâneas juntamente com cargas de trabalho operacionais
• Considere a criação de visualizações materializadas ou indexadas para padrões de consulta comuns

Ative opções de redução de consulta.

Em Power BI Desktop > Opções > Redução de consulta, habilite:

• "Reduza o número de consultas enviadas ao não enviar consultas com destaque cruzado": evita que a filtragem cruzada entre recursos visuais gere consultas adicionais
• "Adicionar um botão Aplicar a cada segmentação de dados": os usuários ajustam várias segmentações de dados antes da execução das consultas, reduzindo o volume total de consultas
• "Adicionar um botão Aplicar ao painel de filtros": O mesmo princípio para o painel de filtros

Use o modo de armazenamento duplo estrategicamente.

As tabelas podem ser definidas no modo "Dual", que armazena dados no modo Importação (para consultas locais rápidas) e mantém uma conexão DirectQuery (para relacionamentos com tabelas DirectQuery). Defina tabelas de dimensões (Produtos, Clientes, Datas) para o modo Dual enquanto mantém grandes tabelas de fatos no DirectQuery. Isso melhora drasticamente o desempenho do filtro e da segmentação de dados sem sacrificar a atualização dos dados nas tabelas de fatos.

Implemente o cache de consulta.

Habilite o "cache de consulta" nas configurações do conjunto de dados do serviço Power BI. Isso armazena em cache os resultados da consulta por um período configurável, exibindo resultados armazenados em cache para consultas idênticas. O cache de consultas é particularmente eficaz para painéis visualizados por muitos usuários com os mesmos filtros (por exemplo, um painel executivo que mostra métricas de toda a empresa).

---

Monitoramento de desempenho de capacidade

Principais métricas de capacidade

Para organizações com capacidade Premium ou Fabric, o desempenho da infraestrutura é tão importante quanto o design do relatório. A limitação da capacidade pode fazer com que até mesmo relatórios bem otimizados tenham um desempenho ruim.

Métricas a serem monitoradas:

O aplicativo de métricas de capacidade do Microsoft Fabric

A Microsoft fornece um aplicativo dedicado de monitoramento de capacidade no Power BI Service. Instale-o do AppSource e conecte-o à sua capacidade. Ele fornece:

• Utilização histórica e em tempo real da CPU com divisão por tipo de carga de trabalho
• Análise interativa de limitação mostrando quais operações acionaram a limitação
• Consumo de memória por conjunto de dados com histórico de despejo
• Atualizar tendências de desempenho
• Consultar percentis de desempenho

Revise este aplicativo semanalmente durante as fases de otimização e mensalmente durante o estado estacionário.

Dimensionamento correto da capacidade

A capacidade subprovisionada causa limitação e má experiência do usuário. Capacidade superprovisionada desperdiça dinheiro. O dimensionamento correto requer a compreensão do seu padrão de carga de trabalho:

• Horários de pico de uso: a maioria das organizações observa uma carga 2 a 3 vezes maior durante o horário comercial do que durante a noite. Se você dimensiona para pico e tem SKUs do Fabric F, considere fazer uma pausa durante a noite ou reduzir fora do horário comercial.
• Conflito entre atualização e interação: atualizações de dados e consultas interativas competem pelos mesmos recursos de capacidade. Programe atualizações pesadas fora dos horários de pico interativo. Se isso não for possível, considere capacidades separadas para cargas de trabalho interativas e de atualização.
• Projeção de crescimento: Planeje de 6 a 12 meses de crescimento. O tamanho do modelo, a contagem de usuários e a complexidade da consulta tendem a aumentar com o tempo. Crie 30-50% de margem de manobra no dimensionamento da capacidade.

---

Antes/Depois do Benchmarking

Por que o benchmarking é importante

Otimização sem medição é suposição. O benchmarking antes/depois prova que as mudanças melhoraram o desempenho, quantifica a melhoria para as partes interessadas e cria uma linha de base para detectar regressões futuras.

Metodologia de Benchmarking

Etapa 1: Definir métricas.

Etapa 2: registrar a linha de base.

Antes de fazer qualquer alteração, registre todas as métricas. Execute o Performance Analyzer 10 vezes para considerar o aquecimento e a variabilidade do cache. Registre a mediana (P50) e o percentil 95 (P95) para cada métrica.

Etapa 3: Implementar mudanças de forma incremental.

Faça uma otimização de cada vez e meça novamente após cada alteração. Isso identifica quais otimizações geraram maior impacto e evita mascarar uma regressão com uma melhoria em outro lugar.

Etapa 4: registrar métricas pós-otimização.

Após todas as otimizações, registre as mesmas métricas usando a mesma metodologia. Apresente os resultados em uma tabela de comparação:

Etapa 5: Agende o monitoramento contínuo.

O desempenho diminui com o tempo à medida que os dados aumentam, novas medidas são adicionadas e novos recursos visuais são criados. Agende revisões de desempenho trimestrais usando a mesma metodologia para detectar a regressão antecipadamente.

Para organizações que precisam de otimização sistemática de desempenho com métricas documentadas de antes/depois, a ECOSIRE fornece serviços abrangentes de desempenho do Power BI, incluindo análise do DAX Studio, otimização de modelo e ajuste de capacidade.

---

Técnicas Avançadas de Otimização

Grupos de cálculo

Os grupos de cálculo substituem variantes de medidas repetitivas por lógica de cálculo reutilizável. Em vez de criar medidas separadas para MTD, QTD, YTD, ano anterior e crescimento anual para cada medida base, um grupo de cálculo aplica essas transformações dinamicamente.

Benefício de desempenho: Menos medidas no modelo significam menos espaço de metadados e carregamento mais rápido do modelo. Mais importante ainda, os grupos de cálculo incentivam medidas básicas mais simples, que tendem a ter um desempenho melhor do que medidas complexas e completas.

Modelos Compostos

Os modelos compostos combinam o modo de importação e tabelas do DirectQuery em um único modelo. Use o modo de importação para tabelas de dimensões e tabelas de fatos consultadas com frequência, DirectQuery para tabelas muito grandes que mudam com muita frequência para importação.

Benefício de desempenho: pesquisas de dimensão e operações de filtro são executadas na velocidade de importação (microssegundos), enquanto as consultas de tabela de fatos são executadas na velocidade do DirectQuery (centenas de milissegundos a segundos). O resultado líquido é significativamente melhor que o DirectQuery puro.

Atualização incremental

A atualização incremental carrega apenas dados novos e alterados durante a atualização, em vez de recarregar todo o conjunto de dados. Para uma tabela de 100 milhões de linhas em que apenas 100.000 linhas são alteradas diariamente, a atualização incremental reduz o tempo de atualização em 99%.

Configuração: Defina um parâmetro RangeStart e RangeEnd no Power Query. Configure a política de atualização incremental para especificar quantos dias/meses de dados serão atualizados e quantos dados históricos serão retidos. O Power BI particiona automaticamente o conjunto de dados e atualiza apenas as partições ativas.

Benefício de desempenho: Redução drástica na duração da atualização e no consumo de capacidade durante a atualização. Também permite atualização em tempo real com partições DirectQuery na capacidade do Fabric.

Consulta dobrada

A dobragem de consultas envia as transformações do Power Query de volta para o banco de dados de origem, executando-as como SQL nativo em vez de no mecanismo do Power Query. As consultas dobradas são executadas muito mais rapidamente porque o mecanismo de banco de dados as otimiza e executa nativamente.

Como verificar: Clique com o botão direito em qualquer etapa do Power Query Editor e verifique se "Exibir consulta nativa" está disponível. Se for, a consulta passa para essa etapa. Se estiver esmaecido, a dobra foi interrompida na etapa anterior.

Separadores dobráveis ​​comuns: Colunas personalizadas com expressões M, mesclagem de tabelas de diferentes fontes, determinadas transformações (dinamização, conversões de tipos complexos). Ao dobrar quebras, todas as transformações subsequentes são executadas no mecanismo Power Query, que é significativamente mais lento para grandes conjuntos de dados.

---

Perguntas frequentes

Qual é uma boa meta para o tempo de carregamento do relatório do Power BI?

Meta de menos de 3 segundos para painéis usados ​​com frequência e menos de 5 segundos para relatórios analíticos detalhados. Essas metas se alinham às expectativas dos usuários em relação aos aplicativos da web e mantêm alto o envolvimento. Os relatórios que excedem consistentemente 10 segundos devem ser priorizados para otimização. Meça o tempo de carregamento da perspectiva do usuário (incluindo rede e renderização), não apenas o tempo de consulta DAX. O tempo de consulta DAX do Performance Analyzer mais o tempo de renderização visual devem totalizar menos de 2 segundos para cada visual para atingir um carregamento de página de 3 segundos com 8 a 10 visuais.

Devo sempre preferir o modo Importar em vez do DirectQuery?

Para relatórios interativos consumidos por usuários empresariais, sim --- O modo de importação é quase sempre a melhor escolha. O modo de importação é 10 a 100 vezes mais rápido para consultas, não depende do desempenho do banco de dados de origem durante a visualização de relatórios e oferece suporte a toda a gama de funções DAX e recursos de IA. Use o DirectQuery somente quando você tiver um requisito genuíno de atualização de dados em menos de um minuto, quando seu conjunto de dados exceder os limites de tamanho de importação ou quando a conformidade exigir que os dados permaneçam no sistema de origem. Considere os modelos compostos como um meio-termo: importe as dimensões e os fatos consultados com frequência, DirectQuery apenas as tabelas que realmente precisam de atualização em tempo real.

Com que frequência devo executar auditorias de desempenho em meus relatórios do Power BI?

Realize uma auditoria de desempenho abrangente trimestralmente para relatórios de produção. Entre as auditorias, monitore as métricas de capacidade semanalmente e investigue imediatamente qualquer lentidão relatada pelo usuário. Os principais eventos que devem desencadear uma auditoria imediata incluem: crescimento significativo do volume de dados (aumento superior a 25%), adição de novas páginas de relatório ou medidas DAX complexas, alterações na simultaneidade de usuários (crescimento de usuários pós-lançamento) e alterações de capacidade (upgrade, downgrade ou migração).

Posso otimizar o desempenho do Power BI sem alterar meus relatórios?

Sim, até certo ponto. As otimizações no nível da infraestrutura incluem: atualização de SKU de capacidade, ativação do cache de consultas nas configurações de serviço, agendamento de atualizações pesadas fora dos horários de pico, configuração de cluster de gateway para melhor rendimento e otimização do banco de dados de origem (índices, estatísticas, visualizações materializadas). Essas alterações melhoram o desempenho sem alterar os arquivos de relatório. No entanto, as otimizações mais impactantes normalmente envolvem alterações no nível do relatório: reescrita de medidas DAX, redução do tamanho do modelo, tabelas de agregação e redução de contagem visual. A otimização da infraestrutura aborda as restrições de capacidade; a otimização do relatório aborda a eficiência.

O que faz com que os relatórios do Power BI fiquem mais lentos com o tempo?

Cinco causas comuns: (1) Crescimento do volume de dados --- as mesmas consultas demoram mais à medida que as tabelas crescem de 1 milhão para 10 milhões de linhas. (2) Acumulação de medidas --- novas medidas são adicionadas sem otimizar as existentes, e as interações entre as medidas criam uma complexidade crescente. (3) Expansão visual – os usuários adicionam mais recursos visuais por página, cada um gerando consultas adicionais. (4) Inchaço do modelo --- novas colunas e tabelas são adicionadas sem remover as não utilizadas. (5) Crescimento simultâneo de usuários --- mais usuários competindo pelos mesmos recursos de capacidade. Aborde essas questões com auditorias de desempenho trimestrais, políticas de governança que limitam a contagem visual e medem a complexidade e monitoramento proativo da capacidade.