Como usar modelo composto (composite) no Power BI: passo a passo

Você precisa de dado em tempo quase real sem abrir mão da velocidade do import#

Chega uma hora em que os dois mundos do Power BI entram em conflito. De um lado, você quer a velocidade do modo import, que carrega tudo em memória e responde ao clique em milissegundos. Do outro, você tem uma tabela gigante ou um dado que muda o tempo todo, e não dá para trazer aquilo inteiro para dentro do arquivo nem esperar o refresh completo. O modelo composto (composite) Power BI existe para resolver justamente esse impasse: ele deixa você misturar tabelas em import com tabelas em DirectQuery no mesmo modelo, cada uma no modo que faz sentido.

Na prática, isso significa que suas dimensões pequenas e estáveis ficam em memória, rápidas, enquanto a tabela fato de bilhões de linhas continua no banco de origem, consultada sob demanda. Ou o contrário: o histórico fechado fica em import, e só o dado quente do dia bate direto na fonte. É uma ferramenta poderosa, e como toda ferramenta poderosa, ela machuca quem usa sem entender o que está acontecendo por baixo.

Este é um tutorial direto. Vou mostrar quando o modelo composto vale a pena, o passo a passo para configurar no Power BI Desktop, os erros que mais derrubam esse tipo de projeto e as boas práticas que a gente aplica em ambiente real. Sem prometer que composite resolve tudo, porque não resolve.

O modelo composto combina modos de armazenamento, não elimina o trade-off#

Antes de sair configurando, entenda o conceito. Todo modelo do Power BI guarda cada tabela em um de três modos de armazenamento (storage mode):

• Import: a tabela é copiada para dentro do modelo, comprimida em memória pelo motor VertiPaq. É o mais rápido, mas o dado é uma fotografia do último refresh.
• DirectQuery: nada é copiado. Cada visual gera uma consulta que vai até a fonte no momento em que você clica. O dado é sempre atual, mas a resposta depende do banco e da rede.
• Dual: a tabela pode se comportar como import ou como DirectQuery, dependendo do que o visual precisa. O motor decide na hora. Esse modo só existe por causa do modelo composto e é a peça que faz tudo funcionar bem.

O modelo composto é simplesmente um modelo que contém tabelas em mais de um desses modos ao mesmo tempo. Ele não é mágica: você continua pagando o preço do DirectQuery onde escolheu usá-lo. O ganho é poder escolher onde pagar esse preço em vez de aplicar o mesmo modo à base inteira.

Vale reforçar uma coisa que muita gente confunde. Composite não deixa o DirectQuery mais rápido por si só. O que acelera é a combinação certa de storage modes com agregações e com dimensões em memória. O modelo composto é o que torna essa combinação possível.

Quando usar modelo composto e quando não usar#

Composite não é o modo padrão que você escolhe por conforto. Ele adiciona complexidade real ao projeto, então precisa ter justificativa. Estes são os cenários em que ele ganha:

Cenário	Modelo composto ajuda?
Tabela fato enorme que não cabe em memória, com dimensões pequenas	Sim, fato em DirectQuery e dimensões em import ou dual
Necessidade de dado quase em tempo real só em parte do modelo	Sim, tabela quente em DirectQuery, resto em import
Enriquecer um dataset publicado com dados locais do analista	Sim, é o caso do composite sobre modelo semântico
Acelerar DirectQuery com pré-agregados	Sim, DirectQuery no detalhe e agregação em import
Modelo pequeno que cabe tranquilo em import	Não, use import puro e evite complexidade
Fonte lenta que você quer só como import	Não, importe e pronto

O primeiro caso é o clássico: você tem uma fato com centenas de milhões ou bilhões de linhas em um banco relacional ou em um Lakehouse, e trazer tudo para import é inviável. Você deixa a fato em DirectQuery e as dimensões em dual, para que filtros e slicers respondam rápido usando a cópia em memória.

O terceiro caso ganhou força com o recurso de composite sobre modelos semânticos publicados. Um analista pode pegar o dataset corporativo, mantê-lo por DirectQuery, e adicionar a própria planilha de metas por cima, tudo no mesmo modelo. Isso é ótimo para self-service governado, mas exige atenção com segurança e governança, assunto que tratamos em governança de dados no Power BI e LGPD.

Se o seu modelo cabe em import sem dor, fique no import. Composite existe para quando o import puro não é possível ou não atende, não para deixar a arquitetura mais sofisticada no papel.

Passo a passo para configurar um modelo composto#

Vou usar o cenário mais comum: dimensões em import e uma fato grande em DirectQuery. O caminho no Power BI Desktop é este.

Passo 1: conecte a fato em DirectQuery#

Ao conectar na fonte pelo Obter Dados, na tela de conexão o Power BI oferece dois modos para fontes que suportam DirectQuery: Importar e DirectQuery. Escolha DirectQuery para a tabela fato. Se a fonte não oferecer essa opção (arquivos Excel, CSV e alguns conectores só permitem import), então composite clássico não se aplica àquela tabela.

Passo 2: traga as dimensões em import#

Conecte as tabelas de dimensão (calendário, produto, cliente, loja) e escolha Importar. São tabelas pequenas, estáveis, e você quer elas em memória para que filtros voem. Neste ponto você já tem um modelo composto: uma tabela em DirectQuery e várias em import.

Passo 3: ajuste o storage mode das dimensões para Dual#

Vá na visão de Modelo, clique em cada dimensão e, no painel de propriedades, mude o Modo de armazenamento de Import para Dual. Dual é quase sempre a escolha certa para dimensões em um composite. Com dual, quando o visual só toca a dimensão, o motor usa a cópia em memória; quando o visual cruza a dimensão com a fato em DirectQuery, ele consegue empurrar o join para a fonte, evitando trazer chaves demais para memória. Esse detalhe é o que separa um composite rápido de um lento.

Passo 4: crie os relacionamentos#

Monte o esquema estrela normalmente, ligando cada dimensão à fato pela chave. Prefira relacionamentos um para muitos, coluna numérica inteira quando possível. Relacionamento sobre texto e relacionamento muitos para muitos custam caro em DirectQuery. Se você não tem uma tabela de datas dedicada, crie uma, porque time intelligence sobre DirectQuery sem uma boa dimensão calendário vira sofrimento. Falo mais sobre modelagem em modelagem e boas práticas de DAX no Power BI.

Passo 5: valide o comportamento com o Performance Analyzer#

Ligue o Analisador de Desempenho, interaja com os visuais e observe quais geram consultas DirectQuery e quanto demoram. O objetivo é confirmar que os visuais mais usados respondem em tempo aceitável e que o motor está usando as tabelas em memória onde deveria. Se um visual simples de dimensão está gerando consulta na fonte, algo no storage mode está errado.

Passo 6 (opcional): adicione agregações#

Se a fato em DirectQuery está lenta nos totais, crie uma tabela de agregação em import com o dado pré-somado por dia, produto e loja, por exemplo. O Power BI redireciona automaticamente as consultas de granularidade alta para a agregação em memória e só desce ao DirectQuery quando precisa do detalhe. Essa combinação de DirectQuery no detalhe com agregação em import é uma das razões mais fortes para usar composite.

Os erros que mais derrubam um modelo composto#

Depois de ver vários projetos com composite mal configurado, esses são os erros que mais aparecem.

Deixar as dimensões em import puro em vez de Dual. É o erro número um. Com a dimensão em import e a fato em DirectQuery, todo cruzamento força o motor a mandar a lista de chaves para a fonte, o que gera consultas enormes e lentas. Dual resolve porque permite ao motor escolher o lado certo em cada consulta.

Tratar composite como se fosse import. As pessoas esquecem que parte do modelo está em DirectQuery e escrevem DAX pesado, com muitas iterações e funções que não folgam bem para a fonte. O que voa em import pode rastejar em DirectQuery. Toda medida sobre a fato precisa ser pensada com a limitação da fonte em mente.

Fonte de dados lenta ou sem índices. DirectQuery devolve para o banco a responsabilidade de responder rápido. Se o SQL Server ou o Lakehouse por trás está sem índice, sem partição e sem tuning, o composite herda essa lentidão inteira. Antes de culpar o Power BI, olhe o plano de execução na fonte. Esse trabalho é típico de um projeto de engenharia de dados.

Ignorar limitações de DAX no DirectQuery. Nem toda função DAX está disponível ou é eficiente sobre tabelas DirectQuery. Algumas caem em avaliação linha a linha custosa. O Power BI avisa em alguns casos, mas não em todos. Teste com volume real, nunca com uma amostra pequena que esconde o problema.

Não pensar em segurança do dado. Em composite sobre modelo semântico publicado, as regras de RLS e permissões da fonte continuam valendo e podem se combinar de formas inesperadas. É fácil abrir ou fechar acesso sem perceber. Valide quem enxerga o quê antes de publicar.

Boas práticas para composite em produção#

Prática	Por que importa
Dimensões em Dual, fato em DirectQuery	Deixa o motor empurrar joins e usar memória onde dá
Tabela de datas dedicada em import ou dual	Time intelligence sobre DirectQuery depende disso
Agregações em import sobre a fato DirectQuery	Acelera totais sem perder o detalhe atual
Reduzir cardinalidade das chaves de join	Chave inteira é mais barata que texto em DirectQuery
Tunar a fonte antes de acusar o Power BI	O DirectQuery só é rápido se o banco for rápido
Testar com volume de produção	Amostra pequena esconde a lentidão real
Monitorar com Performance Analyzer e log da fonte	Você precisa ver onde a consulta está indo

Uma última recomendação de arquitetura. Antes de decidir por composite, pergunte se a resposta não é simplesmente uma modelagem melhor ou o uso de recursos mais novos como o Direct Lake do Fabric, que em muitos casos entrega velocidade de import com dado fresco sem a complexidade do composite tradicional. Vale entender esse cenário no guia sobre o Microsoft Fabric. Composite continua sendo a escolha certa em muitos casos, mas nem sempre é a mais simples.

Perguntas frequentes#

Qual a diferença entre modelo composto e DirectQuery puro? No DirectQuery puro todas as tabelas ficam na fonte e nada é copiado para memória. No modelo composto você mistura: algumas tabelas em import ou dual, em memória, e outras em DirectQuery. Isso permite ter a velocidade do import nas dimensões e a atualidade do DirectQuery na fato, coisa que o DirectQuery puro não oferece.

O que é o modo de armazenamento Dual e por que ele importa tanto? Dual é um modo em que a tabela pode agir como import ou como DirectQuery conforme a consulta. Ele existe por causa do composite e é o que permite ao motor usar a cópia em memória quando o visual só toca a dimensão, e empurrar o join para a fonte quando o visual cruza com uma fato em DirectQuery. Sem dual, as dimensões em import forçam consultas lentas na fonte.

Modelo composto deixa o DirectQuery mais rápido? Não por si só. O que acelera é a combinação de storage modes bem escolhidos, dimensões em memória e agregações pré-calculadas. O composite é o que torna essa combinação possível, mas se você apenas colocar a fato em DirectQuery sem cuidar do resto, vai sofrer com lentidão igual.

Posso usar composite sobre um dataset já publicado no Power BI Service? Sim. O recurso de composite sobre modelos semânticos permite conectar em DirectQuery a um dataset publicado e adicionar por cima suas próprias tabelas locais. É ótimo para self-service, mas exige atenção redobrada com segurança em nível de linha e permissões, porque as regras da fonte e do seu modelo se combinam.

Quando eu deveria evitar o modelo composto? Quando o modelo cabe tranquilo em import puro. Composite adiciona complexidade de configuração, teste e manutenção. Se você não tem uma tabela grande demais para a memória nem necessidade real de dado quase em tempo real, fique no import, que é mais simples, mais rápido e mais previsível.

Composite funciona com qualquer fonte de dados? Não. A parte em DirectQuery só funciona com fontes que suportam DirectQuery, como bancos relacionais, Lakehouse, Warehouse e alguns serviços. Arquivos como Excel e CSV só existem em import. Você pode ter essas tabelas em import dentro de um composite, mas não colocá-las em DirectQuery.

Fechando#

O modelo composto é uma das ferramentas mais úteis do Power BI para quem esbarra no limite da memória ou precisa de dado fresco em parte do modelo, desde que usado com critério. O segredo está no básico bem feito: dimensões em dual, fato em DirectQuery, agregações onde a fonte pesa e uma modelagem estrela limpa. Ignore isso e o composite vira o gargalo em vez da solução. Respeite e você ganha o melhor dos dois mundos.

Se a sua arquitetura de Power BI está ficando complexa demais para resolver sozinho, seja por volume, por performance ou por governança, a gente pode ajudar a desenhar a solução certa. Conheça nossos serviços de Power BI ou fale com a gente para um diagnóstico do seu ambiente.