Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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 tabela 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 | Observação |
|---|---|---|---|
| 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 usa o Power Query. | Um instantâneo dos dados é armazenado em armazenamento nativo para o carregamento rápido de elementos visuais em relatórios. | Para obter os dados mais recentes da fonte de dados, atualize o modelo semântico ou a tabela. |
| Lago direto em 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 a partir de tabelas delta do Microsoft OneLake para o carregamento rápido de elementos 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 reenquadramento para Direct Lake. Para obter mais informações sobre o Direct Lake, consulte Visão geral do Direct Lake. |
| Direct Lake em SQL | Nos pontos de extremidade analíticos SQL de itens de malha, quando você seleciona Novo modelo semântico. | Os dados são digitalizados a partir de tabelas delta 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: - Utiliza-se uma vista. - O acesso granular SQL está habilitado. - Um guardrail direto do lago é alcançado. |
| DirectQuery | No Power BI Desktop, para algumas fontes de dados, como bancos de dados SQL, quando você seleciona Obter dados e usa 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 (Power BI Data Analysis Expressions), que os visuais usam, para a linguagem de consulta nativa da fonte de dados, como uma consulta SQL. |
| DirectQuery em modelos semânticos do Power BI | No Power BI Desktop, quando você se conecta a um modelo semântico do Power BI e seleciona Fazer alterações nesse modelo ou quando uma tabela Importar 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 para 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 para o modo de Importação. Uma caixa de diálogo é exibida com opções para converter as tabelas DirectQuery restantes para o modo Duplo. | As relações entre as tabelas DirectQuery e Import são limitadas. Mudar 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 Importar. 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ções são automatizados para reduzir a quantidade de dados que precisam ser atualizados. | Para obter mais informações, consulte Configurar atualização incremental e dados em tempo real para modelos semânticos do Power BI. |
Observação
O modo de conexão ao vivo é usado nos seguintes casos:
- Para conectar-se 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 de conexão dinâmica não tem 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 na visualizaçã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.
Ver o modo de armazenamento de uma tabela
Cada mesa tem uma Storage mode propriedade. Para ver o modo de armazenamento de uma tabela, execute as seguintes etapas:
Na vista Modelo , selecione a tabela.
No painel Propriedades , expanda a seção Avançado e, em seguida, expanda a lista Modo de armazenamento .
Para a maioria das tabelas, você pode definir o modo de armazenamento somente quando adicionar a tabela. Você pode alterar o modo de armazenamento somente se a tabela estiver no modo DirectQuery ou no modo Direct Lake no OneLake quando criada:
- Você pode alterar uma tabela DirectQuery para uma tabela Import ou Dual. Depois de definir essa propriedade, você não pode 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. Ambos os 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 em Importar tabelas usando laboratórios de vínculo semântico em blocos de anotações de malha.
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 mais informações, consulte as limitações do DirectQuery .
Propagação da configuração dupla
Considere o seguinte modelo. Todas as tabelas são de uma única fonte que suporta os 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, para o modo Duplo 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 onde JOIN a lógica 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 para o modo Duplo, 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
Considere um exemplo que envolve as seguintes tabelas e modos de armazenamento:
| Tabela | Modo de armazenamento |
|---|---|
| Sales | DirectQuery |
| SurveyResponse | Importação |
| Data | Duplo |
| Cliente | Duplo |
| Geografia | Duplo |
O uso desses modos de armazenamento resulta no seguinte comportamento, supondo que a tabela Sales 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 carregamento dos relatórios iniciais quando eles recuperam valores de segmentação de dados para exibição.
O Power BI Desktop não armazena em cache a tabela Sales .
- Não armazenar esta tabela em cache ajuda a melhorar os tempos de atualização de dados e a reduzir o consumo de memória.
- As consultas de relatório baseadas na tabela Sales 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, porque nenhuma latência de cache é introduzida.
As consultas de relatório baseadas na tabela SurveyResponse são relativamente rápidas, porque são retornadas do cache na memória.
Consultas que têm êxito ou falham no uso do 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
- Processamento de consultas\Início da consulta Vertipaq SE
- Processamento de Consultas\Início do DirectQuery
Para cada evento Query Start , 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 a partir do cache.
As consultas que se referem a tabelas duplas retornam dados do cache, se possível. Caso contrário, eles serão revertidos 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 Data , que está no modo Duplo. Portanto, a consulta deve atingir o cache:
A consulta a seguir refere-se apenas a uma coluna da tabela Sales , que está no modo DirectQuery. Portanto, não deve atingir o cache:
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 uma SUM operação ou GROUP BY para o sistema de origem. Se a fonte realizar a operação, apenas a soma das vendas de cada ano é devolvida. Esse resultado provavelmente contém muito menos linhas do que se todos os valores SalesAmount fossem retornados.
Observação
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.
Mantenha 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 diferir 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 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. 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 Compreender relações muitos-para-muitos no Power BI Desktop.
Visualização de tabela
Se pelo menos uma tabela no modelo semântico tiver um modo de armazenamento de Importar ou Dual, a guia Modo de exibição Tabela do Power BI estará disponível.
Quando você seleciona uma tabela Dual ou Import no modo Tabela , seus dados armazenados em cache são exibidos. Nenhum dado é exibido para tabelas DirectQuery. Em vez disso, aparece uma mensagem informando que as tabelas do DirectQuery não podem ser mostradas.
Considerações e limitações
Existem atualmente algumas limitações para os modos de armazenamento de tabelas e o uso de certos modos em 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 modo DirectQuery, não pode se conectar a outra fonte do DirectQuery ou combiná-la com dados importados.
As limitações do uso do 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: