Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Em modelos semânticos do Power BI, o modo de armazenamento de uma tabela depende de sua fonte de dados. Você pode usar o modo de armazenamento para controlar se o Power BI armazena os dados da tabela na memória para relatórios ou recupera os dados da fonte de dados quando os visuais são carregados.
Este artigo apresenta os vários modos de armazenamento de tabelas e descreve como eles afetam o comportamento do relatório.
Modos de armazenamento de tabela
| Modo de armazenamento de tabela | Quando disponível | Benefícios | Nota |
|---|---|---|---|
| Importação | No Power BI Desktop e na modelagem da Web do Power BI, para quase todas as fontes de dados, quando você seleciona Obter dados e usar o Power Query. | Um instantâneo dos dados é armazenado no armazenamento nativo para o carregamento rápido de visuais em relatórios. | Para obter os dados mais recentes da fonte de dados, atualize o modelo semântico ou a tabela. |
| Direct Lake no OneLake | No Power BI Desktop e na modelagem da Web do Power BI, para fontes de dados do Microsoft Fabric, quando você seleciona o catálogo do OneLake. | Os dados são verificados nas tabelas delta do Microsoft OneLake para o carregamento rápido de visuais em relatórios. | Por padrão, os dados mais recentes são carregados. Para acessar os dados mais recentes atualizando-os manualmente, desative a sincronização automática na página de configurações de atualização agendada. Uma atualização também é chamada de reframing para Direct Lake. Para obter mais informações sobre o Direct Lake, consulte a visão geral do Direct Lake. |
| Direct Lake no SQL | Nos pontos de extremidade analíticos do SQL de itens do Fabric, quando você seleciona Novo modelo semântico. | Os dados são escaneados nas tabelas delta do OneLake para carregamento rápido em relatórios. | Nesse modo, o Power BI usa o modo de armazenamento DirectQuery para acessar dados nos seguintes casos: - Uma exibição é usada. - O acesso granular do SQL está habilitado. - Um guardrail do Direct Lake foi atingido. |
| DirectQuery | No Power BI Desktop, para algumas fontes de dados, como bancos de dados SQL, quando você seleciona Obter dados e usar o Power Query. | Os dados são consultados da fonte de dados quando os visuais são carregados e não são armazenados no modelo semântico. | A consulta é uma tradução da consulta DAX (Expressões de Análise de Dados) do Power BI, que os visuais usam, para a linguagem de consulta nativa da fonte de dados, como uma consulta SQL. |
| Modelos semânticos do DirectQuery no Power BI | No Power BI Desktop, quando você se conecta a um modelo semântico do Power BI e, em seguida, seleciona Fazer alterações nesse modelo ou quando uma tabela Import ou DirectQuery já está adicionada. | As consultas DAX do novo modelo são executadas no modelo de origem e podem usar medidas de ambos. Algumas propriedades de coluna no modelo remoto podem ser substituídas no novo modelo. Essa personalização inclui cadeias de caracteres de formato e nomes de exibição. | Use esse modo de armazenamento quando precisar fazer uma pequena alteração em um modelo semântico existente para um relatório específico. |
| Duplo | No Power BI Desktop, quando você converte uma tabela DirectQuery no modo De importação. Uma caixa de diálogo é exibida com opções para converter as tabelas do DirectQuery restantes no modo Dual. | As relações entre as tabelas DirectQuery e Import são limitadas. Alternar do DirectQuery para o modo Dual pode ajudar a manter essas relações regulares. | |
| Híbrido | Em cenários de atualização incremental em uma tabela de importação. A partição mais recente da tabela pode estar no modo DirectQuery para ajudar a garantir que os dados mais recentes estejam disponíveis entre as atualizações de importação. | A criação e o gerenciamento de partição são automatizados para reduzir a quantidade de dados que precisam ser atualizados. | Para obter mais informações, consulte Configurar a atualização incremental e dados em tempo real para modelos semânticos do Power BI. |
Nota
O modo de conexão ao vivo é usado nos seguintes casos:
- Para se conectar a um modelo semântico do Power BI no Power BI Desktop para criar um relatório
- Para criar um relatório a partir de um modelo semântico do Power BI na Web
Um relatório do Live Connect não tem um modelo semântico local e, às vezes, é chamado de relatório fino. O modelo semântico remoto do Power BI pode usar qualquer modo de armazenamento de tabela. Como autor do relatório, você pode ver o modelo no modo de exibição Modelo , mas apenas informações limitadas estão disponíveis. As medidas criadas são armazenadas no relatório.
Um modelo semântico composto é um modelo semântico com tabelas em mais de um modo de armazenamento. Para obter mais informações, consulte Usar modelos compostos no Power BI.
Consulte o modo de armazenamento de uma tabela
Cada tabela tem uma Storage mode propriedade. Para ver o modo de armazenamento de uma tabela, execute as seguintes etapas:
No modo de exibição Modelo , selecione a tabela.
No painel Propriedades , expanda a seção Avançado e expanda a lista de modos de armazenamento .
Para a maioria das tabelas, você pode definir o modo de armazenamento somente quando adicionar a tabela. Você só poderá alterar o modo de armazenamento se a tabela estiver no modo DirectQuery ou direct lake no modo OneLake quando criada:
- Você pode alterar uma tabela DirectQuery para uma tabela Importação ou Dupla. Depois de definir essa propriedade, você não poderá definir o modo de volta para DirectQuery. As exceções são a modelagem da Web do Power BI e a edição ao vivo no Power BI Desktop. Esses ambientes têm controle de versão, que você pode usar para reverter um modo de armazenamento alterado.
- Você pode converter o Direct Lake em tabelas do OneLake para importar tabelas usando laboratórios de link semântico em blocos de anotações do Fabric.
Restrições em tabelas DirectQuery e Dual
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, confira Limitações do DirectQuery.
Propagação da configuração Duplo
Considere o modelo a seguir. Todas as tabelas são de uma única origem que dá suporte aos modos Import e DirectQuery.
Suponha que todas as tabelas neste modelo sejam inicialmente definidas como DirectQuery. Se você alterar o modo de armazenamento da tabela SurveyResponse para Importar, a seguinte janela de aviso será exibida:
Você pode definir as tabelas de dimensão, Cliente, Geografia e Data, como modo Dual para reduzir o número de relações limitadas no modelo semântico e ajudar a melhorar o desempenho. Relações limitadas normalmente envolvem pelo menos uma tabela DirectQuery em JOIN que a lógica não pode ser enviada por push para os sistemas de origem. Como 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) precisam 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 modo Dual, para que você não precise.
A lógica de propagação atravessa apenas para um lado das relações um-para-muitos.
Exemplo de uso do modo de armazenamento
Considere um exemplo que envolva as seguintes tabelas e modos de armazenamento:
| Tabela | Modo de armazenamento |
|---|---|
| Sales | DirectQuery |
| SurveyResponse | Importação |
| Date | Duplo |
| Cliente | Duplo |
| Geografia | Duplo |
O uso desses modos de armazenamento resulta no seguinte comportamento, supondo que a tabela Vendas tenha um volume de dados significativo:
O Power BI Desktop armazena em cache as tabelas de dimensão, Data, Cliente e Geografia, para ajudar a reduzir os tempos de carga dos relatórios iniciais quando eles recuperam valores de segmentação de dados a serem exibidos.
O Power BI Desktop não armazena em cache a tabela Sales.
- Não armazenar em cache essa tabela ajuda a melhorar os tempos de atualização de dados e a reduzir o consumo de memória.
- Consultas de relatório baseadas na tabela Vendas são executadas no modo DirectQuery. Essas consultas podem levar mais tempo do que importar consultas. Mas os resultados das consultas DirectQuery estão mais próximos dos resultados em tempo real, pois nenhuma latência de cache é introduzida.
As consultas de relatório baseadas na tabela SurveyResponse são relativamente rápidas, pois são retornadas do cache na memória.
Consultas que acertam ou ignoram o cache
Você pode usar o SQL Server Profiler para ver quais consultas atingem ou perdem o cache na memória. Se você conectar essa ferramenta à porta de diagnóstico do Power BI Desktop, poderá executar um rastreamento baseado nos seguintes eventos:
- Eventos de consultas\Início da consulta
- Início da consulta de processamento de consulta\Vertipaq SE
- Processamento de consulta\DirectQuery Begin
Para cada evento Query Begin , verifique outros eventos com o mesmo ActivityID valor. Por exemplo, se não houver um evento DirectQuery Begin, mas houver um evento Vertipaq SE Query Begin, a consulta será respondida do cache.
As consultas que se referem a tabelas duplas retornam dados do cache, se possível. Caso contrário, eles reverterão para o modo DirectQuery.
Considere algumas consultas DAX que se referem às tabelas na seção anterior. Por exemplo, a consulta a seguir refere-se apenas a uma coluna da tabela Date , que está no modo Dual. Portanto, a consulta deve atingir o cache:
A consulta a seguir refere-se apenas a uma coluna da tabela Vendas , que está no modo DirectQuery. Portanto, ela não deve ter uma ocorrência no cache:
A consulta a seguir é interessante porque combina ambas as colunas. Essa consulta não atinge o cache. Inicialmente, você pode esperar que ele recupere valores CalendarYear dos valores de cache e SalesAmount da origem e combine os resultados. Mas essa abordagem é menos eficiente do que enviar uma operação ou GROUP BY uma SUM operação para o sistema de origem. Se a origem executar a operação, somente a soma das vendas de cada ano será retornada. Esse resultado provavelmente contém muito menos linhas do que se todos os valores SalesAmount forem retornados.
Nota
Esse comportamento é diferente das relações muitos para muitos no Power BI Desktop quando as tabelas armazenadas em cache são combinadas com tabelas que não são armazenadas em cache.
Manter os caches sincronizados
As consultas na seção anterior mostram que as tabelas duplas às vezes atingem o cache e, às vezes, não. Como resultado, os valores retornados de um cache desatualizado podem ser diferentes dos valores retornados da origem. A execução da consulta não tenta mascarar problemas de dados, por exemplo, filtrando os resultados do DirectQuery para corresponder a valores armazenados em cache. É sua responsabilidade conhecer seus fluxos de dados e você deve projetar adequadamente. Há técnicas estabelecidas para lidar com esses casos na origem, se necessário.
O modo de armazenamento duplo é uma otimização de desempenho. Você deve usá-lo 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 Entender relações muitos para muitos no Power BI Desktop.
Exibição de tabela
Se pelo menos uma tabela no modelo semântico tiver um modo de armazenamento de Importação ou Dupla, a guia exibição tabela do Power BI estará disponível.
Quando você seleciona uma tabela Dual ou Import no modo de exibição Tabela , seus dados armazenados em cache são exibidos. Nenhum dado é exibido para tabelas do DirectQuery. Em vez disso, uma mensagem é exibida informando que as tabelas DirectQuery não podem ser mostradas.
Considerações e limitações
Atualmente, existem algumas limitações para os modos de armazenamento de tabela e o uso de determinados modos em modelos compostos:
As seguintes fontes de conexão dinâmica (multidimensional) não podem ser usadas com modelos compostos:
- SAP HANA
- SAP Business Warehouse
Quando você se conecta a essas fontes multidimensionais usando o modo DirectQuery, não é possível se conectar a outra fonte do DirectQuery ou combiná-la com dados importados.
As limitações de usar o modo DirectQuery ainda se aplicam quando você usa modelos compostos. Muitas dessas limitações se aplicam no nível da tabela e dependem 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 pode 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 estiver no modo DirectQuery.
Conteúdo relacionado
Para obter mais informações sobre modelos compostos e o modo DirectQuery, consulte os seguintes artigos: