Partilhar via

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

  • Artigo

Nota

Este artigo faz parte da série de artigos de planejamento de implementação do Power BI. Esta série se concentra principalmente na experiência do Power BI no Microsoft Fabric. Para obter uma introdução à série, consulte Planejamento de implementação do Power BI.

Este artigo de auditoria de nível de dados destina-se a vários públicos:

  • Criadores de dados e administradores de espaço de trabalho: usuários que precisam entender o uso, a adoção e o desempenho dos modelos semânticos, fluxos de dados e datamarts que 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 podem precisar colaborar com equipes de 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, TI e BI: as equipes que também são responsáveis por supervisionar o Power BI. Eles podem precisar colaborar com administradores do Power BI e outras equipes relevantes.
  • Administradores de sistema: a equipe responsável por criar e proteger os 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 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.

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

Não é possível obter um bom desempenho em relatórios e elementos visuais quando o modelo semântico subjacente e/ou a fonte de dados não têm 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 as descritas no artigo Auditoria em nível de 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 de auditoria no nível de relatório.

Como os modelos semânticos do Power BI são criados com base no mecanismo tabular 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.

Nota

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

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

Logs de eventos do modelo semântico

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

  • Tornar-se mais complexo e incluir medidas complexas.
  • Aumente o volume de dados.
  • Consuma mais memória (às vezes desnecessariamente quando más decisões de design foram tomadas).
  • Use fontes de dados mais diversas e relações de tabela mais complexas.
  • Inclua mais regras de segurança em nível de linha (RLS). Para obter mais informações, consulte Impor a segurança de dados com base na identidade do consumidor.
  • Tem mais relatórios que dependem disso. Para obter mais informações sobre como usar conexões em tempo real com um modelo semântico compartilhado, consulte o cenário de uso de BI de autoatendimento gerenciado.
  • Tenha mais modelos de dados downstream que dependem dele. Para obter mais informações sobre como usar o DirectQuery para modelos semânticos do Power BI e o Analysis Services com um modelo semântico compartilhado, consulte o cenário de uso de BI de autoatendimento gerenciado personalizável.
  • Experimente uma execução de consulta mais lenta e tempos de atualização de dados mais lentos.
  • Contribua para uma renderização mais lenta de relatórios e elementos visuais.

Para garantir a usabilidade, o bom desempenho e a adoção do conteúdo que eles criam, 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 conhecidos como eventos de rastreamento, logs de conjunto de dados ou logs de atividade de conjunto de dados. Os administradores de sistema geralmente os chamam de eventos de rastreamento de baixo nível porque são detalhados.

Nota

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

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

  • Auditar todas as atividades que ocorreram em um modelo semântico.
  • Solucione problemas e otimize o desempenho do modelo semântico, o uso de memória e a eficiência da consulta.
  • Investigue os detalhes e a duração da atualização do modelo semântico.
  • Monitorizar a linguagem de fórmulas do Power Query (consultas M) enviadas 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 na 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 espaço de trabalho de produção).

Os eventos gerados por um modelo semântico do Power BI são derivados de logs de diagnóstico existentes disponíveis para o Azure Analysis Services. 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 Azure Monitor . A integração do Azure Log Analytics com o Power BI permite capturar eventos de modelo semântico de todos os modelos semânticos em um espaço de trabalho do Power BI. É suportado apenas para espaços de trabalho Premium. Depois de configurar a integração e a conexão ser habilitada (para um espaço de trabalho do Power BI Premium), os eventos do modelo semântico são capturados automaticamente e enviados continuamente para um espaço de trabalho 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 espaço de trabalho do Power BI Premium a um espaço de trabalho do Log Analytics no Azure. Você deve criar um novo recurso do Log Analytics em sua assinatura do Azure para habilitar esse tipo de log.

Os logs de um ou mais espaços de trabalho do Power BI serão enviados para um espaço de trabalho do Log Analytics de destino. Aqui estão algumas maneiras de organizar os dados.

  • Um espaço de trabalho de destino para todos os dados de auditoria: armazene todos os dados em um espaço de trabalho do Log Analytics. Isso é útil quando o mesmo administrador ou usuários acessam todos os dados.
  • Espaços de trabalho de destino organizados por área temática: Organize o conteúdo por área temática. 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 segregar dados de vendas de dados de operações.
  • Um espaço de trabalho de destino para cada espaço de trabalho do Power BI: configure uma relação um-para-um entre um espaço de trabalho do Power BI e um espaço de trabalho do Azure Log Analytics. Isso é útil quando você tem conteúdo particularmente sensível ou quando os dados estão sujeitos a requisitos específicos de conformidade ou regulamentação.

Gorjeta

Analise cuidadosamente a documentação e as perguntas frequentes sobre essa funcionalidade para que você tenha clareza sobre o que é possível e compreenda os requisitos técnicos. Antes de tornar essa funcionalidade amplamente disponível para administradores de espaço de trabalho em sua organização, considere fazer uma prova técnica de conceito (POC) com um espaço de trabalho 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 detalhe do mecanismo do Analysis Services. Seu único objetivo é ajudá-lo a analisar e solucionar problemas de desempenho do modelo semântico. Seu escopo está no nível do espaço de trabalho. Por outro lado, o objetivo do log de atividades é ajudá-lo a entender com que frequência 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 de usuário que você pode auditar para seu locatário do Power BI, consulte Auditoria em nível de locatário.

A configuração de locatário do Azure Log Analytics para administradores de espaço de trabalho controla quais grupos de usuários (que também têm a função de administrador de espaço de trabalho necessária) podem conectar um espaço de trabalho do Power BI a um espaço de trabalho 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 espaço de trabalho 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.

Gorjeta

Colabore com seu administrador do Azure no início do processo de planejamento, especialmente quando obter aprovação para criar um novo 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 espaço de trabalho 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 de nível de detalhe do mecanismo do Analysis Services, os dados podem ser detalhados. Grandes volumes de dados são comuns para grandes espaços de trabalho que experimentam alta atividade de modelo semântico.

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

  • Conecte espaços de trabalho do Power BI ao Azure Log Analytics somente quando estiver ativamente solucionando problemas, testando, otimizando ou investigando a atividade do modelo semântico. Quando conectado, um rastreamento é executado em todos os modelos semânticos no espaço de trabalho.
  • Desconecte o Azure Log Analytics de um espaço de trabalho do Power BI quando não precisar mais ativamente solucionar problemas, testar, otimizar ou investigar a atividade do modelo semântico. Ao desconectar, você está encerrando a execução do rastreamento em todos os modelos semânticos no espaço de trabalho.
  • Certifique-se de entender o modelo de custo de como o Azure Log Analytics fatura a ingestão, o armazenamento e as 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 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. Pode utilizar:

  • O aplicativo de modelo Log Analytics for Power BI Semantic Models pré-criado.
  • O conector do Power BI Desktop para o Azure Data Explorer (Kusto). Use a Kusto Query Language (KQL) para analisar os dados armazenados no Log Analytics. Se você tiver experiência em consultas 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.

Gorjeta

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 DirectQuery permite consultar os dados quase em tempo real. Os eventos geralmente chegam em cinco minutos.

Para obter mais informações, consulte Governar conexões do Azure.

Lista de verificação - Ao planejar o uso do Azure Log Analytics, as principais decisões e ações incluem:

  • Considere um POC técnico: planeje um pequeno projeto para garantir que você entenda completamente os requisitos técnicos, os requisitos de segurança, quais eventos capturar e como analisar os logs.
  • Decida quais espaços de trabalho devem ser integrados ao Log Analytics: determine quais espaços de trabalho 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 espaço de trabalho: para otimização de custos, determine se há situações (ou espaços de trabalho específicos) em que o registro em log deve ser habilitado permanentemente. Decida se os espaços de trabalho devem ser desconectados quando a solução de problemas não estiver ocorrendo.
  • Decida por quanto tempo reter os dados do Log Analytics: determine se é necessário definir um período de retenção mais longo do que o padrão de 30 dias.
  • Esclarecer o processo de solicitação de novo espaço de trabalho 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 espaço de trabalho do Power BI.
  • Decida como a segurança funcionará: colabore com seu administrador do Azure para decidir se é mais viável para um administrador de espaço de trabalho do Power BI receber direitos para um espaço de trabalho do Azure Log Analytics ou para um administrador do Azure receber direitos para um espaço de trabalho do Power BI. Ao tomar essa decisão de segurança, considere seu plano de conectar e desconectar espaços de trabalho regularmente (para otimização de custos).
  • Decida como organizar os espaços de trabalho de destino do Log Analytics: considere quantos espaços de trabalho do Azure Log Analytics serão apropriados para organizar os dados de um ou mais espaços de trabalho 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 espaço de trabalho têm permissão para se conectar: determine quais grupos de administradores de espaço de trabalho podem conectar um espaço de trabalho do Power BI a um espaço de trabalho do Log Analytics. Defina a configuração de locatário do Azure Log Analytics para administradores de espaço de trabalho para alinhar com essa decisão.
  • Criar o recurso do Azure Log Analytics: colabore com o administrador do Azure para criar cada espaço de trabalho 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 espaço de trabalho do Power BI: colabore com seus administradores do espaço de trabalho do Power BI para configurar a conexão com o Log Analytics para cada espaço de trabalho do Power BI. Verifique se os dados de log estão fluindo corretamente para o espaço de trabalho do Log Analytics.
  • Criar consultas para analisar os dados: configure consultas KQL para analisar os dados no Log Analytics com base no seu caso de uso e necessidades atuais.
  • Inclua orientações para administradores de espaço de trabalho do Power BI: forneça informações e pré-requisitos aos administradores do espaço de trabalho do Power BI sobre como solicitar um novo espaço de trabalho do Log Analytics e como se conectar a um espaço de trabalho do Power BI. Além disso, explique quando é apropriado desconectar um espaço de trabalho do Power BI.
  • Forneça orientação e consultas de exemplo para analisar os dados: crie consultas KQL para administradores de espaço de trabalho para facilitar o início da 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). A conectividade com um modelo semântico do Power BI tem suporte com o SSMS porque se baseia na arquitetura do Analysis Services originada 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 no Power BI Desktop como uma ferramenta externa. Essa abordagem é útil para modeladores de dados que desejam validar seu modelo de dados ou fazer ajuste 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 espaço de trabalho 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.

Nota

O uso do SQL Profiler é um caso de uso diferente da atividade de criação de perfil de dados. Você cria o 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 permite que você use ou crie recursos do Azure Log Analytics no Azure.
  • Você deseja capturar eventos para um modelo de dados no Power BI Desktop (que não foi publicado em um espaço de trabalho 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 espaço de trabalho Premium).
  • Você deseja capturar determinados eventos somente durante um rastreamento (como apenas o evento Query End ).
  • Você deseja iniciar e parar rastreamentos com frequência (como quando precisa capturar eventos de modelo semântico que estão ocorrendo agora).

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

Gorjeta

O uso do SQL Profiler para monitorar o Analysis Services é abordado em muitos livros, artigos e postagens de 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 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 é suportada e não preterida. Se você estiver familiarizado com eventos estendidos do Analysis Services e preferir usá-los, a conectividade do SSMS é possível para um modelo de dados no Power BI Desktop. No entanto, não é suportado pelo 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 estão atribuídos à função de espaço de trabalho Colaborador, Membro ou Administrador ou à permissão Construir para o modelo semântico individual) podem usar o ponto de extremidade XMLA para consultar e/ou manter modelos semânticos no serviço Power BI. Para obter mais informações sobre como usar o ponto de extremidade XMLA, consulte o cenário de uso de gerenciamento avançado de modelo de dados.

Nota

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 DAX Evaluation Log para exibir resultados intermediários de uma expressão DAX. Esse evento é gerado quando você usa a função EVALUATEANDLOG DAX em um cálculo de modelo.

Esta função destina-se apenas a fins de desenvolvimento e teste. Você deve removê-lo dos cálculos do modelo de dados antes de publicá-lo em um espaço de trabalho de produção.

Lista de verificação - Ao planejar o uso do SQL Profiler, as principais decisões e ações incluem:

  • 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 possam usar o SQL Profiler. Decida se essas ferramentas auxiliares são instaladas mediante solicitação ou se fazem parte de um conjunto padrão de software instalado para criadores de dados aprovados na organização.
  • Adicionar 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 à 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 a criadores de dados aprovados. Defina a configuração de locatário Permitir pontos de extremidade XMLA e Analisar no Excel com modelos semânticos locais para alinhar com essa decisão.
  • Forneça orientação 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 orientação para casos de uso comuns para facilitar o início da 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 tabelas, nomes de colunas e expressões de medida.

Vistas de gestão dinâmicas (DMV)

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

Mais concretamente, pode:

  • Auditar 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 da coluna podem ser compactados.
  • Encontre colunas em um modelo que não são usadas.
  • Audite sessões e conexões de usuários ativos.
  • Verifique a estrutura do modelo.
  • Analise as expressões DAX usadas por tabelas calculadas, colunas calculadas, medidas e regras de segurança em nível de linha (RLS).
  • Identificar dependências entre objetos e medidas.

Gorjeta

Os DMVs recuperam informações sobre o estado atual de um modelo semântico. Pense nos dados retornados pelos DMVs como um instantâneo do que está ocorrendo em um 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 do Detran. Você também pode usar o cmdlet Invoke-ASCmd PowerShell para criar e executar scripts XMLA que consultam os DMVs.

Ferramentas de terceiros e ferramentas externas também são populares entre a comunidade do Power BI. Essas ferramentas usam os DMVs documentados publicamente para simplificar o acesso e trabalhar com dados retornados pelos DMVs. Um exemplo é o DAX Studio, que inclui funcionalidade explícita para acessar os DMVs. O DAX Studio também inclui um recurso integrado de métricas de visualização , que é comumente conhecido como Vertipaq Analyzer. O Vertipaq Analyzer tem uma interface de usuário para analisar a estrutura e o tamanho de tabelas, colunas, relacionamentos 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 do modelo.

Gorjeta

Considere compartilhar um arquivo .vpax com alguém quando precisar de ajuda 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 preferida 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 ajuste de desempenho.
  • Depois que o modelo semântico for publicado no serviço do Power BI: sua ferramenta preferida poderá se conectar a um modelo semântico em um espaço de trabalho 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.

Gorjeta

Se você decidir escrever suas próprias consultas DMV (por exemplo, no SSMS), lembre-se de que os DMVs não oferecem suporte a todas as operações SQL. Além disso, alguns DMVs não são suportados no Power BI (porque exigem permissões de administrador do servidor do Analysis Services que não são suportadas pelo 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 estão atribuídos à função de espaço de trabalho Colaborador, Membro ou Administrador ou à permissão Construir para o modelo semântico individual) podem usar o ponto de extremidade XMLA para consultar e/ou manter modelos semânticos no serviço Power BI.

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

Analisador de Boas Práticas

O BPA (Best Practice Analyzer) é um recurso do Editor de Tabelas, que é uma ferramenta de terceiros que alcançou ampla adoção 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 seu modelo de dados.

Gorjeta

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, detetando decisões de projeto 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, seu objetivo é garantir que um modelo de dados inclua um dicionário de dados.

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

Gorjeta

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

Lista de verificação - Ao planejar o acesso a metadados para modelos de dados, as principais decisões e ações incluem:

  • 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 é 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 DAX Studio e Editor de Tabela) para que eles possam monitorar modelos de dados locais e/ou modelos semânticos publicados. Decida se eles sã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 verificar 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 a configuração de locatário Permitir pontos de extremidade XMLA e Analisar no Excel com modelos semânticos locais para alinhar com essa decisão.
  • Forneça orientação para criadores de conteúdo: crie documentação para seus criadores de dados para que eles entendam a(s) maneira(s) recomendada(s) de analisar modelos semânticos. Fornecer orientação para casos de uso comuns para facilitar o início da coleta e análise dos resultados do Detran e/ou o uso do Best Practice Analyzer.

Modelo de dados e desempenho da 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 fazer ajuste de desempenho antes de publicar no serviço do Power BI.

Analisador de Desempenho

Use o Analisador de Desempenho, que está disponível no Power BI Desktop, para auditar e investigar o desempenho de um modelo de dados. O Analisador de Desempenho ajuda os criadores de relatórios a medir o desempenho de elementos de relatório individuais. Comumente, 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 pela criação de relatórios versus modelos semânticos, é provável que eles precisem colaborar ao solucionar um problema de desempenho.

Gorjeta

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, consulte Auditoria no 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 são úteis para solucionar problemas e para quando você precisa entender o que o mecanismo do Power Query está fazendo.

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

  • Detalhes adicionais relacionados a mensagens de erro (quando ocorre uma exceção).
  • As consultas que são enviadas para uma fonte de dados.
  • Se o dobramento da consulta está ou não ocorrendo.
  • O número de linhas retornadas por uma consulta.
  • Possíveis lentidões 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.

Pode iniciar o diagnóstico de sessão no Power Query Editor. Uma vez 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-lhe várias consultas. Em seguida, pode utilizar a funcionalidade padrão do Power Query para ver 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 em sua máquina 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 dobragem de consultas

O Power Query suporta várias capacidades para o ajudar a compreender a avaliação de consultas, incluindo o plano de consulta. Ele também pode ajudá-lo a determinar se o dobramento da consulta está ocorrendo para uma consulta inteira ou para um subconjunto de etapas em uma consulta. A dobragem de consultas é um dos aspetos mais importantes do ajuste de desempenho. Também é útil rever as consultas nativas enviadas pelo Power Query quando estiver a monitorizar uma origem de dados, que é descrita mais adiante neste artigo.

