Partilhar via


Gerenciar o modo de armazenamento no Power BI Desktop

No Microsoft Power BI Desktop, você pode especificar o modo de armazenamento de uma tabela. O modo de armazenamento permite controlar se o Power BI Desktop armazena ou não em cache os dados da tabela na memória para relatórios. Armazenar em cache significa armazenar temporariamente dados na memória.

Definir o modo de armazenamento oferece muitas vantagens. Você pode definir o modo de armazenamento para cada tabela individualmente em seu modelo. Essa ação permite um único modelo semântico, que fornece os seguintes benefícios:

  • Desempenho da consulta: à medida que os usuários interagem com elementos visuais em relatórios do Power BI, as consultas DAX (Data Analysis Expressions) são enviadas para o modelo semântico. Armazenar dados em cache na memória definindo corretamente o modo de armazenamento pode aumentar o desempenho da consulta e a interatividade de seus relatórios.

  • Modelos semânticos grandes: as tabelas que não são armazenadas em cache não consomem memória para fins de cache. Você pode habilitar a análise interativa em modelos semânticos grandes que são muito grandes ou caros para armazenar completamente em cache na memória. Você pode escolher quais tabelas valem a pena armazenar em cache e quais não valem.

  • Otimização da atualização de dados: não é necessário atualizar tabelas que não estão armazenadas em cache. Você pode reduzir os tempos de atualização armazenando em cache apenas os dados necessários para atender aos seus contratos de nível de serviço e aos seus requisitos de negócios.

  • Requisitos quase em tempo real: tabelas com requisitos quase em tempo real podem se beneficiar de não serem armazenadas em cache, para reduzir a latência dos dados.

  • Writeback: o write-back permite que os usuários corporativos explorem cenários hipotéticos alterando os valores das células. Os aplicativos personalizados podem aplicar alterações à fonte de dados. As tabelas que não são armazenadas em cache podem exibir as alterações imediatamente, o que permite a análise instantânea dos efeitos.

A configuração do modo de armazenamento no Power BI Desktop é um dos três recursos relacionados:

  • Modelos compostos: permite que um relatório tenha duas ou mais conexões de dados, incluindo conexões DirectQuery ou Import, em qualquer combinação. Para obter mais informações, consulte Usar modelos compostos no Power BI Desktop.

  • Relações muitos-para-muitos: com modelos compostos, você pode estabelecer relações muitos-para-muitos entre tabelas. Em uma relação muitos-para-muitos, os requisitos são removidos para valores exclusivos em tabelas. Ele também remove soluções alternativas anteriores, como a introdução de novas tabelas apenas para estabelecer relações. Para obter mais informações, consulte Relações muitos-para-muitos no Power BI Desktop.

  • Modo de armazenamento: com o modo de armazenamento, agora você pode especificar quais elementos visuais exigem uma consulta para fontes de dados back-end. Os elementos visuais que não exigem uma consulta são importados mesmo que sejam baseados no DirectQuery. Esse recurso ajuda a melhorar o desempenho e reduzir a carga de back-end. Anteriormente, até mesmo visuais simples, como segmentações de dados, iniciavam consultas que eram enviadas para fontes de back-end.

Usar a propriedade Modo de armazenamento

A propriedade Modo de armazenamento é uma propriedade que você pode definir em cada tabela em seu modelo e controla como o Power BI armazena em cache os dados da tabela.

Para definir a propriedade Modo de armazenamento ou exibir sua configuração atual:

  1. No modo Modelo , selecione a tabela cujas propriedades você deseja exibir ou definir.

  2. No painel Propriedades, expanda a seção Avançado e expanda a lista suspensa Modo de armazenamento.

    Screenshot of Relationship view highlight the option drop-down to change the storage mode.

Defina a propriedade Modo de armazenamento para um destes três valores:

  • Importar: as tabelas importadas com essa configuração são armazenadas em cache. As consultas enviadas ao modelo semântico do Power BI que retornam dados de tabelas de Importação só podem ser atendidas a partir de dados armazenados em cache.

  • DirectQuery: As tabelas com essa configuração não são armazenadas em cache. As consultas que você envia para o modelo semântico do Power BI - por exemplo, consultas DAX - e que retornam dados de tabelas DirectQuery podem ser atendidas somente executando consultas sob demanda para a fonte de dados. As consultas enviadas à fonte de dados usam a linguagem de consulta para essa fonte de dados, por exemplo, SQL.

  • Dual: as tabelas com essa configuração podem atuar como armazenadas em cache ou não em cache, dependendo do contexto da consulta enviada ao modelo semântico do Power BI. Em alguns casos, você atende consultas a partir de dados armazenados em cache. Em outros casos, você atende às consultas executando uma consulta sob demanda à fonte de dados.

Alterar o modo de armazenamento de uma tabela para Importar é uma operação irreversível. Depois que essa propriedade for definida, ela não poderá ser alterada posteriormente para DirectQuery ou Dual.

Nota

Você pode usar o modo de armazenamento duplo no Power BI Desktop e no serviço do Power BI.

Restrições nas tabelas DirectQuery e Dual

As tabelas duplas têm as mesmas restrições funcionais que as tabelas DirectQuery. Essas restrições incluem transformações M limitadas e funções DAX restritas em colunas calculadas. Para obter mais informações, consulte Limitações do DirectQuery.

Propagação da configuração dupla

Considere o modelo a seguir, onde todas as tabelas são de uma única fonte que oferece suporte a Import e DirectQuery.

Screenshot of the example Relationship view for storage mode.

Digamos que todas as tabelas neste modelo são inicialmente definidas como DirectQuery. Se você alterar o modo de armazenamento da tabela SurveyResponse para Importar, a seguinte janela de aviso será exibida:

Screenshot showing a warning window that describes the results of changing the storage mode to Import.

Você pode definir as tabelas de dimensão (Cliente, Geografia e Data) como Dual para reduzir o número de relações limitadas no modelo semântico e melhorar o desempenho. Relações limitadas normalmente envolvem pelo menos uma tabela DirectQuery onde a lógica de junção não pode ser enviada por push para os sistemas de origem. Como as tabelas duplas podem atuar como tabelas DirectQuery ou Import, essa situação é evitada.

A lógica de propagação foi projetada para ajudar com modelos que contêm muitas tabelas. Suponha que você tenha um modelo com 50 tabelas e apenas determinadas tabelas de fatos (transacionais) precisem ser armazenadas em cache. A lógica no Power BI Desktop calcula o conjunto mínimo de tabelas de dimensão que devem ser definidas como Dual, para que você não precise fazê-lo.

A lógica de propagação atravessa apenas um lado das relações um-para-muitos.

Exemplo de uso do modo de armazenamento

Imagine aplicar as seguintes configurações de propriedade do modo de armazenamento:

Tabela Modo de armazenamento
Vendas DirectQuery
SurveyResponse Import
Date Duplo
Cliente Duplo
Geografia Duplo

A definição dessas propriedades do modo de armazenamento resulta nos seguintes comportamentos, supondo que a tabela Sales tenha um volume de dados significativo:

  • O Power BI Desktop armazena em cache tabelas de dimensão, Data, Cliente e Geografia, portanto, os tempos de carregamento dos relatórios iniciais são rápidos quando recuperam valores de segmentação de dados para exibição.

  • O Power BI Desktop não armazena em cache a tabela Sales . O Power BI Desktop fornece os seguintes resultados ao não armazenar esta tabela em cache:

    • Os tempos de atualização de dados são melhorados e o consumo de memória é reduzido.
    • As consultas de relatório baseadas na tabela Sales são executadas no modo DirectQuery . Essas consultas podem levar mais tempo, mas estão mais próximas do tempo real, porque nenhuma latência de cache é introduzida.
  • As consultas de relatório baseadas na tabela SurveyResponse são retornadas do cache na memória e, portanto, são relativamente rápidas.

Consultas que atingem ou perdem o cache

Se você conectar o SQL Profiler à porta de diagnóstico do Power BI Desktop, poderá ver quais consultas atingem ou perdem o cache na memória executando um rastreamento baseado nos seguintes eventos:

  • Eventos de consultas\Início da consulta
  • Processamento de consultas\Início da consulta Vertipaq SE
  • Processamento de Consultas\Início do DirectQuery

Para cada evento Começo de Consulta , verifique outros eventos com o mesmo ActivityID. Por exemplo, se não houver um evento DirectQuery Begin, mas houver um evento Vertipaq SE Query Begin, a consulta será respondida a partir do cache.

As consultas que se referem a tabelas duplas retornam dados do cache, se possível; caso contrário, eles revertem para DirectQuery.

A consulta a seguir continua da tabela anterior. Refere-se apenas a uma coluna da tabela Data , que está no modo Duplo . Portanto, a consulta deve atingir o cache:

Screenshot showing the text of query that refers to the Date table.

A consulta a seguir refere-se apenas a uma coluna da tabela Sales , que está no modo DirectQuery . Portanto, ele não deve atingir o cache:

Screenshot showing the text of query that refers the Sales table.

A consulta a seguir é interessante porque combina as duas colunas. Esta consulta não atinge o cache. Inicialmente, você pode esperar que ele recupere valores CalendarYear do cache e valores SalesAmount da origem e, em seguida, combine os resultados, mas essa abordagem é menos eficiente do que enviar a operação SUM/GROUP BY para o sistema de origem. Se a operação for empurrada para baixo até a origem, o número de linhas retornadas provavelmente será muito menor:

Screenshot showing the text of query that refers to both the Date table and the Sales table.

Nota

Esse comportamento é diferente de relações muitos-para-muitos no Power BI Desktop quando tabelas em cache e não armazenadas em cache são combinadas.

Os caches devem ser mantidos sincronizados

As consultas exibidas na seção anterior mostram que as tabelas duplas às vezes atingem o cache e às vezes não. Como resultado, se o cache estiver desatualizado, valores diferentes podem ser retornados. A execução da consulta não tentará mascarar problemas de dados, por exemplo, filtrando os resultados do DirectQuery para corresponder aos valores armazenados em cache. É sua responsabilidade conhecer seus fluxos de dados, e você deve projetar de acordo. Existem técnicas estabelecidas para lidar com esses casos na fonte, se necessário.

O modo de armazenamento duplo é uma otimização de desempenho. Ele deve ser usado apenas de maneiras que não comprometam a capacidade de atender aos requisitos de negócios. Para um comportamento alternativo, considere usar as técnicas descritas em Relações muitos-para-muitos no Power BI Desktop.

Vista de dados

Se pelo menos uma tabela no modelo semântico tiver seu modo de armazenamento definido como Importar ou Dual, a guia Exibição de dados poderá ser exibida.

Screenshot highlighting the Data view icon.

Quando você seleciona Tabelas duplas e Importar na visualização Dados, elas mostram dados armazenados em cache. As tabelas DirectQuery não mostram dados e é exibida uma mensagem informando que as tabelas DirectQuery não podem ser mostradas.

Considerações e limitações

Há algumas limitações para a versão atual do modo de armazenamento e sua correlação com modelos compostos.

As seguintes fontes de conexão ao vivo (multidimensionais) não podem ser usadas com modelos compostos:

  • SAP HANA
  • SAP Business Warehouse

Quando você se conecta a essas fontes multidimensionais usando o DirectQuery, não pode se conectar a outra fonte do DirectQuery ou combiná-la com dados importados.

As limitações existentes do uso do DirectQuery ainda se aplicam quando você usa modelos compostos. Muitas dessas limitações agora são por tabela, dependendo do modo de armazenamento da tabela. Por exemplo, uma coluna calculada em uma tabela importada pode se referir a outras tabelas, mas uma coluna calculada em uma tabela DirectQuery ainda é restrita para se referir apenas a colunas na mesma tabela. Outras limitações se aplicam ao modelo como um todo, se qualquer uma das tabelas dentro do modelo for DirectQuery.

Para obter mais informações sobre modelos compostos e DirectQuery, consulte os seguintes artigos: