Share via

Planejamento de implementação do Power BI: auditoria em nível de dados

  • Artigo

Observação

Este artigo faz parte da série de artigos sobre o Planejamento de implantação do Power BI. Esta série se concentra principalmente na carga de trabalho do Power BI dentro do Microsoft Fabric. Para ter uma introdução a essa série, confira Planejamento de implementação do Power BI.

Este artigo de auditoria de nível de dados é direcionado a vários públicos-alvo:

  • Criadores de dados e administradores de workspace: usuários que precisam entender o uso, a adoção e o desempenho dos modelos semânticos (anteriormente conhecidos como conjuntos de dados), fluxos de dados e datamarts que eles criam, publicam e compartilham.
  • Administradores do Power BI: os administradores responsáveis por supervisionar o Power BI na organização. Os administradores do Power BI talvez precisem colaborar com TI, segurança, auditoria interna e outras equipes relevantes. Os administradores do Power BI também podem precisar colaborar com criadores de conteúdo ao solucionar problemas de desempenho.
  • Administradores de capacidade do Power BI: Os administradores responsáveis por supervisionar a capacidade Premium na organização. Os administradores de capacidade do Power BI podem precisar colaborar com criadores de conteúdo ao solucionar problemas de desempenho.
  • Equipe do Centro de Excelência, de TI e de BI: as equipes que também são responsáveis por supervisionar o Power BI. Talvez seja necessário colaborar com administradores do Power BI e outras equipes relevantes.
  • Administradores do sistema: A equipe responsável por criar e proteger recursos do Azure Log Analytics e os administradores de banco de dados que gerenciam fontes de dados.

Importante

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

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

Os conceitos abordados neste artigo se aplicam principalmente a soluções criadas para três escopos de entrega de conteúdo, especificamente BI corporativo, BI de departamento e BI de equipe. Os criadores de soluções pessoais de BI também podem achar as informações deste artigo úteis; no entanto, eles não são o destino principal.

Não é possível obter um bom desempenho em relatórios e visuais quando o modelo semântico subjacente e/ou a fonte de dados não está tendo um bom desempenho. Este artigo se concentra na auditoria e monitoramento de modelos semânticos, fluxos de dados e datamarts. É o segundo artigo da série de auditoria e monitoramento porque as ferramentas e técnicas são mais complexas do que o descrito no artigo Auditoria no nível do relatório. Idealmente, você cria modelos semânticos compartilhados (destinados à reutilização entre muitos relatórios) antes que os usuários criem relatórios. Portanto, recomendamos que você leia este artigo junto com o artigo Auditoria no nível do relatório.

Como os modelos semânticos do Power BI são criados no mecanismo de tabela do Analysis Services, você pode se conectar a um modelo de dados local (no Power BI Desktop) ou a um modelo semântico Premium (no serviço do Power BI) como se fosse um banco de dados do Analysis Services. Portanto, muitos dos recursos de auditoria e monitoramento do Analysis Services têm suporte para modelos semânticos do Power BI Premium.

Observação

Para obter mais informações sobre modelos hospedados no Analysis Services, confira Visão geral do monitoramento.

O restante deste artigo se concentra principalmente em modelos publicados no serviço do Power BI.

Logs de eventos de modelo semântico

Com o tempo, criadores de dados e proprietários podem enfrentar situações com seus modelos semânticos. Um modelo semântico pode:

Para garantir a usabilidade, o bom desempenho e a adoção do conteúdo criado por eles, você deve auditar o uso e o desempenho dos ativos de dados que você é responsável por gerenciar. Você pode usar os logs de eventos do conjunto de dados, que capturam atividades geradas pelo usuário e pelo sistema que ocorrem para um modelo semântico. Eles também são chamados de eventos de rastreamento, logs de conjunto de dados ou logs de atividades do conjunto de dados. Os administradores do sistema geralmente os chamam de eventos de rastreamento em nível baixo porque são detalhados.

Observação

A alteração do nome do conjunto de dados foi implementada no serviço do Power BI e na documentação, embora possa haver algumas instâncias — como nas operações de log de eventos — em que a alteração ainda não ocorreu.

Você deve analisar eventos de rastreamento de modelo semântico para:

  • Audite todas as atividades que ocorreram em um modelo semântico.
  • Solucione e otimize o desempenho do modelo semântico, o uso de memória e a eficiência da consulta.
  • Investigue os detalhes e duração da atualização semântica do modelo.
  • Monitore a linguagem de fórmula do Power Query (consultas M) enviada pelo Power Query.
  • Monitore fórmulas e expressões DAX enviadas para o modelo semântico (mecanismo do Analysis Services).
  • Verifique se o modo de armazenamento correto foi selecionado com base nas cargas de trabalho e necessidade de equilibrar dados atualizados e desempenho ideal.
  • Audite quais funções de segurança em nível de linha são invocadas, para quais usuários e em quais modelos semânticos.
  • Entenda o número de usuários simultâneos.
  • Valide um modelo semântico (por exemplo, para verificar a qualidade e o desempenho dos dados antes de endossar um modelo semântico ou antes de publicá-lo em um workspace de produção).

Os eventos gerados por um modelo semântico do Power BI são derivados de registros de diagnóstico disponíveis para o Azure Analysis Services existentes. Há muitos tipos de eventos de rastreamento que você pode capturar e analisar, que são descritos nas seções a seguir.

Azure Log Analytics

O Azure Log Analytics é um componente do serviço do Azure Monitor . A integração do Azure Log Analytics ao Power BI permite capturar eventos de modelo semântico de todos os modelos semânticos em um workspace do Power BI. Há suporte apenas para workspaces Premium. Depois de configurar a integração e a conexão ser habilitada (para um workspace do Power BI Premium), os eventos de modelo semântico são automaticamente capturados e enviados continuamente para um workspace do Azure Log Analytics. Os logs de modelo semântico são armazenados no Azure Data Explorer, que é um banco de dados somente acréscimo otimizado para capturar dados de telemetria de alto volume e quase em tempo real.

Você atribui um workspace do Power BI Premium a um workspace do Log Analytics no Azure. Você deve criar um novo recurso do Log Analytics em sua assinatura do Azure para habilitar esse tipo de registro em log.

Os logs de um ou mais workspaces do Power BI serão enviados para um workspace do Log Analytics de destino. Aqui estão algumas maneiras pelas quais você pode optar por organizar os dados.

  • Um workspace de destino para todos os dados de auditoria: Armazene todos os dados em um workspace do Log Analytics. Isso é útil quando o mesmo administrador ou usuário acessará todos os dados.
  • Workspaces de destino organizados por área de assunto: Organize o conteúdo por área de assunto. Essa técnica é particularmente útil quando diferentes administradores ou usuários têm permissão para acessar os dados de auditoria do Azure Log Analytics. Por exemplo, quando você precisa separar dados de vendas de dados de operações.
  • Um workspace de destino para cada workspace do Power BI: Configure uma relação um-para-um entre um workspace do Power BI e um workspace do Azure Log Analytics. Isso é útil quando você tem conteúdo particularmente confidencial ou quando os dados estão sujeitos a requisitos regulatórios ou de conformidade específicos.

Dica

Examine minuciosamente a documentação e as perguntas frequentes sobre essa funcionalidade para ter clareza sobre o que é possível e entender os requisitos técnicos. Antes de tornar essa funcionalidade amplamente disponível para administradores de workspace em sua organização, considere fazer uma POC (prova técnica de conceito) com um workspace do Power BI.

Importante

Embora os nomes sejam semelhantes, os dados capturados pelo Azure Log Analytics não são os mesmos que o log de atividades do Power BI. O Azure Log Analytics captura eventos de rastreamento em nível de detalhes do mecanismo do Analysis Services. Sua única finalidade é ajudá-lo a analisar e solucionar problemas de desempenho de modelo semântico. Seu escopo está no nível do workspace. Por outro lado, a finalidade do log de atividades é ajudar você a entender a frequência com que determinadas atividades do usuário ocorrem (como editar um relatório, atualizar um modelo semântico ou criar um aplicativo). Seu escopo é todo o locatário do Power BI.

Para obter mais informações sobre as atividades do usuário que você pode auditar para seu locatário do Power BI, confira Auditoria no nível do locatário.

A configuração de locatárioda conexão do Azure Log Analytics para administradores de workspace controla quais grupos de usuários (que também têm a função de administrador de workspace necessária) podem conectar um workspace do Power BI a um workspace existente do Azure Log Analytics.

Antes de configurar a integração, você deve atender aos pré-requisitos de segurança. Portanto, considere habilitar a configuração de locatário do Power BI somente para administradores de workspace do Power BI que também tenham as permissões necessárias no Azure Log Analytics ou que possam obter essas permissões mediante solicitação.

Dica

Colaborar com o administrador do Azure no início do processo de planejamento, especialmente ao obter aprovação para criar um recurso do Azure, é um desafio em sua organização. Você também precisará planejar os pré-requisitos de segurança. Decida se deseja conceder permissão ao administrador do workspace do Power BI no Azure ou se deseja conceder permissão ao administrador do Azure no Power BI.

Os logs de modelo semântico capturados pelo Azure Log Analytics incluem as consultas de modelo semântico, estatísticas de consulta, atividade de atualização detalhada, tempo de CPU consumido em capacidades Premium e muito mais. Como são logs em nível de detalhes do mecanismo do Analysis Services, os dados podem ser detalhados. Grandes volumes de dados são comuns para workspaces grandes que experimentam alta atividade de modelo semântico.

Para otimizar o custo ao usar o Azure Log Analytics com o Power BI:

  • Conecte workspaces do Power BI ao Azure Log Analytics somente quando você estiver ativamente solucionando problemas, testando, otimizando ou investigando a atividade de modelo semântico. Quando conectado, um rastreamento é executado em todos os modelos semânticos no workspace.
  • Desconecte o Azure Log Analytics de um workspace do Power BI quando você não precisar mais solucionar, testar, otimizar ou investigar a atividade de modelo semântico ativamente. Ao desconectar, você está encerrando a execução do rastreamento em todos os modelos semânticos no workspace.
  • Certifique-se de entender o modelo de custo de como o Azure Log Analytics cobra por ingestão, armazenamento e consultas de dados.
  • Não armazene os dados no Log Analytics por mais tempo do que o período de retenção padrão de 30 dias. Isso ocorre porque a análise de modelo semântico normalmente se concentra em atividades imediatas de solução de problemas.

Há várias maneiras de acessar os eventos que são enviados para o Azure Log Analytics. Você pode usar:

  • O aplicativo de modelo do Log Analytics predefinido para Modelos Semânticos do Power BI.
  • O conector do Power BI Desktop para Azure Data Explorer (Kusto). Use a Linguagem de Consulta Kusto (KQL) para analisar os dados armazenados no Log Analytics. Se você tiver experiência de consulta SQL, encontrará muitas semelhanças com o KQL.
  • A experiência de consulta baseada na Web no Azure Data Explorer.
  • Qualquer ferramenta de consulta que possa executar consultas KQL.

Dica

Como há um grande volume de eventos de rastreamento de modelo semântico, recomendamos que você desenvolva um modelo DirectQuery para analisar os dados. Um modelo do DirectQuery permite consultar os dados quase em tempo real. Os eventos geralmente chegam dentro de cinco minutos.

Para obter mais informações, confira Administrar conexões do Azure.

Lista de verificação – ao planejar usar o Azure Log Analytics, estas são algumas decisões e ações importantes:

  • Considere uma POC técnica: Planeje um projeto pequeno para garantir que você entenda completamente os requisitos técnicos, requisitos de segurança, quais eventos capturar e como analisar os logs.
  • Decida quais workspaces devem ser integrados ao Log Analytics: determine quais workspaces Premium contêm modelos semânticos que você está interessado em analisar.
  • Decida se o Log Analytics deve ser habilitado em tempo integral para qualquer workspace: Para otimização de custo, determine se há situações (ou workspaces específicos) em que o registro em log deve ser habilitado permanentemente. Decida se os workspaces deverão ser desconectados quando a solução de problemas não estiver ocorrendo.
  • Decida por quanto tempo manter os dados do Log Analytics: Determine se há a necessidade de definir um período de retenção mais longo do que o padrão de 30 dias.
  • Esclareça o processo para solicitar um novo workspace do Log Analytics: Colabore com o administrador do Azure para esclarecer como as solicitações para um novo recurso do Log Analytics devem ser enviadas pelos administradores do workspace do Power BI.
  • Decida como a segurança funcionará: Colabore com seu administrador do Azure para decidir se é mais viável que um administrador de workspace do Power BI tenha direitos a um workspace do Log Analytics do Azure ou que um administrador do Azure tenha direitos a um workspace do Power BI. Ao tomar essa decisão de segurança, considere seu plano para se conectar e desconectar workspaces regularmente (para otimização de custo).
  • Decida como organizar os workspaces do Log Analytics de destino: Considere quantos workspaces do Azure Log Analytics serão apropriados para organizar os dados de um ou mais workspaces do Power BI. Alinhe essa decisão com suas decisões de segurança para quem pode acessar os dados de log.
  • Decida quais administradores de workspace têm permissão para se conectar: Determine quais grupos de administradores de workspace podem conectar um workspace do Power BI a um workspace do Log Analytics. Defina a configuração de locatário de conexão do Azure Log Analytics para administradores de workspace para se alinhar a essa decisão.
  • Crie o recurso do Log Analytics do Azure: Colabore com o administrador do Azure para criar cada workspace do Log Analytics. Verifique e atualize as permissões atribuídas no Azure para garantir que a configuração do Power BI possa ocorrer sem problemas. Valide se os dados armazenados no Azure estão na região geográfica correta.
  • Defina a conexão do Log Analytics para cada workspace do Power BI: Colabore com os administradores do workspace do Power BI para configurar a conexão com o Log Analytics para cada workspace do Power BI. Verifique se os dados de log estão fluindo corretamente para o workspace do Log Analytics.
  • Crie consultas para analisar os dados: Configure consultas KQL para analisar os dados no Log Analytics com base no caso de uso e nas necessidades atuais.
  • Inclua diretrizes para administradores de workspace do Power BI: Forneça informações e pré-requisitos aos administradores do workspace do Power BI para saber como solicitar um novo workspace do Log Analytics e como se conectar a um workspace do Power BI. Além disso, explique quando é apropriado desconectar um workspace do Power BI.
  • Forneça diretrizes e consultas de exemplo para analisar os dados: Crie consultas KQL para administradores de workspace para facilitar a introdução à análise dos dados capturados.
  • Monitorar custos: Colabore com seu administrador do Azure para monitorar os custos do Log Analytics continuamente.

SQL Server Profiler

Você pode usar o SQL Server Profiler (SQL Profiler) para capturar eventos de modelo semântico do Power BI. É um componente do SQL Server Management Studio (SSMS). Há suporte para conectividade com um modelo semântico do Power BI com o SSMS porque ele se baseia na arquitetura do Analysis Services que se originou no SQL Server.

Você pode usar o SQL Profiler durante diferentes estágios do ciclo de vida de um modelo semântico.

  • Durante o desenvolvimento do modelo de dados: O SQL Profiler pode se conectar a um modelo de dados em Power BI Desktop como uma ferramenta externa. Essa abordagem é útil para modeladores de dados que desejam validar seu modelo de dados ou fazer ajustes de desempenho.
  • Depois que o modelo semântico é publicado no serviço do Power BI: o SQL Profiler pode se conectar a um modelo semântico em um workspace Premium. O SSMS é uma das muitas ferramentas de cliente com suporte que podem usar o ponto de extremidade XMLA para conectividade. Essa abordagem é útil quando você deseja auditar, monitorar, validar, solucionar problemas ou ajustar um modelo semântico publicado no serviço do Power BI.

Também é possível usar o SQL Profiler como uma ferramenta externa no DAX Studio. Você pode usar o DAX Studio para iniciar um rastreamento do criador de perfil, analisar os dados e formatar os resultados. Os modeladores de dados que usam o DAX Studio geralmente preferem essa abordagem em vez de usar o SQL Profiler diretamente.

Observação

O uso do SQL Profiler é um caso de uso diferente da atividade de criação de perfil de dados. Você cria um perfil de dados no Editor do Power Query para obter uma compreensão mais profunda de suas características. Embora a criação de perfil de dados seja uma atividade importante para modeladores de dados, ela não está no escopo deste artigo.

Considere usar o SQL Profiler em vez do Azure Log Analytics quando:

  • Sua organização não permitir que você use ou crie recursos do Azure Log Analytics no Azure.
  • Você desejar capturar eventos para um modelo de dados no Power BI Desktop (que não foi publicado em um workspace Premium no serviço do Power BI).
  • Você deseja capturar eventos para um modelo semântico por um curto período de tempo (em vez de todos os modelos semânticos em um workspace Premium).
  • Você desejar capturar determinados eventos somente durante um rastreamento (como apenas o evento Query End).
  • Você deseja iniciar e parar rastreamentos com frequência (como quando você precisa capturar eventos de modelo semântico que estão ocorrendo agora).

Assim como o Azure Log Analytics (descrito anteriormente neste artigo), os eventos de modelo semântico capturados pelo SQL Profiler são derivados de registros de diagnóstico disponíveis para o Azure Analysis Services existentes. No entanto, há algumas diferenças nos eventos que estão disponíveis.

Dica

O uso do SQL Profiler para monitorar o Analysis Services é abordado em muitos livros, artigos e postagens no blog. A maioria dessas informações é relevante para monitorar um modelo semântico do Power BI.

Importante

Você também pode usar o SQL Profiler para monitorar consultas enviadas do serviço do Power BI para as fontes de dados subjacentes (por exemplo, para um banco de dados relacional do SQL Server). No entanto, a capacidade de rastrear um banco de dados relacional foi preterida. A conexão com o mecanismo do Analysis Services tem suporte e não foi preterida. Se você estiver familiarizado com eventos estendidos do Analysis Services e preferir usá-los, a conectividade do SSMS será possível para um modelo de dados no Power BI Desktop. No entanto, não há suporte para Power BI Premium. Portanto, esta seção se concentra apenas na conectividade padrão do SQL Profiler.

A configuração de locatário Permitir pontos de extremidade XMLA e Analisar no Excel com modelos semânticos locais controla quais grupos de usuários (que também são atribuídos à função de espaço de trabalho Colaborador, Membro ou Administrador, ou à permissão Criar para o modelo semântico individual) podem usar o ponto de extremidade XMLA para consultar e/ou manter modelos semânticos no serviço do Power BI. Para obter mais informações sobre o uso do ponto de extremidade XMLA, confira o cenário de uso do gerenciamento de modelo de dados avançados.

Observação

Você também pode usar o SQL Profiler para ajudar a depurar e solucionar problemas de expressões DAX específicas. Você pode conectar o SQL Profiler ao Power BI Desktop como uma ferramenta externa. Procure a classe de evento Log de Avaliação do DAX para exibir os resultados intermediários de uma expressão DAX. Esse evento é gerado quando você usa a função do DAX EVALUATEANDLOG em um cálculo de modelo.

Essa função destina-se apenas a fins de desenvolvimento e teste. Você deve removê-la dos cálculos do modelo de dados antes de publicar o modelo de dados em um workspace de produção.

Lista de verificação – ao planejar o uso do SQL Profiler, estas são algumas decisões e ações importantes:

  • Decida quem pode ter o SSMS ou o DAX Studio instalado: Determine se você permitirá que todos os criadores de conteúdo do Power BI em sua organização instalem o SSMS e/ou o DAX Studio para que eles possam usar o SQL Profiler. Decida se essas ferramentas auxiliares são instaladas mediante solicitação ou como parte de um conjunto padrão de software instalado para criadores de dados aprovados na organização.
  • Adicione o SQL Profiler ao menu Ferramentas Externas no Power BI Desktop: se os criadores de dados usarem o SQL Profiler com frequência, peça à equipe de TI para adicioná-lo automaticamente ao menu Ferramentas Externas no Power BI Desktop para esses usuários.
  • Decida quem pode usar o ponto de extremidade XMLA: determine se todos os usuários têm permissão para se conectar a modelos semânticos publicados usando o ponto de extremidade XMLA ou se ele está limitado apenas aos criadores de dados aprovados. Defina os pontos de extremidade Permitir XMLA e Analisar no Excel com a configuração de locatário de modelos semânticos locais para se alinhar a essa decisão.
  • Forneça diretrizes e consultas de exemplo para analisar os dados: crie documentação para seus criadores de dados para que eles entendam a maneira recomendada de auditar e monitorar modelos semânticos. Forneça diretrizes para casos de uso comuns para facilitar a coleta e análise de dados de rastreamento.

Metadados do modelo de dados

Como os modelos semânticos do Power BI são criados com base no mecanismo do Analysis Services, você tem acesso às ferramentas que podem consultar os metadados de um modelo de dados. Os metadados incluem tudo sobre o modelo de dados, incluindo nomes de tabela, nomes de coluna e expressões de medida.

Exibições de gerenciamento dinâmico

As Exibições de Gerenciamento Dinâmico (DMVs) do Analysis Services podem consultar os metadados do modelo de dados. Você pode usar as DMVs para auditar, documentar e otimizar seus modelos de dados em determinado momento.

Especificamente, você pode:

  • Audite as fontes de dados usadas por um modelo.
  • Descubra quais objetos estão consumindo mais memória em um modelo.
  • Determine a eficiência com que os dados de coluna podem ser compactados.
  • Encontre colunas em um modelo que não são usadas.
  • Audite sessões e conexões de usuário ativas.
  • Verifique a estrutura do modelo.
  • Examine as expressões DAX usadas por tabelas calculadas, colunas calculadas, medidas e regras de segurança em nível de linha (RLS).
  • Identifique dependências entre objetos e medidas.

Dica

Os DMVs recuperam informações sobre o estado atual de um modelo semântico. Pense nos dados retornados por DMVs como uma instantâneo do que está ocorrendo em determinado momento. Por outro lado, os logs de eventos do modelo semântico (descritos anteriormente neste artigo) recuperam informações sobre quais atividades ocorreram para um modelo semântico enquanto uma conexão de rastreamento estava ativa.

O SSMS é uma ferramenta comumente usada para executar consultas DMV. Você também pode usar o cmdlet Invoke-ASCmd do PowerShell para criar e executar scripts XMLA que consultam as DMVs.

Ferramentas de terceiros e ferramentas externas também são populares na comunidade do Power BI. Essas ferramentas usam as DMVs documentadas publicamente para simplificar o acesso e trabalhar com os dados retornados pelas DMVs. Um exemplo é o DAX Studio, que inclui funcionalidade explícita para acessar as DMVs. O DAX Studio também inclui um recurso interno de Métricas de exibição, que é comumente conhecido como Vertipaq Analyzer. O Vertipaq Analyzer tem uma interface do usuário para analisar a estrutura e o tamanho de tabelas, colunas, relações e partições em um modelo de dados. Você também pode exportar (ou importar) os metadados do modelo de dados para um arquivo .vpax. O arquivo exportado contém apenas metadados sobre a estrutura e o tamanho do modelo de dados, sem armazenar nenhum dado de modelo.

Dica

Considere compartilhar um arquivo .vpax com alguém quando precisar de assistência com um modelo de dados. Dessa forma, você não compartilhará os dados do modelo com essa pessoa.

Você pode usar consultas DMV durante diferentes estágios do ciclo de vida de um modelo semântico.

  • Durante o desenvolvimento do modelo de dados: Sua ferramenta de escolha pode se conectar a um modelo de dados no Power BI Desktop como uma ferramenta externa. Essa abordagem é útil para modeladores de dados que desejam validar seu modelo de dados ou fazer ajustes de desempenho.
  • Depois que o modelo semântico é publicado no serviço do Power BI: sua ferramenta de escolha pode se conectar a um modelo semântico em um workspace Premium. O SSMS é uma das muitas ferramentas de cliente com suporte que usam o ponto de extremidade XMLA para conectividade. Essa abordagem é útil quando você deseja auditar ou validar um modelo semântico publicado no serviço do Power BI.

Dica

Se você decidir escrever suas próprias consultas DMV (por exemplo, no SSMS), esteja ciente de que as DMVs não dão suporte a todas as operações de SQL. Além disso, algumas DMVs não têm suporte no Power BI (porque exigem permissões de administrador do servidor do Analysis Services que não têm suporte no Power BI).

A configuração de locatário Permitir pontos de extremidade XMLA e Analisar no Excel com modelos semânticos locais controla quais grupos de usuários (que também são atribuídos à função de espaço de trabalho Colaborador, Membro ou Administrador, ou à permissão Criar para o modelo semântico individual) podem usar o ponto de extremidade XMLA para consultar e/ou manter modelos semânticos no serviço do Power BI.

Para obter mais informações sobre como usar o ponto de extremidade XMLA, ferramentas de terceiros e ferramentas externas, confira o cenário de uso gerenciamento de modelo de dados avançado.

Analisador de Práticas Recomendadas

O BPA (Analisador de Práticas Recomendadas) é um recurso do Editor Tabular, que é uma ferramenta de terceiros que alcançou a adoção generalizada pela comunidade do Power BI. O BPA inclui um conjunto de regras personalizáveis que podem ajudá-lo a auditar a qualidade, a consistência e o desempenho do modelo de dados.

Dica

Para configurar o BPA, baixe o conjunto de regras de práticas recomendadas, que são fornecidas pela Microsoft no GitHub.

Principalmente, o BPA pode ajudá-lo a melhorar a consistência dos modelos detectando decisões de design abaixo do ideal que podem reduzir problemas de desempenho. É útil quando você tem modeladores de dados de autoatendimento distribuídos em diferentes áreas da organização.

O BPA também pode ajudá-lo a auditar e controlar seus modelos de dados. Por exemplo, você pode verificar se um modelo de dados inclui funções de segurança em nível de linha (RLS). Ou você pode validar se todos os objetos de modelo têm uma descrição. Isso é útil quando, por exemplo, sua meta é garantir que um modelo de dados inclua um dicionário de dados.

O BPA pode expor problemas de design que podem ajudar o Centro de Excelência a determinar se mais treinamento ou documentação são necessários. Ele pode tomar medidas para instruir os criadores de dados sobre as práticas recomendadas e as diretrizes organizacionais.

Dica

Tenha em mente que o BPA pode detectar a existência de uma característica (como segurança em nível de linha). No entanto, pode ser difícil determinar se ele está configurado corretamente. Por esse motivo, um especialista no assunto pode precisar realizar uma revisão. Por outro lado, a não existência de uma característica específica não significa necessariamente um design ruim; o modelador de dados pode ter um bom motivo para produzir um design específico.

Lista de verificação – ao planejar o acesso a metadados para modelos de dados, estas são algumas ações e decisões importantes:

  • Decida quem pode ter o SSMS instalado: determine se você permitirá que todos os criadores de conteúdo do Power BI em sua organização instalem o SSMS para que eles possam se conectar a modelos semânticos publicados. Decida se ele está instalado mediante solicitação ou como parte de um conjunto padrão de software instalado para criadores de dados aprovados na organização.
  • Decida quem pode ter ferramentas de terceiros instaladas: determine se você permitirá que todos os criadores de conteúdo do Power BI em sua organização instalem ferramentas de terceiros (como o DAX Studio e o Editor tabular) para que eles possam monitorar modelos de dados locais e/ou modelos semânticos publicados. Decida se eles estão instalados mediante solicitação ou como parte de um conjunto padrão de software instalado para criadores de dados aprovados na organização.
  • Configurar regras de práticas recomendadas: Decida quais regras do Analisador de Práticas Recomendadas podem examinar os modelos de dados em sua organização.
  • Decida quem pode usar o ponto de extremidade XMLA: determine se todos os usuários têm permissão para se conectar a modelos semânticos usando o ponto de extremidade XMLA ou se ele está limitado apenas a criadores de dados aprovados. Defina os pontos de extremidade Permitir XMLA e Analisar no Excel com a configuração de locatário de modelos semânticos locais para se alinhar a essa decisão.
  • Forneça diretrizes para criadores de conteúdo: crie documentação para os criadores de dados para que eles entendam as maneiras recomendadas de analisar modelos semânticos. Forneça diretrizes para casos de uso comuns para facilitar a coleta e análise de resultados de DMV e/ou uso do Analisador de Práticas Recomendadas.

Modelo de dados e desempenho de consulta

O Power BI Desktop inclui várias ferramentas que ajudam os criadores de dados a solucionar problemas e investigar seus modelos de dados. Esses recursos são direcionados a modeladores de dados que desejam validar seu modelo de dados e fazem ajuste de desempenho antes de publicar no serviço do Power BI.

Performance Analyzer

Use o Performance Analyzer, que está disponível no Power BI Desktop, para auditar e investigar o desempenho de um modelo de dados. O Performance Analyzer ajuda os criadores de relatório a medir o desempenho de elementos de relatório individuais. Normalmente, no entanto, a causa raiz dos problemas de desempenho está relacionada ao design do modelo de dados. Por esse motivo, um criador de modelo semântico também pode se beneficiar do uso do Performance Analyzer. Se houver diferentes criadores de conteúdo responsáveis por criar relatórios versus modelos semânticos, é provável que eles precisem colaborar ao solucionar problemas de desempenho.

Dica

Você pode usar o DAX Studio para importar e analisar os arquivos de log gerados pelo Performance Analyzer.

Para obter mais informações sobre o Performance Analyzer, confira Auditoria em nível de relatório.

Diagnóstico de consulta

Use o Diagnóstico de Consulta, que está disponível no Power BI Desktop, para investigar o desempenho do Power Query. Eles é útil para solução de problemas e para quando você precisa entender o que o mecanismo de Power Query está fazendo.

As informações que você pode obter com o Diagnóstico de Consulta incluem:

  • Detalhes adicionais relacionados a mensagens de erro (quando ocorre uma exceção).
  • As consultas enviadas para uma fonte de dados.
  • Se a dobragem de consulta está ou não ocorrendo.
  • O número de linhas retornadas por uma consulta.
  • Possível lentidão durante uma operação de atualização de dados.
  • Eventos em segundo plano e consultas geradas pelo sistema.

Dependendo do que você está procurando, você pode habilitar um ou todos os logs: agregados, detalhados, contadores de desempenho e partições de privacidade de dados.

Você pode iniciar o diagnóstico de sessão no Editor do Power Query. Depois de habilitadas, as operações de consulta e atualização são coletadas até que o rastreamento de diagnóstico seja interrompido. Os dados são preenchidos diretamente no editor de consultas assim que o diagnóstico é interrompido. O Power Query cria um grupo de Diagnóstico (pasta) e adiciona várias consultas a ele. Em seguida, você pode usar a funcionalidade padrão do Power Query para exibir e analisar os dados de diagnóstico.

Como alternativa, você pode habilitar um rastreamento no Power BI Desktop na seção Diagnóstico da janela Opções. Os arquivos de log são salvos em uma pasta no computador local. Esses arquivos de log são preenchidos com os dados depois que você fecha o Power BI Desktop, momento em que o rastreamento é interrompido. Depois que o Power BI Desktop for fechado, você poderá abrir os arquivos de log com seu programa preferido (como um editor de texto) para exibi-los.

Avaliação e dobramento de consulta

O Power Query dá suporte a vários recursos para ajudá-lo a entender a avaliação da consulta, incluindo o plano de consulta. Ele também pode ajudar você a determinar se a dobragem de consulta está ocorrendo para uma consulta inteira ou para um subconjunto de etapas em uma consulta. A dobragem de consulta é um dos aspectos mais importantes do ajuste de desempenho. Também é útil examinar as consultas nativas enviadas por Power Query ao monitorar uma fonte de dados, que é descrita posteriormente neste artigo.

Aplicativo de métricas Premium

Ao solucionar problemas, pode ser útil colaborar com o administrador de capacidade do Power BI Premium. O administrador de capacidade tem acesso ao aplicativo de utilização e métricas do Power BI Premium. Esse aplicativo pode fornecer uma grande quantidade de informações sobre as atividades que ocorrem na capacidade. Essas informações podem ajudá-lo a solucionar problemas de modelo semântico.

Dica

O administrador de capacidade Premium pode conceder acesso a usuários adicionais (administradores sem capacidade) para permitir que eles acessem o aplicativo de métricas Premium.

O aplicativo de métricas Premium inclui um modelo semântico interno e um conjunto inicial de relatórios. Ele ajuda você a executar o monitoramento quase em tempo real de uma capacidade do Power BI Premium (SKU P) ou Power BI Embedded (SKU A). Ele inclui dados das últimas duas a quatro semanas (dependendo da métrica).

Use o aplicativo de métricas Premium para solucionar problemas e otimizar modelos semânticos. Por exemplo, você pode identificar modelos semânticos que têm um volume de memória grande ou que experimentam um uso de CPU rotineiramente alto. Também é uma ferramenta útil para encontrar modelos semânticos que estão se aproximando do limite do tamanho da capacidade.

Lista de verificação – Ao considerar as abordagens a serem usadas para monitorar o modelo de dados e o desempenho da consulta, estas são algumas ações e decisões importantes:

  • Identificar destinos semânticos de desempenho de consulta de modelo: verifique se você tem uma boa compreensão do que significa um bom desempenho de modelo semântico. Determine quando você precisará de destinos de desempenho de consulta específicos (por exemplo, as consultas para dar suporte a relatórios devem ser renderizadas dentro de cinco segundos). Nesse caso, verifique se os destinos são comunicados aos criadores de dados em sua organização.
  • Identificar destinos de desempenho de atualização semântica de modelo: determine quando você exigirá destinos específicos de atualização de dados (por exemplo, a conclusão de uma operação de atualização de dados dentro de 15 minutos e antes das 5h). Nesse caso, verifique se os destinos são comunicados aos criadores de dados em sua organização.
  • Instrua sua equipe de suporte: Verifique se sua equipe interna de suporte ao usuário está familiarizada com os recursos de diagnóstico para que eles estejam prontos para dar suporte aos usuários do Power BI quando precisarem de ajuda.
  • Conecte sua equipe de suporte e administradores de banco de dados: Verifique se sua equipe de suporte sabe como contatar os administradores corretos para cada fonte de dados (ao solucionar problemas de dobramento de consulta, por exemplo).
  • Colabore com o administrador de capacidade Premium: trabalhe com o administrador de capacidade para solucionar problemas de modelos semânticos que residem em um workspace atribuído à capacidade Premium ou à capacidade do Power BI Embedded. Quando apropriado, solicite acesso ao aplicativo de métricas Premium.
  • Forneça diretrizes para criadores de conteúdo: Crie documentação para seus criadores de dados para que eles entendam quais ações devem ser executadas durante a solução de problemas.
  • Inclua nos materiais de treinamento: Forneça diretrizes para seus criadores de dados sobre como criar modelos de dados de bom desempenho. Ajude-os a adotar bons hábitos de design desde cedo. Concentre-se em ensinar aos criadores de dados como tomar boas decisões de design.

Monitoramento da fonte de dados

Às vezes, é necessário monitorar diretamente uma fonte de dados específica à qual o Power BI se conecta. Por exemplo, você pode ter um data warehouse que está enfrentando uma carga de trabalho maior e os usuários estão relatando degradação de desempenho. Normalmente, um administrador de banco de dados ou administrador do sistema monitora fontes de dados.

Você pode monitorar uma fonte de dados para:

  • Auditar quais usuários estão enviando consultas para a fonte de dados.
  • Auditar quais aplicativos (como o Power BI) estão enviando consultas para a fonte de dados.
  • Examinar quais instruções de consulta são enviadas para a fonte de dados, quando elas são enviadas e por quais usuários.
  • Determinar quanto tempo leva para uma consulta ser executada.
  • Auditar como a segurança em nível de linha é invocada pelo sistema de origem ao usar o logon único (SSO).

Há muitas ações que um criador de conteúdo do Power BI pode executar depois de analisar os resultados do monitoramento. Ele poderia:

  • Ajustar e refinar as consultas enviadas para a fonte de dados para que elas sejam o mais eficientes possível.
  • Validar e ajustar as consultas nativas que são enviadas para a fonte de dados.
  • Reduzir o número de colunas importadas para um modelo de dados.
  • Remover colunas de alta precisão e alta cardinalidade que são importadas para um modelo de dados.
  • Reduzir a quantidade de dados históricos importados para um modelo de dados.
  • Ajustar os tempos de atualização de dados do Power BI para ajudar a espalhar a demanda pela fonte de dados.
  • Usar a atualização de dados incremental para reduzir a carga na fonte de dados.
  • Reduza o número de atualizações de dados do Power BI consolidando vários modelos semânticos em um modelo semântico compartilhado.
  • Ajustar as configurações de atualização de página automática para aumentar a frequência de atualização e, portanto, reduzir a carga na fonte de dados.
  • Simplificar os cálculos para reduzir a complexidade das consultas enviadas à fonte de dados.
  • Alterar o modo de armazenamento de dados (por exemplo, para o modo de importação em vez de DirectQuery) para reduzir a carga de consulta consistente na fonte de dados.
  • Use técnicas de redução de consulta para reduzir o número de consultas enviadas à fonte de dados.

Os administradores do sistema podem executar outras ações. Eles poderiam:

  • Introduzir uma camada de dados intermediária, como fluxos de dados do Power BI (quando um data warehouse não é uma opção viável). Os criadores de conteúdo do Power BI podem usar os fluxos de dados como sua fonte de dados em vez de se conectar diretamente a fontes de dados. Uma camada de dados intermediária pode reduzir a carga em um sistema de origem. Ela também tem o benefício adicional de centralizar a lógica de preparação de dados. Para obter mais informações, confira o cenário de uso de preparação de dados de autoatendimento.
  • Altere o local da fonte de dados para reduzir o impacto da latência de rede (por exemplo, use a mesma região de dados para o serviço do Power BI, fontes de dados e gateways).
  • Otimize a fonte de dados para que ela recupere dados com mais eficiência para o Power BI. Várias técnicas comuns incluem a criação de índices de tabela, a criação de exibições indexadas, a criação de colunas computadas persistentes, a manutenção de estatísticas, o uso de tabelas columnstore ou na memória e a criação de exibições materializadas.
  • Direcione os usuários a usar uma réplica somente leitura da fonte de dados, em vez de um banco de dados de produção original. Um réplica pode estar disponível como parte de uma estratégia de banco de dados de alta disponibilidade (HA). Uma vantagem de um réplica somente leitura é reduzir a contenção no sistema de origem.

As ferramentas e técnicas que você pode usar para monitorar fontes de dados dependem da plataforma de tecnologia. Por exemplo, o administrador do banco de dados pode usar eventos estendidos ou o Repositório de Consultas para monitorar bancos de dados SQL do Azure e bancos de dados SQL Server.

Às vezes, o Power BI acessa uma fonte de dados por meio de um gateway de dados. Os gateways lidam com a conectividade do serviço do Power BI com determinados tipos de fontes de dados. No entanto, eles fazem mais do que apenas se conectar a dados. Um gateway inclui um mecanismo de mashup que executa processamento e transformações de dados no computador. Ele também compacta e criptografa os dados para que possam ser transmitidos com eficiência e segurança para o serviço do Power BI. Portanto, um gateway não gerenciado ou não otimizado pode contribuir para gargalos de desempenho. Recomendamos que você converse com o administrador do gateway para obter ajuda com gateways de monitoramento.

Dica

O administrador do Power BI pode compilar um inventário de locatário completo (que inclui linhagem) e acessar as atividades do usuário no log de atividades. Ao correlacionar a linhagem e as atividades do usuário, os administradores podem identificar as fontes de dados e os gateways usados com mais frequência.

Para obter mais informações sobre o inventário de locatários e o log de atividades, confira Auditoria no nível do locatário.

Lista de verificação – ao planejar as permissões da fonte de dados, estas são algumas ações e decisões importantes:

  • Determine metas específicas: Ao monitorar uma fonte de dados, obtenha clareza sobre exatamente o que você precisa realizar e as metas para solução de problemas.
  • Colaborar com administradores de banco de dados: Trabalhe com seu banco de dados ou administradores do sistema para obter sua ajuda ao monitorar uma fonte de dados específica.
  • Colabore com administradores de gateway: Para fontes de dados que se conectam por meio de um gateway de dados, colabore com o administrador do gateway durante a solução de problemas.
  • Conecte sua equipe de suporte e administradores de banco de dados: Verifique se sua equipe de suporte sabe como contatar os administradores corretos para cada fonte de dados (por exemplo, ao solucionar problemas de dobramento de consulta).
  • Atualize treinamento e diretrizes: Inclua as principais informações e dicas para criadores de dados sobre como trabalhar com fontes de dados organizacionais. Inclua informações sobre o que fazer quando algo der errado.

Monitoramento de atualização de dados

Uma operação de atualização de dados envolve a importação de dados de fontes de dados subjacentes para um modelo semântico, fluxo de dados ou datamart do Power BI. Você pode agendar uma operação de atualização de dados ou executá-la sob demanda.

Contrato de nível de serviço

A TI normalmente usa contratos de nível de serviço (SLAs) para documentar as expectativas de ativos de dados. Para o Power BI, considere usar um SLA para conteúdo crítico ou conteúdo de nível empresarial. Normalmente, ele inclui quando os usuários podem esperar que os dados atualizados em um modelo semântico estejam disponíveis. Por exemplo, você pode ter um SLA que determina que todas as atualizações de dados devem ser concluídas às 7h todos os dias.

Logs de modelo semântico

Os logs de eventos de modelo semântico do Azure Log Analytics ou do SQL Profiler (descritos anteriormente neste artigo) incluem informações detalhadas sobre o que está acontecendo em um modelo semântico. Os eventos capturados incluem atividade de atualização semântica do modelo. Os logs de eventos são especialmente úteis quando você precisa solucionar problemas e investigar atualizações semânticas de modelo.

Modelos semânticos de capacidade Premium

Quando você tem conteúdo hospedado em uma capacidade de Power BI Premium, você tem mais recursos para monitorar as operações de atualização de dados.

  • A página resumos de atualização do Power BI no portal de administração inclui um resumo do histórico de atualização. Este resumo fornece informações sobre a duração da atualização e as mensagens de erro.
  • O aplicativo de métricas e utilização do Power BI Premium também inclui informações úteis de atualização. É útil quando você precisa investigar a atividade de atualização de uma capacidade do Power BI Premium (SKU P) ou capacidade do Power BI Embedded (SKU A).

Atualizações avançadas do modelo semântico

Os criadores de conteúdo podem iniciar atualizações de modelo semântico programaticamente usando a atualização aprimorada com o conjunto de dados de atualização na API REST do Power BI de grupo. Ao usar a atualização aprimorada, você pode monitorar as operações de atualização históricas, atuais e pendentes.

Monitoramento de agendamento de atualização de dados

Os administradores do Power BI podem monitorar agendamentos de atualização de dados no locatário para determinar se há muitas operações de atualização agendadas simultaneamente durante um período específico (por exemplo, entre 5h e 7h, que pode ser um horário de atualização de dados particularmente ocupado). Os administradores têm permissão para acessar os metadados de agendamento de atualização semântica do modelo das APIs de verificação de metadados, que são conhecidas como APIs do scanner.

APIs REST do Power BI

Para modelos semânticos críticos, não dependa apenas de notificações por email para monitorar problemas de atualização de dados. Considere compilar o histórico de atualização de dados em um repositório centralizado onde você pode monitorar, analisar e agir sobre ele.

Você pode recuperar o histórico de atualização de dados usando:

Dica

É altamente recomendável que você monitore o histórico de atualização de seus modelos semânticos para garantir que os dados atuais estão disponíveis para relatórios e dashboards. Ele também ajuda você a saber se os SLAs estão sendo atendidos.

Lista de verificação – ao planejar as permissões de criador de conjunto de dados, estas são algumas decisões e ações importantes:

  • Determinar metas específicas: ao monitorar atualizações de dados, obtenha clareza sobre exatamente o que você precisa realizar e qual deve ser o escopo do monitoramento (por exemplo, modelos semânticos de produção, modelos semânticos certificados e outros).
  • Considere configurar um SLA: Determine se um SLA seria útil para definir expectativas de disponibilidade de dados e quando os agendamentos de atualização de dados devem ser executados.
  • Colabore com administradores de banco de dados e gateway: Trabalhe com seus administradores de banco de dados ou do sistema e administradores de gateway para monitorar ou solucionar problemas de atualização de dados.
  • Transferência de conhecimento para a equipe de suporte: Verifique se sua equipe de suporte sabe como ajudar os criadores de conteúdo quando surgirem problemas de atualização de dados.
  • Atualize treinamento e diretrizes: Inclua as principais informações e dicas para criadores de dados sobre como atualizar dados de fontes de dados organizacionais e fontes de dados comuns. Inclua práticas recomendadas e preferências organizacionais de como gerenciar a atualização de dados.
  • Use um endereço de email de suporte para notificações: Para conteúdo crítico, configure notificações de atualização para usar um endereço de email de suporte.
  • Configure o monitoramento de atualização centralizado: Use as APIs REST do Power BI para compilar o histórico de atualização de dados.

Monitoramento do fluxo de dados

Você cria um fluxo de dados do Power BI com o Power Query Online. Muitos dos recursos de desempenho de consulta e o diagnóstico do Power Query, que foram descritos anteriormente, são aplicáveis.

Opcionalmente, você pode definir workspaces para usar Azure Data Lake Storage Gen2 para armazenamento de fluxo de dados (conhecido como bring-your-own-storage) em vez de armazenamento interno. Ao usar bring-your-own-storage, considere habilitar a telemetria para que você possa monitorar as métricas da conta de armazenamento. Para obter mais informações, confira os cenários de uso de preparação de dados de autoatendimento e preparação de dados avançada.

Você pode usar as APIs REST do Power BI para monitorar transações de fluxo de dados. Por exemplo, use a API Obter Transações de Fluxo de Dados para verificar o status de atualizações de fluxo de dados.

Você pode acompanhar as atividades do usuário para fluxos de dados do Power BI com o log de atividades do Power BI. Para obter mais informações, confira Auditoria no nível do locatário.

Dica

Há muitas práticas recomendadas que você pode adotar para otimizar seus designs de fluxo de dados. Para obter mais informações, confira as Melhores práticas dos fluxos de dados.

Monitoramento do Datamart

Um datamart do Power BI inclui vários componentes integrados, incluindo um fluxo de dados, um banco de dados gerenciado e um modelo semântico. Confira as seções anteriores deste artigo para saber mais sobre auditoria e monitoramento de cada componente.

Você pode acompanhar as atividades do usuário para datamarts do Power BI usando o log de atividades do Power BI. Para obter mais informações, confira Auditoria no nível do locatário.

Conteúdo relacionado

No próximo artigo desta série, saiba mais sobre auditoria no nível do locatário.