Aplicativo de métricas premium

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

Gorjeta

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

O aplicativo de métricas Premium compreende 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 (P SKU) ou do Power BI Embedded (Uma SKU). 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 grande espaço de memória ou que experimentam rotineiramente alto uso da CPU. Também é uma ferramenta útil para encontrar modelos semânticos que estão se aproximando do limite do tamanho da sua capacidade.

Lista de verificação - Ao considerar abordagens a serem usadas para monitorar o modelo de dados e o desempenho da consulta, as principais decisões e ações incluem:

  • Identificar metas de desempenho de consulta de modelo semântico: certifique-se de ter uma boa compreensão do que significa um bom desempenho de modelo semântico. Determine quando você precisará de metas de desempenho de consulta específicas (por exemplo, consultas para dar suporte a relatórios devem ser renderizadas em cinco segundos). Em caso afirmativo, certifique-se de que os destinos são comunicados aos criadores de dados na sua organização.
  • Identificar metas de desempenho de atualização de modelo semântico: determine quando você precisará de metas específicas 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). Em caso afirmativo, certifique-se de que os destinos são comunicados aos criadores de dados na sua organização.
  • Eduque sua equipe de suporte: certifique-se de que sua equipe de suporte ao usuário interno esteja 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: certifique-se de que sua equipe de suporte saiba como entrar em contato com os administradores corretos para cada fonte de dados (ao solucionar problemas de dobramento de consultas, 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 espaço de trabalho atribuído à capacidade Premium ou à capacidade do Power BI Embedded. Quando apropriado, solicite acesso ao aplicativo de métricas Premium.
  • Forneça orientação para criadores de conteúdo: crie documentação para seus criadores de dados para que eles entendam quais ações tomar ao solucionar problemas.
  • Incluir em materiais de treinamento: forneça orientação aos criadores de dados sobre como criar modelos de dados com bom desempenho. Ajude-os a adotar bons hábitos de design desde cedo. Concentre-se em ensinar os criadores de dados a 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 aumentada e os usuários estão relatando degradação de desempenho. Normalmente, um administrador de banco de dados ou administrador de sistema monitora fontes de dados.

Você pode monitorar uma fonte de dados para:

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

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

  • Ajuste e refine as consultas enviadas para a fonte de dados para que sejam o mais eficientes possível.
  • Valide e ajuste as consultas nativas que são enviadas para a fonte de dados.
  • Reduza o número de colunas importadas para um modelo de dados.
  • Remova colunas de alta precisão e cardinalidade que são importadas para um modelo de dados.
  • Reduza a quantidade de dados históricos importados para um modelo de dados.
  • Ajuste os tempos de atualização de dados do Power BI para ajudar a distribuir a demanda pela fonte de dados.
  • Use a atualização incremental de dados 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.
  • Ajuste as configurações de atualização automática de página para aumentar a frequência de atualização e, portanto, reduzir a carga na fonte de dados.
  • Simplifique os cálculos para reduzir a complexidade das consultas enviadas à fonte de dados.
  • Altere 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 de sistema podem tomar outras ações. Poderiam:

  • Introduza 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 conectarem diretamente a fontes de dados. Uma camada de dados intermediária pode reduzir a carga em um sistema de origem. Ele também tem o benefício adicional de centralizar a lógica de preparação de dados. Para obter mais informações, consulte 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 da 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 para o Power BI de forma mais eficiente. Várias técnicas comuns incluem a criação de índices de tabela, a criação de visualizações indexadas, a criação de colunas computadas persistentes, a manutenção de estatísticas, o uso de tabelas na memória ou columnstore e a criação de exibições materializadas.
  • Direcione os usuários para usar uma réplica somente leitura da fonte de dados, em vez de um banco de dados de produção original. Uma réplica pode estar disponível como parte de uma estratégia de banco de dados de alta disponibilidade (HA). Uma vantagem de uma 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 o Banco de Dados SQL do Azure e os bancos de dados do 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 para 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 na máquina. Ele também compacta e criptografa os dados para que possam ser transmitidos de forma eficiente e segura 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ê fale com o administrador do gateway para obter ajuda com o monitoramento de gateways.

Gorjeta

Seu administrador do Power BI pode compilar um inventário completo de locatários (que inclui linhagem) e acessar 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 gateways usados com mais frequência.

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

Lista de verificação - Ao planejar o monitoramento de uma fonte de dados, as principais decisões e ações incluem:

  • Determinar metas específicas: ao monitorar uma fonte de dados, obtenha clareza sobre exatamente o que você precisa realizar e as metas para a solução de problemas.
  • Colabore com administradores de banco de dados: trabalhe com seus administradores de banco de dados ou de sistema para obter 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 ao solucionar problemas.
  • Conecte sua equipe de suporte e administradores de banco de dados: certifique-se de que sua equipe de suporte saiba como entrar em contato com os administradores corretos para cada fonte de dados (por exemplo, ao solucionar problemas de dobragem de consulta).
  • Atualizar treinamento e orientação: inclua informações importantes e dicas para criadores de dados sobre como trabalhar com fontes de dados organizacionais. Inclua informações sobre o que fazer quando algo corre mal.

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 geralmente usa contratos de nível de serviço (SLAs) para documentar as expectativas para ativos de dados. Para o Power BI, considere usar um SLA para conteúdo crítico ou conteúdo de nível empresarial. Geralmente inclui quando os usuários podem esperar que dados atualizados em um modelo semântico estejam disponíveis. Por exemplo, você pode ter um SLA que todas as atualizações de dados devem concluir até as 7h todos os dias.

Logs de modelo semântico

Os logs de eventos do 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 do modelo semântico. Os logs de eventos são especialmente úteis quando você precisa solucionar problemas e investigar atualizações de modelo semântico.

Modelos semânticos de capacidade premium

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

  • A página de resumos de atualização do Power BI no portal de administração inclui um resumo do histórico de atualizações. Este resumo fornece informações sobre a duração da atualização e 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 para uma capacidade do Power BI Premium (P SKU) ou Power BI Embedded (Uma SKU).

Atualizações aprimoradas 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 avançada, você pode monitorar as operações de atualização históricas, atuais e pendentes.

Monitoramento da agenda de atualização de dados

Os administradores do Power BI podem monitorar agendas 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 da agenda de atualização do modelo semântico a partir das APIs de verificação de metadados, conhecidas como APIs do scanner.

APIs REST do Power BI

Para modelos semânticos críticos, não confie apenas em notificações por e-mail para monitorar problemas de atualização de dados. Considere compilar o histórico de atualização de dados em um armazenamento centralizado onde você possa monitorar, analisar e agir de acordo com ele.

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

Gorjeta

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

Lista de verificação - Ao planejar o monitoramento da atualização de dados, as principais decisões e ações incluem:

  • Determinar objetivos específicos: 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 a configuração de um SLA: determine se um SLA seria útil para definir expectativas de disponibilidade de dados e quando as agendas de atualização de dados devem ser executadas.
  • Colabore com administradores de banco de dados e gateway: trabalhe com seus administradores de banco de dados ou de sistema e administradores de gateway para monitorar ou solucionar problemas de atualização de dados.
  • Transferência de conhecimento para a equipe de suporte: certifique-se de que sua equipe de suporte saiba como ajudar os criadores de conteúdo quando surgirem problemas de atualização de dados.
  • Atualizar treinamento e orientação: inclua informações importantes 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 sobre como gerenciar a atualização de dados.
  • Use um endereço de e-mail de suporte para notificações: para conteúdo crítico, configure notificações de atualização para usar um endereço de e-mail de suporte.
  • Configurar monitoramento de atualização centralizado: use as APIs REST do Power BI para compilar o histórico de atualização de dados.

Monitorização do fluxo de dados

Criar 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 espaços de trabalho para usar o Azure Data Lake Storage Gen2 para armazenamento de fluxo de dados (conhecido como traga seu próprio armazenamento) em vez de armazenamento interno. Ao usar traga seu próprio armazenamento, considere habilitar a telemetria para que você possa monitorar as métricas da conta de armazenamento. Para obter mais informações, consulte o cenário de uso de preparação de dados pessoais e o cenário de uso de 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 Get Dataflow Transactions para verificar o status das atualizações de fluxo de dados.

Você pode controlar 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, consulte Auditoria em nível de locatário.

Gorjeta

Há muitas práticas recomendadas que você pode adotar para otimizar seus projetos de fluxo de dados. Para obter mais informações, consulte Práticas recomendadas de fluxos de dados.

Monitoramento 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. Consulte as seções anteriores deste artigo para saber mais sobre auditoria e monitoramento de cada componente.

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

Conteúdos relacionados

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