Share via

Guia de otimização para o Power BI

  • Artigo

Este artigo fornece orientações que permitem que desenvolvedores e administradores produzam e mantenham soluções otimizadas do Power BI. Você pode otimizar sua solução em diferentes camadas arquitetônicas. As camadas incluem:

  • A(s) fonte(s) de dados
  • O modelo de dados
  • Visualizações, incluindo painéis, relatórios do Power BI e relatórios paginados do Power BI
  • O ambiente, incluindo capacidades, gateways de dados e a rede

Otimizando o modelo de dados

O modelo de dados suporta toda a experiência de visualização. Os modelos de dados são hospedados no ecossistema do Power BI ou externamente (usando DirectQuery ou Live Connection) e, no Power BI, são chamados de modelos semânticos, anteriormente conhecidos como conjuntos de dados. É importante entender suas opções e escolher o tipo de modelo semântico apropriado para sua solução. Existem três modos de modelo semântico: Import, DirectQuery e Composite. Para obter mais informações, consulte Modelos semânticos no serviço do Power BI e Modos de modelo semântico no serviço do Power BI.

Para obter orientações específicas sobre o modo de modelo semântico, consulte:

Otimizando visualizações

As visualizações do Power BI podem ser dashboards, relatórios do Power BI ou relatórios paginados do Power BI. Cada um tem arquiteturas diferentes e, portanto, cada um tem sua própria orientação.

Dashboards

É importante entender que o Power BI mantém um cache para seus blocos de painel, exceto blocos de relatório dinâmico e blocos de streaming. Se o seu modelo semântico impõe segurança dinâmica em nível de linha (RLS), certifique-se de entender as implicações de desempenho, pois os blocos serão armazenados em cache por usuário.

Quando você fixa blocos de relatório dinâmicos em um painel, eles não são servidos a partir do cache de consulta. Em vez disso, eles se comportam como relatórios e fazem consultas a v-cores em tempo real.

Como o nome sugere, recuperar os dados do cache fornece um desempenho melhor e mais consistente do que confiar na fonte de dados. Uma maneira de aproveitar essa funcionalidade é fazer com que os painéis sejam a primeira página de destino para seus usuários. Fixe visuais frequentemente usados e altamente solicitados nos painéis. Desta forma, os painéis tornam-se uma valiosa "primeira linha de defesa", que proporciona um desempenho consistente com menos carga sobre a capacidade. Os usuários ainda podem clicar em um relatório para analisar detalhes.

Para modelos semânticos DirectQuery e conexão ao vivo, o cache é atualizado periodicamente consultando a fonte de dados. Por padrão, isso acontece a cada hora, embora você possa configurar uma frequência diferente nas configurações do modelo semântico. Cada atualização de cache enviará consultas à fonte de dados subjacente para atualizar o cache. O número de consultas geradas depende do número de elementos visuais fixados aos painéis que dependem da fonte de dados. Observe que, se a segurança em nível de linha estiver habilitada, as consultas serão geradas para cada contexto de segurança diferente. Por exemplo, considere que há duas funções diferentes que categorizam seus usuários e eles têm duas exibições diferentes dos dados. Durante a atualização do cache de consulta, o Power BI gera dois conjuntos de consultas.

Relatórios do Power BI

Há várias recomendações para otimizar os designs de relatório do Power BI.

Nota

Quando os relatórios são baseados em um modelo semântico do DirectQuery, para otimizações adicionais de design de relatório, consulte Diretrizes de modelo do DirectQuery no Power BI Desktop (Otimizar designs de relatório).

Aplicar os filtros mais restritivos

Quanto mais dados um visual precisa exibir, mais lento ele é para carregar. Embora este princípio pareça óbvio, é fácil de esquecer. Por exemplo: suponha que você tenha um modelo semântico grande. Com base nesse modelo semântico, você cria um relatório com uma tabela. Os usuários finais usam segmentações de dados na página para chegar às linhas que desejam — normalmente, eles só estão interessados em algumas dezenas de linhas.

Um erro comum é deixar a visualização padrão da tabela sem filtro, ou seja, todas as linhas 100M+. Os dados dessas linhas são carregados na memória e descompactados a cada atualização. Esse processamento cria enormes demandas por memória. A solução: use o filtro "Top N" para reduzir o número máximo de itens que a tabela exibe. Você pode definir o item máximo como maior do que os usuários precisariam, por exemplo, 10.000. O resultado é que a experiência do usuário final não muda, mas o uso de memória cai muito. E o mais importante, o desempenho melhora.

Uma abordagem de design semelhante à acima é sugerida para cada visual em seu relatório. Pergunte a si mesmo, todos os dados neste visual são necessários? Existem maneiras de filtrar a quantidade de dados mostrados no visual com impacto mínimo na experiência do usuário final? Lembre-se, as mesas em particular podem ser caras.

Limitar elementos visuais em páginas de relatório

O princípio acima se aplica igualmente ao número de elementos visuais adicionados a uma página de relatório. É altamente recomendável limitar o número de elementos visuais em uma página de relatório específica apenas ao necessário. Páginas de detalhamento e dicas de ferramentas de página de relatório são ótimas maneiras de fornecer detalhes adicionais sem obstruir mais elementos visuais na página.

Avalie o desempenho visual personalizado

Certifique-se de colocar cada visual personalizado através de seus ritmos para garantir o alto desempenho. Visuais do Power BI mal otimizados podem afetar negativamente o desempenho de todo o relatório.

Relatórios paginados do Power BI

Os designs de relatório paginado do Power BI podem ser otimizados aplicando o design de práticas recomendadas à recuperação de dados do relatório. Para obter mais informações, consulte Diretrizes de recuperação de dados para relatórios paginados.

Além disso, verifique se sua capacidade tem memória suficiente alocada para a carga de trabalho de relatórios paginados.

Otimizando o ambiente

Você pode otimizar o ambiente do Power BI definindo configurações de capacidade, dimensionando gateways de dados e reduzindo a latência da rede.

Definições de capacidade

Ao usar capacidades, disponíveis com Power BI Premium (SKUs P), licenças Premium Por Usuário (PPU) ou Power BI Embedded (SKUs A, A4-A6), você pode gerenciar configurações de capacidade. Para obter mais informações, consulte Licenças de capacidade do Microsoft Fabric e Gerenciando capacidades Premium.

Importante

Às vezes, este artigo se refere ao Power BI Premium ou suas assinaturas de capacidade (SKUs P). Lembre-se de que a Microsoft está atualmente consolidando opções de compra e desativando as SKUs do Power BI Premium por capacidade. Em vez disso, os clientes novos e existentes devem considerar a compra de assinaturas de capacidade de malha (SKUs F).

Para obter mais informações, consulte Atualização importante chegando ao licenciamento do Power BI Premium e Perguntas frequentes sobre o Power BI Premium.

Dimensionamento do gateway

Um gateway é necessário sempre que o Power BI precisa acessar dados que não estão acessíveis diretamente pela Internet. Você pode instalar o gateway de dados local em um servidor local ou IaaS (infraestrutura como serviço) hospedada por VM.

Para entender as cargas de trabalho do gateway e as recomendações de dimensionamento, consulte Dimensionamento do gateway de dados local.

Latência de rede

A latência da rede pode afetar o desempenho do relatório, aumentando o tempo necessário para que as solicitações cheguem ao serviço do Power BI e para que as respostas sejam entregues. Os locatários no Power BI são atribuídos a uma região específica.

Gorjeta

Para determinar onde seu locatário está localizado, consulte Onde meu locatário do Power BI está localizado?

Quando os usuários de um locatário acessam o serviço do Power BI, suas solicitações sempre são encaminhadas para essa região. À medida que as solicitações chegam ao serviço do Power BI, o serviço pode enviar solicitações adicionais — por exemplo, para a fonte de dados subjacente ou um gateway de dados — que também estão sujeitas à latência da rede.

Ferramentas como o Teste de Velocidade do Azure fornecem uma indicação da latência da rede entre o cliente e a região do Azure. Em geral, para minimizar o impacto da latência da rede, esforce-se para manter as fontes de dados, gateways e sua capacidade do Power BI o mais próximo possível. Preferencialmente, residem na mesma região. Se a latência da rede for um problema, tente localizar gateways e fontes de dados mais próximos da sua capacidade do Power BI colocando-os dentro de máquinas virtuais hospedadas na nuvem.

Monitorizar o desempenho

Você pode monitorar o desempenho para identificar gargalos. Consultas lentas — ou visuais de relatório — devem ser um ponto focal da otimização contínua. O monitoramento pode ser feito em tempo de design no Power BI Desktop ou em cargas de trabalho de produção nas capacidades do Power BI Premium. Para obter mais informações, consulte Monitorando o desempenho do relatório no Power BI.

Conteúdos relacionados

Para obter mais informações sobre este artigo, consulte os seguintes recursos: