Modelos compostos no Power BI: misturando importação e DirectQuery

Durante anos, os profissionais do Power BI tiveram que escolher: modo de importação (rápido, mas os dados são tão recentes quanto a última atualização) ou DirectQuery (sempre atual, mas potencialmente lento e com consulta limitada). Os modelos compostos mudaram esse cálculo ao permitir que ambos os modos de armazenamento coexistissem em um único modelo — com relacionamentos que cruzam a fronteira do modo.

Esse recurso desbloqueia cenários que antes eram impossíveis: um painel que mostra o histórico completo de transações de ontem a partir de uma partição de importação junto com os dados em tempo real de hoje de uma fonte DirectQuery, todos unidos a uma tabela de oportunidades ao vivo do Salesforce consultada sob demanda. Compreender como os modelos compostos funcionam — e quando eles criam mais problemas do que resolvem — é um conhecimento essencial para qualquer profissional avançado de Power BI.

Principais conclusões

• Modelos compostos combinam modos de importação, DirectQuery e armazenamento duplo em um único modelo semântico
• O modo de importação fornece compactação VertiPaq e desempenho de consulta na memória para dados históricos
• O modo DirectQuery consulta a fonte em tempo real — a atualização é excelente, mas o desempenho depende da fonte
• As tabelas de modo duplo podem atuar como importação ou DirectQuery dependendo do contexto da consulta
• Relacionamentos que cruzam os limites do modo de armazenamento aumentam a complexidade da consulta e podem causar problemas de desempenho
• Tabelas de agregação em modelos compostos melhoram drasticamente o desempenho da consulta DirectQuery
• Conjuntos de dados do DirectQuery para Power BI (encadeamento) permitem modelos compostos criados com base em modelos semânticos compartilhados
• Relacionamentos limitados entre tabelas de importação e DirectQuery restringem determinadas funções DAX

---

Modos de armazenamento: Importação, DirectQuery e Dual

Antes de compreender os modelos compostos, cada modo de armazenamento deve ser compreendido individualmente.

Modo de importação carrega dados do sistema de origem no mecanismo de armazenamento VertiPaq na memória do Power BI. Os dados são compactados (geralmente 10:1 ou melhor) e armazenados como dados colunares que executam consultas analíticas com extrema rapidez — normalmente em milissegundos para a maioria das consultas em conjuntos de dados de até centenas de milhões de linhas. A limitação: os dados são tão recentes quanto a última atualização programada ou manual.

Modo DirectQuery consulta o sistema de origem em tempo real sempre que um usuário interage com um relatório. O mecanismo do Power BI converte consultas DAX em consultas de origem nativa (SQL para bancos de dados relacionais etc.) e as executa na origem. Os dados são sempre atuais, mas o desempenho depende inteiramente do desempenho da consulta do sistema de origem. Um banco de dados analítico dedicado e bem indexado lidará bem com as consultas do DirectQuery; um banco de dados de produção OLTP sob carga transacional pesada pode produzir resultados lentos e inconsistentes.

Modo duplo é um híbrido especial disponível em modelos compostos. Uma tabela de modo duplo é armazenada fisicamente como importação (dados carregados no VertiPaq), mas também pode ser consultada via DirectQuery quando o contexto da consulta exigir. Isso é usado principalmente para tabelas de dimensões compartilhadas que precisam participar de relacionamentos com tabelas de fatos de importação e do DirectQuery.

---

Quando usar modelos compostos

Os modelos compostos são apropriados para cenários específicos. Eles acrescentam complexidade que não se justifica quando arquiteturas mais simples atendem aos requisitos.

Use modelos compostos quando:

Não use modelos compostos quando:

• Um modelo de importação completo é atualizado com rapidez suficiente e a latência dos dados é aceitável (na maioria dos casos)
• A origem do DirectQuery não consegue lidar com a carga de consulta (bancos de dados OLTP de produção)
• São necessários cálculos DAX complexos — modelos compostos limitam certas funções DAX
• A segurança em nível de linha precisa abranger o limite do modo de armazenamento (implementação complexa)

---

Configurando modos de armazenamento

No Power BI Desktop, o modo de armazenamento é definido por tabela. Clique com o botão direito em uma tabela na visualização Modelo → Propriedades → Avançado → Modo de armazenamento.

Para um modelo composto típico com uma grande tabela de fatos no DirectQuery e dimensões no Import:

1. Defina FactSales → Modo de armazenamento: DirectQuery
2. Defina DimDate → Modo de armazenamento: Dual (atende a consultas de importação e DirectQuery)
3. Defina DimProduct → Modo de armazenamento: Importar (tabela pequena, totalmente armazenada em cache)
4. Defina DimCustomer → Modo de armazenamento: Dual (usado em relacionamentos entre fontes)
5. Defina RealtimeSales (dados de hoje) → Modo de armazenamento: DirectQuery

Quando você configura uma tabela como DirectQuery ou altera os modos de armazenamento, o Power BI exibe avisos sobre relacionamentos e possíveis limitações. Revise-os cuidadosamente – eles indicam onde o comportamento do modelo pode diferir de um modelo de importação puro.

---

Relacionamentos em modelos compostos

Os relacionamentos entre tabelas de diferentes modos de armazenamento se comportam de maneira diferente dos relacionamentos do mesmo modo, e compreender essas diferenças é fundamental para construir modelos que produzam resultados corretos.

Relacionamentos regulares conectam duas tabelas onde o lado "muitos" pode usar o lado "um" para filtrar. Nos modelos de importação, ambas as tabelas estão na memória e o relacionamento é executado na memória – rapidamente. Em modelos compostos com uma tabela de importação e uma tabela DirectQuery, o relacionamento causa uma verificação de tabela de uma tabela que é usada para filtrar a outra, gerando potencialmente grandes consultas de modo cruzado.

Relacionamentos limitados são criados automaticamente quando uma tabela DirectQuery tem um relacionamento muitos para muitos com uma tabela de importação ou em alguns outros cenários de modo cruzado. As relações limitadas não suportam filtros bidirecionais e restringem determinadas funções DAX (por exemplo, funções que dependem do caminho do filtro de relação). O Power BI relata relacionamentos limitados na visualização do modelo com uma linha pontilhada em vez de uma linha sólida.

Relacionamentos entre fontes conectam tabelas de fontes de dados completamente diferentes (por exemplo, uma tabela do SQL Server conectada via DirectQuery e uma tabela do Salesforce conectada por outra conexão DirectQuery). Esses relacionamentos exigem que um lado seja uma tabela de modo duplo. O Power BI precisa ser capaz de materializar um lado do relacionamento na memória para unir-se ao outro.

O impacto prático destes tipos de relacionamento: As medidas DAX que funcionam corretamente em um modelo de importação puro podem produzir resultados inesperados ou erros em um modelo composto. Teste todas as medidas cuidadosamente após alterar os modos de armazenamento, especialmente aqueles que envolvem USERELATIONSHIP, CROSSFILTER, CALCULATE com funções de filtro relacionadas ao relacionamento e agregações em tabelas relacionadas.

---

Tabelas de agregação: o padrão do modelo composto principal

O padrão de modelo composto mais valioso combina uma grande tabela de fatos do DirectQuery com uma tabela de agregação no modo de importação que pré-resume os dados em uma granularidade mais alta.

O problema: uma tabela de fatos de vendas com 500 milhões de linhas no DirectQuery é muito grande para ser consultada interativamente pela maioria dos sistemas de origem. Cada gráfico leva mais de 10 segundos enquanto a origem executa consultas agregadas caras.

A solução: crie previamente uma tabela de resumo que agregue o fato a uma granulação diária/mensal/de categoria de produto e importe essa tabela de resumo para o Power BI. A maioria das consultas (que são mensais, trimestrais ou de categoria) atingem a agregação de importação rápida. Somente consultas que detalham o nível de transação individual voltam para o DirectQuery.

Configurando agregações:

Primeiro, crie a tabela de agregação no seu data warehouse:

CREATE TABLE SalesByDayProduct AS
SELECT
    SaleDateKey,
    ProductKey,
    CustomerSegmentKey,
    RegionKey,
    SUM(SalesAmount) as SalesAmount,
    SUM(Quantity) as Quantity,
    SUM(Cost) as Cost,
    COUNT(*) as TransactionCount
FROM FactSales
GROUP BY SaleDateKey, ProductKey, CustomerSegmentKey, RegionKey;

Importe esta tabela para o Power BI e defina o modo de armazenamento como Importar.

Em seguida, configure a agregação no Power BI:

• Clique com o botão direito em SalesByDayProduct → Gerenciar agregações
• Mapeie cada coluna para seu relacionamento com a tabela de detalhes e a função de resumo (Soma, Média, Contagem, etc.)
• Defina a coluna "Summarization" (SalesAmount → Sum mapeia para FactSales[SalesAmount] → Sum)

O mecanismo de consulta do Power BI agora roteia consultas automaticamente para a tabela de agregação quando possível e retorna à tabela de detalhes do DirectQuery somente quando a consulta exige detalhes em nível de linha que a agregação não fornece.

O resultado do desempenho é dramático: agregações em nível de categoria e em nível de tempo que antes demoravam 15 segundos agora retornam em menos de 1 segundo, enquanto a opção de detalhar transações individuais permanece disponível.

---

DirectQuery para conjuntos de dados do Power BI

O Power BI introduziu o DirectQuery para conjuntos de dados do Power BI (também chamado de "conexão ativa com modelos compostos" ou simplesmente "modelos compostos em conjuntos de dados compartilhados"). Isso permite que um desenvolvedor crie um novo relatório ou conjunto de dados que use um conjunto de dados existente do Power BI publicado como fonte do DirectQuery, ao mesmo tempo que adiciona novas tabelas, medidas calculadas e dados de importação local.

Caso de uso principal: uma organização possui um modelo semântico empresarial certificado que abrange os principais dados financeiros e de vendas. Uma equipe que trabalha em uma análise específica precisa adicionar alguns dados locais (um arquivo CSV com códigos de projeto, um arquivo Excel com metas) sem modificar o modelo empresarial certificado. Usando conjuntos de dados do DirectQuery para Power BI, eles criam um modelo composto que faz referência ao modelo empresarial por meio do DirectQuery e adiciona suas tabelas locais como dados de importação.

Isso permite uma arquitetura de análise governada onde:

• A equipe central de dados mantém conjuntos de dados empresariais certificados
• As equipes de negócios ampliam esses conjuntos de dados com contexto local sem criar modelos separados e inconsistentes
• O modelo empresarial continua sendo a única fonte de verdade para métricas compartilhadas

Limitações: o DirectQuery para conjuntos de dados do Power BI herda todas as limitações do DirectQuery normal: algumas funções DAX são restritas, a segurança em nível de linha deve ser configurada corretamente para propagação por meio do modelo composto, e a conexão com o conjunto de dados de origem adiciona uma camada de processamento de consulta.

---

Otimização de desempenho para modelos compostos

Os modelos compostos exigem um ajuste de desempenho mais cuidadoso do que os modelos de importação puros. As seguintes otimizações são mais impactantes:

Reduza consultas entre modos: cada passagem de relacionamento que cruza um limite de modo de armazenamento adiciona latência. Minimize-os mantendo as tabelas de dimensão no modo Dual (elas podem servir consultas de importação e DirectQuery sem uma travessia entre modos) e estruturando o modelo para que a maioria das consultas permaneça em um único modo.

Pré-agregar na origem: não peça à origem do DirectQuery para fazer agregações que o Power BI poderia fazer com mais eficiência. Crie visualizações ou visualizações materializadas no banco de dados de origem que pré-agreguem na granularidade que seus relatórios realmente precisam.

Monitore o plano de consulta com o Performance Analyzer: no Power BI Desktop, Exibir → Performance Analyzer registra o tempo gasto para cada consulta DAX do visual e a consulta de origem subsequente (se DirectQuery). Isso revela quais elementos visuais são lentos e se a consulta lenta está na camada DAX ou na camada de consulta de origem.

Usar configurações de redução de consulta: Em Power BI Desktop → Opções → Redução de consulta, habilite opções para adicionar botões Aplicar a segmentações de dados e filtros. Isso evita que cada interação de segmentação dispare imediatamente uma consulta de origem, o que é particularmente importante para relatórios do DirectQuery, onde cada consulta tem latência de execução de rede e de origem.

Limite o número de conexões DirectQuery: cada origem DirectQuery diferente em um modelo composto cria um pool de conexões separado. Limite a 1–2 fontes DirectQuery sempre que possível; mais de 3 aumenta significativamente a complexidade do modelo e possíveis problemas de desempenho.

---

Segurança em nível de linha em modelos compostos

A segurança em nível de linha (RLS) em modelos compostos requer um planejamento cuidadoso, principalmente quando a RLS é definida em uma tabela de importação que tem um relacionamento com uma tabela do DirectQuery.

Quando um usuário com um filtro RLS consulta um relatório, o Power BI aplica o filtro à tabela apropriada. Se a tabela filtrada estiver no modo de importação e tiver um relacionamento com uma tabela do DirectQuery, o Power BI deverá converter o filtro de importação em um filtro que possa ser enviado para a origem do DirectQuery. Isso funciona na maioria dos casos, mas pode produzir resultados inesperados com hierarquias de filtros complexas.

Prática recomendada: defina RLS nas tabelas de dimensões do modo de importação (não nas tabelas de fatos do DirectQuery). O filtro se propaga de dimensão para fato por meio do relacionamento — que funciona de maneira confiável. Definir RLS diretamente nas tabelas do DirectQuery é possível, mas é mais difícil de testar e depurar.

Para modelos compostos que usam conjuntos de dados do DirectQuery for Power BI, o RLS definido no conjunto de dados de origem é aplicado automaticamente quando esse conjunto de dados é consultado. RLS adicionais podem ser definidos na camada do modelo composto. Essa abordagem de RLS em camadas requer testes cuidadosos para garantir que os filtros sejam compostos corretamente.

---

Perguntas frequentes

Posso misturar dados de plataformas de banco de dados completamente diferentes em um modelo composto?

Sim. Um modelo composto pode conter tabelas do SQL Server (DirectQuery), do Salesforce (DirectQuery), de um arquivo do Azure Blob Storage (Import) e do Snowflake (DirectQuery) simultaneamente. Cada fonte mantém sua própria conexão. Os relacionamentos entre tabelas de fontes diferentes devem ter pelo menos uma tabela de modo duplo para facilitar junções de fontes cruzadas. O desempenho e a complexidade aumentam com cada fonte adicional – limitar a 2 a 3 fontes é prático para a maioria das implementações.

Quais funções DAX não funcionam em modelos compostos?

Algumas funções DAX são restritas ou se comportam de maneira diferente em modelos compostos com tabelas DirectQuery. As funções que não funcionam com relacionamentos limitados incluem SUMMARIZE (em determinados contextos), TOPN (em tabelas DirectQuery) e algumas funções de inteligência de tempo. USERELATIONSHIP funciona, mas pode causar consultas entre modos. A lista completa de limitações está documentada na documentação do Power BI da Microsoft em "Limitações do DirectQuery". É altamente recomendável testar todas as medidas críticas após adicionar tabelas do DirectQuery.

Como funciona a atualização incremental com modelos compostos?

A atualização incremental se aplica a partições no modo de importação em um modelo composto. As tabelas configuradas como DirectQuery não usam atualização incremental — elas consultam a origem em tempo real em cada interação. A combinação mais comum é usar atualização incremental em partições históricas no modo de importação e ter DirectQuery para os dados do período atual — esse é o recurso de tabelas híbridas, que é uma forma específica de modelagem composta em uma única tabela.

Qual é o impacto no desempenho dos modelos compostos versus importação pura?

Os modelos compostos com componentes do DirectQuery sempre serão mais lentos que os modelos de importação puros equivalentes para consultas equivalentes. A lacuna de desempenho depende do desempenho do sistema de origem e da proporção de consultas que atingem o DirectQuery versus partições de importação. Com tabelas de agregação bem projetadas, a maioria das consultas dos usuários atinge a agregação de importação e retorna em menos de 1 segundo, tornando o desempenho aceitável. As consultas que detalham o DirectQuery podem levar de 3 a 15 segundos, dependendo do desempenho da origem.

Devo usar modelos compostos ou apenas agendar atualizações mais frequentes?

Atualizações mais frequentes (a cada 15 minutos para o modo de importação) são suficientes para a maioria dos casos de uso em que "quase em tempo real" é aceitável. Os modelos compostos com DirectQuery adicionam complexidade significativa — use-os somente quando: (a) você precisar de dados que sejam genuinamente atuais em minutos ou segundos, (b) o conjunto de dados for muito grande para ser atualizado dentro da janela disponível, mesmo com atualização incremental, ou (c) você precisar combinar dados de fontes que não podem ser consolidados em uma única atualização de warehouse.

---

Próximas etapas

Os modelos compostos são uma ferramenta poderosa para arquiteturas sofisticadas do Power BI, mas exigem um design cuidadoso para evitar armadilhas de desempenho e correção. As implementações mais bem-sucedidas utilizam modelos compostos para cenários específicos e justificados, em vez de uma arquitetura padrão.

Os serviços de modelagem de dados do Power BI da ECOSIRE incluem design de modelo composto, implementação de tabela de agregação e otimização de desempenho. Entre em contato conosco para avaliar se os modelos compostos são a solução certa para seus requisitos específicos de atualização de dados e desempenho.